How to Reduce Your Claude API Costs
Claude API bills get big fast when every call runs on the flagship model at full price. This guide shows you how to cut spend with model selection, prompt caching, batch processing, and tighter token usage. You will leave with concrete settings and prompt patterns you can apply to production traffic right now.
Most Claude bills are inflated by three habits: running everything on the most expensive model, re-sending the same context on every call, and asking for more output tokens than the task needs. Each of these has a direct lever. Below is the order of operations that gives you the biggest savings for the least effort. Work top to bottom and stop when the bill is where you want it.
Step 1: Match the model to the job
Model choice is the single largest cost lever, because output tokens are where the money goes and the price gap between tiers is wide. Here is the current per-million-token API pricing so you can do the math before you commit traffic to a model.
- Opus 4.8: $5 input / $25 output (Fast Mode is $10 / $50). Flagship. Best agentic coding and long autonomous runs.
- Sonnet 5: introductory API pricing of $2 input / $10 output per million tokens through August 31, 2026, then $3/$15; the current default on Claude Free and Pro.
- Haiku 4.5: $1 input / $5 output. Fastest and cheapest. 200K context.
Model routing can cut costs only when quality stays inside your threshold. Start general production traffic on Sonnet 5, whose introductory API price is $2 in / $10 out per million tokens through August 31, 2026 and $3/$15 after. Benchmark classification, extraction, summaries, and routing separately, then move high-volume steps only when the cheaper path passes your evaluations.
Fable 5 was restored globally on July 1, 2026 and can be included in cost benchmarks where your account exposes it. Mythos 5 is limited to approved Project Glasswing organizations, so exclude it without confirmed access. Use Sonnet 5 as the generally available API baseline.
Step 2: Turn on prompt caching for repeated context
Prompt caching gives you up to 90% off cached input tokens. If your calls share a stable prefix, a system prompt, a tool schema, a long document, a codebase chunk, or few-shot examples, you are paying full input price to re-send that prefix every single time. Caching it means you pay full price once, then a fraction on every reuse.
- RAG and document Q&A: cache the retrieved document or knowledge base so follow-up questions reuse it.
- Agents and tool use: cache the system prompt and tool definitions across every turn.
- Long-context analysis: cache a large codebase or document set once, then query against it repeatedly.
- Few-shot prompts: cache the examples block that never changes between requests.
Structure your prompts so the stable content sits at the front and the variable content (the user question) sits at the end. Mark the stable prefix for caching. The first call writes the cache, every call after that reads it at a steep discount. For chat sessions and agent loops where the same context is hit dozens of times, this is often the largest single saving after model choice.
Step 3: Batch anything that does not need to be real time
Batch processing is 50% cheaper than standard synchronous calls. The tradeoff is latency: batched jobs run asynchronously rather than returning instantly. For any workload where the user is not waiting on the response, that tradeoff is free money.
- Bulk classification or tagging of a backlog.
- Overnight summarization of documents, tickets, or transcripts.
- Generating embeddings-style enrichment or metadata at scale.
- Evaluation and grading runs over a dataset.
- Any scheduled report or digest that ships on a cadence, not on demand.
Stack the discounts. A batched job on Sonnet 4.6 that also caches a shared document prefix pays the 50% batch rate on top of up to 90% off the cached input. Routing it to Haiku 4.5 instead of Opus compounds the saving again.
Step 4: Control your output tokens
Output is the most expensive token you buy: 5x the input price on every model. Verbose responses are a silent tax. Two things keep output tight: a hard ceiling and an instruction that asks for less.
- Set max_tokens to the smallest value the task can live with. It is a hard cap, not a target.
- Ask for the format you actually want. 'Reply with only the JSON object, no preamble' kills wasted explanation.
- For classification or routing, request a single label or short field, not a paragraph of reasoning.
- Avoid asking the model to restate the question or summarize what it is about to do.
A prompt like 'Classify this support ticket. Respond with exactly one word: billing, technical, or account.' returns a few tokens. The same task phrased openly can return a paragraph that costs 50x as much for no added value.
Step 5: Trim and reuse input context
Opus 4.8 and Sonnet 4.6 both offer 1M-token context at flat rates with no surcharge, which is a real advantage for long-context analysis over big codebases and document sets. But a large context window is not a reason to stuff every call with everything you have. You pay input price on every token you send, every time you send it.
- Retrieve only the relevant chunks for RAG, do not dump the whole corpus when a slice answers the question.
- Prune conversation history in long agent loops instead of resending the full transcript each turn.
- Cache the parts of context that repeat (Step 2) rather than re-paying for them.
- Remember Haiku 4.5 caps at 200K context, so size your prompts to the model you route to.
Step 6: Route by complexity instead of using one model for everything
The cheapest architecture sends each request to the smallest model that can handle it. A simple router can triage incoming work: send extraction, classification, and short-form tasks to Haiku 4.5, send general work to Sonnet 4.6, and escalate only the genuinely hard agentic or coding tasks to Opus 4.8. You can even use a cheap model to decide which tier a request belongs in.
A simple routing pattern
- Tier 1 (Haiku 4.5): tagging, routing, extraction, short summaries, high volume.
- Tier 2 (Sonnet 5): starting point for production assistants, RAG answers, and drafting; measure before routing to another model.
- Tier 3 (Opus 4.8): agentic coding, long autonomous runs, planning-heavy tasks.
Most teams find the majority of their volume belongs in Tier 1 or Tier 2. Moving that traffic off Opus is usually the difference between a comfortable bill and a painful one.
Step 7: Measure, then cut the biggest line item first
Do not optimize blind. Instrument your calls so you can see spend by model, by feature, and by input-versus-output split. Then attack in this order: move the most expensive traffic to a cheaper model, cache the largest repeated prefix, batch whatever can run async, and tighten the most verbose outputs. Re-measure after each change so you know which lever actually moved the number.
Use the token counting endpoint to estimate cost before you ship a new prompt to production. Knowing a prompt is 40K input tokens before it runs at scale beats discovering it on the invoice.
Get the Claude playbook in your inbox.
One weekly email for Claude and Claude Code users. Real workflows, no hype. Subscribe and we send you The Claude Power-User Cheatsheet.