Claude Fast Mode

Verified against Anthropic’s live documentation and Claude Code changelog on November 1, 2026.

What Claude Fast Mode Actually Changes

Fast mode runs the same model with a faster serving configuration. Think of an express checkout: the work in your basket stays the same, but you pay to move through it sooner. Anthropic publishes up to 2.5x higher output tokens per second, with unchanged intelligence and capabilities. That claim concerns how quickly the answer is generated, not how soon its first token arrives or how quickly your entire coding job finishes. API fast-mode documentation.

Your workflow still has to inspect files, run tests and wait for tools. Paying for faster model output cannot remove those steps. My recommendation: buy fast mode for a shorter conversation loop when a person is waiting to act. Leave it off when you can walk away.

Which Claude Models Support Fast Mode?

The supported list is narrow. These are rates per million tokens, the small pieces of text the model reads or generates. Input and output are billed separately.

Sonnet and Haiku do not support this switch. Opus 5 fast mode remains in research preview; Opus 4.8’s preview is deprecated. The table shows USD per million tokens at the documented base rates. Supported models, model and fast-mode rates.

Since October 30, 2026, Opus 4.8 fast mode is deprecated, with removal on November 30, 2026. After removal, fast-mode requests return an error; they do not fall back to standard Opus 4.8. Separately, since October 22, 2026, Opus 5.5 fast mode is available through Claude Models on Google Cloud (Anthropic managed). Anthropic release notes, Claude Code changelog 2.1.316.

If you use Opus 4.8 fast mode, switch to Opus 5.5 before removal. In Claude Code, select Opus 5.5 with /model, then enable /fast. For the API, migrate to claude-opus-5-5 with speed="fast" and check the Opus 4.8 migration guide for request changes. You can instead choose standard-speed Opus 4.8 explicitly if you need that model. The model deprecations page still lists Opus 4.8 itself as active; the November deadline concerns its fast mode.

Choose the model before choosing its speed. If your task does not need Opus, use our Claude Opus vs Sonnet comparison to make that decision first.

Turn It On in Claude Code

Claude Code documents /fast for the Anthropic API and Claude subscription accounts. Its current requirements exclude Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry and Claude Platform on AWS. These are Claude Code restrictions; the Messages API has its own platform support below. Claude Code requirements.

In the interactive terminal:

1. Run /fast.
2. Press Space to switch it on, then Enter to confirm.
3. Check for the ↯ indicator beside the prompt.
4. Run /fast again to switch it off. You remain on Opus; use /model to change models.

Opus 5.5 is the fast-mode default in Claude Code v2.1.280 and later. If you are using an unsupported model, enabling fast mode switches you to Opus. Claude Code controls.

You can also set "fastMode": true in ~/.claude/settings.json, your personal settings file. The interactive preference normally carries into later sessions. For deliberate opt-in each session, set "fastModePerSessionOptIn": true. That is the setting I would use on a machine that also runs unattended work. Settings reference, settings-file locations.

Subscription Allowance Does Not Pay for Fast Mode

On Pro, Max, Ultra, Team and Enterprise, fast mode draws from usage credits even when included plan usage remains. For the subscription-versus-extra-usage question, it is separately metered usage; the current documentation calls it “usage credits.” Team and Enterprise also require an Owner to enable fast mode. Claude Code billing requirements.

On Pro, Max or Ultra, /usage-credits opens the page where you enable credits and manage the spend limit. Organization members with billing access can manage them for their organization; other members can request access. API-key users pay through their Console organization instead. Use /status to check how you signed in. Usage-credit controls, billing by sign-in method.

For the plan-level decision, see Claude Code pricing in 2026. A larger subscription allowance does not turn this premium mode into included usage.

Turn It On Through the API

For the direct Anthropic API, set the request's speed parameter to "fast". Opus 5.5 fast mode is available by default in the Start, Build and Scale usage tiers; Evaluation accounts must upgrade. API availability.

For Messages API requests, Opus 5.5 fast mode is offered on the Claude API, Claude Models on Google Cloud (Anthropic managed), and Microsoft Foundry deployments hosted on Azure. The Opus 5 and deprecated Opus 4.8 previews are listed for the Claude API only. Managed Agents also supports fast mode on the Claude API, with the same model statuses. API platform support, Anthropic-managed Google Cloud.

The current Python SDK example for Opus 5.5 uses the ordinary Messages method:

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    speed="fast",
    messages=[{"role": "user", "content": "Explain this failing test: ..."}],
)
print(response.usage.speed)

max_tokens caps total generated output, including thinking and response text; it does not set the speed. usage.speed reports the speed actually used. Omit speed="fast" for standard requests. Messages API reference.

The Opus 5.5 example needs no fast-mode beta header. Opus 5 and the deprecated Opus 4.8 preview require anthropic-beta: fast-mode-2026-02-01; Opus 5 access also requires your account manager or the fast-mode waitlist. API request documentation.

A Long Agent Session: $15 Standard, $30 Fast

