Cutting Token Cost in Parallel Claude Code Runs

Parallel agents are the most expensive thing you can do with Claude Code, and the cost sneaks up on you. A single orchestrator that fans out to several subagents doesn't just multiply the work — it multiplies the context. Every subagent re-reads instructions, re-loads relevant files, and re-establishes its own working memory. Run that across four or five workers and a task that would have cost a modest amount as a single agent can cost several times more in tokens. On desktop, where you may trigger these runs casually throughout the day, that adds up quickly. The good news: most of the waste is structural and removable without hurting quality.

Key takeaways

• Multi-agent runs typically spend several times the tokens of a single agent — use parallelism deliberately, not by default.
• Prompt caching is the single biggest lever: put stable instructions and shared context up front so repeated reads are cheap.
• Batch independent tool calls into one turn instead of one-call-per-turn round trips.
• Route by difficulty — Haiku for cheap mechanical work, Sonnet for most tasks, Opus only for the hard reasoning.
• Keep subagent context lean: pass pointers and summaries, not whole files, to each worker.
• Measure cost per run, not per token, and set a budget that aborts runaway loops.

Where the tokens actually go

Before optimizing, find the spend. In a parallel run, the dominant costs are usually: the orchestrator's growing transcript as it coordinates; each subagent re-reading the same large files or instructions; and chatty tool loops where the agent makes one call, waits, makes another, and re-sends the entire context each time. The reasoning tokens — the part you actually want — are often a minority of the bill. That's encouraging, because it means you can cut cost without making the agent dumber.

A useful mental model: every token in the context window is paid for on every turn it survives. A 30,000-token file that stays in context for ten turns is paid roughly ten times. So the cheapest optimization isn't generating fewer output tokens — it's not carrying input tokens you don't need, and making the ones you do carry cacheable.

Caching: the highest-leverage move

Prompt caching lets Claude reuse a previously processed prefix of the context at a large discount instead of reprocessing it. The rule is mechanical: put the stable, reused parts of your prompt — system instructions, tool definitions, shared reference docs — at the very front and keep them byte-for-byte identical across calls. The volatile parts (the specific task, the latest tool result) go at the end. Because subagents in a parallel run share the same instructions, a well-structured cacheable prefix pays off across every worker.

flowchart TD
  A["Build prompt"] --> B{"Stable prefix
unchanged?"}
  B -->|Yes| C["Reuse cached prefix
cheap"]
  B -->|No| D["Reprocess prefix
full price"]
  C --> E["Process only new suffix"]
  D --> E
  E --> F["Model responds"]
  F --> G{"Within run budget?"}
  G -->|No| H["Abort & report"]

The biggest mistake people make is invalidating the cache by accident — injecting a timestamp, a random ID, or reordering tool definitions on each call. Anything that changes the prefix forces full reprocessing. Keep the prefix deterministic and you keep the discount.

Batching tool calls instead of round-tripping

Each tool round trip resends the full context. If an agent needs to read five files, the expensive pattern is five separate turns, each re-paying for the entire conversation so far. The cheap pattern is to request all five in a single turn when the model supports multiple tool calls per response, or to provide a tool that reads many files at once. Fewer turns means fewer reprocessings of the accumulated context.

// Expensive: 5 turns, context resent each time
read("a.ts") -> wait -> read("b.ts") -> wait -> read("c.ts") ...

// Cheap: 1 turn, batched
read_many(["a.ts", "b.ts", "c.ts", "d.ts", "e.ts"])

Design tools that take lists. A grep-and-read tool that returns the matching files' contents in one call collapses what would have been a dozen turns into one, and the savings compound across every parallel worker doing similar discovery.

Route the right model to the right work

Not every subtask deserves your most expensive model. A run that uses Opus to rename variables is overpaying by a wide margin. The pattern that consistently wins is tiered routing: use Haiku for mechanical, well-specified work (formatting, simple edits, classification), Sonnet as the default for most coding and analysis, and reserve Opus for genuinely hard reasoning or planning. In a multi-agent setup the orchestrator can assign each subagent a model based on the nature of its slice.

Keep subagent context lean

The orchestrator should hand each subagent the minimum it needs: a clear task, pointers to the relevant files, and a short summary of shared context — not the entire conversation and not whole files it can read on demand. A common anti-pattern is the orchestrator dumping the full repository map into every worker. Pass a path and let the worker read selectively. Leaner context is cheaper on every turn and, as a bonus, often improves quality because the model isn't distracted by irrelevant material.

Compact long transcripts before they balloon

In a long parallel run, the orchestrator's transcript grows turn after turn as it coordinates workers, and that growing history is re-paid on every subsequent turn. Left unchecked, coordination overhead can eventually dwarf the useful work. The fix is periodic compaction: replace a long run of completed, no-longer-relevant turns with a short summary of what was decided and what state remains. The orchestrator keeps the decisions it needs and sheds the verbose tool chatter that produced them.

Be deliberate about what survives compaction. Keep the task definition, the current plan, and the outstanding subagent results; drop the intermediate tool transcripts that have already been folded into those results. Done well, compaction holds the orchestrator's working context roughly flat across a long run instead of letting it climb linearly, which is often the difference between a run that costs a reasonable amount and one that costs many times more for the same output.

Ship cheaper runs in 6 steps

1. Measure current cost per run and break it down into orchestrator, subagent, and tool-loop spend.
2. Move stable instructions and shared docs to a deterministic, cacheable prefix.
3. Replace one-call-per-turn patterns with batched, list-taking tools.
4. Add tiered model routing so each subagent uses the cheapest model that can do its slice.
5. Trim subagent context to pointers and summaries instead of whole files.
6. Set a per-run token budget that aborts loops before they get expensive.

Common pitfalls

• Reaching for parallelism by default. Multi-agent runs cost several times more; a single agent is often cheaper and just as good for linear tasks.
• Cache-busting by accident. Timestamps, random IDs, or reordered tool definitions in the prefix silently kill your caching discount.
• Chatty tool loops. One file read per turn resends the whole context each time; batch reads instead.
• Using one model for everything. Running Opus on mechanical work is pure overspend; route by difficulty.
• No run-level budget. Without a hard cap, a single looping worker can quietly multiply your bill.

Frequently asked questions

How much more do parallel Claude agents cost?

Multi-agent runs typically use several times more tokens than a single agent because each subagent maintains its own context and re-reads shared material. Use parallelism deliberately for genuinely independent work, not as a default.

What is prompt caching and why does it matter here?

Prompt caching reuses a previously processed prefix of the context at a large discount instead of reprocessing it. It matters most in parallel runs because all subagents share the same instructions, so a stable, deterministic prefix pays off across every worker.

Should I always use the most capable model?

No. Route by difficulty: Haiku for mechanical work, Sonnet for most coding and analysis, and Opus only for hard reasoning or planning. Tiered routing cuts cost substantially without hurting outcomes.

How do I stop a single agent from blowing the budget?

Set a per-run token budget that aborts the run when exceeded, and add a no-progress detector so a looping worker fails fast instead of silently consuming tokens.

Bringing agentic AI to your phone lines

CallSphere uses the same cost discipline — caching, batching, and right-sizing the model — to run voice and chat agents that handle every call and message affordably at scale. See how it works at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.