The case study
I asked an AI agent to revise a slide deck. It read ten million tokens.
A case study in context amplification, and why prompt caching hides it.
This week I gave a coding agent a routine job: revise a set of go-to-market slide decks using notes I had already written. The agent was OpenAI’s Codex, working through its built-in orchestration, where a “parent” agent plans the work and hands pieces to “worker” sub-agents. The decks came back fine. Then I looked at the token telemetry, and the numbers did not match the size of the job.
What the numbers said
| Measure | Value |
|---|---|
| Parent’s working context, one activation | ~200,000 tokens |
| Cumulative input the parent processed | ~10.5 million tokens |
| Total cached input, whole task | ~11.2 million tokens |
| Parent-context equivalents | ~52 |
The last row is the one that matters. Divide everything the parent read by the size of one full read, and you get how many times it effectively re-read its whole conversation. Fifty-two times, for one deck task. I asked the agent what a healthy number looks like. Its own answer was under ten. I call this ratio the Context Amplification Factor.
Why this happens
Picture a manager with a 400-page project binder. Every time they want to know whether an intern has finished, they re-read the binder cover to cover, then ask. That is what a parent agent does when it polls.
Here is the loop. The parent decides to check on a worker. A status tool runs and returns a line of text. The parent model is invoked again to interpret that line, and its input is the entire conversation so far. Each check is cheap to fetch and expensive to interpret. Waiting, steering, interrupting and restarting workers all go through the same loop. A plain scheduler doing the same wait would cost nothing, because no model runs.
When I put this to the agent, it conceded the point in its own words: each unnecessary parent activation produced a new model response cycle.
Why caching does not make it free
The usual reply is that prompt caching solves this. The repeated prefix is cached, so re-reading is nearly free. I checked OpenAI’s published prices rather than take that on faith.
| GPT-5.6 Sol, per million tokens | API price | Codex credits |
|---|---|---|
| Fresh input | $4.00 | 100 |
| Cached input | $0.40 | 10 |
| Output | $20.00 | 500 |
Cached input is ten percent of fresh. Not zero. Two more details from the caching guide: for GPT-5.6 and later, writing to the cache costs 1.25 times the fresh rate, and the cache lives for 30 minutes. In an orchestration loop, every tool result appended to the parent is a new write. Any wait longer than 30 minutes expires the whole prefix and rewrites it.
Priced as if entirely GPT-5.6 Sol at API rates, my task came to about $6.72. On the Codex credit rate card, the cached tokens alone were about 112 credits. Without caching, the same parent input would have been around 1,050 credits. Caching hid a ten-fold inefficiency. It did not remove it. And these prices are promotional, cut in August and guaranteed only through November 2026.
One thing I could not confirm: whether the base allowance on Plus and Pro plans applies the same ten percent weighting to cached tokens. OpenAI’s pricing page describes those allowances in messages per five-hour window, and the help-center rate card blocks automated readers.
The fix that broke its own budget
The agent wrote a policy into its global instructions: no polling, event-driven waits, do not fork conversation history into workers, one steering attempt, one replacement, and a cap of twelve parent activations per task. Sensible, all of it.
The turn that installed the policy used more than twelve activations. The agent disclosed this itself. That is the clearest evidence I have that instructions alone will not hold. A model cannot reliably count its own activations, especially after its context has been compacted. Enforcement has to live in the runtime.
What you can do today
These apply to any agent framework with a parent-worker pattern, not just Codex.
- Ask for the bill. After any delegated task, ask the agent for total input, cached input, uncached input and output tokens. Divide cumulative parent input by one full activation. Above ten, the workflow is wasteful even if the output is good.
- Forbid polling. Tell the parent to dispatch workers and wait for completion, not to check status on a timer.
- Pass paths, not history. Workers should get the objective, constraints and file paths. They should not inherit the parent’s conversation.
- One return per worker. No progress messages. Every message wakes the parent.
- Start fresh threads. A long thread multiplies the cost of every activation. New task, new thread.
- Do not interrupt on silence. A quiet worker at high reasoning effort is usually working. Elapsed time alone is not evidence of a stall.
What I would like vendors to show
A per-task amplification factor in the usage view. A wait primitive that blocks on worker completion without invoking the parent model. A runtime counter for parent activations with a warning before the budget is gone. None of this is hard to measure. It is just not surfaced.
Why I am sharing this
I am not selling a tool. I am a user who noticed a number that looked wrong, pushed until the vendor’s own agent agreed, and verified the prices before writing. The pattern compounds silently. The user sees a finished deck, not fifty re-reads. It scales with context length, so the best long-context models are the most exposed. If you use agents to do real work, look at your telemetry once. I expect you will find the same thing.
I have the raw telemetry and the installed policy text, and I am happy to share both.