Claude API Pricing in 2026: Cost Per Token, Billing, and What Actually Gets Expensive

The first invoice that scared me was $0.09. Not the total bill, the cost of a single article. I run a daily content pipeline that hands Claude an 8,000-token system prompt and asks for an 1,800-word draft back. Nine cents a call felt fine until I multiplied it across every agent in the fleet running on a cron, every day, with retries. The sticker price per million tokens is the number everyone quotes. The number that actually lands on your card is a function of how you call the model, not what tier you picked.

So this is the breakdown I wish I had when I started: what Claude API pricing looks like in 2026, line by line, with the two or three decisions that move your bill by an order of magnitude.

What Claude API pricing looks like in 2026

Anthropic bills the Claude API pricing the same way it has for years: per million tokens, quoted separately for input and output. Input is everything you send (system prompt, conversation history, the user’s message, tool definitions). Output is everything the model writes back. The two rates are not equal, and that asymmetry is the whole game.

Here are the current rates for the three models I actually run:

Model	Model ID	Input ($/M)	Output ($/M)
Claude Opus 4.8	claude-opus-4-8	$5	$25
Claude Sonnet 4.6	claude-sonnet-4-6	$3	$15
Claude Haiku 4.5	claude-haiku-4-5-20251001	$1	$5

Opus 4.8 is the flagship as of June 2026 and the model writing this sentence. There is also a 1M-context variant, claude-opus-4-8[1m], which prices long-context requests at a premium above a certain input threshold. For most agent work you never touch the 1M tier, so I am leaving it out of the math below to keep the examples honest.

Notice the pattern in every row: output costs five times what input costs. A model that rambles is five times more expensive per token than one that reads. That single fact explains most surprise invoices.

Input vs output tokens: why your bill is mostly output

People budget for input because it is the part they can see. You wrote the prompt, you can count it. Output is the part the model decides, and it is where the money goes.

Take my content pipeline call on Opus 4.8. The system prompt is 8,000 tokens. The draft it returns is roughly 2,400 tokens. Run the numbers:

# Opus 4.8 rates, per token
INPUT_RATE = 5 / 1_000_000   # $5 per million
OUTPUT_RATE = 25 / 1_000_000 # $25 per million

input_tokens = 8_000
output_tokens = 2_400

input_cost = input_tokens * INPUT_RATE    # $0.040
output_cost = output_tokens * OUTPUT_RATE # $0.060
total = input_cost + output_cost          # $0.100 per article

The input is 3.3x larger than the output by token count, yet output is the bigger line item. That is the 5x multiplier doing its work. When I want to cut the cost of that call, trimming the system prompt helps a little; getting the model to write tighter, or routing the draft to a cheaper model, helps a lot more.

This is also why streaming a long, chatty agent loop gets expensive fast. Every tool call round-trip re-sends the growing transcript as input and adds another block of output. The conversation does not just get longer, it gets quadratically more expensive if you are not careful. I wrote up the patterns that contain this in reduce-ai-api-costs, and the short version is: cap output, prune history, and cache the parts that never change.

Prompt caching: the single biggest lever

If you take one thing from this article, take this one. Prompt caching is the difference between a sustainable agent and an invoice that scales with your cron frequency.

The mechanic is simple. You mark a stable prefix of your request (the system prompt, the tool definitions, a big reference document) as cacheable. The first call pays a small write premium, roughly 1.25x the normal input rate for a five-minute window. Every call after that, within the window, reads that prefix at about 10 percent of the normal input rate. A 90 percent discount on the part of your prompt that never changes.

Back to my pipeline. That 8,000-token system prompt is identical on every single call. Without caching I pay $0.04 of input per article forever. With caching:

1. First call writes the cache: 8,000 tokens at 1.25x = $0.05 of input, once.
2. Every subsequent call inside the window reads it: 8,000 tokens at 0.10x = $0.004 of input.
3. The output cost ($0.06) does not change, because caching only touches input.

