Claude Fast Mode

What 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 and Opus 4.8 fast mode remain in research preview. Supported models, model and fast-mode rates.

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

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, 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 or Max, /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.

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 the generated answer; 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; research-preview models also require the request header anthropic-beta: fast-mode-2026-02-01, which opts into that preview. 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 standard or $10 fast per million tokens; cache reads cost $0.20 or $0.40. Public pricing, 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. Claude Code documents that this charge happens once per conversation; later off/on toggles retain the cache. 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.

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.

DataForSEO estimates 1,300 US monthly searches for “ai code review”, retrieved October 19, 2026. That supports interest in the job, not willingness to pay for fast mode. 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.

DataForSEO estimates 140 US monthly searches for “ai code debugging” on the same date. That is a smaller, directional signal. 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. Claude Code falls back to standard speed and pricing during a fast-mode rate-limit cooldown, then re-enables fast mode. 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.