Claude Opus 5.5 Fast Mode Is Generally Available: The Beta Header Was Your Cost Control

Fast mode for Claude Opus 5.5 came out of research preview on 15 October 2026. Two things changed at once. Teams no longer need to request access, and requests to the model no longer need the fast mode beta header that the preview required. Reported pricing is 8 US dollars per million input tokens and 40 per million output tokens, against 4 and 20 for the same model at standard speed, in exchange for up to 2.5 times more output tokens per second. Reporting also says the Batch API is not available for fast mode, and that prompt caching and data residency multipliers apply on top of the fast mode price. These figures come from release coverage rather than a contract, so confirm them on the Anthropic pricing page before you build a budget on them.

The capability is genuinely useful. Opus 5.5 at standard speed is already cheaper than Opus 5 was, and the reported fast mode rate on Opus 5.5 is below the fast mode rate on Opus 5 and Opus 4.8. For interactive work where a person is waiting, such as a coding agent in Claude Code, a support copilot or a voice agent that needs the reasoning of a large model, cutting wall clock time by more than half can change whether the feature is usable at all. Nothing in this post argues against using it. The point is narrower: the way you turn it on has changed, and with it the control that most teams were relying on without writing it down.

During the preview, fast mode was gated twice. Someone had to apply for access, and someone had to add a beta header in code. Both steps were visible. The access request landed in an inbox, and the header showed up in a pull request where a reviewer could ask why. That is not a formal control, but in practice it meant fast mode spend arrived through a deliberate decision. With general availability both gates are gone. Switching to fast mode is now an ordinary request parameter, which can be set in a config file, an environment variable or a framework default that nobody reviews, and the bill for that call doubles from the first token.

The multipliers are where estimates go wrong. A team that already pays a data residency premium, or that leans on prompt caching to make a long system prompt affordable, will see those multipliers applied to the fast mode price rather than the standard one. And because batch processing is reported as unavailable for fast mode, any workload that was quietly moved to fast mode and also relied on batch discounts loses both savings at once. The practical result is that a job that looked like a two times cost increase in a planning spreadsheet can land well above that once the real request mix is counted. Model it on your own traffic, with your own cache hit rate and residency settings, rather than on the headline rate.

The first control to put back is a written rule for where fast mode is allowed. Most organisations need a short list: interactive, latency sensitive paths where a human is waiting, approved by the product owner, with a named cost owner. Background jobs, evaluations, nightly pipelines and anything that would otherwise go through batch stay on standard speed. Put that rule in the same place as your model routing policy, and if you run a gateway or proxy in front of the Claude API, enforce it there by allowlisting fast mode for specific services rather than leaving it to each caller. A rule that only exists in a wiki will not survive the next framework upgrade that changes a default.

The second control is visibility. Your monthly invoice will tell you that Opus spend went up. It will not tell you which service started sending fast mode requests. Tag requests by service and environment, log the speed setting alongside the model name and token counts, and set budget alerts in the Anthropic Console or your cloud billing tool at the workspace level, so a doubling in one service shows up within a day rather than at month end. If your teams use Claude Code with a company API key, the same applies there: the fast mode toggle in the CLI spends the same organisation budget, and it is worth checking whether your managed settings allow it.

There is a compliance angle that is easy to miss because nothing about the model changed. Under ISO 42001, a change to how an AI system in use is configured, including its performance and cost profile, should be assessed and recorded, and SOC 2 change management expects production configuration changes to go through review. Turning on fast mode for a customer facing service is that kind of change, even though the model name stays the same. Record it in your AI system inventory, note the effective date and the approval, and add a line to your vendor register that Anthropic pricing for this mode changed on 15 October 2026. That record is what you will want when finance or an auditor asks why the AI line item moved.

A short list for this week. Search your code and configuration for the old fast mode beta header and for the new speed parameter, so you know where fast mode is already on. Confirm the current prices and multipliers on the Anthropic pricing page and update your cost model with your real cache hit rate and residency settings. Write down which services may use fast mode and who owns the cost, and enforce it at the gateway if you have one. Set a budget alert per workspace. Then log the change in your ISO 42001 inventory and your change management record, using the tracking features in Vanta, Drata or Secureframe if that is where your evidence lives.

Our view is that general availability is a good outcome. Fast mode is cheaper on Opus 5.5 than it was on earlier models, and removing the access request makes it easier to use where it is worth paying for. The gap is in governance rather than the product. The preview process happened to act as a spending approval, and that approval disappeared on 15 October without anyone deciding to remove it. Put a deliberate one back, keep it small, and fast mode becomes a tool you choose for specific paths rather than a cost you discover on the invoice.