Cutting Claude agent token cost in financial workflows

A reconciliation agent we shipped for a payments team looked great in the demo and terrible on the invoice. Each run pulled the full chart of accounts, a policy document, and three months of transaction context into the prompt, then asked Claude to reason over all of it — every single run, from scratch. Multiply that by thousands of nightly reconciliations and the token bill alone made the project hard to justify. The agent was correct. It was just wildly wasteful. Performance and cost are not afterthoughts in financial deployments; they often decide whether an agent ships at all.

The good news is that agent cost is highly compressible once you understand where tokens go. Most of the spend in a typical Claude financial agent is not the model's clever reasoning — it is repeated, redundant context shoveled into the window on every turn. This post is about the levers that actually move the needle: caching, batching, model routing, and disciplined context management. Used together they routinely cut cost and latency without touching output quality.

Where the tokens actually go

Before optimizing, measure. Instrument every run to record input tokens, output tokens, and the breakdown per turn. When teams do this for the first time, the result is almost always surprising: the model's own generated text is a small fraction of the bill. The bulk is input — system prompts, tool definitions, retrieved documents, and the growing transcript that gets re-sent on every turn of a multi-step run. A ten-turn agent re-sends most of its context ten times, so a 30,000-token base prompt becomes 300,000 input tokens before the agent does anything interesting.

A useful definition: prompt caching is a mechanism that stores the processed form of a stable prompt prefix so that repeated requests reusing that prefix are served far faster and at a fraction of the input-token cost. In finance, your system prompt, compliance policies, tool definitions, and reference data are largely stable across runs and across turns — exactly the kind of content caching is designed for.

Cache the stable prefix, change only the tail

The structural move that pays for itself fastest is ordering your prompt so everything stable sits at the front and only the per-request specifics sit at the end. Put the system prompt, tool schemas, compliance rules, and reference tables in the cacheable prefix. Put the specific account, the specific query, and the live transaction data in the variable tail. Then mark the prefix for caching. Now a multi-turn run pays full price for the prefix once and a steep discount on every subsequent turn that reuses it.

flowchart TD
  A["Incoming agent request"] --> B["Assemble prompt: stable prefix + variable tail"]
  B --> C{"Prefix in cache?"}
  C -->|Yes| D["Reuse cached prefix, pay only for tail"]
  C -->|No| E["Process full prompt, write prefix to cache"]
  D --> F{"Task simple & bounded?"}
  E --> F
  F -->|Yes| G["Route to Haiku"]
  F -->|No| H["Route to Sonnet / Opus"]
  G --> I["Return result, log tokens"]
  H --> I

The discipline here is keeping the prefix genuinely stable. If you inject a timestamp or a per-run ID near the top of the prompt, you invalidate the cache for every request and lose the benefit entirely. Treat the cacheable prefix like a build artifact: it changes when policies or tools change, not on every run. I've seen a single misplaced dynamic value silently erase most of the savings, so verify cache hit rates in your token logs rather than assuming.

Route by difficulty: not every step needs Opus

The second lever is model routing. The Claude family spans Opus 4.8, Sonnet 4.6, and Haiku 4.5, and they differ enormously in cost and speed. Using the most capable model for every step is like sending a senior analyst to fetch coffee. Many sub-tasks in a financial agent — classifying a transaction type, extracting a date from a document, deciding which tool to call next — are well within Haiku's range and run for a fraction of the cost and a fraction of the latency.

The pattern I use is tiered: a fast model handles routing, classification, and extraction, and escalates to a stronger model only for genuinely hard reasoning like resolving a discrepancy or explaining a regulatory judgment. In an orchestrator–subagent design this falls out naturally — subagents doing mechanical work run on Haiku, while the orchestrator that synthesizes their findings and makes the consequential call runs on Sonnet or Opus. The cost curve bends sharply when most turns happen on the cheap tier.

Batch the work that doesn't need to be live

A great deal of financial agent work is not interactive. Nightly reconciliations, end-of-day transaction categorization, monthly statement summarization — none of these need a sub-second response. For this class of work, batch processing trades latency for a substantial cost reduction. Rather than firing thousands of individual real-time requests during business hours, you queue them and submit them as a batch that completes within a window. The per-token economics improve and you stop competing with your own interactive traffic for capacity.

The architectural implication is to separate your agent's interactive path from its bulk path early. A customer-facing agent answering a balance question needs live latency. A back-office agent categorizing yesterday's settlements does not. Routing the bulk work through a batch queue, and reserving real-time calls for genuinely interactive moments, is one of the cleanest cost wins available and it requires no change to the model or prompts at all.

Keep context lean as the run grows

The final lever is context discipline across long runs. As an agent works, its transcript grows, and every turn re-sends that transcript. Left unchecked, a long-running financial investigation can balloon its own context until each turn is expensive and slow. The countermeasure is summarization and pruning: periodically compress earlier turns into a compact running summary, drop raw tool outputs you've already extracted what you need from, and carry forward only the facts the agent still needs.

This is where subagents shine again. A subagent can do a heavy, context-hungry task in its own isolated window and return only a tight summary to the orchestrator, so the orchestrator's context never absorbs the full weight of every sub-task. The result is an agent that stays fast and cheap even on long, multi-step financial workflows, because no single context window ever has to hold everything at once. Cost control, in the end, is mostly context architecture.

Frequently asked questions

How much can prompt caching save on a Claude agent?

It depends on how much of your prompt is stable, but in financial agents the system prompt, tool schemas, and policy text are usually a large, fixed share of every request. Caching that prefix means you pay full price for it once and a steep discount on every reuse across turns and runs, which is where most of the savings come from.

When should I use Haiku instead of Opus in a financial agent?

Use the fast tier for bounded, mechanical sub-tasks — classification, extraction, routing decisions — and reserve the stronger models for consequential reasoning like resolving discrepancies or making compliance judgments. Tiered routing keeps most turns on the cheap model while preserving quality where it matters.

What's the difference between batching and real-time agent calls?

Real-time calls return quickly and suit interactive work like answering a customer's balance question. Batch processing queues many requests to complete within a window at lower per-token cost, which fits non-interactive bulk work like nightly reconciliation. Separate these paths early in your architecture.

How do I stop a long agent run from getting expensive?

Manage context actively: summarize earlier turns into a compact running summary, prune raw tool outputs once you've extracted what you need, and push heavy sub-tasks into subagents that return only tight summaries. This keeps any single context window small even on long workflows.

Bringing agentic AI to your phone lines

CallSphere applies the same cost discipline — caching, tiered models, and lean context — to voice and chat agents that handle high call volumes affordably while using tools mid-conversation. 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.