Turn On Prompt Caching for Anything You Send More Than Once
If your system prompt, tool definitions, or a reference document get sent on every call, you're paying full input-token price for the same text repeatedly. Prompt caching lets you mark a block of context as reusable, so repeat calls within the cache window bill at a fraction of the standard input rate.
The highest-leverage place to start is anywhere with a long, static preamble: agent system prompts, tool schemas, and any large reference document a workflow reuses across many calls. In practice, this looks like marking the static portion of a request explicitly:
{
"system": [
{
"type": "text",
"text": "You are an internal support agent. Follow these 40 lines of policy...",
"cache_control": { "type": "ephemeral" }
}
]
}Teams we've worked with on Anthropic API integration projects typically see this alone cut input-token cost by more than half once caching is wired into the request structure correctly.
Key takeaway: if you're not marking your static context as cacheable, you're re-paying for the same tokens on every call — this is usually the first fix, not the last.
Route by Task Complexity, Not by Default to Your Best Model
Not every call in a production system needs your most capable model. Classification, extraction, short-form rewriting, and simple tool-selection steps often perform just as well on a smaller, cheaper model. The frontier model should be reserved for steps that genuinely require deep reasoning or long-horizon planning.
A simple rule-based routing layer, before you reach for a learned router, can send a large share of a typical agent workflow's calls to a cheaper tier without a measurable quality drop on those specific steps. This is the same logic behind the advisor-executor pattern some AI teams use: a stronger model plans, a cheaper model executes the repetitive parts.
Key takeaway: model routing isn't a quality compromise when it's scoped correctly — it's matching model cost to task difficulty, which a default-to-the-best-model setup never does.
Stop Reinjecting Full Documents and Conversation History Every Turn
Context windows are generous now, which makes it easy to get lazy about what actually needs to be in them. A full document reinjected on every turn, and prior conversation turns kept verbatim, get billed again at full price. The cost compounds with conversation length, not just document size.
Summarizing older turns and referencing documents by retrieval rather than full reinjection keeps the active context lean without losing the information the model actually needs to answer well. This is the same discipline that matters for an internal knowledge base built on Claude — retrieval quality, not context size, is what keeps both cost and accuracy in check.
Key takeaway: a large context window is a capability, not a license to skip context management — the bill scales with what you send, not what the model can technically hold.
Working on something like this? See our Claude Agent Development →
Cap Output Length and Batch What Doesn't Need a Live Response
Output tokens cost more than input tokens on most Claude pricing tiers, and an unconstrained prompt will happily generate a long, hedged answer when a short one would do. Setting an explicit max-token cap and asking directly for the format you want shortens responses without hurting usefulness — this matters most in workflows nobody reads as prose, like classification or structured extraction.
Separately, if a workload doesn't need a live response — nightly enrichment jobs, bulk classification, report generation — batch processing is usually priced well below real-time calls for identical work. The tradeoff is latency, which is irrelevant for anything that isn't blocking a user in the moment.
| Change | Typical Impact | Effort to Implement |
|---|---|---|
| Prompt caching on static context | 50–90% lower cost on cached input tokens | Low — mostly request-structure change |
| Model routing by task complexity | Cost drops to smaller-model rate on routed share | Medium — needs a routing rule or classifier |
| Context trimming / retrieval instead of reinjection | Scales down cost growth as conversations lengthen | Medium — requires a summarization or retrieval layer |
| Output length caps | Modest, consistent reduction on output tokens | Low — a parameter and prompt-format change |
| Batching non-interactive workloads | Meaningful discount vs. real-time pricing | Medium — requires tolerance for async turnaround |
Monitor Cost Per Task, Not Just Total Spend
A dashboard showing total monthly spend tells you the bill grew — it doesn't tell you why. Tagging calls by task type and tracking cost-per-completed-task surfaces which specific workflow is driving the number, so you're optimizing the actual cost driver instead of guessing.
Teams running Claude in production at real scale, including several we've supported through enterprise Claude API integration work, treat this the same way they'd treat any other unit-economics metric: cost per task, not cost per month. That's also the framing worth applying before scaling out a multi-agent workflow, since agent-to-agent handoffs multiply token spend fast if nobody is watching per-task cost from day one.
Key takeaway: the goal isn't a lower total bill in isolation — it's a cost-per-task number you can defend to whoever owns the budget.
