What Changed When Priority Became Fast Mode

A service tier got a new name — and, it turns out, a little more than that. When this article was first written, it described Priority becoming Fast mode as a rename and nothing else. A closer reading of OpenAI's own Fast mode guide shows that was wrong: the rename arrived with a speed increase for GPT-5.6 Sol, and it left behind a reporting quirk that matters more to day-to-day monitoring than the name ever did. The original argument still stands — a rename with a preserved old identifier is a particularly sneaky kind of change — but the list of what actually changed is longer than this page used to admit.

What actually happened

Priority processing was renamed Fast mode on July 30, 2026. Both service_tier: "priority" and service_tier: "fast" remain accepted; a request tagged with the old value simply runs in Fast mode. At the same time, OpenAI raised Fast mode's speed for GPT-5.6 Sol to up to 2.5x faster than Standard processing. What carried over unchanged is the shape of the deal: Fast charges a per-token premium over Standard, cached-input discounts still apply to it, and it shares a model's Standard rate limit rather than adding a separate pool on top.

What has changed since

The tier hasn't stood still after the rename either. Fast mode began accepting long-context requests on the GPT-5.6 models — prompts past 272K input tokens, which previously couldn't run in it at all. Every GPT-6 model launched with Fast pricing of its own. And a quicker tier, Ultrafast, now sits above it for GPT-6 Astra: a separate tier with its own price and its own token limits, not Fast under another name. The service tiers reference lays all of them side by side.

The reporting quirk that matters more than the name

For GPT-5.6 and earlier models, the service_tier field in the response reports priority whether you sent priority or fast, and the usage dashboard groups those requests under priority too. A dashboard or alert written after the rename — filtering on fast, because that's what the current documentation calls the tier — quietly counts nothing for those models. OpenAI states that behavior for GPT-5.6 and earlier specifically, so if you run newer and older models side by side, filter on both names rather than assuming either one covers everything.

There's another value to watch for. If your traffic ramps too quickly, some Fast requests are downgraded to standard speed and charged standard rates, and the response then reports service_tier: "default". A cost report that assumes every request sent as Fast was billed as Fast will overstate spend in exactly the periods when traffic surged. OpenAI's guidance is to slow the ramp once traffic reaches 1,000,000 input tokens a minute, adding no more than 50% in any 15-minute stretch, and the ramp limit counts all of your traffic together, across projects.

Why a rename with a preserved old identifier is a particularly sneaky kind of change

If the old identifier had simply stopped working, every integration using it would have failed loudly and immediately, forcing an update on a clear, unmissable timeline. Because it keeps working, nothing forces anyone to notice the rename happened at all. A script written against "Priority," an internal wiki page describing "the Priority tier," a team's collective mental model built around the old name — none of these break, so none of them get corrected, and the old and new names coexist indefinitely in different parts of an organization's understanding.

Where this actually causes friction

Most of the friction is in communication and onboarding: a new team member reading current OpenAI documentation learns "Fast mode" and then meets a colleague's script referencing "Priority" with no explanation of why both terms mean the same thing — or the reverse, someone who learned the old name struggling to map a newer colleague's "Fast" back to what they already know. Neither confusion is dangerous, but both cost time to untangle, repeatedly. The reporting quirk adds a functional edge this page originally said didn't exist: the old name is still what some responses and dashboards show, so the mismatch reaches monitoring, not just conversation.

A setting that switches tiers without touching code

Fast mode can also be turned on for a whole project. In the project's general settings, changing the default service tier to Fast makes every request that doesn't specify a service_tier run in Fast mode, with traffic moving over gradually. That's convenient for a latency-sensitive product and a trap for everything else sharing the project: a batch-style job with no tier in its code starts paying Fast rates, and nothing in the code explains why. If a project's bill rises with no deploy to blame, check that setting before the code.

In Codex the switch is /fast, and it only appears for models whose catalog advertises a Fast tier. Signed in with ChatGPT, Fast draws on included usage at 2.5x the Standard rate and bills purchased credits at 2x — OpenAI notes those are billing multipliers, not speed figures. With an API key, Codex simply uses the API's Fast token prices. The Codex credits calculator shows what that does to a credit balance.

Fast mode isn't identical across models

The name is shared; the guarantees aren't. OpenAI's FAQ says Fast mode for GPT-6 Astra carries no latency SLA, while GPT-5.6 and earlier models get the same service-level treatment as Scale Tier. Fast mode isn't available with EU data residency for GPT-6 Astra, GPT-6.1 Sol, GPT-6 Sol or GPT-6 Luna, and it doesn't support fine-tuned models or embeddings on any model. A team moving a latency-critical workload from GPT-5.6 Sol to a GPT-6 model while staying on Fast is changing more than its model — it may be giving up an SLA, and, in the EU, the tier itself.

What to actually do about it in your own systems

New code and new documentation should use fast; there's no reason to write fresh integrations against a superseded name. Existing code using priority isn't broken and doesn't need an urgent migration for the name alone. Monitoring is different: anything that groups, filters or alerts on the service tier should accept priority, fast and default, because any of them can appear for traffic you sent as Fast. And when reconciling costs, group by line item rather than trusting the tier you requested — the billed tier is the one that counts.

Why small changes like this are still worth tracking

None of this is high drama the way a repricing or a capability change would be. That's precisely why it belongs in this site's running record of pricing changes: a reference that only records dramatic changes gives a false sense that anything not mentioned hasn't moved. This page's own history makes the point: it first recorded the rename as cosmetic, and the details it missed turned out to be the ones with operational consequences.

What the rename doesn't tell you

It's still worth resisting the temptation to read strategy into a name. There's no evidence that "Fast" signals a roadmap beyond what OpenAI has published, and treating every rename as a hint about bigger changes produces more speculation than insight. What the record supports is narrower and more useful: the name changed, the old identifier still works, the speed for one model went up at the same moment, and the old name lives on in some responses and dashboards.

How to verify this yourself

If you maintain integrations that reference either name, OpenAI's Fast mode guide is the place to confirm both identifiers are still accepted and which models report which value — not this page, indefinitely. Backward compatibility that holds today isn't a permanent guarantee. Checking on a schedule, the same way this site re-checks its own facts, is the more durable habit than trusting any single article as a permanent source of truth — including this one, which has already needed correcting once.

The one thing worth taking away

Both names point to the same tier — but not quite the tier it was before the rename, not reported under the same name everywhere, and not offering the same guarantees on every model. Make sure your team's notes say the names are interchangeable, and make sure your monitoring doesn't depend on which one a response happens to use.