Across a batch of 20 articles, uncached input is $0.80. Cached, it is $0.05 + (19 x $0.004) = $0.126. The input bill drops by roughly 84 percent, and the more often you reuse the prefix, the closer you get to the full 90. There is a longer-window option too: a one-hour cache costs about 2x to write but survives gaps between calls, which matters for agents that fire every few minutes rather than in a tight loop. I walk through the exact cache_control block placement in claude-prompt-caching-tutorial.

The trap is cache invalidation. The cached prefix has to be byte-identical. Inject a timestamp, a per-user variable, or a reordered tool list into that prefix and you bust the cache on every call, paying the 1.25x write premium each time and never collecting the read discount. Put the volatile stuff after the cache breakpoint, always.

Which model for which task

The cheapest token is the one you route to the right model. I do not run Opus 4.8 for everything, because most of what an agent fleet does is not flagship-grade reasoning. It is classification, extraction, formatting, and short structured replies.

Here is the routing logic I actually use:

• Opus 4.8 for the hard middle of a task: planning, multi-step reasoning, writing that has to carry a voice, code that has to be correct. Worth $25/M output when the output quality is the product.
• Sonnet 4.6 for the workhorse lane: solid drafts, summaries, tool-use loops where the reasoning is real but not flagship-deep. At $3/$15 it is the default I reach for before I reach for Opus.
• Haiku 4.5 for high-volume narrow jobs: tagging, routing, yes/no gates, pulling fields out of a blob. At $1/$5 you can run it thousands of times a day and barely notice.

A concrete example from the fleet: a triage step that reads an inbound email and labels it customer, prospect, or noise. That is a Haiku job. Running it on Opus would cost 5x the input and 5x the output for a decision a $1/M model makes correctly. I picked apart the tradeoff in detail in claude-sonnet-4-6-vs-opus-4-7, and the heuristic that survived is: start every task on the cheapest model that plausibly works, and only escalate when you can point to a specific failure the cheaper model produced.

What actually gets expensive (the surprises)

The sticker price is rarely what bites. Four things actually inflate a Claude bill, and I have been burned by three of them.

The first is uncached repeated context, covered above. The second is retries on a cron. A job that fails halfway and re-runs from scratch pays for all the tokens twice, and a flaky pipeline retrying overnight can quietly double a daily spend. The fix is making jobs resumable and idempotent, not just adding a retry wrapper.

The third is the tokenizer change history. When Opus 4.7 shipped, the new tokenizer billed up to 35 percent more tokens for the same prompt at an unchanged sticker price. The per-million rate did not move, the invoice did. The lesson stuck: when you migrate a model, re-measure your actual token counts on a real sample of traffic before you trust your old cost projection. The model card tells you the rate, not your bill.

The fourth is forgetting the Batch API exists. Anything that does not need an answer in the next few seconds can go through batch processing at a 50 percent discount on both input and output, with results inside 24 hours. My overnight content generation, bulk re-summarization, and any backfill all run through batch now. Half price for work nobody is waiting on is the easiest cost decision in the stack.

If you want the full picture of what an agent costs to build and run, not just per-call token math, I broke down real numbers in ai-agent-development-cost-2026. And if you are evaluating Opus specifically before committing, the first-party rundown lives in claude-opus-4-7-guide, with the 4.8 deltas noted throughout.

Here is the honest summary. Claude API pricing is not complicated, but it is asymmetric in ways that punish naive usage. Output is 5x input. Caching saves 90 percent on static context. The wrong model for a narrow job costs 5x more for the same answer. Get those three right and your bill tracks your actual reasoning load instead of your sloppiness. Get them wrong and the meter runs while you are not looking.

That is the part most teams underestimate, which is why we build the metering, caching, and model-routing into every agent we ship at /work/. If you would rather skip the per-token accounting entirely and have someone hand you a system that already does it, that is the /hire/ conversation, and you can start scoping it through the /architect/ intake.