Mastering Claude Token Costs: Tune Thinking to Control Your API Bill

You open your Anthropic console on a Monday morning. The month's bill shows four times what you budgeted. Nobody on the team ran a giant batch, traffic did not spike, and yet the meter keeps climbing. You dig in and find the real cause: your agent calls Claude Opus on every single request, the model reasons deeply even to rephrase an email, and every bit of reasoning is billed at top rate. I see this happen in almost every engagement where a company moves from a working prototype to real production use.

This bill is not a fixed cost. You can pilot it, lever by lever, without touching the quality your end user perceives. The most misunderstood lever in 2026 is the thinking level: how much Claude "thinks" before it answers. That is where 50 to 80% of avoidable spend usually hides. Here are the levers, from highest payoff to finest tuning, each with the problem, how to do it, and a realistic saving. Everything is based on the real Claude API rates and behavior as of May 2026.

1. Tune the thinking level: lever number one

The trap is letting the model think at full depth everywhere, "just in case". On recent models, extended thinking generates an internal reasoning block before the final answer. That block is counted in tokens, and those tokens are billed as output, so 25 $ per million on Opus. If your model thinks 8000 tokens to rephrase a sentence, you pay 8000 output tokens for nothing.

How to do it: it depends on the model.

On recent Opus models (Opus 4.7 and Opus 4.8), manual budget_tokens tuning is gone, it returns a 400 error. Instead you enable adaptive thinking and steer the depth with a dial:

response = client.messages.create(
    model="claude-opus-4-8",
    thinking={"type": "adaptive"},
    effort=2,  # scale 1 to 5: lower = thinks less = cheaper
    messages=[...]
)

With adaptive thinking, the model decides on its own when to think and how much, based on the request. On a simple task, it barely triggers any reasoning at all. You lower the effort parameter when a task does not deserve deep reasoning, and only raise it for genuinely complex requests.

On models where manual budgeting is still available (Sonnet 4.6, Haiku 4.5), you set the ceiling yourself:

response = client.messages.create(
    model="claude-sonnet-4-6",
    thinking={"type": "enabled", "budget_tokens": 4000},
    messages=[...]
)

Anthropic's official advice: start low (around 4000 tokens), then raise in steps only if quality falls short. Above a 32,000-token budget, returns drop sharply, and the model often does not even use everything you allocate.

Outcome: across a fleet of mixed requests, moving from systematic maximum thinking to depth calibrated per task type routinely cuts output cost by 2 to 4 times. It is the only lever that acts directly on the priciest line of your bill, without changing models or rewriting your product.

2. Pick the right model for each task

The most expensive and most common mistake: running everything on the most powerful model. Opus is remarkable at complex reasoning, but paying for it to classify a support ticket or pull a date out of a PDF wastes a factor of 5 on both input and output.

Here are the real per-million-token rates as of May 2026:

How to do it: segment your calls by actual complexity.

• Haiku for simple volume: classification, structured extraction, tagging, routing, short answers in a closed format.
• Sonnet for the bulk of production: writing, summarizing, customer support, most business tasks.
• Opus reserved for genuinely hard reasoning: architecture, multi-document analysis, decisions where a mistake is costly.

In practice you put a small router upstream: a first simple rule (length, task type, keyword) that sends each request to the right model. You can even use Haiku as the routing classifier, its cost is negligible.

Outcome: moving 70% of volume off Opus onto Sonnet or Haiku cuts the bill for that portion by 2 to 5 times. On a workload where most requests are actually simple, this is often the biggest absolute gain after tuning the thinking.

3. Turn on prompt caching

If you resend the same large block on every call (system instructions, product docs, examples, conversation history), you make it reprocess in full every time, and you pay full input price every time. That is money thrown at identical content.

How to do it: you mark the stable portion of your prompt as cacheable. The API stores that block and rereads it at a slashed price on the following calls. The real multipliers on Claude:

• Cache write (5 minutes): 1.25 times the base input price.
• Cache write (1 hour): 2 times the input price.
• Cache read (hit): 0.1 times the input price, a 90% saving on that portion.

It pays off immediately: with the 5-minute cache, the operation wins from the very first reread. With the 1-hour cache, from the second.

Outcome: on an assistant that repeats a long system context (typically a support agent or an internal copilot), caching routinely shaves 50 to 90% off the input side of the bill. The bigger your fixed context is relative to the variable question, the larger the saving.

4. Switch to batch processing (Batch API)

Plenty of tasks have no need for a real-time answer: generating 500 product descriptions, analyzing a month of NPS verbatims, classifying a ticket export, enriching a database. Yet they get pushed through the synchronous API, at full price, purely out of habit.

How to do it: you group these requests and send them through the Batch API. Anthropic processes them asynchronously (within 24 hours) with a 50% discount on both input and output. And crucially, that discount stacks with prompt caching: a batch with caching active piles both savings on top of each other.

Outcome: all your non-urgent volume goes to half price, with no quality loss, just a processing delay. For a company that runs regular background analyses, moving those jobs to batch halves their cost in one move.

5. Control the context and the output ceiling

Two silent leaks inflate bills without anyone seeing them.

The first: people stack whole documents, full histories, and raw tool outputs into the context, 90% of which does nothing for the answer. Every token sent is billed as input, on every call.

The second: people leave max_tokens very high "to be safe", and the model fills the space with verbose answers. But every output token costs 5 times an input token.

How to do it:

• Prune the context: send only what genuinely serves the request. Retrieve the right passages (search, history summary) instead of dumping everything.
• Cap max_tokens at the length the answer actually needs.
• Ask for structured, concise outputs in the prompt ("answer in 3 bullets", "strict JSON, no commentary").
• Watch one thing on Opus 4.7 and later: their new tokenizer can consume up to 35% more tokens for the same text. Your estimates based on older models need recalibrating.

Outcome: serious context pruning plus a bounded output often cuts the bill by 20 to 40%, on top of the earlier levers. It is the least glamorous lever, and the one people neglect longest.

6. Measure before you optimize

You cannot pilot what you do not measure. Most companies discover their overrun on the monthly bill, a month too late. Yet the usage field returned on every call gives you everything in real time: input tokens, output tokens, cache reads, cache writes.

How to do it:

1. Log the usage of every call with a label (which feature, which model, which task type).
2. Aggregate by day and by feature in a simple table.
3. Spot the 3 cost sources that weigh the most, and apply levers 1 to 5 in that priority order.

You will almost always see the same thing: a handful of features concentrate most of the spend. That is where optimization happens, not in uniform micro-tuning everywhere.

Outcome: you move from a bill you endure to a bill you pilot. You know which feature costs what, you catch a drift in hours instead of a month, and you make your model decisions on numbers, not on a hunch.

And now?

Token cost is not an isolated technical problem, it is a product architecture problem. The right model in the right place, the right thinking per task type, caching on repeated contexts, batching on the non-urgent: put end to end, these levers routinely divide an API bill by 3 to 5 with no quality loss for the user. And they turn a scary expense into a predictable line you pilot down to the number.

The hard part is not technical. It is the diagnosis: knowing which of these levers actually matter in your case, and in what order to attack them so you do not waste a week optimizing a line worth 3% of the bill. Exact rates change, so always check Anthropic's official pricing page before any committing budget calculation.

That is exactly what we do in the Scan of the S3 framework: 30 minutes to look at your real AI usage, find where the money goes, and walk out with the 2 or 3 priority levers for your specific context. No pitch, no commitment. If we find an engagement together afterward, great. If you leave with an optimization plan to run in-house, that works just as well. You can book the slot on solidscale.tech.