The rate card gap is real, but it isn’t the whole story
Every serious provider now lists two Anthropic line items: Opus 5 and Opus 5 Fast. Pull up the current rates on /models and the gap between them is not a rounding error, it’s the kind of spread that changes which model wins your unit economics if you take it at face value. The mistake is stopping at that spread.
A per-token discount only tells you what one call costs. Agent workloads run many calls per task, and the number of calls is exactly the variable a “fast” tier is most likely to move. If the fast tier needs an extra tool call, a re-ask, or a longer transcript to reach the same outcome, the discount you saw on the rate card gets eaten before the invoice arrives.
Two different reasons a “fast” tier is cheaper
A cheaper tier gets there one of two ways: the same model served leaner (speculative decoding, lower-precision serving, better batching), or a genuinely smaller model wearing the same brand name. These are not interchangeable, and open-weight labs let you check which one you’re getting because they publish parameter counts.
Look at GLM-4.7 against GLM-4.7 Flash. The flagship runs 358B total params with 32B active; the Flash variant drops to roughly 31B total with about 3B active. That’s not a serving optimization on the same brain, it’s an order-of-magnitude smaller checkpoint doing an order-of-magnitude less compute per token. Cheaper, yes, but cheaper because it’s thinking less, not because someone found a free lunch in the inference stack.
Now look at Qwen3.6 35B A3B against Qwen3.6 27B. Total footprint sits in the same rough class, 36B versus 27.8B, but the dense 27B model uses all 27.8B params on every token while the MoE variant routes through about 3B. Same size class on disk, wildly different compute bill per token, and that’s the mechanism a routed “fast” tier is selling you: fewer active parameters per call, not a smaller download.
Anthropic doesn’t publish which of these two stories applies to Opus 5 Fast. No active-parameter count, no architecture disclosure. That’s the honest limit here: you can verify the mechanism for open weights and reason from it, but for a closed model you’re buying a discount without being able to audit what it’s cutting.
Model the workload, not the token
Take a concrete shape: a multi-step agent loop where each step reruns a growing transcript and produces new output. Say a support-ticket triage agent needs a second tool call on roughly one ticket in six when routed to the fast tier, because the smaller reasoning path misses a field the flagship would have caught on the first pass. That one extra round trip adds transcript tokens on top of the output tokens, and it lands disproportionately on exactly the tickets that were already ambiguous enough to need the tool call in the first place. Run the math on a few thousand tickets a day and that “one in six” line item stops looking like a rounding error.
This is a scenario to model against your own logs, not a measured number, and that’s the point: the fast tier’s real cost isn’t on the rate card, it’s in your step count. Pull the live rates for both tiers, run them against your actual steps-to-completion, and use the calculator to find where the crossover sits for your workload rather than guessing from the sticker price.
The same pattern shows up outside model pricing. GPU marketplace capacity for something like H200 NVL prices roughly 70% or more below secure on-demand tiers as of this writing, and that gap is real money on the invoice. It’s also not free: you’re trading guaranteed uptime for a discount, same as trading reasoning depth for a discount on the fast tier. Cheap tiers don’t remove cost from a system, they relocate it to wherever your workload is least tolerant of the tradeoff.
The rule
Pull your last week of production traffic on Opus 5 and get the average steps-to-completion for your actual task class. Route a matched sample through Opus 5 Fast and measure the same number. Check the current discount on the fast tier’s output-token rate against the flagship’s on /vs. If the discount percentage is bigger than the percentage increase in steps-to-completion, migrate the traffic and take the savings. If the step count grows faster than the price drops, the fast tier is a worse deal than the rate card makes it look, no matter how wide the gap seems on the page.