Claude Opus 5.5 Fast Mode Drops the Waitlist, but Speed Still Has a Cost

Anthropic has opened Claude Opus 5.5 fast mode without a waitlist, promising up to 2.5 times higher output throughput for developers willing to pay a premium.

The change moves Opus 5.5 fast mode beyond its research preview on the Claude Platform. Eligible API organizations can now request the accelerated configuration directly, without applying for access first. The rollout also extends to Microsoft Foundry deployments hosted on Azure.

This is not a new model or a lighter version of Opus. Anthropic says fast mode uses the same model weights and behavior as standard Opus 5.5. The difference lies in how Anthropic serves the model, and how much customers pay for the added speed.

That distinction creates the central tradeoff. Faster output can shorten agent loops, coding sessions, and interactive workflows. However, it does not reduce every kind of latency, and operational details can raise the effective cost beyond the visible premium.

Open access therefore matters less as a product announcement than as a shift in infrastructure strategy. Anthropic is turning inference speed into a selectable service level for its most capable general-purpose model.

Claude Opus 5.5 Fast Mode Is Now an Open API Option

The most important change is access: supported customers no longer need approval before placing fast-mode requests.

Anthropic announced the change on October 15, 2026, through its developer account. The company said Opus 5.5 fast mode had left research preview and that the waitlist had been removed.

The current fast mode documentation reflects that broader access. Organizations in Anthropic’s Start, Build, and Scale usage tiers receive a default fast-mode rate limit for Opus 5.5. Evaluation organizations must move into an eligible usage tier before they can use it.

Developers opt in by adding speed: "fast" to a Messages API request. Opus 5.5 no longer requires the earlier fast-mode beta header, although existing requests that still send that header remain compatible.

The response includes a speed field in its usage data. That field allows an application to confirm whether Anthropic processed the request in fast or standard mode. This detail matters when teams compare performance, attribute usage, or investigate inconsistent latency.

Fast mode also has its own rate limit, separate from the organization’s standard Opus allowance. When a request exceeds the available fast capacity, the API can return a 429 rate-limit error with a retry-after value.

Anthropic exposes additional response headers for fast-mode input and output capacity. These report the applicable limits, remaining capacity, and reset timing. Actual allowances can differ by organization, so developers must inspect their Claude Console rather than assume a universal threshold.

The removal of the waitlist does not make every older fast-mode implementation generally available. According to Anthropic’s documentation, fast mode for Opus 5 and Opus 4.8 remains in research preview. Those versions still follow their existing gated-access requirements.

That model-specific distinction makes Opus 5.5 the practical default for teams that want accelerated Opus inference without negotiating access. It also gives Anthropic a cleaner migration path away from earlier preview configurations.

Claude Code follows a separate product path. Anthropic says its fast-mode behavior remains unchanged and continues to consume additional usage credits. The API announcement does not remove that accounting distinction for terminal and editor users.

The result is a more accessible feature, but not a universal switch across every Claude product. Teams still need to distinguish between the Claude API, Claude Code, cloud-hosted deployments, and older Opus models.

The Speed Claim Applies to Output, Not the Entire Request

Anthropic’s headline speed figure describes generated tokens per second, not a 2.5-fold reduction in total task time.

Fast mode is a faster inference configuration for the same Opus 5.5 model. Anthropic says it can produce up to 2.5 times more output tokens per second than standard speed. It does not claim that every request completes 2.5 times sooner.

The difference begins with time to first token, often shortened to TTFT. This measures the delay before a model starts returning its answer. Output tokens per second, or OTPS, measures how quickly the response arrives after generation begins.

Anthropic explicitly says the fast-mode benefit focuses on OTPS rather than TTFT. A request involving a long reasoning phase, large tool result, network delay, or slow external service can therefore show a smaller end-to-end improvement.

Consider a coding agent that reads a repository, proposes a patch, runs tests, and interprets failures. Faster text generation can shorten the model’s visible response and planning stages. It cannot make the test suite, source-control server, or package registry complete its work faster.

