What Changed When Priority Became Fast Mode

A service tier got a new name. That's the entire event, as far as this site's own careful, dated research has been able to confirm — no repricing, no change in which models offer it, no change in the underlying latency benefit that made the tier worth choosing in the first place. And yet a rename this small is worth its own article, because the actual risk it creates has nothing to do with what changed and everything to do with what didn't get updated everywhere it should have.

What actually happened

Priority processing became Fast mode. Both service_tier: "priority" and service_tier: "fast" remain accepted by the API — the old identifier wasn't removed, just superseded. Every other detail about the tier this site has been able to verify — its price relative to Standard, which models offer it and which don't, the latency benefit it's built for — appears unchanged across the rename.

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 two names just coexist indefinitely in different parts of an organization's understanding.

Where this actually causes friction

The friction isn't functional — a request tagged with the old identifier works exactly the same as one tagged with the new one. It's in communication and onboarding: a new team member reading current OpenAI documentation learns "Fast mode" and then encounters a colleague's script referencing "Priority" with no explanation of why the two terms mean the same thing. Or the reverse — someone maintains institutional knowledge under the old name and struggles to map a newer team member's references to "Fast" back to what they already know. Neither confusion is dangerous, but both cost real time to untangle, repeatedly, for no functional reason.

Why this site records the rename explicitly rather than just updating silently

It would be simpler to just always use "Fast mode" going forward and let old references quietly become obsolete. This site does that for anything it writes new — but it also states the rename explicitly, with both names, specifically because a reader arriving from an older piece of documentation, an older blog post, or their own older notes needs to know the two names refer to the same thing, not silently encounter one name here and a different one elsewhere with no bridge between them.

What to actually do about it in your own systems

New code and new documentation should use the current identifier — there's no reason to keep writing fresh integrations against a superseded name just because the old one still technically works. Existing code using the old identifier doesn't need urgent migration purely because of the rename, since it isn't broken — but it's worth updating opportunistically, the next time that code is touched for an unrelated reason, rather than treated as a standing task worth its own dedicated migration effort.

The broader pattern this is one instance of

Vendor renames that preserve backward compatibility are common enough across the industry that it's worth having a general habit for handling them, not just a one-off fix for this specific case: when you notice a rename like this, a brief note in whatever documentation your team actually reads — not a comprehensive migration, just a bridge connecting the old name to the new one — pays for itself the first time it saves someone from independently rediscovering that the two names are the same thing.

Why small, low-stakes changes like this are still worth tracking

None of this is high-drama the way a genuine repricing or a capability change would be. That's precisely the point of including it in this site's running record of pricing and naming changes: a reference that only records dramatic changes gives a false sense that anything not mentioned hasn't moved at all. Recording the quiet, low-stakes renames too is part of what makes the absence of a note about something else actually mean "nothing changed," rather than "nothing dramatic changed."

What this rename doesn't tell you, and shouldn't be read to imply

It's worth resisting the temptation to read strategic significance into a name change this small — there's no evidence here that "Fast" signals a different positioning, a future roadmap change, or anything beyond a naming preference. Vendors rename things for all sorts of internal reasons that rarely make it into public documentation, and treating every rename as a hint about bigger changes to come is a habit that produces more speculation than insight. The honest reading of this one is exactly as narrow as what's actually been confirmed: a name changed, the backward-compatible old identifier still works, and nothing else has been found to move alongside it.

How to verify this yourself rather than take it on faith

If you maintain integrations that reference either name, the API's own current documentation is the place to confirm both identifiers are still accepted, rather than relying on this page's account indefinitely — documentation like this ages, and a rename that preserved backward compatibility today isn't a permanent guarantee that compatibility continues indefinitely. Checking periodically, the same way this site checks its own published facts on a standing schedule, is the more durable habit than trusting any single article, including this one, as a permanent source of truth.

The single sentence worth taking away from this whole page

If nothing else from this article sticks, this is the part worth remembering: two names, one tier, no functional difference confirmed so far — and the only real action item is making sure everyone on your team, and everything your team has written down anywhere, knows that both names point to the exact same underlying service tier, not two related-but-different options.