Claude API Cost Optimization: Find Where the Tokens Go, Then Pick the Lever (2026)

Claude API cost optimization works best in two steps: first read the usage object on your own responses to see which token bucket dominates the bill, then apply the lever that targets that bucket. Output tokens cost five times as much as input on current models, so the right fix depends on your cost profile, not on a generic checklist.

Most "reduce your Claude bill" advice jumps straight to caching and batching. Both are real, but they only move specific buckets. If your spend is dominated by long answers, caching the prompt changes little; if it is dominated by tool definitions and images, a cheaper model helps less than you expect. This guide is the diagnosis step that comes first. For the rate table itself, see our Claude API pricing breakdown.

All prices and multipliers below are quoted from Anthropic's official pricing page (platform.claude.com/docs/en/about-claude/pricing) as of September 2026. Rates change, so treat the numbers as a snapshot and re-check the source before you budget.

Step 1: Measure where Claude API cost actually comes from

Every Messages API response carries a usage object. Depending on the features you use, it can contain:

The multipliers come from Anthropic's pricing page. The point of the table is that one request can land in four different price buckets, and the rest of this article is about moving tokens out of the expensive ones.

Log the whole usage object per request, tagged with a route name (for example classify, chat, agent-step). Then, over a representative day, sum each field per route and convert to money:

RATES = {  # USD per million tokens, from Anthropic's pricing page (Sept 2026)
    "claude-opus-5":    {"in": 5.0, "out": 25.0},
    "claude-sonnet-5":  {"in": 2.0, "out": 10.0},
    "claude-haiku-4-5": {"in": 1.0, "out": 5.0},
}

def cost_breakdown(model, u, cache_write_mult=1.25):
    r = RATES[model]
    parts = {
        "input":       u.get("input_tokens", 0) * r["in"],
        "cache_write": u.get("cache_creation_input_tokens", 0) * r["in"] * cache_write_mult,
        "cache_read":  u.get("cache_read_input_tokens", 0) * r["in"] * 0.1,
        "output":      u.get("output_tokens", 0) * r["out"],
    }
    return {k: v / 1_000_000 for k, v in parts.items()}

Sum the four parts across a route's traffic and look at the shares. One bucket usually carries most of the cost, and that bucket tells you which of the profiles below you are in. If you route traffic through a gateway, its per-request usage log gives you the same fields without extra instrumentation; our note on reading usage records explains how those map.

Step 2: Match your cost profile to the right lever

Profile A: output-heavy

Symptom: output_tokens dominates. Typical for long-form generation, verbose explanations, and agent loops.