The gain becomes more noticeable when the model generates long outputs. Code creation, detailed reviews, migration plans, and document drafting all spend meaningful time streaming tokens. Fast mode can reduce that portion of the loop.

Short classification or routing requests present a different picture. If a response contains only a few words, startup latency and network overhead may dominate. Paying for higher output throughput then offers limited practical value.

Streaming interfaces make the improvement easier to perceive. Users see code, explanations, or agent progress arrive at a higher rate. In a non-streaming system, the application receives the whole response only after completion, making the subjective difference less immediate.

Anthropic’s Opus model overview positions Opus 5.5 for coding, professional work, and long-running agents. Those use cases often contain repeated model calls, which can make small latency reductions accumulate across a session.

A single response saved by several seconds may not change a workflow. Dozens of agent steps can turn those seconds into a meaningful reduction in wall-clock time. The value comes from shortening repeated inference segments rather than accelerating unrelated work.

This explains why the removal of the waitlist matters most for agent builders. They can now test fast inference within their real orchestration loops instead of extrapolating from a playground response.

The company’s speed claim still requires careful attribution. Anthropic describes the improvement as “up to” 2.5 times, and no broadly accepted independent benchmark has established a fixed multiplier across workloads.

Output length, load, region, rate limits, and application architecture can all influence observed performance. A team evaluating fast mode should measure completed tasks, not just the animation speed of streamed text.

A useful evaluation records at least four values: time to first token, output throughput, total request duration, and total workflow duration. The last measurement decides whether the feature improves the product users actually experience.

Faster Inference Turns Latency Into a Budget Decision

The main contest is not Opus against another model; it is faster iteration against the higher cost of serving every token.

Fast mode carries a premium over standard Opus 5.5. Shared publishing rules prevent listing specific prices here, but Anthropic’s official documentation provides the current commercial terms.

That premium applies across the context window, including requests with large inputs. Prompt-caching and data-residency adjustments can also apply on top, depending on how an organization configures its workload.

The immediate temptation is to compare the speed multiplier with the pricing multiplier. That calculation is useful, but incomplete. A model request is only one component of an application’s cost and latency.

For an interactive coding assistant, a faster response can keep a developer focused and reduce idle time. The economic benefit may exceed the added inference bill when expensive engineering time is the limiting resource.

For an overnight repository migration, latency might matter much less. Standard speed can produce the same model behavior while leaving the job to finish unattended. Paying a premium would shorten the run without necessarily changing its business value.

Customer-support systems occupy the middle. Faster output can improve perceived responsiveness, but many support answers are short. Teams must determine whether output generation or retrieval and tool execution create the real delay.

The same question applies to research agents. An agent may spend most of its time waiting for web pages, databases, or document parsers. Faster model output helps only during the portions controlled by inference.

Developers also need to account for prompt caching. Caching allows repeated requests to reuse a previously processed prompt prefix, which can reduce work on long conversations and agent sessions.

Anthropic states that fast and standard requests do not share cached prefixes. Switching speed invalidates that reuse across the two configurations. A fallback can therefore be operationally correct while being economically surprising.

Suppose a long agent session builds a cached context at fast speed. If capacity runs out and the application retries at standard speed, the standard request cannot reuse the fast cache. It must process the relevant prefix under the other speed setting.

The reverse is also true. An application cannot warm a standard-speed cache and then expect a fast request to inherit it. Teams should treat speed as part of the cache identity, not merely a presentation preference.

This makes simple per-token comparisons less reliable for persistent agents. Cache behavior, retry rates, response length, and the number of calls per completed task all affect the final cost.

A better deployment strategy routes only latency-sensitive work to fast mode. Interactive edits, live pair programming, synchronous research, and user-facing agent loops are stronger candidates than queues, batch summaries, or scheduled maintenance.

Anthropic does not support fast mode through the Batch API. It is also unavailable with a Priority Tier commitment, according to the current documentation. These exclusions reinforce its focus on opt-in interactive throughput.

The best unit of comparison is therefore not cost per request. It is cost per successful task at an acceptable latency. That framing captures retries, tool calls, cached context, and the value of the user’s time.

