Fast mode for Claude Opus 5.5 is open to every paying tier

On October 15, 2026, Anthropic took fast mode for Claude Opus 5.5 out of research preview. A team no longer needs to request access or send a beta header. Fast mode makes Opus 5.5 write its answer up to 2.5 times faster. It costs twice the standard rate.

This piece covers what shipped, who it matters to, and a one-week test to decide whether to use it. Emeri did not test fast mode for this article. Everything below comes from Anthropic’s published pages, which are listed in the sources.

What shipped

The Claude Platform release notes dated October 15 list three changes:

• Requests to Claude Opus 5.5 no longer need the fast mode beta header. Requests that still send it keep working.
• Opus 5.5 now has a default fast mode rate limit in the Start, Build and Scale usage tiers. That means no access request.
• Fast mode for Opus 5.5 is available on Claude in Microsoft Foundry, for deployments hosted on Azure.

Fast mode for Claude Opus 5 and Claude Opus 4.8 stays in research preview. Those models still need an access request and the beta header.

To turn it on, a developer adds one setting, speed: "fast", to a request. The response then reports which speed ran, in a field called usage.speed. It reads "fast" or "standard".

Fast mode runs the same model with a faster inference configuration.

The docs say there is no change to intelligence or capabilities. The gain is in output tokens per second: how fast the model writes once it starts. The gain is not in time to first token: how long the model takes to start. The docs say the gain shows most when the answer streams.

What it costs

The pricing page lists these rates for Claude Opus 5.5, per million tokens:

• Standard speed: $4 input, $20 output.
• Fast mode: $8 input, $40 output.
• Fast mode applies the same rate across the full context window.
• Prompt caching and data residency multipliers apply on top of the fast mode rate.

Here is Emeri’s arithmetic for one request. It is an estimate from the published prices, not a measurement. Suppose a request sends 2,000 input tokens and gets back 800 output tokens. At standard speed it costs about $0.024. In fast mode it costs about $0.048. One thousand such requests cost about $24 at standard speed and about $48 in fast mode.

Fast mode has limits. It does not work with the Batch API. It does not work with a Priority Tier commitment. It is not available on Claude Platform on AWS. Organizations in the Evaluation tier must move to the Start, Build or Scale tier first.

Who this matters to

It matters to a team where a person waits for a long answer. Examples include an assistant that drafts long replies for support staff while a customer is on the line. Another is an internal tool that writes a full proposal section while a salesperson watches. A third is an agent that writes many steps of output while someone waits for the result.

It matters less in three cases. The first is a batch job that runs overnight, because nobody is waiting and the Batch API does not support fast mode. The second is a job with short answers, such as a one-line label. The docs say fast mode speeds up writing, not the time to start, so a short answer gains little. The third is a job a cheaper model already does well. Claude Sonnet 5.5 costs $2 input and $10 output at standard speed.

What to do this week

The steps below test fast mode on one workflow before anyone depends on it. They need a developer for about half a day.

1. Pick one workflow where a person waits for a long Opus 5.5 answer. Write down who waits and what they do while they wait.
2. Check your usage tier in the Claude Console. If the organization is in the Evaluation tier, fast mode will not run yet.
3. Collect 20 recent requests from that workflow. Remove names, email addresses, order numbers and anything else that identifies a customer.
4. Send each request twice with streaming on: once at standard speed and once with speed set to "fast". Record the time from send to the last word, the usage.speed value and the token counts.
5. Have the person who uses the output today compare each pair. The docs say the model is the same, so the answers should be of the same quality. Check that anyway.
6. Work out the seconds saved per request and the extra cost per request. Decide whether the person waiting gains enough to pay for it.
7. If you keep it, turn it on for that one workflow only. Add a fallback to standard speed for when the fast mode rate limit is reached.

Three details that can surprise you

• Fast mode has its own rate limit, separate from standard Opus limits. When a team exceeds it, the API returns a 429 error with a retry-after header. The SDK retries twice by default.
• Falling back to standard speed is the team’s choice. The docs show code that catches the rate limit error and resends the request without the fast setting.
• Switching speed loses the prompt cache. Requests at different speeds do not share cached prefixes. A workflow that relies on caching should keep one speed.

The Console shows fast mode rate limits on its Rate limits page. Each response also carries headers that show how many fast mode tokens remain in the current minute.

What we did not test

Emeri did not run fast mode for this article. We have not measured its speed, its rate limits or its cost on a real workflow. The 2.5 times figure is Anthropic’s upper bound, not an average. Your own 20-request test is the number to trust for your workflow.

Emeri’s certification grading runs on Claude models.