Fast mode (research preview) promises up to 2.5x higher output tokens/sec on Opus. The pricing isn't a flat "fast tax" across models — Opus 4.8 pays a 2x multiplier, Opus 4.7 pays 6x. Here's every number, sourced from Anthropic's docs, not estimated.
| Model | Standard input | Fast input | Standard output | Fast output | Multiplier |
|---|---|---|---|---|---|
| Opus 4.8 | $5/MTok | $10/MTok | $25/MTok | $50/MTok | 2x |
| Opus 4.7 | $5/MTok | $30/MTok | $25/MTok | $150/MTok | 6x |
Both models have identical standard rates, but fast mode prices them completely differently. Opus 4.7's fast mode is deprecated as of June 25, 2026 and is removed on July 24, 2026 — after that date, speed: "fast" requests to claude-opus-4-7 error out entirely rather than falling back to standard speed. If you're paying the 6x rate today, that pricing has an expiration date built in either way.
Fast mode runs the exact same model weights at a faster inference configuration — no capability change. The speed gain is specifically in output tokens per second (OTPS), up to 2.5x higher; it does not improve time to first token (TTFT). That matters for how you should evaluate it: fast mode helps long-generation workloads (large refactors, long-form writing, extended tool-call chains) far more than latency-sensitive short replies, since the wait before the first token is unchanged.
Set speed: "fast" on the request body, plus the beta header:
anthropic-beta: fast-mode-2026-02-01
{
"model": "claude-opus-4-8",
"speed": "fast",
...
}
It's a research preview gated behind account-manager access or a waitlist — not something every API key can flip on today. Check usage.speed in the response ("fast" or "standard") to confirm which one actually served the request, since Opus 4.6 silently accepts speed: "fast" but runs (and bills) at standard speed instead of erroring.
| Modifier | Applies with fast mode? |
|---|---|
| Prompt caching multipliers | Yes — stacks on top of fast mode rates |
Data residency 1.1x (inference_geo) | Yes — stacks on top of fast mode rates |
| Batch API 50% discount | No — fast mode isn't available on the Batch API at all |
| Priority Tier | No — mutually exclusive with a Priority Tier commitment |
| Claude Platform on AWS | No — fast mode isn't offered there |
The prompt cache catch specifically: switching speed invalidates the cache. A request at speed: "fast" and the same request at standard speed do not share cached prefixes — falling back from fast to standard on a rate limit costs you a cache miss on top of the speed change.
Fast mode has its own dedicated rate limit, tracked via anthropic-fast-input-tokens-* and anthropic-fast-output-tokens-* response headers — separate from your normal Opus RPM/ITPM/OTPM. Hit it and you get a 429 with a retry-after header; because fast mode uses continuous token replenishment, that wait is typically short. Anthropic's SDKs retry these automatically (up to 2 times by default) rather than erroring immediately.
At 2x on Opus 4.8, fast mode is a real lever for output-heavy, latency-sensitive workloads (interactive coding agents, live-generation UX) where users are watching tokens stream and 2.5x throughput visibly shortens the wait. At 6x on a model that's being removed within weeks, Opus 4.7's fast mode is a bad long-term bet regardless of the speed gain — migrate to 4.8 rather than build around it. Either way, fast mode doesn't work with the Batch API, so it's not a fit for anything you'd otherwise run asynchronously — see batch API pricing for the inverse tradeoff (50% off, no speed guarantee, no urgency).
Use the full calculator for standard-rate estimates, or see Managed Agents pricing for why the fast mode premium doesn't apply at all inside a managed session (the runtime controls inference speed itself).