Moving from Priority to Fast Mode Naming

This is the smallest migration on this site's entire list, and it deserves a page anyway, precisely because "small" migrations are exactly the ones most likely to get skipped indefinitely — nothing forces the update, so it's worth a deliberate, quick, five-minute pass rather than left to happen accidentally over an unspecified amount of time, if it ever actually happens at all.

What actually needs to change

Anywhere your code, scripts, or documentation references the priority service-tier identifier by name, updating it to fast is the entire technical scope of this migration — both identifiers are accepted by the API, so nothing breaks if you don't do this, but new code and new documentation should use the current name rather than perpetuating a superseded one indefinitely.

Why this is worth doing even though nothing is actually broken

An identifier that still works but has been renamed is exactly the kind of detail that causes confusion months or years later — a new team member reading current documentation learns "Fast mode," encounters an internal script referencing "Priority," and has no way to know the two mean the same thing without someone explaining it. Migrating deliberately now removes that confusion at the source rather than leaving two names for the same thing to coexist indefinitely across your systems.

Finding every place the old name appears

A straightforward text search for priority across your codebase, scripts, configuration, and internal documentation will surface most instances — though it's worth being careful that a bare text search doesn't produce false positives from unrelated uses of the word "priority" that have nothing to do with the service tier, which is a real risk given how common that word is in ordinary technical writing outside this specific context.

Updating documentation alongside code

Code references are the functionally important half of this migration, but internal documentation, wikis, and onboarding materials referencing the old name matter just as much for avoiding the confusion this migration is meant to prevent — a codebase fully migrated to the new identifier while all the surrounding documentation still says "Priority" only half solves the actual problem, since a reader encountering the documentation first will still be confused by the mismatch.

No behavior testing required, which makes this an easy one

Unlike most migrations this site covers, there's no behavior to test here — price, latency benefit, and model availability for this tier all appear unchanged across the rename, based on this site's own research. This migration is close to purely cosmetic, which makes it one of the lowest-risk items on this entire list to knock out, with essentially no chance of introducing a functional regression along the way.

A good candidate for a quiet, opportunistic fix

Because there's no urgency and no risk, this is a reasonable candidate to fix opportunistically — the next time you're touching a file that references the old name for an unrelated reason, updating it then rather than treating it as a dedicated task worth scheduling separately. Not every migration needs a formal project; some are small enough to absorb into ordinary maintenance as you go.

Confirming both identifiers still work, for your own peace of mind

If you want direct confirmation rather than relying purely on this site's account, sending a request with each identifier and confirming both succeed with identical behavior is a five-minute check worth doing once, especially before committing to migrate away from the old identifier in anything you're not planning to revisit soon.

Why this page exists on a site mostly about bigger decisions

Most of this site's migration guidance concerns genuine tradeoffs — cost, context window, recency. This one doesn't have a tradeoff at all; it's included because a complete reference covers the full range of migrations a reader might actually search for, including the small, low-stakes ones, and because even a low-stakes migration benefits from a clear, dedicated answer rather than being left as an assumption nobody's actually verified.

What this migration teaches about renames generally

Even though this specific rename carries no functional risk, it's a useful, low-stakes example of the broader discipline this site recommends for any vendor rename: verify explicitly that nothing beyond the name actually changed, rather than assuming a rename is always purely cosmetic. This one genuinely is, as far as this site's research has confirmed — but that confirmation came from actually checking, not from assuming renames are always this simple, and the next rename this ecosystem ships might not be.

A final sanity check worth running

If you're uncertain whether your own systems have fully migrated, a quick audit — grepping for the old identifier across your codebase, configuration, and any automation scripts one more time — is a cheap way to confirm the migration is genuinely complete rather than assumed complete based on memory of having done it at some point in the past, months ago, possibly by someone who's since left the team.

What "done" actually looks like for this specific migration

Done means every new reference uses the current name, every piece of internal documentation someone might actually read reflects the current terminology, and there's no meaningful confusion left for a new team member encountering both names with no context for why. It doesn't require purging every single historical reference from old commit messages or long-closed tickets — that's not a genuinely productive use of anyone's time for a change this low-stakes, and it's worth being explicit up front that "done" here has a reasonable, deliberately bounded scope rather than an exhaustive, unreasonably thorough one.