Claude API pricing, explained by the invoice and not the price list

The Anthropic pricing page is one of the cleanest in the API business. It tells you exactly what each model costs per million tokens. It also tells you almost nothing about what your invoice at the end of the month will be. The price list is the rate. The invoice is the rate times a set of multipliers you only discover by running traffic.

This post is the one I wish I had before I shipped my first Claude integration. It covers the cost multipliers the price list hides, a way to estimate cost before you build, and the order in which to apply the cost levers once you're live. I'm not going to quote exact dollar figures, because Anthropic changes them. I'll give you the ratios, which have stayed stable for two years.

What the price list shows, and what it hides

The price list shows you three numbers per model: input cost, output cost, and (on supported models) cache write and cache read. Multiply by your token count, apply your volume, you have a bill. Done.

In practice, your bill is shaped by five things the price list doesn't show:

1. Conversation history. Most production Claude traffic isn't a single request/response. It's a session. Turn 1 sends the system prompt and the first user message. Turn 2 sends the system prompt, turn 1's user message, turn 1's assistant reply, and turn 2's user message. Turn N sends everything since the beginning. If you don't truncate, every turn pays for every previous turn. After 10 turns you've billed yourself 10× for the system prompt.

2. Tool definitions. If you're using Anthropic's tool use feature (function calling), the tool definitions are part of the input. A reasonable agent setup with 5 to 15 tools is 1K to 4K tokens of definitions every call, every turn, on every retry. Tool definitions are invisible in the price list because the price list just charges per token; you don't see them as a separate line item.

3. Output tokens cost roughly 5× input. The price list shows the ratio. What it doesn't show is that outputs are also harder to predict. You write 100 tokens of input. The model writes 800 tokens of "let me think step by step" before the actual answer. You just paid for 800 tokens at 5× the input rate. Output tokens are the line item that surprises teams the most.

4. Retries and fallbacks. If a request fails, you retry. If you're using a fallback model (Opus to Sonnet to Haiku), you might pay for the failed Opus call and the successful Haiku call. If you have an evaluation step that calls the model again to check the first call's output, that's a second billable call.

5. Streaming vs non-streaming. Both bill the same per token. But streaming hides output cost: your user might close the tab mid-stream, but you paid for the full generation. With a non-streaming call you know exactly what you generated. With streaming you only know what the network received, which can differ.

These are not exotic failure modes. They are the default for any non-trivial Claude integration.

Estimating before you build

Most teams estimate cost by guessing. Guessing is fine for the first 10× of traffic; it's catastrophic at 100×. The minimum useful estimate needs three numbers:

# Inputs
model = "claude-sonnet"
avg_input_tokens_per_call = 8000      # system prompt + tools + history + user msg
avg_output_tokens_per_call = 1500     # measured, not guessed
calls_per_day = 20000

# Ratios (check the current pricing page for exact rates)
input_rate_per_million = 3.0
output_rate_per_million = 15.0        # roughly 5x input on current Sonnet

# Calculation
daily_input_cost  = calls_per_day * avg_input_tokens_per_call  / 1_000_000 * input_rate_per_million
daily_output_cost = calls_per_day * avg_output_tokens_per_call / 1_000_000 * output_rate_per_million
monthly_cost      = (daily_input_cost + daily_output_cost) * 30

print(f"Daily input:  ${daily_input_cost:.0f}")
print(f"Daily output: ${daily_output_cost:.0f}")
print(f"Monthly:      ${monthly_cost:.0f}")

Run that with honest numbers from a single test session, multiply by the daily call volume you expect, and you have a starting estimate that will be within 2× of the real bill. If you can't fill in avg_input_tokens_per_call and avg_output_tokens_per_call from real calls, you're not ready to estimate. Make the calls first.

Two traps:

• Output tokens are usually higher than you think. Reasoning models ("let me think step by step") can produce 2K to 5K tokens before the final answer. If you're using extended thinking, that's a separate line item that runs at output rates but is easy to miss in the usage dashboard.
• History growth is nonlinear. A 5-turn conversation is roughly 5× the input tokens of a single turn, not 1.5×. If your sessions average 10 turns and you don't truncate, your "input" budget is 10× your per-turn input.

