2026-08-08

The Token Bill Is a Value Gate

Software teams have spent years treating the cost of another feature as a staffing conversation. Agents make the meter visible on every run, and that forces the better question: was this change worth producing at all?

Usage is not a return

A company can buy AI tools, distribute seats, watch usage rise, and still have no idea whether the investment improved the business. Logins prove access. Model calls prove consumption. Neither proves that a customer problem was solved, a risk was removed, or an operating constraint changed.
The same mistake appears inside software delivery. Teams celebrate generated pull requests, shorter coding sessions, and a growing volume of automated work. Those signals may describe motion, but motion is not value. A factory can produce the wrong feature faster, retry a weak specification twenty times, and spend less than a human team while still destroying money efficiently.
Our position is that the token bill is useful precisely because it refuses to stay abstract. Each run consumes something countable. Once the machine has a meter, leaders can no longer hide every request inside a fixed payroll and call the resulting queue a strategy.

Price the route, not the prompt

The model call is not the unit of production. A change moves through discovery, specification, implementation, evaluation, release, and production watching. It may trigger retrieval, tool calls, retries, independent checks, infrastructure, and human decisions. Measuring only generation cost rewards routes that push failure into another stage.
Attach cost to the whole route. Record what it took to clarify the request, build the artifact, prove it somewhere the generating agent did not control, release it, and respond when reality disagreed. Include failed attempts. Include the expensive model that rescued a cheap model's weak output. Include human intervention instead of treating it as free capacity.
Then connect that route to an outcome the business actually owns. A feature should name the behavior it intends to change. A fix should name the consequence it prevents. An optimization should name the constraint it releases. If nobody can state the destination, the factory should not manufacture activity on faith.

Value belongs before build

Most delivery systems ask whether work is worth doing once the work is already underway. By then a proposal has accumulated meetings, status, and political ownership. Cancellation feels like waste, so the team finishes the thing to defend what it has already spent.
An agent-run factory can move the decision upstream. Before implementation, require a named outcome, an acceptable cost range, evidence that the problem exists, and a decision owner who accepts the trade. The threshold can be rough. The discipline cannot. Uncertainty written down is governable; enthusiasm disguised as certainty is not.
This does not mean reducing every product decision to immediate revenue. Reliability, security, learning, and strategic options can be valuable without a clean sales number. But somebody must say which value is being purchased and what evidence would show that the bet was wrong. Long-term value still needs an owner and a testable claim.

The loop makes cost useful

A cost record becomes powerful when production evidence returns to the next decision. If customers ignore the feature, the factory should retain that result beside the specification that justified it. If a fix eliminates a recurring failure, that evidence should sharpen the next estimate. If verification repeatedly costs more than implementation, the route has exposed where the machinery needs work.
That feedback changes planning from negotiation into portfolio control. Leaders can compare classes of work by the outcomes they produced and the complete cost of producing them. The factory can route routine changes through lean machinery, reserve expensive capability for consequential uncertainty, and stop patterns that repeatedly consume more than they return.
The model will not make those value judgments for you. Human decision owners choose the destination, the acceptable consequence, and the time horizon. The machinery preserves those choices, meters execution, and brings back evidence without waiting for someone to assemble a quarterly story from disconnected dashboards.

Software joins the rest of the business

Factories will make code cheaper. They will also make weak demand easier to expose. When the marginal act of building stops consuming a human sprint, the scarce resource becomes the organization's willingness to spend machine capacity, attention, and risk on one outcome instead of another.
That shift will eliminate work that survived because its cost was buried inside headcount and its purpose was protected by process. Backlogs full of inherited requests, ornamental improvements, and fixes nobody can connect to a consequence will face a gate they should have faced years ago. Some current coordination and prioritization roles will disappear with them because the factory can enforce the decision record mechanically.
This is not a reason to fear the meter. It is a reason to build the right one. Count the entire route. Tie it to an owned outcome. Feed production evidence back into the next bet. The token bill is not the business case, but it can finally force software to have one.