Agent Orchestration Cost Control With Budgets, Caching, Routing and a Worked Cost Table

Keep a multi-agent or long-running agent bill predictable by controlling the loop, not the model. Cache the stable prefix, cap turns and dollars outside the model, load fewer tool definitions, send easy steps to cheaper models, and set effort per role. In the hypothetical run below, caching alone cut a 10-turn single-agent loop from $1.84 to $0.57 on Claude Opus 5.5. A lead agent with five subagents went from $6.40 uncached to $2.40 cached, and to $0.60 when the subagents ran on Claude Haiku 5.5 with a trimmed tool set.

The token counts are invented. The prices are real list prices read from Anthropic, OpenAI and Google on November 12, 2026. Expect the shape of the savings, not your own invoice.

Disclosure: Oakgen is our product. This is infrastructure advice that applies to any agent stack. It is not an Oakgen feature.

Cost levers at a glance

Who this is for

You run an agent that loops for many turns, or a lead that spawns workers, and you want a number you can put in a budget. You build on the Claude, OpenAI or Gemini APIs, or on a framework from our orchestration patterns guide.

How I checked this

On November 12, 2026 I opened the pricing, caching, effort, tool, compaction and budget pages of Anthropic, OpenAI and Google listed in the sources, plus the Claude Agent SDK and OpenAI Agents SDK loop docs. I re-read our Fable 5.2 pricing post and reused only the Artificial Analysis figures I could confirm on its page.

Who measured what. Prices and multipliers are the vendors' list prices. The 4 times and 15 times token multipliers are Anthropic's own June 2025 data. Cost per task by effort is Artificial Analysis' independent run. Anthropic's routing numbers are its own benchmark runs. The budget table is invented arithmetic.

What I did not do. I ran no agent, so none of this is measured. I held token counts equal across vendors, but tokenizers differ, and Anthropic says its newer one yields about 30 percent more tokens for the same text.

Why agent bills grow faster than turn counts

Each turn resends the whole history. The input you pay for on turn 40 includes everything from turns 1 to 39. So input cost grows with the square of the turn count, not linearly, until caching or compaction breaks the pattern.

Anthropic's June 13, 2025 engineering post put numbers on fan-out. In its data, agents used about 4 times the tokens of chat and multi-agent systems about 15 times. Those are one vendor's averages, not a law. Our single agent vs multi-agent guide covers when that is worth paying.

The list prices behind the table

USD per million tokens, read November 12, 2026. "Write" is the 5-minute or 30-minute cache write. "Read" is a cache hit.

Haiku 5.5 charges more for prompts over 100,000 tokens, and OpenAI lists higher rates above 272,000 input tokens, for example $4 input and $15 output on GPT-6.1 Sol. My examples stay below both. Gemini 4 supports implicit caching only, so there is no write premium and no guarantee of a hit. Google's page also shows Gemini 4 Argon doubling on December 1, 2026, a date a budget should carry.

Lever 1. Cache the prefix, and do not break it

Anthropic says a 5-minute write pays for itself after one read, because 1.25 plus 0.1 is 1.35 against 2 for processing the prefix twice. A 1-hour write costs 2 times and pays after two reads. OpenAI's guide shows the same arithmetic, one write and nine reads at 2.15 times against 10 times uncached.

Anthropic builds the prefix as tools, then system, then messages, and a change at any level invalidates that level and everything after it. Its docs list what breaks the cache.

• Editing a tool definition invalidates the whole cache.
• Changing top-level effort invalidates cached messages.
• Switching between fast and standard speed invalidates system and messages.
• Changing thinking parameters invalidates cached messages.

OpenAI lists the same traps. Its tools, reasoning.effort and context_management settings all change the rendered prefix. To change effort mid-run, Anthropic's per-message effort and OpenAI's configuration_update item on GPT-6 models both keep the cached prefix.

Four limits. Anthropic's entries last 5 minutes by default, so a loop that waits on a person or a slow tool needs the 1-hour option. An entry only becomes available after the first response starts, so parallel workers that fire together all pay the write. Prompts under the minimum are not cached, 512 tokens on current Claude models, 1,024 on OpenAI GPT-5.6 and later, and 4,096 on Gemini 4. And Anthropic's rate limits count only uncached input, so caching also raises throughput.

