Cutting Token Cost on Claude Compliance Agents

An agent that audits your AWS accounts for evidence can be genuinely useful — or it can quietly cost you hundreds of dollars a day because every run re-reads the same policy documents, re-summarizes the same control catalog, and ships a multi-agent fan-out where a single agent would do. Security and compliance work is verbose by nature: long policies, big scan outputs, repetitive evidence collection. That makes it the ideal place to get serious about token cost.

This post is about keeping Claude agents that touch security and compliance tools both fast and cheap. We will cover prompt caching, request batching, result shaping, and model routing — and where each one actually moves the needle versus where it is a distraction.

Where the tokens actually go

Before optimizing, measure. In a typical compliance agent, token spend concentrates in three places. The system prompt and tool definitions, which are re-sent on every single turn and are often enormous when you have a dozen security tools loaded. The tool results, especially raw scan and log output that the model has to read in full. And multi-agent orchestration, where an orchestrator spawns several subagents that each carry their own copy of the shared context.

The mistake teams make is optimizing the model choice first. Switching Opus to Haiku saves on per-token price but does nothing about the fact that you are re-sending a 12,000-token tool catalog forty times per run. Fix the structural waste before you touch the model.

Prompt caching: the highest-leverage lever

Prompt caching lets you mark a stable prefix of your request — system prompt, tool definitions, long reference documents like your control framework — so that on subsequent calls Claude reads it from cache at a large discount instead of reprocessing it. For a compliance agent that references the same NIST or control catalog on every turn, this is transformative, because that catalog is both large and unchanging within a run.

The rule is to order your prompt from most-stable to least-stable. Put tool definitions and reference docs first and mark the cache breakpoint after them; put the volatile per-turn content (the latest tool result, the user's evolving request) after the breakpoint. Get this ordering wrong — interleave a changing timestamp into your "stable" prefix — and you invalidate the cache on every call and pay full price.

flowchart TD
 A["Build request"] --> B["Stable prefix: tools + control catalog"]
 B --> C{"Prefix in cache?"}
 C -->|Yes| D["Read prefix from cache (cheap)"]
 C -->|No| E["Process prefix & write cache"]
 D --> F["Append volatile turn data"]
 E --> F
 F --> G["Claude reasons & calls tool"]
 G --> H["Shape result, loop or finish"]

Shape tool results before they reach the model

The second-biggest win is refusing to feed raw security output into context. A vulnerability scan might return 4,000 findings as JSON; the model does not need all of it to write an audit summary. Do the aggregation in the MCP server or tool wrapper: collapse findings into counts by severity, dedupe by CVE, and return a handful of representative examples plus a link to the full dataset. Result shaping is the practice of transforming a tool's raw output into the smallest structured form that still supports the agent's decision.

This matters even more than it sounds, because tool results are read on every subsequent turn until they fall out of context. A 30,000-token raw scan that the agent references three more times effectively costs four times its size. Shaping it down to 800 tokens compounds across the whole run.

Batch the work instead of looping the agent

Compliance tasks are often embarrassingly parallel: check the same control across 50 accounts, validate the same policy against 30 repositories. The naive approach runs the agent in a loop, paying for the full system prompt and tool catalog on every iteration. The better pattern is to batch — collect the inputs, run the deterministic data-gathering once, and ask Claude to evaluate the whole set in a single structured pass.

For genuinely independent, long-running checks, Anthropic's batch processing path lets you submit many requests for asynchronous completion at a reduced rate, which suits overnight evidence collection where latency does not matter. The discipline is to separate the work that needs an interactive agent from the work that is really bulk classification, and route the bulk to a cheaper, batched path.

Route models by task, not by habit

Not every step needs Opus. A good compliance agent uses a tiered approach: Haiku or Sonnet for high-volume, low-judgment steps like extracting fields from a config or classifying a finding's severity, and Opus only for the steps that require real reasoning, like deciding whether a set of controls collectively satisfies an audit requirement. Because the latest family spans Opus 4.8, Sonnet 4.6, and Haiku 4.5, you have a real cost-capability spectrum to route across.

The orchestrator-subagent pattern fits this naturally: a capable orchestrator plans and delegates, while cheaper subagents execute narrow, well-specified subtasks. Just remember that multi-agent runs typically use several times more tokens than a single agent, so reach for fan-out only when the parallelism genuinely pays for itself — auditing 50 accounts at once, not summarizing one policy.

Frequently asked questions

What gives the biggest token savings on a Claude compliance agent?

Prompt caching the stable prefix — tool definitions and your control catalog — usually wins, because that content is large and re-sent every turn. Result shaping is a close second since raw scan output is read repeatedly until it leaves context.

Does switching from Opus to Haiku fix high costs?

Only partly. Cheaper models lower per-token price but do not address structural waste like re-sending huge tool catalogs or feeding raw scan output into context. Fix the structure first, then route low-judgment steps to Haiku or Sonnet.

When should I use batch processing instead of an interactive agent?

When the work is bulk and latency-tolerant — overnight evidence collection, classifying thousands of findings. Asynchronous batch submission runs at a reduced rate and avoids paying interactive-loop overhead per item.

How do I keep prompt caching from silently breaking?

Order your prompt most-stable to least-stable and place the cache breakpoint after the unchanging content. Never let volatile values like timestamps leak into the cached prefix, or you invalidate the cache and pay full price every call.

Fast, cheap agents on every conversation

CallSphere applies the same caching and result-shaping discipline to voice and chat agents, so each call stays fast and affordable while still using live tools. See it 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.