When I compared Claude and Codex on the same Drupal upgrade last week, one result surprised me: the model that did the most work used clearly fewer tokens. Claude ran deprecation scans, installed analysis tools, looked up release status for every blocked module and checked the database. Codex stayed read-only and priced the uncertainty instead. Still, Claude used clearly fewer tokens.
That made me think. Tokens often feel like a measure of how much a model has done. In practice, they often measure something else.
The experiment itself is in the article where I compared Claude and Codex on the same Drupal estimate.
Tokens do not measure work, they measure uncertainty
An agent that knows what it is allowed to do, and has a clear next step, often just does that step. An agent that does not know where the boundaries are needs to reason more. It weighs options, writes out assumptions and prices risks that it might have been able to check if the instruction had been clearer. All of that costs tokens without producing a better answer.
The difference in this experiment was not that Codex spent more effort on the task. It spent more effort handling what the instructions did not say. Every assumption it had to make because the room to act was unclear generated text, and that text costs.
It showed up most clearly in three patterns.
Three instruction patterns that drive up cost
No mandate. If the instruction does not say what the agent may and may not do, the model has to fill that in itself, and it often chooses the cautious option. "Feel free to check themes and db if needed" was read by one model as permission and by another as a read-only mandate. Same words, two interpretations, a big difference in output. What was missing was a mandate: you may install analysis tools locally if you clean up afterward. You may read the database. You must not touch staging or production.
No verification ladder. If the instruction does not say how the agent should handle uncertainty, it often chooses to price it. That is a reasonable choice when the alternative is unclear. A verification ladder makes the alternative concrete: for each blocked dependency, check whether a compatible release exists, check whether the dependency is even in use, run a scan if you own the code. Uncertainty that can be turned into facts costs fewer tokens than uncertainty that has to be described and priced.
No question threshold. "Ask questions if needed" sounds open, but in practice it often produces question sections at the bottom of a finished document, not questions asked in the middle of the work. The model completes the task and then lists what it should have asked before it started. A question threshold defines when the agent should stop: if an unanswered assumption can clearly affect the total, stop and ask before continuing.
What tighter instructions look like
It is easier to understand in concrete terms. This is roughly what I added to version 2 of my estimate skill after the experiment:
A mandate section that explicitly says what the agent may install locally, that it should uninstall it afterward and document what was run, and that staging and production must never be touched. Not because the model does not know that, but because it removes the room for interpretation.
A verification ladder for upgrade estimates: check compatible releases for each blocked module, check actual usage in the database, run a deprecation scan on the code we own. Each step is either completed with evidence or marked as not completed with a reason.
A question threshold: if an open assumption can move the total by more than a fifth, stop and ask. Do not write a questions section. Stop.
And an assumptions register in the output: every assumption is either verified with evidence or priced as risk. It should be visible in the estimate, not hidden inside the range.
It is a tradeoff, not a rule
Tighter instructions reduce token usage for the right reasons: the agent knows what it is allowed to do and does not need to reason its way into the mandate. But there is a limit. What made Claude's estimate good was initiative the model took without the instruction asking for it. A tightly steered skill can suppress exactly that kind of judgment.
The answer is not always maximally detailed instructions. It is instructions that remove unnecessary ambiguity without turning off the useful part. Mandates and verification ladders remove uncertainty about what the agent may do. They do not have to limit how it thinks once it starts doing the work.
In this context, token usage is a symptom rather than a goal. If a run costs more tokens than you expected and the output is not better, the model is probably not the problem. The problem is what the instruction left open.
