Claude Opus 5.5 fast mode: migration and latency checks

What changed on October 15

Anthropic announced that fast mode for Claude Opus 5.5 has left research preview. Requests for that model no longer require the fast-mode-2026-02-01 beta header, while requests that retain it continue to work. Opus 5 and Opus 4.8 remain in research preview and still need that header. Scope the migration by model; do not remove the header from a shared client indiscriminately.

Who this guide is for

This guide is for a workflow owner evaluating a model API behind an agent, such as a drafting or research workflow. It is a documentation review and a proposed measurement plan. No API request, paid trial or latency benchmark was run. The separately recorded Claude consumer-interface cases in our directory do not establish fast-mode API performance or compatibility.

Check the route and price before changing code

The documented model ID is claude-opus-5-5 and the request setting is speed: "fast". The response usage.speed field identifies the served speed. At review time, documented fast-mode token rates are USD 8 per million input tokens and USD 40 per million output tokens, before applicable modifiers. These are API rates, not a consumer subscription or an observed bill. Availability and limits depend on the platform. Higher output-token throughput is not a guarantee of shorter time to first token.

Migrate one workflow with an offline fixture

Write down the existing model ID, provider, SDK version, request fields, retry policy and rollback condition. Keep a known working route available. Prepare a synthetic request fixture without submitting it, then inspect the serialized payload from your framework. Confirm that model and speed fields survive routing. Record unsupported settings as an unresolved compatibility question rather than assuming an API relay exposes every provider feature.

Measure three different waits

Measure request start to first visible answer text, first to final visible answer text, and the complete task including tool calls and retries. Record what starts and stops each clock. A faster generation stream may barely change a task dominated by retrieval or remote tools. Keep a row for every attempt, including failures and fallbacks; a successful response alone does not show the experience of the person waiting.

Keep the comparison useful

Freeze representative synthetic tasks and their acceptance rubric before collecting results. Hold prompt, tools, effort, output cap and concurrency constant where supported. Record cache state and test order, alternate configurations and retain original outputs. Report sample count, ordinary and slow-tail completion times, and failures. Do not compare one short answer against one long answer as evidence of model speed. These are suggested controls, not measurements made by uAgentKit.

Budget for accepted results

Record the actual charge for every attempt and the review time needed to accept its output. A useful decision measure is attributable spending divided by accepted outputs. If none is accepted, report spending and zero accepted outputs instead of a cost per result. Check fallback and retry behavior separately because additional attempts can change both elapsed time and spend. Do not translate the vendor token rate into a promised task price.

Decide before expanding

Set your quality, latency and spending thresholds before any authorized trial. Keep the rollout limited until the retained results meet those thresholds and the fallback is understood. If a workflow cannot expose route, timing or charge information, treat those fields as unknown. Start with our workflow evaluation guides and use the contact route for a selection question; this article does not establish a tested winner or recommend replacing every model route.

Continue your comparison

Claude profile and separately recorded consumer-interface cases →

Evaluate an agent with a small, reviewable task →

Compare no-code workflow approaches →

Discuss a workflow selection question →