The 2x rate is confirmed. For Opus 5.5, ordinary input rises from $4 to $8 per million tokens and output from $20 to $40. Caching has its own rates: storing reusable input costs more than reading it again. Five-minute cache writes cost $5 per million tokens at standard speed; cache reads cost $0.20. Applying Anthropic’s documented cache multipliers to fast input pricing gives $10 for writes and $0.40 for reads. Cache pricing and fast-mode modifiers.

Consider a long coding session that repeatedly reads project context while editing and checking changes. The following is an illustrative usage ledger, not a measured session. The totals accumulate across many API requests, not one giant prompt. Each input token is counted in its appropriate billing category, without double-counting cache reads as ordinary input.

This assumes global routing, the same cache behavior and token totals in both runs, and one speed from the outset. It excludes tax, separate tool charges and hosted runtime fees. The arithmetic compares metered token costs. If your standard Claude Code work fits inside your subscription allowance, $15 is its API-rate equivalent, not an extra $15 bill; fast mode still consumes separately billed credits. Subscription cost reporting.

The business question is whether the extra $15 buys enough useful human time. At an assumed labor cost of $120 an hour, it breaks even after 7.5 minutes of avoided waiting: $15 ÷ $120 × 60. That is a decision threshold, not a claim that fast mode saves those minutes. If standard work is already covered by your subscription, assess the full additional fast-mode spend against the time saved.

Switching Mid-Session Can Add Cost

A warm prompt cache is like keeping your working papers open on the desk. Claude Code's first fast-mode turn has to reread the conversation without cache hits, at fast input rates. Enable it at the start of an interactive session when you expect to need it. Standard and fast speeds keep separate caches. Each later toggle rereads whatever the destination speed does not have cached, including automatic switches during rate-limit cooldowns. Claude Code caching.

For your own API integration, follow the API's separate cache rules: changing speed invalidates system and message caches. Do not assume alternating request speeds will preserve your original cache-hit rate. API cache invalidation.

Five Jobs Where Paying for Speed Can Make Sense

These are recommended uses, ranked by how directly faster answers could remove human waiting. None assumes a measured time saving.

1. An engineer handling an active incident. Inspect the failing path with Claude, request a bounded patch, run the relevant test and decide the next action. A person is waiting between decisions. Keep the usual review and deployment checks.

2. Two developers reviewing a difficult change together. Ask about a specific diff, examine a suggested fix and challenge its reasoning while both developers are present. Each slow reply can interrupt two people's attention.

3. A founder iterating before a live product demo. Make one UI change, inspect it, request the next adjustment and repeat. The value is a tighter feedback loop while the founder is actively judging the result.

4. A maintainer resolving a release-blocking test. Compare a failure with the recent change, propose a fix and inspect the next test result. It can help when model output is the pause between actions. A slow test suite still sets its own pace.

5. A developer asking for help in an unfamiliar subsystem. Follow a call path, question an explanation and inspect the suggested edit before proceeding. Faster dialogue could protect a focused work block. Passive repository summarization does not justify the same premium.

The common factor is an immediate next action. Urgency in the task's title is not enough if nobody will read the answer until tomorrow.

Two Things Worth Building Around This

Strongest: an On-Demand Review Desk

A team could build a pull-request review tool with a visible “review with me” action. Ordinary queued reviews would use standard mode; a developer opening a live discussion could opt into faster responses and a spend cap.

The smallest useful version would accept a diff, keep a review conversation, show its metered cost and offer a clear standard-speed fallback. An engineering team could pay for fewer interruptions during review.

This is the strongest opportunity because the person waiting is explicit. The catch is that established review tools can add the same switch. The product must earn its place through useful findings and repository context, not the speed setting alone.

Second: a Live Debugging Assistant

A team could offer a debugging workspace that combines a failure log, the relevant code and a live conversation, with fast mode limited to attended sessions.

An MVP could support one stack, accept a failing test and its trace, and propose a patch for a developer to approve. The buyer would be a team repeatedly losing focused time to that class of failure.

The catch is diagnosis quality. Faster wrong answers create extra work. Start with a narrow failure category and evaluate whether the suggestions are useful before paying to deliver them sooner.

When to Leave Fast Mode Off

Use standard mode for batch jobs, background agents, overnight refactors, scheduled documentation and any workflow with nobody waiting on the answer. My default is also standard when test execution, deployment queues or external services dominate the wait.

For independent requests that can run asynchronously, Anthropic's Batch API offers a 50% input/output discount from standard rates. Fast mode cannot be combined with that API. A background agent with dependent steps may need ordinary requests instead, but it still does not need the fast premium. Batch and fast-mode pricing.

Availability is another limit. On a supported model, Claude Code falls back to standard speed and pricing during a fast-mode rate-limit cooldown, then re-enables fast mode. That temporary capacity fallback does not apply to Opus 4.8 fast-mode removal: those requests will error after removal. In an API app, implement fallback yourself: handle a 429 and retry without speed="fast" if waiting is undesirable. Claude Code cooldown, API fallback.

Monday move: choose one attended debugging session, set a spend limit and record model waiting separately from test runtime. Compare a similar standard-mode session at the same model and effort settings. Keep fast mode only if the time recovered justifies the extra bill; leave scheduled agents on standard.

If you want this kind of cost-aware routing built into your product, we build production AI systems.