The 30-second answer: Claude Opus 4.8’s standard pricing is $5 per million input tokens and $25 per million output tokens. There are three key levers for cutting cost: prompt caching for 90% savings on cache reads, the Batch API for a 50% discount on input and output, and — if you need speed — a fast mode that’s 3x cheaper than before. The 1M context is provided at the standard rate with no surcharge.
I keep Claude open all day and run my solo-business operations through it. Since I pile code writing, research, and document review onto a single model, the first thing I look at when the monthly statement opens is “which call ate the most tokens.” There are already plenty of posts on model performance. This one is the flip side — it focuses only on how a cost-conscious operator runs the same work for less. (The release summary, the benchmarks, and the intro to the 1M context are covered in separate posts, so here I’ll focus on the numbers and the savings levers.)
The figures are based on the official pricing page (platform.claude.com). Pricing policy changes often, so it’s safer to check it directly before you adopt anything.
Standard pricing and generation comparison
Opus 4.8’s standard pricing is $5 input and $25 output per million tokens (MTok). This rate has held steady from Opus 4.5 through 4.8. In other words, performance improved as the version stepped up, but the surface rate stayed the same.
A comparison point worth remembering is the older-generation Opus 4.1. Its pricing was $15 input and $75 output. Even within the same Opus line, the rate came down to about a third starting with the 4.5 generation. For anyone thinking about token-cost optimization, if you’re still on an older version, the rate alone is reason enough to switch.
On top of that, Opus 4.8 includes a 1M (one-million) token context within the standard rate. In the past, some models tacked on a long-context surcharge for a long context, but 4.8 uses 1M at the plain standard rate with no separate beta header. Not having to pay a separate “context premium” for jobs that load a whole codebase at once keeps the cost math simple.
Fast mode: an option that’s exactly 3x cheaper
For workloads that need speed, a fast mode was added. Fast mode pricing is $10 input and $50 output per million tokens.
Here’s a point that’s easy to misread. Fast mode is twice as expensive as the standard rate ($5 input / $25 output). So why call it “3x cheaper”? Because the comparison is to something else. The previous fast-processing cost structure was $30 input and $150 output, and fast mode’s $10 / $50 is exactly 3x lower than that. In other words, you get the same value — “a fast response” — at a third of the previous price. And it’s about 2.5x faster.
There’s one constraint. Fast mode can’t be used together with the Batch API. That means you can’t choose “fast” and “cheap (batch discount)” at the same time — you pick one based on the nature of the work. For real-time work where a user waits in front of the screen for a response, fast mode fits; for bulk work that can run overnight, Batch is the match.
Prompt caching: the heart of the 90% savings
For a cost-conscious operator, the biggest lever is prompt caching. When you repeatedly reference the same long context (a system prompt, a codebase, a document, and so on), loading that portion into the cache means every call after the first is processed at the cache-read rate.
The cache-read rate is 10% of the standard input rate. For Opus 4.8, that’s 10% of $5 — $0.50 per million tokens. Instead of paying for the same tokens as fresh input every time, from the second call on you read them at one-tenth the price. That’s what the “up to 90% savings” really is.
That said, the act of writing to the cache (a cache write) carries a cost of its own. The rate differs by how long the cache is retained.
| Item | Rate (vs standard input) | Opus 4.8 equivalent ($/MTok) |
|---|---|---|
| Standard input | 1x | $5 |
| Cache read | 0.1x | $0.50 |
| 5-min cache write | 1.25x | $6.25 |
| 1-hour cache write | 2x | $10 |
Here you have to work out the break-even. Because a cache write costs extra, it only pays off if you reuse it enough. The rough rule of thumb: a 5-minute cache pays off if you use the same context as a read even one more time, and a 1-hour cache clears its cost when you reuse it two or more times. Which means if you’re only going to look at the same document once or twice and toss it, caching is actually a loss.
There’s one improvement in Opus 4.8: the minimum cache unit dropped to 1,024 tokens (lower than 4.7). Relatively short contexts now qualify for caching, opening up savings even on small, repeated prompts.
Batch API: an additional 50% discount
For bulk work that isn’t urgent, the Batch API is the answer. Batch gives a 50% discount on both input and output. Converted for Opus 4.8, that’s $2.50 input and $12.50 output.
Batch’s strength is that it can stack with caching — in contrast to fast mode, which can’t be combined with Batch. So for “bulk plus repeated-context” work, you can layer the 90% cache-read savings on top of Batch’s 50% discount to build an effective cost far below the surface rate. Just note that Batch delivers results asynchronously rather than instantly, so it only fits work where you can tolerate a delayed response.
A tokenizer caveat: the same text, but more tokens
There’s one trap that’s easy to miss if you only look at the price table: the tokenizer. Since Opus 4.7 introduced a new tokenizer, the same text can consume up to 35% more tokens than before.
Why does this matter? Even if the rate is the same, if the token count for the same task rises, your bill goes up. And the 1M context is also measured in tokens, so more tokens counted means the same amount of text fills the context limit faster. That’s why, when moving from an older version to 4.8, you shouldn’t assume “the rate is the same, so the cost will be too.” In reality, cost and context usage can both climb in proportion to the token increase. I’d recommend running the same task at small scale before and after migration and comparing the token counts directly.
There are also add-on charges. The data residency (us-fixed) option is 1.1x, and routing through a cloud like Bedrock or Vertex adds a 10% premium depending on the region. Factor these in when choosing a hosting channel.
Cost-saving scenarios by workload
To sum up, the conclusion of tool comparison isn’t “which mode is cheapest” but “what kind of work you’re doing.” Mapping the situations a cost-conscious developer runs into most often, by workload, looks like this.
- Real-time chat and coding assistance — work where a user waits for a response. Secure speed with fast mode, and bundle the identical system prompt with caching. Batch is a poor fit.
- Repeated-context reference (repeated queries over the same codebase) — caching is the top lever. Drop it to the $0.50 cache-read rate, but first confirm your reuse count clears the break-even.
- Overnight bulk processing (batch-classifying or summarizing documents) — stack Batch’s 50% with caching’s 90%. Only when you can tolerate a delayed response.
- One-off short tasks — no lever helps much. The plain standard rate is simplest, and since a cache write can only add cost, hold off on caching.
For work that calls the same system prompt several times a day — like my publishing pipeline — I keep caching on, and I split off the overnight batch-check jobs to Batch. Conversely, for one-off research I’ll look at once or twice, I apply no lever at all. The key is to keep asking myself, each time, “does my call pattern clear the break-even?”
One last thing to be clear about: all these levers are just savings tools Anthropic provides — they don’t cut costs on their own. Deciding what work to put on which mode, and what to cache, is the operator’s job. The tool makes it possible, but building the cost structure to fit your own workflow is on you. In the end, knowing your own call pattern — more than being able to read a price table — is the starting point of token-cost optimization.
What’s next in the series
This post is part 3 of the five-part Claude Opus 4.8 series — the pricing and efficiency installment. Coming up: (4) competitor comparison and (5) the migration guide.
Pricing reflects the official announcement and may change.
Tags: Claude Opus, token cost optimization, tool comparison, developer, Anthropic
Sources: Claude Platform — Pricing, Anthropic — Introducing Claude Opus 4.8