Lever 2. Set effort per role, and leave room for thinking

Anthropic says effort affects all output tokens, including text, tool calls and thinking. Lower effort also means fewer and terser tool calls, which compounds in a loop because every call adds a turn. For Claude Fable 5.2 it says to start at high, step up only where you measured a gain, step down where your evals hold, and reserve max for measuring the ceiling.

Artificial Analysis shows the spread. Its Fable 5.2 page lists $3.10 per Intelligence Index task as the cheapest variant and $26.54 as the headline figure, and says prices vary up to 8.6 times across the release's five variants, which our pricing guide identifies as effort levels. It is one benchmark mix, not your task.

OpenAI says GPT-6.1 Sol defaults to medium reasoning effort, bills reasoning tokens as output, and recommends reserving at least 25,000 tokens for reasoning and output. Google says thinking is priced as output plus thinking tokens, and bills thinking even when output is truncated.

Do not cap spend with a tiny max_tokens. In Anthropic's internal benchmark a 16,384 cap ended 85 percent of Fable 5.2 attempts and solved 20.3 percent of tasks, against 77.4 percent at 64,000. A cap that truncates thinking wastes the tokens already spent.

Lever 3. Trim tool definitions

Anthropic's tool search documentation says a typical five-server setup (GitHub, Slack, Sentry, Grafana, Splunk) can use about 55,000 tokens of definitions before Claude does any work, and that tool search typically cuts this by over 85 percent. It recommends search at 10 or more tools or when definitions pass 10,000 tokens.

Built-in toolsets add up too. Anthropic lists about 4,500 tokens for the computer toolset and 6,600 for the browser toolset. Its Agent SDK docs advise limiting each subagent to the minimum tool set it needs. For the code execution route see code execution with MCP, and for central control see MCP gateways.

One catch. A deferred tool cannot carry cache_control, so put the breakpoint on a non-deferred tool and keep the list stable.

Lever 4. Compact, but price it

Anthropic's compaction replaces older turns with a summary Claude writes on the server. The threshold trigger must be at least 50,000 input tokens. It needs an extra sampling step, and the docs say to sum usage.iterations for the billed total, because top-level token fields leave the compaction step out. Anthropic recommends a cache breakpoint at the end of the system prompt so only the summary is written fresh. Context editing clears old tool results or thinking blocks by rule, but clearing invalidates the cached prefix, so Anthropic suggests a minimum clear_at_least size. Google's agents-cli cost guide notes that each ADK compaction is a summarizer call, which can use a cheaper model.

The worked table below surprised me. With caching on, compaction saved little. With caching off, it saved a third. The reason to compact a cached loop is context quality and window limits, not the bill.

The worked budget table

Everything in the token columns is invented. The prices are the list prices above. I assume automatic caching, where each turn reads the previous request from cache and writes only the new content, and where requests stay under every long-context threshold.

The loop. A static prefix of 20,000 tokens (2,000 system, 18,000 tool definitions). Each turn adds 3,000 tokens of new input (user text or tool results) and the model writes 1,000 output tokens, which join the history. Input on turn t is 20,000 + 3,000 t + 1,000 (t minus 1).

For 10 turns that sums to 410,000 input tokens and 10,000 output tokens. With caching, turn 1 writes 23,000 tokens, each later turn writes 4,000 and reads everything before, so 59,000 written and 351,000 read. The check is 59,000 + 351,000 = 410,000.

A. One 10-turn loop, by model

Check on Opus 5.5. Uncached is 410,000 times $4 per million, $1.64, plus 10,000 times $20, $0.20, for $1.84. Cached is 351,000 times $0.20, $0.0702, plus 59,000 times $5, $0.295, plus $0.20, for $0.5652. For Gemini I priced first-seen tokens at the input price and assumed every later turn hits, which implicit caching does not promise. These rows say nothing about which model finishes your task.

B. The same job with a lead and five subagents

