Cut Claude analytics agent costs: caching & batching guide

A self-service analytics agent has a cost profile that surprises teams in production. Every question a user asks replays a large, mostly-fixed payload — your system prompt, the tool definitions, a chunk of schema — through the model, and then the agent loops several times calling tools. Multiply that by a few hundred analysts asking a few questions a day each, and the bill that looked trivial in a demo becomes a line item someone asks about. The good news is that almost all of that cost is recoverable, because the expensive parts are the repeated parts, and Claude gives you precise tools to stop paying for the same tokens twice. This post walks through prompt caching, batching, and effort tuning as they apply specifically to a database-querying agent.

Where the tokens actually go

Before optimizing, measure. The naive assumption is that the user's question dominates the input, but in an analytics agent it's usually the smallest part. The system prompt explaining the agent's job, the tool schemas for run_sql and friends, and the injected schema context for the relevant tables together often run tens of thousands of tokens, and every single turn of the agentic loop resends all of it. A three-tool-call question can therefore process your fixed preamble four times. The output side matters too: each intermediate tool result lands back in context and gets reprocessed on the next turn, so a query that returns a thousand rows quietly inflates every subsequent turn.

Claude's usage object is your ground truth here. After each request, inspect cache_read_input_tokens, cache_creation_input_tokens, and input_tokens — the uncached remainder. If you've enabled caching and cache_read_input_tokens is stuck at zero across repeated questions, something in your prefix is changing between requests and silently invalidating the cache. That's the first thing to fix, because no other optimization matters if you're paying full freight on the preamble every time.

Prompt caching: stop paying for your preamble

Prompt caching is a prefix match: Claude caches the prompt up to a marked breakpoint, and any later request whose prefix is byte-identical reads those tokens at roughly a tenth of the normal price instead of reprocessing them. For an analytics agent, this is the headline optimization, because the system prompt, tool definitions, and schema context are exactly the kind of large, stable prefix caching was built for. Put a cache_control breakpoint at the end of your stable system block and the savings can reach the high double digits on input cost.

The discipline that makes it work is keeping the prefix frozen. The render order is tools, then system, then messages, so anything volatile must sit after the stable content, never interpolated into it. The classic mistake in an analytics agent is stamping the current date or the user's name into the system prompt — that one dynamic string at the front invalidates everything downstream. Put the date and per-question detail in the user turn instead. Serialize tool definitions deterministically so a reordered JSON key doesn't break the match, and never swap the tool set mid-conversation, since tools render at position zero and changing them invalidates the entire cache.

flowchart TD
  A["User question arrives"] --> B{"Cacheable prefix unchanged?"}
  B -->|Yes| C["Read system + tools from cache (~0.1x)"]
  B -->|No| D["Pay full write (~1.25x) once"]
  C --> E["Process only the new question"]
  D --> E
  E --> F{"Latency-sensitive?"}
  F -->|Yes| G["Stream + tuned effort"]
  F -->|No| H["Queue into Batches (-50%)"]

Batching the questions that aren't interactive

Not every analytics request needs an answer in two seconds. Nightly metric refreshes, a backlog of saved questions re-run against new data, bulk classification of incoming requests by topic — these are latency-insensitive, and the Batches API processes them at half the standard price. You submit a set of independent requests, Claude works through them asynchronously (most batches finish within an hour), and you poll for results. For an analytics platform, the pattern is to split traffic: interactive questions go through the normal streaming path, while scheduled and bulk work goes through batches and pockets the fifty-percent discount.

Batching composes with caching, which is where it gets genuinely cheap. If a hundred batched questions all share the same large system prompt and schema context, mark that shared block with cache_control once and every request in the batch reads it from cache. You're now stacking a half-price discount on top of a ninety-percent input reduction for the shared portion. The constraint is that batch requests must be genuinely independent — one question's answer can't depend on another's — which fits a workload of "run these fifty saved reports" perfectly.

Effort, model choice, and keeping runs short

The effort parameter is the lever most teams under-use. It controls how much the model thinks and acts before answering, and lower effort means fewer, more consolidated tool calls and less preamble — which for a well-scoped analytics question is often exactly right. A straightforward "sum revenue by region for last quarter" doesn't need maximum deliberation; run it at a lower effort and it resolves in fewer turns at a fraction of the tokens. Reserve higher effort for genuinely open-ended exploration where the agent must form and test hypotheses. Pairing adaptive thinking with a tuned effort level lets Claude decide how hard to think per question rather than burning a fixed budget every time.

Model choice is the other axis. Default to the most capable Opus model for the hard reasoning, but route simple, high-volume sub-tasks — classifying a question's intent, formatting a result, summarizing a table — to a cheaper, faster model. A common architecture keeps the main analytical loop on Opus while a Haiku-class model handles the cheap mechanical steps. Finally, keep results out of context once they've served their purpose: cap row counts returned to the model, summarize large tool results before they re-enter the conversation, and use context editing to prune stale tool outputs so each turn doesn't drag the full history of every prior query.

Putting it together: a cost budget per question

The teams that keep analytics costs predictable set an explicit token budget per question and instrument against it. Count tokens before sending with the token-counting endpoint when you need a pre-flight estimate, cache the fixed prefix, route non-interactive work to batches, tune effort down for routine questions, and watch cache_read_input_tokens to confirm the cache is actually hitting. Each of these is independently worthwhile, but together they routinely take a per-question cost from "someone is going to ask about this" to "rounding error." The key mental model is that an analytics agent's cost is dominated by repetition — the same preamble, the same schema, the same tools, over and over — and every technique here is a different way of paying for that repetition once.

Frequently asked questions

How much can prompt caching actually save on an analytics agent?

For the cached prefix — system prompt, tool definitions, schema context — cache reads cost roughly a tenth of normal input price, so input savings on the repeated portion commonly land in the high double digits. The exact figure depends on how large your fixed preamble is relative to each question; the bigger and more stable the preamble, the larger the win.

Why is my cache_read_input_tokens always zero?

A silent invalidator is changing your prefix between requests. The usual culprits in analytics agents are a timestamp or username interpolated into the system prompt, non-deterministic JSON serialization of tool definitions, or swapping the tool set mid-conversation. Diff the rendered prompt bytes between two requests to find the difference, then move the volatile piece after your cache breakpoint.

When should I use the Batches API instead of normal requests?

Whenever the result isn't needed immediately — nightly refreshes, bulk re-runs of saved questions, large classification jobs. Batches run at half price and most complete within an hour. Keep interactive, user-facing questions on the streaming path and route everything latency-insensitive to batches.

Does lowering effort hurt answer quality?

Not for well-scoped questions. Lower effort produces fewer, more consolidated tool calls and less deliberation, which suits routine aggregations and lookups. Keep higher effort for open-ended, multi-step investigations where the agent genuinely needs to explore. The right move is to tune effort per question type rather than picking one global setting.

The same economics, on the phone

Caching a fixed preamble and tuning effort per request is exactly how you keep a real-time voice agent both fast and affordable. CallSphere applies these agentic cost patterns to voice and chat — assistants that answer every call, pull live data mid-conversation, and book work 24/7 without running up a surprise bill. See how 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.