Token Efficiency Is Not Factory Efficiency

Token efficiency matters. If two workers produce the same useful result and one consumes less computation, the cheaper worker has earned the route. Better quality from a smaller budget can make tasks practical that were wasteful a release ago. That changes what a factory can afford to run and how often it can run it.

But a token is an input to the line, not a unit of completed work. Customers do not buy tokens. Your repository does not accept tokens. Production does not stay healthy because a model formed a concise answer. The business receives value only when a change satisfies the requirement, survives verification, ships inside its authority, and keeps working after release.

Confusing those units creates a wonderfully cheap machine for producing unfinished inventory. The dashboard celebrates lower consumption while retries, review queues, escaped defects, and human rescue keep the real bill off-screen.

The useful denominator is accepted work. Start with everything the factory spent to get there: planning, retrieval, model calls, tool use, verification, failed attempts, escalation, deployment, and recovery. Then divide by the changes that actually cleared the gates. That is a production measure. Cost per generated answer is only a receipt from one station.

A compact response can be expensive when it leaves out a boundary the verifier has to rediscover. A longer planning run can be cheap when it prevents three broken implementations. A low-cost model can own a mechanical transformation and lose money on an ambiguous migration. None of those outcomes is visible if the accounting stops when generation stops.

This is why averages mislead. Different stations produce different artifacts and carry different consequences. Measure them separately. The least expensive accepted plan, accepted patch, accepted review, and accepted release may come from four different routes.

Efficiency claims always depend on what counts as good enough. A score can show that a model reached a target with fewer tokens under a fixed evaluation. That is useful evidence about the model. It does not define the target your production system should accept.

Your factory needs its own gate before it can price the result. The requirement must be executable enough to judge. Tests must attack the boundaries that matter. State changes need an independent readback. Permission changes need proof through routes the builder did not choose. If the worker controls the demonstration, the cost calculation is pricing confidence instead of completed work.

Rejected output belongs in the bill. So does output that passes a shallow check and returns as an incident. Leaving either out rewards the route for pushing cost downstream, where it becomes harder to connect to the decision that caused it.

Once the factory measures accepted work, token efficiency becomes actionable. Give each station a budget tied to consequence. Let routine, reversible work start on the cheapest route that has repeatedly passed. Give ambiguous or high-authority work more room to reason. Escalate because a known condition fired, not because somebody happened to notice the agent struggling.

The limit has to change the system. When a run crosses it, stop, narrow the task, retrieve better context, switch workers, or ask for the human decision the machinery cannot make. A budget that only triggers an alert after spending continues is not a control. It is an explanation of the invoice.

Preserve the evidence by route. Models, prices, and capabilities will keep changing. If the factory knows what each station accepted, rejected, consumed, and returned from production, a new worker can audition against real work without forcing the organization to restart the argument every month.

Our position is that model efficiency will keep improving and will make agent-run delivery cheaper. It will also erase jobs as more repeatable work becomes economical to automate. But the companies that capture that advantage will not be the ones with the smallest token counter. They will be the ones that turn lower model cost into more accepted work without lowering the standard.

People still choose the destination, define the consequences, and decide what proof deserves authority. They should not spend their time manually rescuing cheap attempts or comparing usage charts that never reach the release. Once a routing choice becomes repeatable, the factory should own it.

Measure tokens because they cost money. Measure retries because they expose weak routes. Measure proof because it separates output from work. Then optimize the whole line around the only result the business can use: software that earned its way into production.