Anthropic has removed the waiting list from the fast mode of its most capable model, making a setting that trades cost for speed available to developers and subscribers who had been queued behind a research preview.
The company described the setting as a different configuration of the same model rather than a smaller version of it. Output runs up to 2.5 times faster than the standard mode, according to the company, using the same underlying model weights. The option is available for the Opus releases at version 5.5 and the two preceding versions, and not for the smaller and cheaper model families.
Developers reach it through an API parameter, and users of the company’s coding tool switch it on with a single command. Pricing runs at 8 dollars per million input tokens and 40 dollars per million output tokens, which is above the standard rate for the same model but below what the previous generation’s fast setting cost.
The design choice is worth pausing on. Most developers of frontier models sell a family of different models and let customers pick by capability, with the smaller ones cheaper and faster. Anthropic’s approach separates speed from capability and charges for speed as its own feature, which assumes that some buyers care more about latency than about the price of the tokens that produce it.
There is a real market for that. An agent that writes code, runs a test and reads the result in a loop pays for latency many times per task, and the delay compounds. A customer support system answering a live conversation needs an answer inside a second or two, and a slow model makes the exchange feel broken regardless of how well it reasons.
The economics of inference explain the pricing gap. Generating text faster requires either more computing capacity working on the same request or a scheduling method that admits more requests at once. Both raise the cost per token, and both reduce the number of other customers the same hardware can serve during that window. Charging more for the fast configuration is how a provider keeps those two uses from competing for the same capacity.
The billing details carry the practical risk for buyers. Usage in the fast mode draws on a separate allowance rather than sharing the standard quota, and the company has said the fast configuration does not share prompt caching with the standard one. A cache that stores the repeated prefix of a long prompt is how customers cut the cost of the large context windows these models accept, and losing it for a fast request changes the arithmetic. Enterprise administrators can turn the setting off by default for their accounts.
The comparison buyers will make is with competitors that offer speed at the low end. Several labs sell small models that respond quickly at a fraction of the price, and for many tasks those models are good enough. The case for a fast configuration on the largest model rests on the tasks where a cheaper model fails, and the buyer who pays a premium for speed is betting that the quality difference survives the constraint.
Latency has become a competitive dimension in its own right over the past year. Inference providers have built caching layers, speculative decoding and hardware-specific optimizations to cut response times, and buyers of coding tools compare the seconds a request takes as readily as they compare the quality of the code. A vendor that lets the same model run in two speed tiers sells to both kinds of buyer.
Support for older versions is unusual and reveals something about the customer base. The setting works on three generations of the top model, which suggests that customers keep older models in production and would resist a change that forced an upgrade. Compatibility with deployments already in use is what an enterprise buyer asks about first.
What the company has not published is how the speed gain holds under load, how output quality compares between the two settings on real tasks, and how the separate quota is sized for a typical account. Those are the numbers engineering teams ask for before switching a production system, and they are the ones that will be tested in the coming weeks by customers with bills to compare.
Publishing a research preview and then opening it more widely is the pattern the company has followed with several features, and the sequence serves a purpose beyond marketing. Preview users generate the load data that tells a provider how a configuration behaves across many requests, which is the information needed to price it and to decide how much capacity to reserve.
Pricing above the standard rate for the same weights also raises a question about what standard mode is for. If the company can serve the model faster at a higher price, the standard configuration is best understood as a capacity allocation decision dressed as a product tier: customers pay less per token and wait, or pay more and move to the front of the queue.
The competitive response is likely to be a matching tier rather than a price cut. Once one provider sells speed as a separate line item, buyers comparing offers ask for the same option, and a rival that cannot serve a faster configuration without raising its price must either invest in serving efficiency or explain why its answers take longer.
