On July 30, 2026, OpenAI renamed a pricing lever. The lever is the story.
Priority Processing became Fast mode. Same service_tier parameter, same 2x-of-Standard price, same "up to 2.5x faster and more consistent" latency claim — just a name a developer might actually reach for instead of skipping past as enterprise-only jargon. Source: OpenAI, "Fast mode," API docs, 2026. The rename is a footnote. What it points at isn't: most teams still think of an LLM's price as one number per model. For GPT-5.6 Sol, Gemini 3.1 Pro, and every model behind a modern API, it's up to four — and which one you pay is a setting most integrations never touch after the day they were written.
The four tiers, in plain terms.
Every major provider now sells the same model at multiple price-latency points instead of one:
- Fast / Priority — a premium tier for predictable, low latency. OpenAI's Fast mode runs 2x the Standard rate; Google's Priority tier on Vertex AI and Gemini runs roughly 1.8x Standard and is explicitly "non-sheddable," meaning it won't get queued behind Standard traffic during a busy period. Source: OpenAI Fast mode docs, 2026; Source: CloudZero, "Google Vertex AI Pricing," 2026.
- Standard — the default. Real-time, best-effort latency, the rate on the pricing page everyone quotes.
- Flex — OpenAI's discount lane for the Responses and Chat Completions APIs: priced at Batch rates, in exchange for slower responses and occasional 429s when capacity is tight. Requests that hit a 429 aren't billed. Source: OpenAI, "Flex processing," API docs, 2026.
- Batch — fully asynchronous, roughly half of Standard, built for jobs that can wait rather than requests that can't.
For GPT-5.6 Sol, short context, that's $8.00 / $40.00 per 1M input/output tokens on Fast mode, $4.00 / $20.00 on Standard, and $2.00 / $10.00 on Flex or Batch — a flat 4x spread on the exact same weights, for the exact same request, decided entirely by one field in the request body. Source: OpenAI API pricing, 2026.
Three providers, three menus, and the menu itself isn't fixed.
This is where it gets interesting for anyone tempted to hardcode a choice and move on. OpenAI's four-tier ladder above is one shape. Google's is close but not identical: Gemini and Vertex AI offer Standard, Priority (~1.8x, dedicated capacity, tighter SLA), Flex, and Batch, spanning models from Gemini 2.5 Flash-Lite up through Gemini 3.1 Pro. Source: CloudZero, "Google Vertex AI Pricing," 2026. Anthropic's shape changed under its own feet mid-2026: Priority Tier as a purchasable capacity commitment was closed to new customers, with existing commitments honored through their contract term; the service_tier parameter itself is still live on the Messages API, accepting auto or standard_only on request and returning standard, priority, or batch on response. Source: Anthropic, "Service tiers," Claude Platform Docs, 2026. A tier that was purchasable in January was retired for new buyers by August. That's not a one-time migration to absorb once — it's the same "pricing keeps moving under a static integration" pattern that has driven every model-selection and cache-strategy post on this blog, just running one layer over, on tiers instead of models.
The complexity got real enough that OpenRouter shipped a dedicated abstraction for it: a service_tier request parameter, :nitro and :floor model-name suffixes that sort candidate endpoints by throughput or price, and explicit provider slugs for pinning a tier directly. Billing "always follows the endpoint actually used," so a Priority request that falls back to Standard capacity is billed at the Standard rate, not the rate you asked for. Source: OpenRouter, "Service Tiers," docs, 2026. An entire routing feature exists because picking the right tier, per request, per provider, on a landscape that reshuffles every few months, was too much for teams to track by hand.
Where the 4x gets wasted, and where it gets needed.
The mistake is the same one this blog keeps returning to with models: pick one setting at integration time, apply it to every request forever. With tiers it shows up in both directions.
Paying Fast/Priority for work nobody is waiting on. A nightly re-embedding job, a batch of evals, a backlog of support-ticket classification — none of it is blocking a human, and all of it is billed at up to 4x Flex/Batch rates if the integration never sets service_tier. OpenAI is explicit that Flex is built for exactly this: "model evaluations, data enrichment, and asynchronous workloads." Source: OpenAI Flex processing docs, 2026.
Paying Standard for work a user is actively watching, when Fast was cheap insurance. A support-chat reply, an in-IDE code completion, a voice-agent turn — the kind of request where every added millisecond is a UX cost, not just a bill line — is exactly the case Google built the "non-sheddable" guarantee for. Paying 1.8-2x to keep that request out of a queue during a traffic spike is often the correct trade, not an indulgence.
Running production traffic on Flex without a fallback. Flex can 429 under load, and OpenAI's own guidance is to catch that and retry with service_tier: "auto" or fall back to Standard. Source: OpenAI Flex processing docs, 2026. Chasing the 2x discount on a path a customer is staring at, with no fallback wired in, trades a bill line for an outage.
None of these are model-quality questions. The model doesn't change. The weights don't change. The only thing moving is how much latency risk you're willing to sell back to the provider for a given request, and that answer is different for a chatbot reply than for a nightly backfill — which means it's a per-request decision, the same way which model handles a request is a per-request decision, not a once-at-launch one.
What actually ships this week.
- Tag every call site by latency tolerance, not just by model. "User is watching" vs. "nobody is watching yet" is a two-value classification most codebases can add without touching model selection at all.
- Move anything async off Standard by default. Evals, embeddings backfills, enrichment pipelines, and nightly reports belong on Flex or Batch. That's close to the discount batch inference already gets you — tiers extend the same idea to synchronous APIs that can tolerate delay.
- Wire a fallback on anything running Flex in front of a user, even rarely. A 429 with no retry path turns a savings feature into an incident.
- Re-check your tier menu on a schedule, not once. Anthropic closing Priority Tier to new commitments in 2026 is proof the menu itself can change under an integration nobody revisited.
- Don't confuse a faster tier with a cheaper one. Fast and Priority are latency purchases at a real premium — worth it for the request a person is waiting on, wasted on the one that isn't.
Where this fits next to routing.
Model routing decides which model answers a request based on what the task needs. Verifier-gated cascades decide whether that answer was good enough before it ships. Tier selection is the same shape of decision on a third axis: not which model, not whether the answer passed, but how much of the 4x latency premium this particular request is worth paying. Handled well, it's a small, mechanical rule — is someone waiting, yes or no — sitting right next to the routing decision a request already goes through.
That's the layer Nadir sits at: point traffic at model=auto and every request already gets priced against live model and provider economics instead of a hardcoded integration. Extending that same per-request policy to tier, so a background job never pays Fast-mode rates and a live chat reply never silently lands on Flex, is the next turn of the same crank — one more setting that shouldn't have to be decided once, by hand, on the day someone wrote the integration.
Conclusion.
Fast mode is a rename. The 4x spread it sits inside is not, and it isn't going away — Google runs a nearly identical ladder, and even Anthropic's more conservative tier structure has already changed shape once this year. A team that picks Standard for everything is leaving Flex and Batch discounts on the table for every async job it runs. A team that picks Flex for everything to chase the discount is one traffic spike away from a 429 hitting a real user. The fix isn't a better guess at integration time. It's making the tier decision per request, the same way the model decision already should be.
Data in the chart is drawn from published provider pricing and documentation as of August 2026, not from proprietary production traces. Sources: [OpenAI, "Fast mode," API docs](https://developers.openai.com/api/docs/guides/priority-processing). [OpenAI, "Flex processing," API docs](https://developers.openai.com/api/docs/guides/flex-processing). [OpenAI API pricing](https://developers.openai.com/api/docs/pricing). [Anthropic, "Service tiers," Claude Platform Docs](https://platform.claude.com/docs/en/api/service-tiers). [CloudZero, "Google Vertex AI Pricing: Complete Enterprise Guide (2026)"](https://www.cloudzero.com/blog/google-vertex-ai-pricing/). [OpenRouter, "Service Tiers," docs](https://openrouter.ai/docs/guides/features/service-tiers).