Your OpenAI model IDs stop on 23 October, so map each one before then

Your app can keep calling a model ID that OpenAI stops serving on 23 October 2026. OpenAI's deprecations page lists a replacement for each one, and most of the table shares that single date.

What the OpenAI page saysCopy Anchor Link

The page has a section headed "2026-04-22: Legacy GPT model snapshots." It lists each snapshot with a shutdown date of October 23, 2026 and a substitute model. The page does not say that requests will fail. It says: "At the time of the shut down, the model or endpoint will no longer be accessible." A call to a model that is no longer accessible cannot succeed, so treat the date as the end of that ID.

The page also has a separate section for April 2027. It says: "The following models are deprecated and will be removed from the API on April 1, 2027, with six months' notice." That list names GPT-5.3-Codex, GPT-5.1 and GPT-5.4-Nano, and it is not part of this October deadline. If you want that one, read the April 2027 migration checklist.

The rules below are ours, and they are labelled as ours.

The snapshots that stop on 23 OctoberCopy Anchor Link

The table below is taken from the page. Where the page lists an alias next to a snapshot, the alias is in brackets. Fine-tuned models have their own table, which names a recommended base model rather than a direct replacement.

The fine-tuned table lists five more: ft-gpt-3.5-turbo and ft-babbage-002 and ft-davinci-002 take gpt-5.6-terra as the base model, ft-gpt-4 takes gpt-5.6-sol, and ft-gpt-4.1-nano-2025-04-14 takes gpt-5.6-luna. The table names a base model for each one, so a fine-tuned app means retraining on that base. Your training data and the new base model are a separate job.

Find every ID in your codeCopy Anchor Link

Search the repository for the model strings in the table above, and search for the aliases too. A string like gpt-4 can match more than one place, so read each hit. Check the environment files, the CI secrets, the admin settings and any prompt store you keep outside the repo, because a model ID often lives in one of those and not in the code.

Keep the IDs in one config file. Our rule is one place per model choice, so a switch touches one line rather than a dozen call sites. The map can be as small as this:

// model choices, in one place
export const MODELS = {
  chat: "gpt-5.6-sol",
  cheap: "gpt-5.6-luna",
} as const

Name the purpose, not the model. A name like chat survives the next migration, and a name like gpt4 does not.

Test behavior, not only the IDCopy Anchor Link

A replacement ID that the page lists tells you where to point the call. It does not tell you that your prompts produce the same output. The page does not describe output parity between the old and new models, so do not assume it.

Run your real prompts through the new ID before the switch. Compare the outputs against a small set you already trust, and check the cases that matter most to your product: the structured output your parser reads, the tone your users see, and the tools your agent calls. Change one model at a time, so a regression points at one choice.

Plan the switch before 23 OctoberCopy Anchor Link

Work backward from the date. Find the IDs, map them, test them and ship the change at least a few days before the deadline, so a failed test does not become an outage. A shutdown on a Friday night is a bad time to learn that a prompt broke.

Keep the old ID working in staging until the change is live in production. After 23 October, the page says the old ID is no longer accessible, so a staging copy that still points at it will fail on that date too.

Confirm the switch in your logsCopy Anchor Link

Log the model ID on every request your app makes. A log line that shows the model used is the only check that does not depend on memory. Before 23 October, search those logs for each old ID. Once the switch is live, a search for the old IDs over the last seven days should return nothing. If it returns rows, something still calls the old ID, and you have found it before the deadline rather than on it.

Watch for the places logs do not reach. A scheduled job, a webhook handler or a script run by hand can keep a model ID for months without showing up in the request logs you read each day. List those jobs when you find the IDs, and check each one by hand after the switch.

Keep the parameters honestCopy Anchor Link

A new model ID can keep the same request shape and still behave differently. Read each call site for the parameters it sends, such as the output length, the response format or a reasoning setting, and compare them with what the replacement accepts. The page's o1-pro row names a reasoning mode setting, which is one parameter you should check in particular. Remove any setting the new model does not use, rather than leaving it in place to fail silently.

Where OTF standsCopy Anchor Link

If you want an AI-ready app with the model IDs already set for you, we cannot point you to one. We checked the SaaS Dashboard, Booking, Fitness and Arcade kit pages for OpenAI, GPT, model ID and LLM terms, and none of them mentions a model ID. Their footers say "AI configs pre-wired," which this article does not read as a model configuration.

The pricing page lists the Full-stack kits at $99 each and the Everything Bundle at $149, both as one-time payments, and it offers a live demo before you buy. Check each kit's repository for the model settings it uses before you rely on any of them. If you are choosing a starting point for a product, the pricing page is the place to compare kits side by side: OTF pricing.

SourcesCopy Anchor Link

• OpenAI, API deprecations: https://developers.openai.com/api/docs/deprecations
• OTF pricing: otf-kit.dev/pricing