Token discipline: five questions before an agent run
Most agent cost isn't the model. It's context you re-send, work you re-do, and a model tier you never questioned.
The first properly agentic workflow I ran was cheap to build and expensive to operate, and it took me an embarrassingly long time to work out why.
The instinct is to look at the model price and conclude that agents are just costly. That is almost never where the money goes. In every workflow I have since measured, the bill was dominated by things that had nothing to do with the quality of the model and everything to do with how carelessly I was feeding it.
These are the five questions I now ask before letting anything run repeatedly.
1. Am I re-sending context that never changes?
Long-lived agents accumulate a preamble — instructions, schemas, examples, file contents — that is identical on every call and paid for on every call.
Prompt caching exists precisely for this, and using it is mostly a matter of ordering: stable content first, volatile content last. Get that ordering wrong and the cache never hits, because a single changed token near the top invalidates everything after it.
This is usually the single largest line item, and it is a structural fix rather than a clever one.
2. Does this step need the strongest model?
A multi-step workflow rarely needs the same capability at every step. Classification, extraction, routing and formatting are not the same kind of problem as synthesis or judgement.
Routing the mechanical steps to a smaller, cheaper model and reserving the strongest tier for the steps that genuinely need reasoning is the second-largest saving available, and it usually costs nothing in output quality — because the mechanical steps were never the bottleneck.
The failure mode is deciding this once, at the start, and never revisiting it as the workflow grows.
3. What happens when it fails halfway?
An agent that dies at step nine of eleven and restarts from step one pays for the first eight steps twice. Do that a few times a day and retries quietly become a meaningful share of the bill.
Checkpointing intermediate results is a cost control, not just an engineering nicety. So is making steps idempotent, so a retry is cheap rather than a full re-run.
4. Am I paying for output I discard?
Two common versions:
- Verbose intermediate output. A step that returns three paragraphs of explanation when the next step consumes one field. You pay per output token whether or not anything reads it.
- Wide fan-out with a narrow filter. Generating twelve candidates and keeping one. Sometimes correct — often the same result is available with three.
Constraining intermediate steps to structured output does two things at once: it cuts tokens and it removes a parsing failure mode.
5. Do I actually know what this costs?
This is the one that matters, and the one I skipped for far too long.
Without per-run instrumentation, every optimisation above is a guess. With it, the answer is usually surprising — the expensive step is rarely the one you would have named.
Log tokens per run, per step, split into input and output, before changing anything. Then change one thing and compare. That is the whole method, and it is boring, and it is the only part that reliably works.
The honest summary
None of this is sophisticated. It is context hygiene, model routing, retry discipline, output constraints, and measurement — and between them they account for the large majority of what I was wasting.
If you only do one: instrument first. Optimising without measurement is how you spend a weekend making the cheap step cheaper.
The practices behind dont-burn.token. Your numbers will differ from mine — measure your own.