A Cheaper Model Is a Routing Signal

Model prices are moving quickly enough to make every static buying decision look old. A provider cuts a rate, another changes its cache terms, and a third puts a capable model beneath yesterday's budget tier. The tempting response is to pick the new winner and start moving everything toward it.

That is procurement thinking applied to a production system. A lower token rate tells you what one input costs. It does not tell you how many attempts a task will take, how much context the model will reread, how often its work will fail a gate, or what recovery will cost after a bad change escapes. The cheapest call can still produce the most expensive accepted result.

A software factory needs a different response. Treat every price change as a routing signal. It may justify sending more work down one lane, but only after the work survives the same evidence standard as every other lane.

There is no useful answer to which model is best in the abstract. One model may handle a narrow transformation reliably and stumble on an ambiguous migration. Another may be wasteful for routine edits but earn its cost when a failure crosses a security or data boundary. A leaderboard compresses those jobs into one score. Your factory has to separate them again.

Start with classes of work you can actually describe: dependency updates, interface changes, test repair, incident diagnosis, specification review, or a release decision. Give each class an acceptance contract. Then record the total path to an accepted result: attempts, context consumed, verification failures, escalations, and recovery. That is the number the router can use.

The model's name is not the policy. The task, its consequence, and the evidence required to finish it are the policy. This keeps a launch announcement from becoming an architecture migration before your own system has learned anything.

Routing inexpensive work to an inexpensive model is sensible. Leaving it there after the evidence turns bad is not. The cheap lane needs explicit exit conditions: repeated gate failures, missing context, an unresolved authority question, a high-consequence boundary, or a budget that has already been burned on retries.

When one of those conditions appears, the factory should escalate mechanically. It can add context, switch models, narrow the task, or route a decision to the person who owns the consequence. What it should not do is let an agent keep guessing because the next call looks cheap on a rate card.

This is where factories beat manual model selection. A person choosing from a dropdown sees the advertised price and a familiar brand. A governed router sees the history of this task class, the current budget, the failed evidence, and the cost of being wrong. It can make the boring economic decision every time without turning that decision into another meeting.

Falling model prices are good news, but not because they crown a permanent winner. They make more routes economically viable. A task that once required the premium lane may now run cheaply by default and escalate only when proof fails. A verification pass that once looked extravagant may now cost less than the human coordination it replaces.

That leverage compounds only when the factory owns the interface. Specifications, tools, permissions, evidence, and acceptance gates must survive a model swap. If changing providers means rewriting the operating process by hand, you do not have routing. You have a dependency wearing an abstraction layer.

Our prediction is that model margins will keep getting squeezed while the value moves into the system that assigns work and judges the result. The winning organization will not be the one that guessed the cheapest provider this quarter. It will be the one that can exploit a cheaper option the day it earns authority and remove it the day it stops earning it.

Pick one repeatable class of work and run it through two controlled lanes. Keep the destination, tools, permissions, and acceptance tests fixed. Measure the full cost of accepted work, including retries and escalation. Then let the router send the next job according to what happened, not according to which launch made the loudest entrance.

Human judgment still sets the consequence. People decide which failures are tolerable, which work may use the cheap lane, and what evidence earns promotion into a broader route. They should not manually assign every routine task or compare rate cards before every run. That is repeatable coordination, and repeatable coordination belongs in the machinery.

The model market will keep moving. Good. Let it. A factory with durable controls turns that volatility into leverage. Every lower price becomes an opportunity to test a new route, and every failed route becomes evidence the system remembers. The price changed. Your standards did not.