The model is a component, not the product

Before Miton, I was using Claude Code and other terminal agents, Cursor and the growing collection of AI editors. They are useful tools. They also made the missing layer obvious: the model was often treated as the product, while the project, provider choice, cost and recovery story stayed scattered around it.

The market has a version of the same problem. Thin wrappers receive venture pricing. Token bundles hide their margin. Lock-in is dressed up as integration. I would rather build the part that remains useful when the provider changes.

Model releases create a peculiar kind of amnesia. A benchmark moves, a context window grows and the industry briefly pretends that all the difficult product work has been solved by an API name.

The model matters enormously. It is still a component.

A model does not know which files it may change. It does not decide whether old tool output deserves another thousand tokens. It does not preserve the project’s goals when the user moves from a conversation to a document. It does not choose a cheaper eligible model for a routine classification, store a provider key safely or give somebody a way back after a bad edit.

Those are system decisions. They determine whether intelligence becomes work.

The belief behind Miton is unfashionably simple: the model is a component. Local models deserve real work, cheap models are often enough, and open source is not a staffing plan. The capability is already cheap. What matters is what the technology is for, and whether the person using it can turn that capability into durable work.

Miton treats models as a changing field of capabilities, prices and constraints. Routing begins with the boundaries the user selected, then scores eligible choices for the task. Context is shaped to the model rather than dumped indiscriminately. Costs and cache behaviour are visible. When a task would benefit from a stronger model, the suggestion should explain the trade rather than silently upgrade the bill.

This approach ages better than building a product identity around one provider. The decision to use a multi-provider gateway was a rejection of the simpler single-vendor default: it costs more adapter, capability and failure-handling work, but it prevents one provider’s prices, limits or policy from becoming the product boundary. The free path consequently aggregates providers rather than making Miton subsidise inference or hiding a token margin.

Adding providers exposed the real work. Adapters disagree about streaming and tool dialects; capability flags cannot be assumed; local models vary in native tool support; and fallback behaviour must distinguish a provider outage from a model that cannot perform the task. ADR-0206 records the resulting contract: native tools are preferred, while models without them can use fenced prompt-based tools with reduced fidelity and honest limits.

That choice matters because excluding every model without native tools would make local inference a checkbox rather than a real path. A compatible harness can give a smaller model compact context, the tools it can actually use and a task it has a reasonable chance of completing.

Benchmarks reinforce the point. A cheap model landing close to the frontier is not an argument that all models are interchangeable. It is an argument against paying frontier prices by reflex. Routing should ask what the task needs, what the user permits and what the evidence says.

Today’s frontier model becomes tomorrow’s sensible default. A small local model becomes unexpectedly good at a narrow tool protocol. A provider changes its cache economics. The harness should absorb those changes and make every connected model more useful.

The durable product is therefore the project system: the permissions, routing, memory, tools, workspaces, recovery and evidence that surround generation. Models improve in jumps. A good harness compounds each jump.