Claude API Cost Optimization, 6 Real Levers

Claude API pricing in July 2026

You cannot reason about cuts without the rates. Here are current published Claude prices per million tokens, input and output. Confirm on the Anthropic pricing page before you rely on any number, because they change. To turn these rates into a dollar figure for a given call, use the Claude API cost calculator.

Model               ID                  Input $/M    Output $/M
----------------------------------------------------------------
Claude Haiku 4.5    claude-haiku-4-5    1.00         5.00
Claude Sonnet 4.6   claude-sonnet-4-6   3.00         15.00
Claude Opus 4.8     claude-opus-4-8     5.00         25.00

Cache read: 0.1x input.  Cache write: 1.25x input.  Batch: 50 percent off.
All figures per 1,000,000 tokens. Current as of July 2026.

Read the output column closely. Sonnet output is 3x Haiku output. Opus output is 5x Haiku output. Since output tokens dominate most real bills, the model you assign to a chatty, high volume feature is the single biggest lever you have.

The 6 levers, ranked by impact

1. Pick the right model per task

This is where most of the waste lives. Teams wire up Sonnet or Opus for everything because it is easy, then pay 3x to 5x more than the task needs. Match the model to the job instead.

Use claude-haiku-4-5 for classification, extraction, routing, and short structured outputs. Use claude-sonnet-4-6 for most production work. Reserve claude-opus-4-8 for the cases where quality genuinely demands it, like hard reasoning or long horizon agents.

The gap is real money. A feature classifying 10 million tokens of output a month costs 50 dollars on Haiku, 150 on Sonnet, and 250 on Opus. Same task, same result, 5x spread. Look at reduce your OpenAI costs for the same idea on the other side.

2. Use prompt caching properly

If you resend a large static prefix (system prompt, tools, reference context) on every call, you pay full input price for it every time. Prompt caching fixes that: mark the stable prefix with cache_control and cache reads bill at 0.1x the input rate.

The math is stark. A 10,000 token static prefix on Sonnet costs 10,000 x 3 per million, about 3 cents per call, uncached. Cached, that same prefix reads at 10,000 x 0.1 x 3 per million, about 0.3 cents per call. The cache write costs 1.25x once, so you break even after roughly two calls and every call after is nearly free on that prefix.

const message = await anthropic.messages.create({
  model: 'claude-sonnet-4-6',
  max_tokens: 1024,
  system: [
    {
      type: 'text',
      text: LARGE_STATIC_CONTEXT,       // system prompt + tools + docs
      cache_control: { type: 'ephemeral' },
    },
  ],
  messages,                             // the small, varying part goes last
})

The rule that makes it work: put the large stable content first and the volatile content (the user question, timestamps, per request IDs) last. Caching is a prefix match, so any change near the top invalidates everything after it. Verify it is working by reading cache_read_input_tokens on the response. If that stays zero across identical prefixes, something is silently busting the cache.

3. Trim your system prompts

The system prompt bills on every single call. A bloated one is a tax you pay per request, forever. It is easy to let these grow: an example here, a caveat there, until a 3,000 token prompt is riding along on every message.

On Sonnet, 3,000 tokens is 3,000 x 3 per million, about 0.9 cents per call. That sounds tiny until you multiply by volume: at a million calls a month it is 9,000 dollars, most of it repeated boilerplate the model already understood at half the length. Cut the prompt to what earns its place, and if a large chunk is genuinely static, cache it per lever 2 instead of trimming it.

4. Cap output tokens with max_tokens

Output is the expensive side. On Sonnet, output bills at 5x the input rate. An unbounded max_tokens lets the model ramble to the ceiling, and you pay for every extra token of padding.

Set max_tokens to the shortest value that fits the real answer. A classifier needs maybe 50. A short summary needs a few hundred, not 4,000. This does not degrade quality on scoped tasks; it just stops you paying for output nobody asked for.

await anthropic.messages.create({
  model: 'claude-haiku-4-5',
  max_tokens: 50,                       // a label is short; do not budget for an essay
  messages: [{ role: 'user', content: 'Classify sentiment: ' + text }],
})

5. Use the Batch API for non realtime work

Anything that can wait should not pay realtime prices. The Batch API is 50 percent off both input and output for work you submit and collect later.

Nightly aggregation jobs, evaluation runs, bulk content generation, and one time backfills are all ideal. You cut those costs in half with a one line change to how you submit. The only tradeoff is latency, since a batch can take up to 24 hours, so keep it off anything a user is actively waiting on.

6. Set per user spending caps

Averages hide your problem. A handful of heavy users can consume most of your Claude budget while the median user costs almost nothing. Without a cap, one runaway account, or one abusive one, can blow the whole month.

Set a month to date spending cap per user and per plan. When a user crosses it, block the call or downgrade them to a cheaper model automatically. Caps also contain the worst case for agents, where agent reasoning loops can burn a large amount of tokens very fast before anyone notices.

Optimization without per user visibility is guesswork

Here is the trap. You can apply all six levers and still be flying blind, because the Anthropic console shows one account total. It has never heard of your users, so it cannot tell you which customer or feature is behind the number.

You cannot cut what you cannot see. Optimizing a feature that costs 20 dollars a month while ignoring the one that costs 2,000 is wasted effort. Before you touch a prompt, you need the spend broken down by user and by feature so you optimize the top of the list, not a random entry.

See where the money goes, then cap it, with Weckr

Weckr wraps your existing Anthropic client in two lines and records cost and margin per user and per feature, calculated server side from current pricing. Same call, same Claude response, plus the breakdown the console will never give you:

import Anthropic from '@anthropic-ai/sdk'
import { Weckr } from '@weckr/sdk'

const anthropic = new Anthropic()
const wk = new Weckr({
  apiKey: process.env.WECKR_API_KEY,
  plans: { free: 0, pro: 29, business: 99 },
})

const message = await wk.chat(anthropic, {
  model: 'claude-sonnet-4-6',
  max_tokens: 1024,
  messages,
  userId: user.id,
  feature: 'assistant',
  plan: user.plan,
})

Now you know which users and which features burn the most before you optimize, so you cut the expensive ones first. Weckr also adds per user spending caps that block or downgrade a heavy user automatically, and it detects agent loops so a runaway agent gets flagged instead of quietly running your bill up. See it on seeded data, no signup, at the live demo, and wire it up with the Weckr docs.

FAQ

Cut the waste, then watch it stay cut

The six levers get your Claude bill down fast: right model per task, prompt caching, lean system prompts, capped output, the Batch API for anything that can wait, and per user caps so one account cannot ruin the month. The biggest wins are model choice and caching, so start there.

But cutting once is not the same as staying cut. Costs creep back as usage grows and new features ship. This is one step in the complete guide to AI cost and margin management. See your real per user Claude cost at the live demo.