Anthropic quietly changed the math on latency this cycle: Claude Opus 4.8's fast mode is now about 3× cheaper than fast mode was on Opus 4.7. Same frontier model, up to 2.5× the output speed, at double the standard token price — $10 / $50 per million input/output tokens versus the standard $5 / $25. For a solo founder shipping an interactive agent, that price cut is the difference between "too expensive to consider" and "run the numbers." Here is the one line of math that decides it, and the two gotchas that quietly give the savings back.
What fast mode actually is (and isn't)#
Fast mode is not a smaller model. It is the identical Claude Opus 4.8 — same weights, same 1M context window, same capabilities — served at up to 2.5× higher output tokens per second. You are not trading intelligence for speed; you are paying for latency. It's a research-preview beta on the first-party Claude API only, so before you design around it, note where it doesn't run: not on the Batch API, not on Priority Tier, not on Claude Platform on AWS, and not on any third-party platform (Amazon Bedrock, Google Vertex AI, Microsoft Foundry).
Opus 4.7 had a fast mode too, but it's being deprecated — after removal, requesting speed: "fast" on 4.7 returns an error. Opus 4.8 is the durable fast-capable tier. If you have fast-mode traffic on 4.7, move it now.
The decision rule: is a human waiting?#
The whole call comes down to one question. Fast mode is worth double the token bill only when a human is waiting on the output.
- A human is waiting — an interactive coding assistant, a live chat agent, a voice loop, anything where the user is staring at a spinner. Here ~2.5× throughput roughly halves the wait, and responsiveness is the product. The token premium buys the one thing users notice most. Flip it on.
- Nothing is waiting — nightly jobs, bulk classification, background agents grinding through a queue. Paying 2× for speed nobody perceives is pure waste. Reach for the opposite lever: the Batch API is a flat 50% discount in exchange for async execution (minutes to hours). Unattended work should be getting cheaper, not faster.
That's it. The trap is treating fast mode as a general "make it better" switch. It isn't — it's a latency instrument, and latency only has value when someone is there to feel it. For the intelligence-vs-cost trade across models, that's a different decision entirely — see our breakdown of Claude Sonnet 5 vs Opus 4.8 for agents and, at the cheap end, which cut-rate model to route to.
How to turn it on#
Three things are required on every fast request: use the beta messages endpoint, pass the beta flag, and set speed as a top-level parameter.
response = client.beta.messages.create(
model="claude-opus-4-8",
max_tokens=4096,
speed="fast",
betas=["fast-mode-2026-02-01"],
messages=[{"role": "user", "content": "..."}],
)
# Confirm what actually served the request
print(response.usage.speed) # "fast" or "standard"Always check response.usage.speed — it tells you which speed actually ran, which matters because of the second gotcha below.
The two gotchas that eat the savings#
1. Switching speed invalidates your prompt cache. Fast and standard are, for caching purposes, different configurations. Flip a request from standard to fast (or back) and the next call pays a cold cache-write instead of a cheap cache-read. If your agent loop reuses a large system prompt or tool schema — and most do — a careless speed switch can cost you more than the speed-up saved.
2. Fast mode has its own rate limit. It's a separate pool from standard Opus. When you hit a 429, you have two options: wait out the retry-after delay, or drop speed and fall back to standard. But that fallback is itself a speed switch — so it busts the cache (gotcha #1). Design the fallback deliberately: a naive "retry on standard" wrapper that fires on every burst will quietly double your token spend through repeated cold cache-writes.
The clean pattern for an interactive loop: keep the whole conversation on one speed for its lifetime, size your fast-mode rate limit for your real concurrency, and only fall back to standard when you're genuinely rate-limited — not on every request.
The bottom line for a team of one#
Fast mode got cheap enough this cycle to be a real tool instead of a luxury. Use it exactly where it earns its 2× premium — the interactive path where a person is waiting — and nowhere else. Route your unattended work to the Batch API's 50% discount, keep each conversation pinned to a single speed to protect the cache, and watch usage.speed so a silent fallback doesn't hand the savings back. That's the whole playbook: two levers, opposite directions, one question — is a human waiting?
