I keep seeing a strange new flex in AI building: people bragging about how many millions, or even billions, of tokens their agents consumed.
That number can mean the system did something ambitious. It can also mean ten agents read the same files, wrote overlapping tests, ran the same checks, summarized one another, and produced a patch that a focused developer could review in five minutes.
Tokens are not output. Tokens are the meter running.
I am bullish on AI agents. I have written before that AI is becoming infrastructure, and I still believe that. But infrastructure needs cost controls. When an agentic workflow burns through huge context windows without producing proportionate value, that is not intelligence. It is an expensive process problem.
The token usage data should get your attention
We now have enough real-world data to stop treating this as a theoretical concern.
| Observed workload | Token usage | What it tells me |
|---|---|---|
| Anthropic agent research | Agents used about 4x more tokens than chat. Multi-agent systems used about 15x more. | Agent orchestration has a large built-in token multiplier. |
| Anthropic parallel C compiler project | 2 billion input tokens and 140 million output tokens across nearly 2,000 sessions | Even a successful agent-team build can consume industrial-scale tokens. |
| OpenAI internal Codex usage | Codex accounted for 99.8% of weekly output tokens inside OpenAI | As work shifts from chat to long-running agents, token volume grows dramatically. |
Anthropic’s own analysis found that token usage alone explained 80% of the performance variance in its BrowseComp evaluation. It also found that agents typically consumed around four times as many tokens as chat interactions, while multi-agent systems consumed around 15 times as many. Anthropic’s conclusion was not that multi-agent systems are bad. It was that the task has to be valuable enough to justify the increased performance and cost. The same article specifically notes that many coding tasks have fewer truly parallelizable parts than research tasks. That matters. Read Anthropic’s multi-agent research system analysis.
The most useful billion-token example is Anthropic’s experiment building a C compiler with 16 parallel agents. Over two weeks and nearly 2,000 Claude Code sessions, the agents consumed 2 billion input tokens and generated 140 million output tokens. The reported API cost was just under $20,000. The result was substantial: roughly 100,000 lines of Rust and a compiler capable of building Linux and other major projects. Anthropic published the full experiment.
That is actually the positive case. It had a hard technical goal, a serious harness, measurable tests, and an output worth studying. If your agent team spends a similar token budget to rename a feature, build a settings screen, or refactor code nobody asked it to touch, you do not have the same story.
OpenAI’s own usage data shows how quickly agentic work can dominate consumption. By June 2026, users at the 99th percentile were regularly generating more than 60 hours of Codex agent turns per day across parallel agents. Inside OpenAI, Codex represented 99.8% of weekly output tokens. The adoption data is impressive. It is also a reminder that once agents run in parallel, token monitoring becomes an operating requirement.
What 1 billion tokens can cost
Token pricing changes, so I prefer showing the math instead of throwing out one scary number. Here is a simple workload of 1 billion input tokens and 100 million output tokens at published standard API rates in August 2026.
| Model | Published price per 1M input / output tokens | Estimated cost for this workload |
|---|---|---|
| GPT-5.6 Sol | $5 / $30 | $8,000 |
| GPT-5.6 Terra | $2.50 / $15 | $4,000 |
| GPT-5.6 Luna | $1 / $6 | $1,600 |
| Claude Opus 4.6 | $5 / $25 | $7,500 |
The arithmetic is straightforward. For GPT-5.6 Sol, 1,000 million-token input units cost $5,000. Another 100 million output tokens cost $3,000. Total: $8,000. The OpenAI model page lists current token rates, and Anthropic lists Opus pricing.
Your real bill can be lower or higher. Prompt caching can reduce repeated input cost. Long-context pricing, cache writes, tool fees, priority processing, failed attempts, and retries can push it the other direction. The point is not that every billion-token workflow costs exactly the same. The point is that “a billion tokens” is a budget line, not a trophy.
Where all those tokens actually go
When people picture AI token usage, they usually picture the final answer. In agentic systems, the final answer can be a tiny fraction of the work.
1. Every agent rebuilds context
Spawn five agents and you may be paying five times for repository instructions, task history, tool definitions, file reads, dependency notes, and summaries. If each agent reads the same 40 files before deciding what to do, parallelism has not made the work efficient. It has replicated the intake process.
2. Coordination becomes its own workload
A lead agent has to delegate, monitor, reconcile conflicts, inspect results, request revisions, and synthesize the final output. Subagents explain what they did. The lead agent reads those explanations and often re-checks the same work. None of this is free.
3. Vague prompts make agents protect themselves with activity
If I tell an agent to “make this better,” I have left nearly every important decision open. The agent may inspect the entire repository, refactor adjacent modules, add tests, run linters, run type checks, run the full suite, investigate unrelated failures, and write a long explanation.
It is doing what we often reward agents for doing: being thorough. The problem is that thoroughness without a boundary turns into expensive wandering.
4. Agents can produce verification theater
A green check mark feels productive, so agents generate more of them. They write tests that simply mirror the implementation. They re-run a full suite after a documentation change. They validate a value three different ways because no one defined which proof actually matters.
I saw a smaller version of this problem in my real-life comparison of Copilot, Cursor, and OpenAI’s o1. The first answers used outdated or incorrect methods. Better prompting finally got the right result. The lesson was not that AI coding fails. The lesson was that a weak request creates more rounds, and every round consumes time and tokens.
Tests are not the enemy. Unbounded verification is.
I do not want an agent shipping code it never tested. That is not token efficiency. That is recklessness.
The fix is to define the proof that matches the risk.
- A copy change may need a rendered-page check and a link check.
- A small function change may need focused unit tests plus the affected package suite.
- An authentication change needs negative tests, integration tests, and a security review.
- A data migration needs backups, dry runs, row counts, invariants, and a rollback path.
Risk should buy verification. Habit should not.
In my broader take on coding in the age of AI, I argued that senior developers and operators still own architecture, review, and the critical path. That becomes even more important with agent teams. The human has to define what “done” means before the agents invent their own definition.
The prompt I use to control agent cost
A good agent prompt is not only a description of what to build. It is a work order with a proof budget.
Goal:
State the exact outcome in one or two sentences.
Deliverable:
Name the file, feature, report, decision, or artifact expected.
Done when:
List the observable acceptance criteria.
Non-goals:
Name adjacent work the agent must not touch.
Agent budget:
Use one agent unless independent parallel work is clearly identified.
Cap the number of subagents and revision rounds.
Verification budget:
Run the smallest checks that prove the acceptance criteria.
Do not add tests unless behavior changes or a regression risk requires them.
Stop conditions:
Stop and report if the requirement is ambiguous, the same failure repeats,
or the work would expand beyond the stated scope.
Final report:
Return the artifact, the checks run, token usage, cost, and anything not verified.This does not make the agent lazy. It makes the agent accountable.
When multi-agent work is worth it
I use multiple agents when the work can genuinely happen in parallel and the result is valuable enough to justify the multiplier.
- Broad research where agents can investigate independent source sets.
- Large systems with clean module boundaries and minimal shared state.
- Security or reliability reviews where independent perspectives reduce blind spots.
- High-value migrations or launches where parallel validation has real economic value.
- Work that exceeds one context window and can be divided without constant coordination.
I avoid multi-agent orchestration for one small bug, one linear migration, a single tightly coupled feature, or a task whose goal is still fuzzy. Adding agents before clarifying the work usually multiplies the ambiguity.
The same economic thinking applies to company knowledge systems. In my guide to building a company knowledge brain versus renting ChatGPT, the central question is whether repeated AI spend creates a reusable asset. Agentic development should face the same test. Are you buying an enduring capability, or are you renting an impressive-looking loop?
What I would measure on every serious agent run
- Total input, cached input, and output tokens. Cached tokens may be cheaper, but they still show how much context the workflow is moving.
- Tokens by agent. One runaway subagent should not hide inside the team total.
- Useful artifacts produced. Code merged, bugs fixed, decisions made, research gaps closed, or revenue-impacting work completed.
- Duplicate work. Count agents that read the same files, ran the same checks, or proposed the same solution.
- Verification yield. Which tests found a real issue? Which checks merely repeated prior proof?
- Human review time. A 10-agent output that takes a day to reconcile may be slower than one focused implementation.
- Cost per accepted outcome. Cost per task is less useful than cost per result you kept.
The useful KPI is not tokens consumed. It is accepted value per dollar, per hour, and per million tokens.
My bottom line
AI agents are getting good enough that they can stay busy for a very long time. That is exactly why we need to stop confusing activity with progress.
Multi-agent systems can solve problems that one model cannot. They can also turn a vague request into 15 times the token usage, a pile of duplicated checks, and a polished report explaining why very little changed.
Prompt the outcome. Define the boundaries. Match verification to risk. Cap parallelism. Measure the tokens. Then make the agents prove the work was worth the meter.