Levers, in order of impact

The order in this table is the order I apply them in. Each row compounds on the rows below it.

I'll walk through the top four.

1. Prompt caching first

This is the biggest single lever and the only one that doesn't trade off against quality. If your integration reuses any prefix more than twice within 5 minutes, you should be caching it. I wrote a full post on prompt caching that covers the mechanics, the gotchas, and the cases where caching actively hurts. The TL;DR: cache a stable prefix (system prompt, tool definitions, large reference content), leave variable content (user messages, retrieved documents specific to the query) outside the cache boundary, and measure cache_read_input_tokens in your usage logs to verify hits.

A cache hit costs roughly 10% of the normal input price. If half your input tokens come from cache hits, your input line item drops by ~45%. That alone can cut the total bill by a third on typical workloads.

2. Right model per task

Most teams default to one model for the whole product and ship. That's a mistake. The price list shows a 50 to 75× spread between Haiku and Opus, and the quality spread is much smaller than that for many tasks. A routing layer that sends classification, extraction, and short summarization to Haiku, default Q&A to Sonnet, and only the hard reasoning tasks to Opus, typically cuts the bill by 5 to 10× without changing user-perceived quality.

The risk is variance. Opus and Sonnet fail differently. Build an eval set before you route. Don't ship a router that you haven't measured against your actual task distribution.

3. Truncation before you cache

Caching a bloated prefix is cheaper than paying full price for the bloat, but both are worse than deleting the bloat. Before reaching for caching, audit the system prompt. I regularly see 20K-token system prompts where 8K of that is unused tools, redundant instructions, and "you are a helpful assistant" boilerplate. Cut it. Then cache what's left.

Truncation also applies to conversation history. If your sessions are long, summarize older turns and inject the summary. Keep the last 2 to 4 turns verbatim. Test that summarization doesn't degrade output quality before shipping it.

4. Batches when you can tolerate latency

Anthropic's Message Batches API is roughly half price for the same tokens, in exchange for asynchronous delivery (results within 24 hours, typically much faster). This is the right tool for: nightly report generation, bulk document processing, evaluation runs, anything offline. It's the wrong tool for user-facing traffic.

If you have a queue of background jobs, batching them is free money. If you have user-facing latency requirements, batching is irrelevant.

What you can't fix with prompt engineering

Output length is the most underpriced cost in any LLM integration. I keep seeing teams write a 200-token system prompt that produces 2000-token responses because the model thinks out loud. max_tokens and stop sequences are blunt but effective. If your product only uses the first 100 tokens of the response, the other 1900 are waste. Cap them.

There's also a class of problem where Claude isn't the right tool. If you can solve it with a regex, a SQL query, or a 200-line script, the Claude API is the most expensive solution on the market per unit of useful work. LLMs are for problems where the input is unstructured and the output requires reasoning. Everything else should be code.

The one number to watch

Track output_tokens per call as a percentile, not just an average. The average hides the long tail. A p95 output length of 5K tokens on a workload where p50 is 800 tokens means 5% of your calls are 6× more expensive than the median, and they usually cluster around the same kind of query. Find that query, understand why it's so verbose, and fix it (usually by adding a stop condition or a "be concise" instruction that the model actually respects).

If output p95 is over 3× output p50, you have an output-cost problem that prompt caching cannot solve.

A small spreadsheet to keep

I keep a three-line sheet per integration:

1. Daily calls, broken down by model
2. Average input tokens per call, by model, by prompt version
3. Average output tokens per call, by model, by prompt version

Multiply by rates, multiply by 30, that's the bill. When the bill moves, one of those three numbers moved, and you can find it in five minutes.

If you're not measuring those three numbers on every integration, you're going to be surprised by your invoice. The surprise is rarely a price change. It's a usage change you didn't see.

I'm Ignacio Belando, a freelance senior engineer building Claude and multi-provider LLM integrations for production. If you're staring at an unexpectedly large Anthropic invoice and want help finding where the cost is leaking, email me.