Cutting Claude Agent Token Costs in Finance Pipelines

A risk-scoring agent we built re-read the same 40-page underwriting policy on every single turn. Forty pages, four hundred times a day, at full input price — for a document that hadn't changed in eight months. The agent was correct. It was also quietly the most expensive line item in the whole system, and almost all of that spend was waste. In financial services you can't trim cost by cutting corners on correctness; an agent that skips a verification step to save tokens is worse than useless. So the real engineering question is narrower and more interesting: how do you make a verifiable Claude agent cheap and fast without touching what it checks?

The answer comes down to three levers that compound: caching the parts of the prompt that don't change, batching the work that isn't latency-sensitive, and keeping the live context lean so you're not paying to re-process history. Get all three right and a long-running financial agent can run most of its tokens at a tenth of list price while finishing in a fraction of the wall-clock time.

Where the money actually goes

Before optimizing, instrument. Every Claude response carries a usage block, and the three fields that matter are input_tokens (full price), cache_creation_input_tokens (the ~1.25x write premium), and cache_read_input_tokens (roughly a tenth of base price). If you've been ignoring these, the first surprise is usually that input_tokens dwarfs output_tokens by an order of magnitude. Agents are input-heavy: every turn re-sends the system prompt, the tool definitions, and the entire conversation so far. Output is a rounding error next to that growing prefix.

The second surprise is that the prefix grows superlinearly in effect. A twenty-turn reconciliation run doesn't pay for its history once — without caching it pays for turn one's context on turn one, turns one-and-two on turn two, and so on. That triangular cost is exactly what prompt caching collapses, which is why it's the first lever, not the last.

Caching the stable prefix

Prompt caching is a prefix match: Claude hashes the rendered prompt up to each cache_control breakpoint, and any byte change anywhere before the breakpoint invalidates everything after it. Render order is tools, then system, then messages. So the design rule writes itself — put the things that never change at the front. The 40-page underwriting policy, the frozen system prompt, the deterministic tool list: all of that belongs before your last breakpoint, and a single breakpoint on the final system block caches tools and system together.

The failure mode here is the silent invalidator. Interpolate datetime.now() into the system prompt, serialize a dict without sorting keys, or vary your tool order per request, and your cache-read tokens quietly stay at zero while you wonder why nothing got cheaper. The verification is one line: log cache_read_input_tokens across repeated requests with the same prefix. If it's zero, diff the rendered bytes of two requests and find the thing that changes. In a financial agent the usual culprit is a "current as of" timestamp helpfully stamped into the policy header — move it into the user turn and the cache lights up.

flowchart TD
  A["Incoming agent request"] --> B["Render: tools > system > messages"]
  B --> C{"Prefix byte-identical to a cached entry?"}
  C -->|Yes| D["cache_read ~0.1x price"]
  C -->|No| E{"Prefix >= min cacheable size?"}
  E -->|No| F["Full price — too short to cache"]
  E -->|Yes| G["cache_write ~1.25x, served cheap next time"]
  D --> H["Run turn, append result"]
  G --> H

Batching the work that can wait

Not every financial task needs an answer in two seconds. Overnight portfolio classification, end-of-day transaction categorization, bulk document extraction across a backlog of statements — these are throughput problems, not latency problems, and the Message Batches API exists for exactly them: the same Messages API features at 50% of standard price, with most batches finishing inside an hour. For a nightly job that classifies ten thousand transactions, halving the per-token rate is found money, and the latency you're trading away was never being used.

Batching and caching stack cleanly. Put your shared classification rubric or chart of accounts in the system prompt with a cache breakpoint, then fire every transaction as a separate request in the same batch — the shared prefix caches across the batch, and the whole batch runs at the discounted rate. The two discounts multiply rather than compete. The discipline is simply deciding, per workload, whether a human is waiting on the result. If not, it belongs in a batch.

Right-sizing the model and the effort

Cost isn't only about token price; it's about token count, and the effort parameter is the lever there. Lower effort produces fewer, more consolidated tool calls and terser reasoning — which on a well-scoped task means fewer round trips and a smaller bill. The trap is treating effort as a global setting. Sweep it per route against your eval set: a balance-lookup subtask might run perfectly at low effort while the reconciliation that depends on it needs high. Combine that with adaptive thinking so the model decides per request how much to reason rather than always reasoning at the ceiling.

Model choice is the coarser version of the same idea. The most capable Opus model is the right default for the reasoning-heavy core of a financial agent, but a high-volume, narrow subtask — a yes/no compliance flag, a single-field extraction — often runs faster and cheaper on a smaller, faster model spawned as a subagent. Keep the main loop on one model to preserve its cache (switching models mid-session invalidates everything), and delegate the cheap narrow work to a cheaper model in a separate call.

Keeping context lean over long runs

A financial agent that runs for an hour accumulates a transcript that eventually crowds the context window and inflates every turn. Two server-side tools fix this without you hand-rolling a summarizer. Context editing prunes stale tool results and completed thinking blocks once they cross a threshold, keeping the live transcript small. Compaction goes further: as you approach the window limit, the API summarizes earlier context into a compaction block. The one rule you cannot break is appending the full response.content — including the compaction block — back into your messages on the next turn; extract only the text and you silently drop the compaction state, and the next request balloons back to full size.

The net effect is that the prefix you pay to re-process stays bounded even as the agent works for an hour. Combined with caching the frozen head and pruning the stale tail, you end up paying full price only for the genuinely new tokens each turn — which is the theoretical floor.

Frequently asked questions

Will caching ever hurt me on a verifiable agent?

Only economically, and only if you cache prefixes that aren't reused. A cache write costs ~1.25x, so a prompt fired once is more expensive cached than not. Caching never changes what the model sees — the bytes are identical whether read from cache or processed fresh — so it can't affect a verification step's correctness. Cache the shared, repeated context; leave one-off prompts alone.

How do batching and real-time requests coexist in one system?

Cleanly — they're different endpoints. Route latency-sensitive work (a customer waiting on a chat answer) through the standard Messages API and shove everything asynchronous (nightly categorization, backfills, bulk extraction) into batches. The same prompts, tools, and cached prefixes work in both, so you're not maintaining two codebases — just choosing the endpoint per workload.

What's the highest-leverage first move?

Add a cache breakpoint to your frozen system prompt and verify cache_read_input_tokens goes non-zero. For an input-heavy agent re-sending a large stable prefix every turn, that single change typically removes the largest share of waste before you touch batching or effort at all.

Bring efficient agents to your phone lines

Cost discipline matters even more at voice scale, where every call is a live, tool-using session. CallSphere applies these caching and context patterns to voice and chat agents that answer 24/7 without runaway token bills — 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.