The Price Card Is Not the Bill

Model economics are usually presented as a clean unit price. That number is real, but it belongs to the supplier's meter, not your production system. Your business does not earn anything when a model consumes input or produces output. It earns something when a requested change is correct, accepted, released, and still working after reality gets a vote.

The distance between those two events contains the actual bill. Context has to be assembled. Tools have to run. Failed attempts have to be retried or replaced. Another system has to verify the result. A person may have to resolve ambiguity. A release can fail and demand recovery. None of that disappears because the first model call looked inexpensive.

Our position is simple: cost per token is a purchasing input. Cost per independently accepted outcome is the operating metric. Confusing them is how a cheap demo becomes an expensive department.

A more capable route may spend more during the build and less everywhere around it. Better decomposition can shrink the search space. Better tool selection can avoid dead ends. Better awareness of repository constraints can prevent a plausible change from arriving at review already broken. The expensive call may remove three cheap calls, a repair pass, and an interruption for the person who owns the decision.

The reverse happens too. Paying for the strongest available reasoning on a narrow, reversible change can waste money without changing the outcome. A deterministic edit with a deterministic gate does not need heroic inference. It needs a bounded worker, the right context, and proof that the artifact satisfies the contract.

This is why a single model winner is the wrong procurement goal. Work has different ambiguity, consequence, reversibility, and proof. The factory should match the route to those properties before the meter starts.

Large context windows make it possible to send more material. They do not make sending more material wise. Dumping a repository, a ticket history, tool transcripts, and every prior decision into each run charges the model to rediscover structure your factory should already know. It also gives stale assumptions and irrelevant detail more opportunities to steer the work.

Build context the way you build an interface. Give the worker the approved objective, the constraints that apply to its scope, the evidence it needs, and the tools it may use. Store durable state outside the conversation. Retrieve additional material when the work establishes a reason for it. Every token should have a job; capacity is not a command to fill it.

Good context engineering reduces cost twice. It lowers consumption, and it improves the chance that the first completed attempt survives verification. The second saving is usually the one that matters.

A governed factory classifies work before choosing a model. Is the request clear? Can failure be reversed? Does the change touch a sensitive boundary? Can acceptance be proved mechanically? How much human judgment would a wrong answer consume? Those questions turn model selection from brand preference into policy.

Send low-consequence, mechanically provable work down a lean route. Escalate ambiguous or consequential work to stronger reasoning, narrower authority, and tougher verification. Set budgets for attempts, tool calls, and context expansion. When a route exhausts its budget, change the conditions or escalate; do not let it purchase more confidence by repeating itself.

Keep the interface stable while the workers change behind it. Models will get cheaper, stronger, and stranger. A factory with explicit routing and evidence can test a new option against known work without rebuilding delivery around a leaderboard headline.

For each class of work, record the complete route: planning, context assembly, model calls, tool use, retries, verification, human intervention, release, and recovery. Divide that cost by outcomes that passed independent acceptance, not attempts that reached a fluent conclusion. Keep rejected work in the record. Failure is part of the economics, even when the vendor invoice labels it usage.

Then optimize the system instead of arguing about the engine. A costly route that consistently clears a dangerous boundary may deserve its place. A cheap route that handles routine changes cleanly should absorb more volume. A route that consumes human attention or repeatedly fails proof should lose work, however attractive its unit price looks.

Software factories will not win because they found one model with the lowest posted rate. They will win because they know what each outcome truly costs and can change the route when the evidence changes. The price card starts the calculation. The factory closes it.