Cutting Claude Agent Token Cost: Caching and Batching (Claude Managed Agents Production)

A Claude agent that works is the easy part. A Claude agent that works and costs a few cents per run instead of a few dollars is what gets you to production. The difference is almost never the model you chose — it's how much context you resend on every turn, how often you recompute things you already computed, and whether you reach for the most expensive model when a cheaper one would do. Token cost and latency are two views of the same problem: both grow with the size of the context you push through Claude on each step, and an agent can run dozens of steps.

This post walks through the levers that move the bill the most, in rough order of impact: prompt caching, context discipline, batching, model routing, and run-shape choices like single-agent versus multi-agent.

Where the tokens actually go

In an agentic loop, the expensive thing isn't the user's question — it's the resend. Every turn re-sends the system prompt, the tool definitions, and the entire conversation so far, including every tool result. By turn fifteen, you might be paying to reprocess a giant system prompt and a dozen verbose JSON tool outputs on every single call. The output tokens are usually a rounding error next to this accumulated input.

So the first instinct — "use a cheaper model" — often helps less than fixing the resend. Two agents on the same model can differ tenfold in cost purely because one keeps a tight context and the other lets results pile up unbounded. Measure before you optimize: log input and output tokens per turn, and you'll almost always find the cost is dominated by re-processed input.

Prompt caching: stop paying for the same prefix

Prompt caching is the single biggest win for agents. The stable parts of your context — system prompt, tool definitions, long reference material — don't change between turns, so Claude can cache that prefix and charge a steep discount to reuse it on subsequent calls. You mark the boundary; everything before it is cached, and reads against a warm cache cost a fraction of a normal input token.

flowchart TD
  A["New turn begins"] --> B["Assemble context: stable prefix + fresh tail"]
  B --> C{"Prefix matches cache?"}
  C -->|Yes| D["Read cached prefix at discount"]
  C -->|No| E["Process full prefix, write cache"]
  D --> F["Process only new tail tokens"]
  E --> F
  F --> G["Claude responds"]
  G --> H{"More turns?"}
  H -->|Yes| A
  H -->|No| I["Run ends"]

The discipline that makes caching pay off is prefix stability. Put everything constant at the front — system prompt, then tool definitions, then any fixed knowledge — and keep the volatile, per-turn material at the end. If you inject a timestamp or a freshly shuffled list near the top, you bust the cache on every turn and pay full price. Order your context most-stable-first and treat that ordering as a contract.

Caching also cuts latency, because reading a warm prefix is faster than reprocessing it. For multi-turn agents this compounds: the longer the run, the more turns benefit, so the savings grow exactly where naive agents get most expensive.

Context discipline: prune before you process

Caching reduces the cost of carrying context; pruning reduces how much you carry at all. Tool results are the usual culprit — a single API call can dump kilobytes of JSON that the agent needed for one decision and never references again. Summarize or drop stale results: after a tool result has been used, replace it in the running history with a short note of what it contained rather than the full payload.

For long-running agents, adopt a compaction step. When the conversation crosses a threshold, have a cheap model condense the older turns into a compact state summary and continue from there. This keeps each turn's input bounded no matter how long the task runs, which is the difference between a cost that grows linearly and one that grows quadratically. Retrieve detail on demand rather than carrying everything: let the agent re-fetch a document by reference instead of holding its full text in context for the whole run.

Batching: when you don't need an answer this second

Not every agent run is interactive. Overnight enrichment, bulk classification, evaluation suites, and report generation can tolerate latency in exchange for a meaningfully lower rate. The Message Batches API processes large sets of requests asynchronously at a substantial discount versus the synchronous path. If a workload is high-volume and not user-facing, batching it is close to free money.

The pattern is to split your agent fleet by latency requirement. Interactive runs go through the live, cached path tuned for speed; background jobs accumulate into batches submitted off-peak. You keep the responsive experience where it matters and move the cheap-and-patient work to the cheap-and-patient lane.

Model routing: right-size each decision

The Claude 4.x family spans Opus 4.8, Sonnet 4.6, and Haiku 4.5, and an agent rarely needs the most capable model for every step. Routing means matching model to task: use Haiku for cheap classification and routing decisions, Sonnet for the bulk of tool-using reasoning, and reserve Opus for the genuinely hard planning or synthesis steps. A common shape is a cheap model that triages and decides whether the heavy model even needs to be called.

Be empirical about it. Route a slice of traffic through a smaller model and compare quality on your evals; if it holds, the savings are immediate and permanent. The failure mode is over-downgrading — pushing a model below the task's real difficulty so it loops or errors, which costs more in retries than the upgrade would have. Let your eval numbers, not vibes, set the boundary.

Single-agent versus multi-agent economics

Multi-agent systems are powerful, but they are not free: spawning subagents typically multiplies token usage several times over a single-agent run, because each subagent carries its own context and the orchestrator pays to coordinate them. Reach for multi-agent when the task genuinely parallelizes or needs isolated context windows, not as a default. For many workflows, a single well-instructed agent with good tools is both cheaper and easier to debug. Decide deliberately, and let the workload — not the architecture's novelty — justify the spend.

Frequently asked questions

What gives the biggest token savings in a Claude agent?

Prompt caching, by a wide margin, because agents resend a large stable prefix on every turn. Put the system prompt and tool definitions at the front, keep them byte-stable, and you pay a steep discount to reuse them across the whole run. Pruning verbose tool results is the natural second step.

When should I use the Batches API?

For any non-interactive, high-volume workload — bulk classification, enrichment, eval runs, report generation. It processes requests asynchronously at a significant discount versus synchronous calls, so route patient background work there and reserve the live path for user-facing turns.

Does multi-agent cost more than single-agent?

Yes — typically several times more, since each subagent carries its own context and the orchestrator pays to coordinate. Use multi-agent only when the task truly parallelizes or needs isolated contexts; otherwise a single well-equipped agent is cheaper and easier to reason about.

How do I keep latency low as a run gets long?

Stabilize your cached prefix so warm reads stay fast, compact older turns into summaries so per-turn input stays bounded, and route simple steps to a smaller, faster model. Latency tracks input size, so anything that shrinks the context shrinks the wait.

Bringing cost-aware agents to the phone

CallSphere runs the same playbook — caching, context pruning, and model routing — under voice and chat agents that answer every call and message, use tools live, and book work 24/7 without the bill ballooning. See the economics in action 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.