An expensive business lunch once implied that something important had happened. Now a person can produce a large inference bill without leaving the chair. At least the lunch occasionally came with a customer.
In July, Systima published a comparison of token overhead in coding-agent systems, examining how scaffolding, tools, caching, and task structure affected its measurements. It is a vendor-authored experiment with specific configurations and caveats, not a universal ranking of cost or quality. We are not adopting its headline ratios as general facts.1
An input with excellent branding
But a large bill does not establish the opposite. It may reflect productive exploration, repeated mistakes, unnecessary context, poor orchestration, or a task that was badly specified.
This makes it an awkward status symbol. The person sharing the number can invite the audience to infer intensity and sophistication without showing the completed work. We recognize the ritual from the executive who is extremely busy but unavailable to explain with what.
A deliberately small accounting exercise
Imagine two hypothetical processes. One costs ten units and produces a result that takes an hour to correct. Another costs twenty units and produces an acceptable result with little review.
The second may be more economical overall. Now imagine that the more expensive process merely generates a longer explanation of the same mistake. It is not.
Change the denominator and the comparison changes with it. Cost per attempt rewards cheap attempts. Cost per accepted outcome makes room for the person who has to fix the result.
A useful comparison should also consider what was omitted from the bill: human review, retries, external tools, and the consequences of undetected errors. These costs may exceed the visible model charge, or they may be small. They need to be observed rather than assumed.
The dashboard is not the accomplishment
That comparison can become absurd quickly. A researcher exploring a difficult question and a developer renaming a field have different needs. A high-stakes task may deserve checks that would be wasteful for a disposable experiment.
This requires judgment about the task before the meter starts. What would count as success? What must be checked? When should the system stop? What uncertainty is worth spending more to reduce?
Without those choices, a system can keep producing activity that feels like diligence while becoming increasingly distant from the original purpose.
Spend where it changes the answer
Ask the operator what changed because of the run. If the only available answer is the balance on the account, the meter has been promoted beyond its qualifications.
Some problems deserve a large compute bill. The bill itself is not one of the achievements.