Cutting Claude agent token cost: caching & batching

Agents have a cost shape that surprises almost everyone the first month. A single chat call costs pennies. An agent that loops twenty turns, re-reads its system prompt and tool definitions every time, and spawns three subagents to investigate in parallel can cost a hundred times more for one task. Token cost in agentic systems isn't a line item — it's an emergent property of how your loop is built, and most of the waste is invisible until you go looking for it.

The good news is that the same architecture that makes agents expensive also makes them very compressible. Most tokens an agent processes are repeated, predictable, or unnecessary, and Claude's platform gives you direct levers — prompt caching, batching, and model routing — to claw most of that cost back without hurting quality. This post walks through where the money actually goes and how to keep runs cheap and fast.

Where the tokens actually go

In a typical agent turn, the model re-reads the entire conversation so far: the system prompt, every tool definition, all prior tool results, and the running dialogue. On turn one that's small. By turn fifteen it can be tens of thousands of tokens, and you pay to reprocess nearly all of it every single turn. Multiply that by a multi-agent run and the input-token bill dwarfs the output you actually wanted.

So the first move isn't a clever trick — it's measurement. Instrument every run with input tokens, output tokens, cached tokens, and turn count, then compute cost per completed task, not cost per call. Once you can see that one class of task averages eighteen turns and 400K cumulative input tokens, you know exactly where to aim. Teams that skip this step optimize the wrong thing; teams that do it usually find one or two dominant cost sinks they can fix in an afternoon.

Prompt caching: stop paying for the same prefix

Prompt caching is the highest-leverage optimization in agentic systems, and it maps perfectly onto how agents work. Anthropic's prompt caching lets you mark a stable prefix of your request so that on repeat calls the model reuses the already-processed prefix at a steep discount instead of charging full price to reprocess it. Because an agent's system prompt and tool definitions are identical on every turn, that's a large, stable prefix you'd otherwise pay full freight for over and over.

The rule that makes caching work is ordering: put the stable content first and the volatile content last. Your system instructions, skill definitions, and tool schemas go at the front behind a cache breakpoint; the growing conversation and fresh tool results go after it. Get the order wrong — interleave a changing timestamp into the prefix — and the cache misses every time. Get it right and a long agent run can read its cached prefix at a fraction of the input cost, which on a loop-heavy workload is often the difference between viable and not.

flowchart TD
  A["Incoming agent turn"] --> B{"Stable prefix cached?"}
  B -->|Hit| C["Reuse prefix at discount"]
  B -->|Miss| D["Process full prefix & write cache"]
  C --> E{"Task complexity?"}
  D --> E
  E -->|High| F["Route to Opus"]
  E -->|Routine| G["Route to Sonnet/Haiku"]
  F --> H["Emit result + log tokens"]
  G --> H

Routing: don't send every turn to your biggest model

The diagram's second decision is model routing, and it's where a lot of money hides. Claude 4.x spans Opus 4.8 for the hardest reasoning, Sonnet 4.6 as the workhorse, and Haiku 4.5 for fast, cheap, high-volume steps. Sending every turn to Opus is like hiring a principal engineer to read directory listings. Most turns in a real agent run are mechanical — parse a result, format a query, decide the next step — and a smaller model handles them perfectly at a fraction of the price and latency.

A practical routing pattern: use a capable model for planning and genuinely hard reasoning, and a smaller model for the routine execution turns in between. In multi-agent setups, the orchestrator may warrant Opus while the worker subagents run on Sonnet or Haiku. You can route statically by role or dynamically by a cheap complexity classifier. Either way, measure quality per route — the goal is to drop cost on the turns where the bigger model wasn't adding anything, not to degrade the answer.

Batching the work that doesn't need to be live

Not every agent task is interactive. Overnight evals, bulk document processing, backfilling classifications across a dataset — these don't need sub-second latency, and that flexibility is worth real money. The Anthropic Message Batches API processes large volumes of requests asynchronously at a significant discount versus synchronous calls, which is ideal for any agent workload where you can tolerate minutes-to-hours turnaround instead of milliseconds.

The architectural move is to split your traffic by latency requirement. Interactive, user-facing agent turns stay on the synchronous path with caching and routing. Everything offline — nightly regression evals, large-scale enrichment, scheduled report generation — goes through batching. Combine batching with caching on the shared prefix and you compound two discounts on exactly the workloads where cost matters most and speed matters least.

Trimming context before it trims your budget

The last lever is the one teams reach for last and should reach for first: send less. Agents accumulate context like a desk accumulates paper. A 50KB tool result that mattered on turn three is still being reprocessed on turn twenty for no reason. Before each turn, prune: summarize stale tool outputs into a few lines, drop results that have been superseded, and keep only the working set the next decision actually needs.

Two patterns help a lot. First, compaction — periodically replace a long history with a compact, faithful summary plus the live working state, which caps context growth instead of letting it run linearly. Second, externalize memory — write durable facts to a file or store and let the agent re-read on demand rather than carrying everything in the conversation. Done well, context trimming both lowers cost and improves quality, because a focused context produces sharper decisions than a bloated one. Cheap and good usually turn out to be the same optimization.

Frequently asked questions

What gives the biggest token-cost reduction for Claude agents?

Prompt caching, by a wide margin, because an agent reprocesses the same stable system prompt and tool definitions on every turn. Order your request so that stable content sits in a cached prefix and only volatile content follows it, and a long run reads most of its input at a steep discount.

Should I always use the most capable model for my agent?

No. Reserve the largest model for planning and hard reasoning, and route routine execution turns to a smaller, faster, cheaper model. Most turns in a real agent run are mechanical, and a smaller Claude model handles them at a fraction of the cost without hurting the final result.

When does request batching make sense?

Whenever the workload tolerates asynchronous turnaround — nightly evals, bulk classification, scheduled processing. The Message Batches API trades latency for a meaningful discount, so route every non-interactive agent workload through it and keep the synchronous path for live, user-facing turns.

How do I stop context from quietly inflating my bill?

Prune and compact each turn: summarize stale tool outputs, drop superseded results, and periodically replace long histories with a faithful summary plus live working state. Externalize durable facts to storage and re-read on demand instead of carrying everything in the conversation.

The economics of always-on agents

These same levers — caching the stable prefix, routing by difficulty, trimming context — are what make an always-on voice or chat agent affordable at scale. CallSphere applies them so its multi-agent assistants can answer every call and message, use tools mid-conversation, and book work 24/7 without the token bill spiraling. See it live 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.