The lead is the 10-turn loop. Each subagent runs 6 turns with the same 3,000 and 1,000 token steps. Subagent summaries arrive as part of the lead's tool results. A subagent with the full 20,000 token prefix uses 198,000 input and 6,000 output tokens. With a trimmed 4,000 token prefix it uses 102,000 input and 6,000 output.

Checks. A full-prefix Opus subagent costs $0.912 uncached (198,000 times $4, $0.792, plus 6,000 times $20, $0.12) and $0.366 cached. S3 is $1.84 plus 5 times $0.912, which is $6.40. S4 is $0.5652 plus 5 times $0.366, which is $2.3952. A Sonnet subagent costs $0.183 cached with the full prefix and $0.135 trimmed. Haiku trimmed costs $0.007125. So S5 is $0.5652 plus $0.915, S6 is $0.5652 plus $0.675, S7 is $0.5652 plus $0.0356.

The fan-out used 1,440,000 tokens against 420,000, which is 3.4 times, and the bill followed at 3.5 times. In S4 each subagent writes its own prefix, because workers that start together cannot share a cache entry that does not exist yet. S7 holds only if Haiku clears your quality bar.

C. What a turn cap is worth

Same loop on Opus 5.5, different stopping points.

A stuck loop with 10 times the turns costs 49 times as much uncached and 15 times as much cached, which argues for a turn cap even with caching on. Check on the 100-turn cached row. Reads are 21,681,000 times $0.20, $4.3362, writes are 419,000 times $5, $2.095, and output is 100,000 times $20, $2.00, for $8.4312.

D. Compaction, priced

Take the 40-turn loop and compact once after turn 20, when history is 99,000 tokens. I assume a 4,000 token summary, a compaction call that reads 99,000 cached tokens, writes 4,000 and outputs 4,000, and a new context of prefix plus summary plus 3,000 fresh tokens. Real billing is whatever usage.iterations reports.

Cached check. First 20 turns cost $1.1192, the compaction call $0.1198, and turns 21 to 40 $1.0584, for $2.2974.

Sizing a hard cap

If S4 normally costs about $2.40, a $5 cap is roughly twice normal. Anthropic's session budget docs say model spend past a cap is at most one model request per thread. The costliest request in S4 is about $0.051 (the lead's turn 10 reads 55,000 tokens, writes 4,000 and outputs 1,000), so six threads overshoot by roughly $0.31 at worst. Request cost rises with context, so caps matter more as loops lengthen.

Lever 5. Route easy steps to cheaper models

Route by step difficulty, and verify each route. Anthropic's cost page reports, on its own defect-search benchmark, that Claude Opus 5.5 with Claude Sonnet 5.5 subagents cost about a third less than one Opus 5.5 session per part and scored about the same. Fable 5.2 as the orchestrator instead of Opus 5.5 cost 19 percent more for about the same score.

It is less rosy for the smallest model. On an internal coding benchmark, adding Haiku 5.5 subagents to Opus 5.5 at medium cut cost per attempt by 32 percent and the pass rate by about 4 points. Anthropic says to compare Haiku subagents with lower effort first.

The cascade is the second pattern. Anthropic's page shows Opus 5.5 at low with failures re-run at high solving about 97 percent for about $0.17 per task, against 95.3 percent and $0.29 at high throughout, on its SWE-bench Pro subset. It needs a reliable failure signal such as tests, and costs latency on failures.

Routing works across vendors. Google's cost guide says each agent in an ADK app can use its own model, and the Claude Agent SDK sets effort per subagent. Our framework comparison covers how each declares agents.

Lever 6. Caps, budgets and stop conditions

Know which controls are hard and which are advice.

Two traps. Anthropic says its SDK cost fields are estimates, not billing, so reconcile against the Console. And a spend-cap 429 has no retry-after, so an agent that retries on it hammers a wall. Treat it as a stop signal.

My stop conditions, in priority order.

1. A dollar cap per run, enforced outside the prompt.
2. A turn cap sized from your own p95 turn count.
3. A wall-clock timeout on the whole task.
4. A no-progress check, such as the same tool and arguments three times. This is my recommendation, not a vendor feature.
5. A named destination for unfinished work, a fallback model, a simpler path or a person.

