OpenAI says GPT-5.5 will retire on October 14, 2026, from ChatGPT, ChatGPT Work, and Codex. The OpenAI API is not included in that retirement notice.
That sounds like a model-picker errand: choose something newer, click save, carry on. The snag is that a visible picker is only one place a model choice can live. A saved setting, a workspace default, a custom agent, a scheduled task, or a command can each keep an explicit reference around long after the obvious setting has been changed. Configuration has a talent for hiding in plain sight. It is almost impressive, in the least helpful way.
So the useful job before the cutoff is not declaring one universal successor. It is making a small, bounded inventory of any workflow that explicitly selects GPT-5.5, then testing the replacement in the same place it will actually run.
Start with the scope, not the scramble
This is conditional guidance. It matters if a person or team uses GPT-5.5 in an affected ChatGPT, ChatGPT Work, or Codex context. It does not mean every ChatGPT user has work to do, and it does not mean an API-key application needs a model change because of this particular retirement notice.
That distinction is more than tidy wording. It keeps unrelated systems out of a migration that may not apply to them. Start by listing the workflows that matter: perhaps a recurring research routine, an internal coding helper, or a custom agent. The list can be short. The point is to name the workflows before hunting settings, so an old model selection is less likely to be mistaken for a current one.
Separate defaults from explicit pins
A default is a starting point. A pin is a specific instruction to use a particular model. Changing the default may be enough for a workflow that has no explicit selection, but it will not necessarily touch a workflow that does.
OpenAI’s migration guidance calls out a useful review list for Codex with ChatGPT sign-in: workspace defaults, saved model settings, managed configurations, custom agents, scheduled tasks, scripts, and commands that explicitly select gpt-5.5. Treat that as a search map, not a promise that every category exists in every setup.
The practical sequence is deliberately boring:
- Open the workflow and note the surface where it runs.
- Check its saved settings and configuration for an explicit model choice.
- Check the adjacent places that can carry a separate choice, such as an agent, task, script, or command.
- Record “nowhere found” when there is no explicit pin. That is a useful result, not an unfinished blank.
This prevents a common kind of false confidence: changing a front-door setting while a back-room instruction continues to point at the retiring model.
Then separate surface from sign-in
“Codex” is not one uniform location, and neither is access. A setting in a ChatGPT workspace does not automatically apply to every Codex surface or an API-key workflow. The product surface and the authentication boundary both matter.
For Codex with ChatGPT sign-in, OpenAI’s current migration documentation directs users to replace gpt-5.5 with gpt-5.6-sol. That instruction should stay in its lane. It is not a reason to copy the same choice into every tool, client, workspace, or API-key application.
OpenAI’s model documentation describes GPT-5.6 Terra as a pragmatic everyday starting point, while GPT-5.6 Sol is the more capable GPT-5.6 option for complex coding, computer use, research, and cybersecurity. Those are product descriptions, not a substitute for a test in a real workflow. Before selecting a replacement, check that it is available in the exact surface and sign-in context you recorded.
The 15-minute model-retirement inventory
Use one copy of this card per workflow. “15 minutes” is a constraint, not a guarantee: if a workflow turns out to be complicated, record the triage note and keep the investigation separate rather than guessing.
| Field | Record |
|---|---|
| 1. Workflow name and owner | ______________________________ |
| 2. Surface: ChatGPT, Work, Codex desktop/CLI/IDE/cloud, or API | ______________________________ |
| 3. Sign-in boundary: ChatGPT identity or API key | ______________________________ |
| 4. Where is a model explicitly selected? Workspace default, saved setting, managed configuration, custom agent, scheduled task, script/command, or nowhere found | ______________________________ |
| 5. Replacement and availability check | ______________________________ |
| 6. One representative smoke test, result, and rollback/triage note | ______________________________ |
A smoke test need not be clever. Run one ordinary, low-risk task that resembles the workflow’s usual work. For a coding helper, that might be a small, non-sensitive request in the normal tool surface. For a scheduled routine, it may mean safely confirming the configuration and then observing the next appropriate run under existing controls. The goal is not to score models in public. It is to confirm that the replacement is available, selected where expected, and usable for the task at hand.
Write down the result. “Passed” is useful. So are “model unavailable here,” “requires an owner review,” and “no explicit pin found.” A short record gives the next person a way to distinguish a finished migration from a guess made during a deadline rush.
What this does not cover: This checklist does not choose the best model for every job, change API-key workflows, or grant access to models that a surface, plan, workspace control, or sign-in method does not make available. It is a way to find explicit GPT-5.5 selections in the affected scope and verify a replacement where one is available.
Use a different lead after the deadline
A date-based checklist has an expiry date. If October 14 has passed when this is being published, the useful lead is no longer “before the retirement.” Recheck OpenAI’s release notes and migration documentation first. If the retirement happened as described, turn the piece into a post-cutoff verification and troubleshooting guide. If the scope or date changed, update it or choose a different topic.
For now, the sensible move is small: inventory the explicit pins, respect the surface and sign-in boundary, choose a replacement only where it is available, and run one ordinary test. That is less dramatic than a model-ranking debate. It is also much more likely to reveal the setting that actually needs attention.