Teams already documenting AI workflows in an engineering knowledge base can apply the same discipline here. Record the workload, service level, failure path, and measured outcome before changing the default.

Microsoft Foundry Expands Access, While Google Cloud Remains a Watchpoint

Fast mode is becoming a cloud distribution feature, but availability still depends on the hosting path.

Anthropic’s documentation lists Opus 5.5 fast mode on the Claude API, including Claude Managed Agents. It also lists Claude in Microsoft Foundry when the deployment is hosted on Azure.

Microsoft’s hosting comparison confirms that Opus 5.5 Fast is available in the Azure-hosted configuration. The Anthropic-hosted Foundry configuration does not list the accelerated variant.

That distinction can be easy to miss because both configurations appear inside Microsoft Foundry. They differ in infrastructure, endpoints, authentication options, deployment behavior, and feature availability.

Customers should therefore verify the hosting type rather than assume that every Foundry deployment supports fast mode. Selecting Claude in Microsoft’s catalog does not by itself establish access to the accelerated configuration.

The Azure-hosted option gives enterprise teams another procurement and deployment route. It can matter for organizations that already manage cloud spending, identity, and regional architecture through Microsoft’s platform.

However, Microsoft notes that Anthropic remains the seller and operator of Claude models in Foundry. The models are treated as non-Microsoft products, and Anthropic’s applicable terms still govern their use.

Amazon Bedrock and Claude Platform on AWS do not currently support fast mode, according to Anthropic’s documentation. This creates an uneven capability map for teams that want to keep model traffic inside an existing cloud relationship.

Google Cloud presents a more nuanced situation. Standard Claude Opus 5.5 is already available there, with a documented context window and support for capabilities including computer use, function calling, and prompt caching.

The October announcement says Google Cloud support for fast mode is coming soon. Anthropic has not published a launch date, and its current feature documentation still marks fast mode as unavailable on Google Cloud.

Google’s Opus documentation describes the standard model rather than a fast variant. Until the relevant documentation and model catalog change, buyers should treat the future rollout as a stated plan.

This staggered availability creates pressure on cloud teams rather than directly on another model vendor. Developers may prefer one cloud for governance while needing another route for a specific inference feature.

Large organizations rarely move production workloads solely for a speed toggle. They consider data handling, regional coverage, support, committed spending, procurement, identity, and existing observability.

Still, feature gaps influence new deployments. A team designing an interactive coding agent today might choose the native Claude API or Azure-hosted Foundry because fast mode is immediately testable there.

Cloud support also changes how Anthropic competes for enterprise adoption. A capability available only through a direct API reaches developers. A capability present in a major cloud catalog can enter existing purchasing and governance processes.

Google Cloud support is therefore more than another logo on an availability page. It will test whether Anthropic can offer consistent service characteristics across infrastructure partners without creating confusing product differences.

What the 2.5-Times Claim Does Not Establish

Open access removes an administrative barrier, but it does not answer the hardest questions about sustained performance and production reliability.

The first uncertainty is independent validation. Anthropic reports up to 2.5 times higher output throughput, but teams should not treat that ceiling as a guaranteed production result.

A useful test suite must include realistic prompts, tools, context sizes, output lengths, and concurrency. Short synthetic prompts can overstate benefits because they exclude the surrounding work performed by a real agent.

The second uncertainty concerns capacity. Fast mode has a dedicated rate limit, but Anthropic does not publish one universal allowance that applies to every eligible organization.

This means waitlist removal is not equivalent to unlimited availability. A team can access the feature and still encounter rate limits during bursts or sustained concurrent use.

Applications need explicit handling for both 429 rate-limit responses and 529 capacity errors. Anthropic’s software development kits automatically retry certain failures, but retries add delay and can obscure the user experience.

A fallback to standard speed can preserve availability. It can also rebuild prompt context because caches do not transfer between speed settings. The application must decide whether continuity, latency, or cache efficiency matters most.

The third uncertainty is quality under real workflows. Anthropic says fast mode uses the same weights and behavior, so customers should not expect a deliberate intelligence tradeoff.