Enforce these in a layer you control, because a prompt that says be frugal is advice. Our observability and evals guide covers logging cost per agent so the caps have data behind them.

The agent cost-control checklist

Use it as a pre-launch review. Each line is something a vendor doc supports or a rule I would apply.

• Log first. Record input, cached input, cache write and output tokens per agent per run.
• Set explicit effort for every agent. Defaults differ by model.
• Cache the stable prefix. Tools first, then system, then slow-changing context, and the latest user input last.
• Freeze the tool list during a run. Check that cache reads are not near zero.
• Match cache lifetime to your gaps. Use the longer option when a person or slow tool pauses the loop.
• Defer rarely used tools. Keep the 3 to 5 most used loaded.
• Scope each subagent. Minimal tools, and summaries or file references instead of transcripts.
• Cap fan-out. Set a maximum worker count and depth in the runtime.
• Route by step difficulty. Test a cheaper model against your own pass rule.
• Set max_tokens high enough for thinking. Anthropic's cost page suggests 64,000 for agent work.
• Add a turn cap, a dollar cap and a timeout. Enforce them outside the model, and name where unfinished tasks go.
• Track cost per solved task. Cost per call hides retries and failures.
• Date your prices. Note scheduled changes, like Gemini 4 on December 1.

How a creative team would apply this

A creative agent has two cost shapes. The research and planning front is read-heavy and loops, so it benefits from caching, tool trimming and a turn cap. The generation back is priced per image, second or character, not per token, so no token trick helps there. Cap the planning loop, then spend the real budget where the output is. Our guides on human approval in creative agents and agentic creative pipelines show where a person sits between the two. Oakgen Agent Chat bills in credits, not tokens, and I did not measure its internal cost per turn.

Common mistakes

• Optimizing before logging. You cannot cut a cost you have not split into input, cached, output and thinking.
• Breaking the cache with small edits. A timestamp at the top of the prompt, a reordered tool or a mid-run effort change turns cached reads back into full price.
• Giving every subagent every tool. The prefix is paid once per worker.
• Trusting a prompt to enforce a budget. Anthropic's task budget is advisory and says so.
• Capping with a tiny max_tokens. It truncates thinking, and the retry costs more.
• Reading cost per call. Divide by solved tasks, because a cheap call that fails twice is not cheap.

Decision framework

What I would do

Log tokens for a week before changing anything. Then work in order. Turn caching on and fix whatever keeps breaking it. Put a turn cap and a dollar cap outside the model, sized from the logs with headroom for one request per thread. Move subagents to a cheaper model and scoped tools, and keep the change only if the pass rate holds on your own tasks. Set effort per role last, because it moves cost the most and quality the least predictably.

I would not enable compaction to save money on a cached loop. I would enable it when context quality drops or the window fills. And I would note the December 1, 2026 Gemini 4 price change next to the budget, because a hidden price date breaks a budget on schedule.

Last updated November 12, 2026.

Frequently asked questions

How do I keep a multi-agent system's cost predictable?

Control the loop, not just the model. Cache the stable prefix, cap turns and dollars outside the model, load only the tool definitions each agent needs, send easy steps to a cheaper model, and set effort per role. In the hypothetical run in this guide, caching cut a 10-turn Claude Opus 5.5 loop from $1.84 to $0.57, and a lead with five subagents from $6.40 uncached to $2.40 cached. The token counts are invented, the prices are list prices read on November 12, 2026, so run the same arithmetic on your own logged usage.

How much does prompt caching save in an agent loop?

On Anthropic's list prices a 5-minute cache write costs 1.25 times base input and a read costs 0.1 times on most models, 0.05 times on Claude Opus 5.5 and 0.025 times on Claude Fable 5.2 (Anthropic pricing page, read November 12, 2026). Anthropic says a 5-minute write pays for itself after one read. OpenAI's caching guide gives the same shape for GPT-5.6 and later, 1.25 times to write and 0.1 times to read, or 0.05 times on GPT-6.1 Sol and GPT-6.1 Terra. In this guide's invented 10-turn loop, caching cut the cost about 3.3 times on Opus 5.5. Real savings depend on how stable your prefix is and how often you change tools or effort.

