The Arithmetic of Agent Cost

The first cost report for a multi-agent system often causes a small panic. Someone adds up the tokens, sees a number several times larger than the chatbot pilot, and asks whether the design was a mistake. Sometimes it was. More often the team is measuring the wrong thing.

At Poly, the studio I am building, a team of agents builds one course lesson at a time. The running example is Lesson 3.2 on prompt caching: a script, three diagrams and a five-question quiz. The question I care about is what one lesson that passes review costs.

The bill is mostly input, read again on every turn

A model call is billed on the tokens it reads and the tokens it writes. An agent loop makes reading expensive in a particular way: every turn re-sends the whole window. A research page fetched at turn two is paid for again at turn three, turn four and turn nineteen. Output tokens cost more each, but a run produces far fewer of them.

Picture a single agent building the lesson: research, syllabus, script, diagrams and quiz, all in one window. In the illustrative teaching model behind Figure 1, with five strands of work and 20,000 tokens of raw material each, that window is re-read across 19 turns. The total is about 1.3 million input tokens for one lesson, most of it the same pages paid for again and again.

That gives the arithmetic in one line: cost is roughly window size times turns, summed across every agent, times the price per token. Every useful cost decision changes one of those terms.

More tokens can still mean a cheaper result

Anthropic’s account of its multi-agent research system is the honest place to start. Its agents used about four times the tokens of a chat interaction, and its multi-agent system about fifteen times. That system, a Claude Opus 4 lead with Claude Sonnet 4 sub-agents, also outperformed single-agent Claude Opus 4 by 90.2 per cent on Anthropic’s internal research evaluation. In their analysis, token usage alone explained 80 per cent of the variance in performance. They spent tokens on purpose, because more searching bought better answers.

So the token count can move either way. In Anthropic’s case it rose sharply because the agents did more work. In Poly’s lesson build it falls, because the single agent’s problem is re-reading, not effort. The researcher reads about 38,000 tokens of pages in its own window and hands the orchestrator a summary of about 850 tokens plus a pointer to the full file. The orchestrator never carries the pages, so it never pays for them twice. The Orchestrator Should Never Read the Raw Material explains the technique.

Five levers, in the order to pull them

Figure 1 prices the same lesson five ways. The first lever changes how many tokens are read; the next three change what each token costs.

1. Split the windows. Give each worker its own window and return summaries plus pointers. In the teaching model the index falls from 100 to 32 with every agent still on the large model. It works only when the job divides into strands whose raw material the other agents don’t need.
2. Tier the models. Keep the large model for planning and judging, and move extraction, formatting and quiz drafting to a small one. At published list prices in mid-2026, a large model’s input costs several times a small model’s. The index falls to 12. The risk is a small model in a judging role quietly lowering quality, which only the success rate will reveal.
3. Cache the stable prefix. Put the system prompt, tool definitions and style guide first, and don’t change them during a run. Anthropic’s prompt caching documentation is typical: cache reads bill at a fraction of the base input price, writes at a premium, and the match is on the exact prefix. A timestamp on line one of the system prompt drops the hit rate to zero. At a 60 per cent hit rate the index falls to 8.
4. Batch what nobody is waiting for. Asynchronous batch processing, in Anthropic’s documentation for example, is billed at about half the normal price. A course built overnight qualifies; a producer waiting at a screen doesn’t. The index falls to 4.
5. Stop runaway work. This lever doesn’t lower the typical run, so it is not on the staircase. It removes the expensive tail: maximum turns, a budget per task and a cap on evaluator revisions, all enforced in code. This is Loop Engineering, the author’s model for treating agent iteration as a control loop with progress signals, budgets and stop conditions enforced outside the model.

Ratios and discounts move, so check the current price sheet before quoting any of this. You can watch the first lever at work in the fan-out scenario of the agent simulator, where the single-agent equivalent cost pulls away as raw material lands.

Budget each task, and divide by successes

A budget for the whole run is not enough. Take an illustrative runaway loop: a lesson with a $1.50 run budget costs $14.20 after 118 turns, against a $0.60 median, because the scriptwriter and evaluator keep trading revisions over a criterion nobody can measure. The budget was set at the edge and never passed down. The fix is to write a budget into each task in the task ledger and check it before every delegate call.

Then change the metric. Each common measure rewards something, and most reward the wrong thing.

Cost per successful task divides all spend, including failed and revised runs, by the outputs that met their acceptance criteria. For Poly that is the week’s spend on lesson builds divided by the lessons that passed the rubric and human review. A tiering change that saves 20 per cent per run but drops the pass rate from 94 to 70 per cent has made each good lesson about 7 per cent more expensive.

What the arithmetic won’t tell you

It won’t tell you what a successful lesson is worth; people set that, and the budget follows. It won’t make a cheaper tier good enough; it only shows when one isn’t. The teaching model is not your workload, so measure your own runs with the usage fields every response returns, including cache reads and writes. And it won’t justify a multi-agent design where none is needed. For a question like “what is our refund policy”, one call with retrieval beats any team, as Start With One Agent argues.

Who does what

Executives: ask for cost per successful task for each agent workflow, not a monthly token total. Decide what a good outcome is worth before approving scale.

Architects: design budgets into the task ledger, choose a model tier per role, put the stable prefix first, and route anything nobody is waiting for through batch.

Engineers: record input, output, cache-read and cache-write tokens on every model call, enforce maximum turns and per-task budgets in code, and add a CI check that fails when the prompt prefix changes unexpectedly.

This article is part of The Agentic AI Architect, a series from the author of The Contextual Agentic Enterprise. Each piece matches a module of his course in development, Agentic AI Architect Pro.

References

1. The Contextual Agentic Enterprise.
2. Anthropic (13 June 2025) "How we built our multi-agent research system". https://www.anthropic.com/engineering/multi-agent-research-system
3. Anthropic, "Prompt caching", Claude documentation (accessed 24 September 2026). https://docs.claude.com/en/docs/build-with-claude/prompt-caching
4. Anthropic, "Batch processing", Claude documentation (accessed 24 September 2026). https://docs.claude.com/en/docs/build-with-claude/batch-processing