Because output is priced at five times input on Opus 5, Sonnet 5 and Haiku 4.5 alike (per Anthropic's rate table), trimming output moves the bill fastest.

• Lower effort where quality holds. Anthropic documents output_config.effort with levels low, medium, high (the default), xhigh and max, and states that it affects all output tokens, including text, tool calls and thinking. Sweep lower levels on your own evaluation set per route rather than globally.
• Ask for shorter answers explicitly. On Claude Opus 5, Anthropic notes that changing effort does not reliably shorten the visible response, and recommends prompting for length instead. A stated format ("answer in three bullet points", "return only the JSON") is a cost control.
• Do not treat max_tokens as a saving. It is a ceiling, not a target. You pay for what is generated; a lower cap only truncates, and a truncated answer that gets retried costs twice.

Profile B: input-heavy with a stable prefix

Symptom: large input_tokens on every call, and most of it is the same system prompt, documents or tool list.

This is the profile prompt caching was designed for. According to Anthropic, a cache hit costs 10% of the base input price, and caching pays off after one read for the 5-minute cache or two reads for the 1-hour cache. Check the result in usage: if cache_read_input_tokens stays at zero on repeat calls, the cache is not hitting. Our prompt caching guide covers the silent invalidators.

One interaction worth knowing: Anthropic states that changing the top-level effort value between requests invalidates prompt caching, so within a cached conversation, pick an effort level and keep it constant.

Profile C: input-heavy because of growing history

Symptom: input_tokens climbs with every turn of a conversation or agent loop.

The Messages API is stateless, so each request resends the full history. Every new turn pays again for all the turns before it, so the total cost of a long conversation grows much faster than its length unless you intervene. Options, cheapest first:

1. Keep the history append-only so each new turn can reuse the cached prefix from the previous one.
2. Summarise or drop old turns that no longer matter to the task.
3. Return trimmed tool results. A tool that dumps a full file or page into the context bills those tokens on every later turn.

Long context does not carry a surcharge on newer models: Anthropic states that Claude 4.6 and later include the full 1M-token window at standard pricing. That removes a cliff, not the cost; a 900k-token request is still 900k tokens. See our explainer on the Claude API context window for what fills it.

Profile D: overhead from tools, images and search

Symptom: input looks larger than the text you wrote. This is the profile most teams miss, because the tokens come from features rather than from prompts.

• Tool definitions. When a request includes tools, the API adds a tool-use system prompt. Anthropic's pricing page lists it per model: 286 tokens for Claude Opus 5, 354 for Claude Sonnet 5 and 496 for Claude Haiku 4.5 with tool_choice set to auto or none, plus the names, descriptions and schemas you send. Only attach the tools a route actually needs.
• Images. Anthropic's vision documentation states an image costs ceil(width/28) x ceil(height/28) visual tokens, capped per model. Claude 4.7 and later process up to 2576 px on the long edge (up to 4784 visual tokens), and Anthropic's own example puts a 4K image at about $23.92 per thousand on Opus 5 versus about $6.48 for a 1000x1000 image. Downsample before sending unless you need the detail.
• Web search. Anthropic charges $10 per 1,000 searches plus tokens, and search results stay in context as input tokens on later turns. Web fetch has no per-call fee, but fetched pages become input; Anthropic suggests the max_content_tokens parameter to cap them.

Profile E: asynchronous volume

Symptom: large jobs where nobody waits for the answer, such as nightly enrichment, evaluations and bulk classification.

Anthropic's Batch API applies a 50% discount on both input and output tokens, and the pricing page states the batch discount stacks with prompt caching multipliers. The trade is latency. Our batch processing guide covers the processing window and result ordering.

Step 3: Check the model choice last, not first

Model tiering is a real lever. Per Anthropic's rate table, Claude Haiku 4.5 costs $1 input and $5 output per million tokens, Claude Sonnet 5 costs $2 and $10, and Claude Opus 5 costs $5 and $25. Anthropic's own cost guidance is to use Haiku for simple tasks, Sonnet for most production workloads and Opus for the most complex reasoning.

It comes last because it interacts with everything above. Two details to check before you switch:

• Tokenizer differences. Anthropic states that Claude 4.7 and later models use a newer tokenizer that produces approximately 30% more tokens for the same text. A cheaper per-token rate on a different tokenizer is not a like-for-like comparison. Re-count with the count_tokens endpoint against the model you plan to use; Anthropic lists token counting as free, subject to its own rate limits.
• Hidden multipliers. Pinning inference_geo to "us" applies a 1.1x multiplier on Claude 4.6 and later, and fast mode on Opus 5 is billed at $10 input and $50 output per million tokens. Both are legitimate choices; just make sure they are deliberate ones.

If you are still comparing providers, our Claude vs GPT API comparison covers the integration differences that sit alongside price.

A one-page Claude API cost optimization checklist

Change one lever at a time and compare a day of usage before and after. Stacking three changes at once makes it impossible to tell which one mattered, or which one quietly hurt quality.

If you want to inspect streaming responses while you measure, note that the final usage counts arrive in the message_delta event and are cumulative; our streaming guide shows where to read them. For a first working request to test against, see how to use the Claude API.

FAQ

What is the fastest way to reduce Claude API cost?

Find the dominant bucket in your usage data first. If output dominates, lower effort and ask for shorter answers; if a stable prompt dominates, enable prompt caching. Applying a lever to the wrong bucket saves little.

Does lowering max_tokens reduce Claude API cost?

Not directly. You are billed for tokens actually generated, and max_tokens is only a ceiling. Setting it too low truncates answers, which often leads to retries that cost more.

Can prompt caching and the Batch API be used together?

Yes. Anthropic's pricing page states that prompt caching multipliers stack with the Batch API discount, so a batched request with a cached prefix gets both.

Why did my bill rise after switching to a newer Claude model at the same price?

Anthropic states that Claude 4.7 and later use a tokenizer that produces approximately 30% more tokens for the same text. Re-count your prompts with count_tokens against the new model before comparing costs.