What is the difference between a soft budget and a hard cap?

A soft budget asks the model to pace itself. A hard cap stops new work whatever the model does. Anthropic's Messages API task budget is advisory, with a 20,000 token minimum, and Anthropic says the model might exceed it. The hard limits are max_tokens per request, a Managed Agents session budget in US dollars, which stops new model requests once list cost reaches the cap, and monthly spend limits in the Console. Agent SDK max_budget_usd and max_turns stop the loop, but the dollar figure is a client-side estimate and can pass the cap by one response.

Does lowering reasoning effort really cut cost?

Yes, because effort controls how many output tokens the model spends, including thinking and tool calls, and output costs several times input. Artificial Analysis measured Claude Fable 5.2 at $3.10 per Intelligence Index task at its cheapest setting and $26.54 at its headline figure, a spread it describes as up to 8.6 times across the release's five variants (page read November 12, 2026). Anthropic tells you to start at high for Fable 5.2 and step down only where your own evals show quality holds. Effort barely changes reply length, so control length in the prompt.

Do MCP tool definitions really add that much to an agent's bill?

They can. Anthropic's tool search documentation says a typical five-server setup with GitHub, Slack, Sentry, Grafana and Splunk can use about 55,000 tokens of definitions before any work starts, and that tool search typically cuts that by over 85 percent. The definitions are resent on every request unless cached, and changing them invalidates the cache. Load only the tools each agent needs, defer the rest, and see our guide on code execution with MCP for the vendor-reported savings.

When should an agent stop automatically?

Stop on whichever limit hits first. A turn cap, a dollar cap, a wall-clock timeout, and a no-progress check such as the same tool call with the same arguments repeated. Decide in advance where an unfinished task goes, a fallback model, a simpler non-agent path or a person. OpenAI's Agents SDK raises MaxTurnsExceeded and lets an error handler return a controlled final output. The Claude Agent SDK returns error_max_turns or error_max_budget_usd. The no-progress check is my recommendation, not a documented vendor feature.

Is a cheaper model for subagents safe?

Only after you test it. Anthropic's cost page says a Claude Opus 5.5 session with Claude Sonnet 5.5 subagents cost about a third less than one Opus 5.5 session per part on its defect-search benchmark and scored about the same. For Claude Haiku 5.5 subagents on coding tasks it reported a 32 percent lower cost per attempt and a pass rate about 4 points lower. Both are Anthropic's own runs. Treat them as a reason to test your own tasks, not as a guarantee.

Sources

1. Claude Platform docs, Pricing (read 2026-11-12)
2. Claude Platform docs, Prompt caching (read 2026-11-12)
3. Claude Platform docs, Effort (read 2026-11-12)
4. Claude Platform docs, Tool search tool (read 2026-11-12)
5. Claude Platform docs, Task budgets (read 2026-11-12)
6. Claude Platform docs, Compaction overview and compaction at a token threshold (read 2026-11-12)
7. Claude Platform docs, Context editing (read 2026-11-12)
8. Claude Platform docs, Managed Agents session budgets (read 2026-11-12)
9. Claude Platform docs, Rate limits and spend limits (read 2026-11-12)
10. Claude Platform docs, Optimizing for cost and intelligence (read 2026-11-12)
11. Anthropic Engineering, How we built our multi-agent research system, Jun 13 2025 (read 2026-11-12)
12. Claude Agent SDK docs, How the agent loop works (read 2026-11-12)
13. Claude Agent SDK docs, Track cost and usage (read 2026-11-12)
14. OpenAI API docs, Pricing (read 2026-11-12)
15. OpenAI API docs, Prompt caching (read 2026-11-12)
16. OpenAI API docs, Reasoning models (read 2026-11-12)
17. OpenAI Agents SDK docs, Running agents (read 2026-11-12)
18. Google, Gemini Developer API pricing (read 2026-11-12)
19. Google, Gemini API context caching (read 2026-11-12)
20. Google, Gemini API thinking (read 2026-11-12)
21. Google agents-cli docs, Control cost (read 2026-11-12)
22. Artificial Analysis, Claude Fable 5.2 release page, Intelligence Index v5.0.1 (read 2026-11-12)