Cutting Claude Agent Token Costs: Caching and Batching (How Enterprises Build Agents 2026)

An agent that works but costs three dollars per run is a prototype, not a product. The moment you put a Claude agent in front of real volume, token economics stop being an afterthought and become the thing that decides whether the feature ships. The frustrating part is that the cost is usually not where people look. It is not the final answer; it is the dozens of intermediate turns, the giant tool results stuffed back into context, and the multi-agent fan-out that quietly multiplies your bill several times over. This post is about getting all of that under control without lobotomizing the agent.

The mental model that helps most: every token in the context window is paid for on every subsequent turn. An agent that runs twelve turns re-reads its growing context twelve times. So the cost of a run grows roughly with the square of how much you let context accumulate. Cost control is therefore mostly about context discipline — being ruthless about what stays in the window — and about caching the parts that don't change.

Prompt caching is the highest-leverage lever

Prompt caching lets you mark a stable prefix of your context — system prompt, tool definitions, skill instructions, long reference documents — so that the model doesn't reprocess it from scratch on every call. On a multi-turn agent, the system prompt and tool schemas are identical on turn one and turn twenty, yet without caching you pay full input price for them every single turn. With caching, repeated reads of that prefix are billed at a steep discount. For long-running agents this is frequently the difference between viable and unaffordable.

To get the benefit, structure your context so the stable stuff comes first and the volatile stuff comes last. Put your system prompt, tool definitions, and any large unchanging reference material at the top, mark the cache boundary after them, and let the conversation accumulate below. If you interleave changing content into your stable prefix, you invalidate the cache and lose the discount. Architecturally, this rewards a clean separation between "the agent's unchanging brain" and "this run's evolving state."

Batching and the right model for the job

Not every step of an agent needs the most capable model. A common and expensive mistake is running Opus 4.8 for everything when a great deal of the work — classifying an intent, extracting fields, summarizing a tool result, deciding whether a step succeeded — is handled perfectly by Sonnet 4.6 or Haiku 4.5 at a fraction of the cost and latency. Mature agent systems route by difficulty: a cheap fast model handles the routine turns, and the expensive model is reserved for genuinely hard reasoning.

flowchart TD
  A["Incoming step"] --> B{"Hard reasoning needed?"}
  B -->|No, routine| C["Route to Haiku/Sonnet"]
  B -->|Yes| D["Route to Opus"]
  C --> E{"Stable prefix?"}
  D --> E
  E -->|Yes| F["Hit prompt cache"]
  E -->|No| G["Full input billing"]
  F --> H["Batch offline jobs & compact context"]
  G --> H

For workloads that don't need to be real time — overnight enrichment, bulk classification, eval runs over a large dataset — batch processing is the other big saver. Submitting many requests as a batch trades immediate latency for a meaningful per-token discount, which is exactly the right trade for offline agent work. The rule of thumb: if a human isn't waiting on the result, it should probably go through a batch path.

Keeping context small without losing the plot

The single biggest avoidable cost in long agent runs is letting raw tool output pile up in the window. A web search returns ten thousand tokens of HTML; the agent needed one fact from it. If you leave the whole blob in context, you pay for it on every remaining turn. The fix is compaction: after a tool returns, summarize or extract the relevant slice and keep only that, dropping the raw payload. Claude Code does a version of this automatically as context fills, but in your own agents you should design it deliberately.

A related pattern is offloading state to files or a scratchpad instead of the context window. If the agent is working through a long checklist, write the checklist to a file and have the agent read and update it, rather than carrying the entire evolving plan in the prompt. The file is cheap; the prompt is not. This is also why multi-agent designs can save money despite using more total tokens — a subagent does its noisy exploration in its own context and returns only a tight summary to the orchestrator, so the expensive shared context stays lean.

Measure cost like you measure latency

You cannot optimize what you do not see. Every agent run should emit a cost record: input tokens, output tokens, cache-read tokens, which model handled each turn, and the total. Aggregate these and you will quickly find the outliers — the 5% of runs that consume 40% of spend, usually because they hit a loop or dragged a huge document through every turn. Often the cheapest optimization is simply capping pathological runs rather than shaving pennies off the healthy ones.

Treat a cost regression like a performance regression. If a prompt change quietly doubles average tokens per run, you want a dashboard to catch it before the invoice does. Teams that ship affordable agents in 2026 are not using secret models; they are the ones who instrument token usage, route by difficulty, cache aggressively, and keep context tight as a matter of routine engineering hygiene.

Frequently asked questions

What is prompt caching and how much does it save?

Prompt caching stores a processed, stable prefix of your context so repeated calls don't reprocess it from scratch, billing those cached reads at a large discount. For multi-turn agents that reuse a big system prompt and tool set on every turn, it commonly cuts input costs dramatically — the savings scale with how long and how reused that prefix is.

Does using multiple agents always cost more?

Multi-agent runs use more total tokens than a single agent, often several times more, because of coordination overhead. But they can still be cost-effective when each subagent isolates noisy work in its own context and returns only a compact result, keeping the orchestrator's expensive shared context small. Use them deliberately, not by default.

How do I stop tool results from blowing up my context?

Compact them. After a tool returns a large payload, extract or summarize the part you actually need and discard the raw blob before the next turn. Offload long-lived state to files the agent reads on demand. This keeps the per-turn context — which you pay for repeatedly — as small as possible.

When should I batch instead of calling the API live?

Whenever no human is waiting on the result. Overnight data enrichment, bulk classification, and large eval runs are ideal for batch processing, which trades immediate latency for a per-token discount. Reserve live calls for interactive, latency-sensitive steps.

Bringing agentic AI to your phone lines

On a live phone call, cost and latency are the same problem — a cheap, fast agent is also a responsive one. CallSphere brings these efficiency patterns to voice and chat: cached prompts, smart model routing, and tight context so assistants answer instantly, use tools mid-call, and book work 24/7. See it 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.