Even so, identical weights do not guarantee identical application outcomes across every run. Generative systems remain variable, and tool-based workflows can diverge after small differences in an intermediate response.

Teams should compare task success rates alongside speed. A faster stream has little value if the agent requires more corrections, produces a larger response, or triggers extra tool calls.

The fourth uncertainty is total infrastructure latency. Fast inference cannot eliminate delays from vector databases, permission checks, browser automation, compilation, or external APIs.

A product team that has not profiled its workflow may optimize the wrong component. It could pay for faster generation while users continue waiting on retrieval or tool execution.

The fifth uncertainty is adoption. Waitlist removal creates availability, not demand. Anthropic has not disclosed how many organizations use fast mode, what share of Opus traffic selects it, or which workloads retain it after testing.

That missing adoption data matters because premium inference must produce enough value to become a stable production setting. Otherwise, it remains a switch teams enable for demonstrations or unusually urgent tasks.

Claude Code offers another caution. Its fast mode remains separate and uses additional usage credits, so desktop adoption cannot be inferred directly from API availability.

The strongest interpretation is therefore limited but meaningful. Anthropic has enough confidence to remove the research-preview gate for Opus 5.5 on its platform. It has not proved that fast mode is the correct default for every Opus workload.

Developers should frame their evaluation around a falsifiable question: does faster output improve completed-task latency enough to justify the added cost and operational complexity?

That question is more useful than asking whether the mode feels fast. It forces teams to include rate limits, cache misses, retries, and tool delays in the same measurement.

Three Signals Will Show Whether Fast Mode Becomes a Production Standard

The next phase depends on cloud expansion, measured workload gains, and evidence that dedicated capacity remains dependable under real demand.

The first signal is Google Cloud availability. Anthropic’s developer announcement says support is coming, while the current documentation still excludes the platform.

A documented Google Cloud release would strengthen the case that fast inference is becoming a standard deployment option rather than a direct-API specialty. Continued delay would preserve the present cloud fragmentation.

The details will matter as much as the launch. Buyers should watch whether Google exposes a separate model identifier, which regions support it, and how quotas interact with existing Claude capacity.

They should also examine whether feature behavior matches the native API. Prompt caching, rate-limit reporting, tool use, and fallback handling need consistent documentation before teams can compare deployments fairly.

The second signal is independent performance data. Developers need measurements across coding agents, long-form generation, research systems, and customer-facing assistants.

Useful reports will separate time to first token from output throughput and total workflow duration. They should also state context length, output length, concurrency, region, and retry behavior.

Evidence of large end-to-end gains in repeated agent loops would support Anthropic’s positioning. Small improvements outside long streaming tasks would narrow fast mode to a more specialized role.

The third signal is operational stability. Teams should watch how often fast requests encounter dedicated rate limits, how quickly capacity replenishes, and how frequently applications fall back to standard speed.

A service can be fast in isolation but unreliable during traffic spikes. Predictable throughput matters more than a peak number for production systems with response-time commitments.

Anthropic can strengthen confidence by providing clearer capacity guidance and better organization-level telemetry. Customers need to know whether a slower result came from their application, their quota, or service-wide demand.

These signals will also show whether inference speed is becoming its own product category. Model providers have historically competed through capability, context length, benchmark results, and token economics.

Selectable speed introduces a different market structure. The same model can serve multiple latency classes, letting customers pay according to how urgently they need the answer.

That structure resembles other cloud services where capacity, priority, and response time become separate purchasing decisions. It gives providers another way to segment demand without training a new model for every tier.

For developers, the immediate action is straightforward. Select one representative workflow, run it at standard and fast speed, and measure the entire task rather than the token stream.

Include cache reuse, tool latency, retries, output length, and human waiting time. Repeat the test under realistic concurrency instead of relying on one successful request.

Then decide where Claude Opus 5.5 fast mode belongs: the default path, a user-controlled option, or a targeted route for latency-sensitive requests. The waitlist is gone, but the deployment decision still requires evidence.