What Anthropic changed on 15 October

Anthropic's developer account posted on X at 20:09 UTC on 15 October 2026 that Opus 5.5 fast mode in the Claude Platform is no longer in research preview and that the waitlist is gone. The same day's entry in the Claude Platform release notes gives the developer details: requests to Claude Opus 5.5 no longer need the fast-mode-2026-02-01 beta header, requests that still send it keep working, and Opus 5.5 now has a default fast-mode rate limit in every usage tier.

Fast mode itself is not new. Anthropic made it available for Opus 5.5 as a research preview when the model launched on 22 September 2026, and earlier Opus versions had their own previews. What changes now is access: any developer on the Claude API can switch it on without asking first.

Fast mode for Claude Opus 5 and Claude Opus 4.8 remains in research preview. Developers using those models still need to join the waitlist or go through an account manager, and must keep sending the beta header.

What fast mode is, and what it is not

Anthropic's fast mode documentation describes it as the same model with a faster inference configuration, with no change to intelligence or capabilities. The weights and behaviour are the same; it is not a distilled or smaller model.

The speed gain is specific. Anthropic says fast mode delivers up to 2.5x higher output tokens per second, and that the benefit is focused on output speed rather than time to first token. In practice that means long answers and big code edits finish sooner, while the wait before the first token appears may not change much. The docs note the gain is most visible with streaming.

Turning it on is one parameter. On a Messages API request to claude-opus-5-5, you set speed to fast. The response's usage object includes a speed field that reports fast or standard, so you can confirm which one you were billed for. AI Lookout has not measured the speed-up; the 2.5x figure is Anthropic's upper bound.

What it costs: twice the standard Opus 5.5 rate

Anthropic's pricing page lists standard Claude Opus 5.5 at $4 per million input tokens and $20 per million output tokens. Fast mode for Opus 5.5 costs $8 and $40, a flat 2x multiplier that applies across the full context window, including requests over 200,000 input tokens.

For comparison, fast mode on Claude Opus 5 and Opus 4.8 costs $10 and $50, so the newer model is 20% cheaper to run fast than the older ones. Opus 5.5 in fast mode also costs less per token than Claude Fable 5.1 at standard speed, which the same page lists at $10 and $50.

A worked example, using Anthropic's list prices and no caching: an agent turn that reads 200,000 input tokens and writes 20,000 output tokens costs $0.80 plus $0.40, or $1.20, at standard speed. In fast mode the same turn costs $1.60 plus $0.80, or $2.40. The arithmetic is ours; your bill depends on caching, data residency and how many tokens the model actually uses.

Fast pricing stacks with other modifiers. Prompt caching multipliers and data residency multipliers apply on top of the fast rates. Two things are not available with fast mode at all: the Batch API, which halves standard prices, and a Priority Tier commitment.

Cost per token is only part of the picture. Our look at GPT-6.1 Sol's cost and capability shows how pricing tiers interact with how many tokens a model needs to finish a job, and Anthropic's Haiku 5.5 release is the cheaper option when speed matters more than Opus-level reasoning.

Rate limits, errors and falling back to standard speed

Fast mode has its own rate limit, separate from standard Opus limits. Responses carry headers for fast-mode input and output tokens per minute, how many remain and when each resets, and the Claude Console shows the limits on its Rate limits page.

When you exceed the fast-mode limit, the API returns a 429 error with a retry-after header. Anthropic's SDKs retry such requests up to twice by default, and the docs say the delay is usually short because fast-mode capacity replenishes continuously. A 529 error signals that fast-mode capacity is exhausted.

If you would rather fall back to standard speed than wait, the documentation shows a client-side pattern: send the fast request with retries disabled, catch the rate-limit error and resend without the speed parameter. There is a trade-off. Requests at different speeds do not share cached prompt prefixes, so a fallback causes a prompt cache miss and you pay full input price for the retried request.

Where it works: Claude API, Claude Code and Foundry

The documentation, as read on 15 October, says fast mode is available on the Claude API, including Claude Managed Agents, only, and not on Amazon Bedrock, Claude Platform on AWS, Google Cloud or Microsoft Foundry. Anthropic's developer account says something different: that fast mode is also available in Microsoft Foundry (hosted on Azure), with Google Cloud coming soon. We are reporting both until the docs are updated.

In Claude Code, nothing changes with this release. The Claude Code fast mode guide still labels the feature a research preview. You toggle it with the /fast command, and on Pro, Max, Team and Enterprise subscriptions it is billed from extra usage credits rather than counted against plan limits. Opus 5.5 is the fast-mode default in Claude Code v2.1.280 and later, and Team and Enterprise organisations need an owner to enable it first.

Fast mode works with the observability features Anthropic has been adding, such as OpenTelemetry tracing for agents, and the usage and cost API can break out fast-mode spend across an organisation.

When fast mode is worth paying for

Doubling the price for faster output makes sense when a person is waiting. Interactive coding sessions, live debugging, customer-facing agents and demos are the obvious cases: if a long response arrives in a fraction of the time, the human on the other end can keep working.

It makes less sense for background work. Overnight batch jobs, evaluations and data processing do not benefit from faster output, and for those the Batch API at half the standard price is the better deal. Opus 5.5's standing on coding benchmarks, such as Artificial Analysis's FrontierCode leaderboard, is unchanged by fast mode, because the model is the same.

Claude Code's guide gives one more tip that applies to the API too: turn fast mode on at the start of a session rather than mid-conversation. Switching speeds invalidates the prompt cache, so flipping back and forth on a long agent run can cost more than staying in one mode.

Caveats

The 2.5x figure is an upper bound from Anthropic, measured on output tokens per second; real gains will vary with prompt length, output length and load. Time to first token is not where the improvement lands.

Availability outside the Claude API is unclear on the day: the docs and Anthropic's social post disagree about Microsoft Foundry. And because fast-mode capacity sits behind its own rate limit, teams that rely on it for production traffic should plan a fallback path and budget for the cache misses that come with it.

Common questions

Is Claude Opus 5.5 fast mode a different model?

No. Anthropic says it is the same model and weights with a faster inference configuration, and no change to intelligence or capabilities.

How do I turn on fast mode in the Claude API?

Set speed to fast on a Messages API request to claude-opus-5-5. For Opus 5.5 you no longer need the fast-mode beta header or an access request; check usage.speed in the response to confirm it ran fast.

Does fast mode work with the Batch API?

No. Anthropic's documentation says fast mode is not available with the Batch API or with a Priority Tier commitment.

Sources & further reading

  1. Opus 5.5 fast mode in the Claude Platform is no longer in research preview ↗
  2. Claude Platform release notes ↗
  3. Fast mode ↗
  4. Pricing ↗
  5. Speed up responses with fast mode ↗
  6. What's new in Claude Opus 5.5 ↗
How this story was made

Written by Kristian Kostov with AI assistance and checked against the linked sources. Company performance claims are attributed to the company. Analysis reflects AiLookout’s interpretation; we have not independently tested the products discussed. The cover places the companies’ own logos, taken from public-domain or openly licensed files credited in the caption, on a plain background. It is not a product photograph, a screenshot, or an endorsement.

Our editorial standards
Back to all stories