GPT-5.5 Leaves ChatGPT and Codex on 14 October: Find the Pinned Model Before It Finds You

On 15 September 2026 OpenAI announced that GPT-5.5 would be retired from ChatGPT, ChatGPT Work and Codex on 14 October 2026, across consumer, Business, Enterprise and Edu plans. For Codex users the stated migration path is GPT-5.6 Sol, with GPT-6 Astra as the higher capability option. The API is not part of the retirement: developers who call GPT-5.5 with an API key can keep doing so. For most people who use whatever default ChatGPT gives them, nothing visible happens on Tuesday. For teams that named the model somewhere, two days is very little runway, and the work is mostly about finding where the name lives.

The detail that matters most is the split by access method. Codex can run under a ChatGPT plan login or under an API key, and the retirement applies to the plan based path. That means two developers on the same team, running the same script with the same model string, can see different results on 14 October depending on how each of them authenticated. One keeps working on GPT-5.5 through the API. The other loses access. If your team mixes the two, which is common when some engineers use a company ChatGPT Business seat and the CI runner uses an API key, do not assume a single answer for the whole team. Check each path separately.

Here is where GPT-5.5 tends to hide. Workspace or admin settings that pin a model for a group of users. Custom GPTs built while GPT-5.5 was the default, where the model choice was set once and forgotten. Scheduled tasks in ChatGPT that were created against a named model. Codex configuration files, CLI flags and wrapper scripts with the model name hardcoded, including the ones in CI that nobody has opened since spring. Prompt libraries and internal docs that tell staff to pick GPT-5.5 for a particular job. And the evaluation sets you used to approve a workflow in the first place, because those results described GPT-5.5 behaviour, not the behaviour of whatever replaces it.

A quick sweep covers most of it in an hour. Search your repositories and dotfiles for the model string, including variants with and without the hyphen. Ask the ChatGPT workspace admin to export or review pinned model settings and the custom GPTs owned by your organisation. List scheduled tasks for any shared or service style accounts. For Codex, record for each user and each automation whether it authenticates with a plan login or an API key, because that single fact decides whether it is affected. Where a workflow is affected, change the model deliberately to GPT-5.6 Sol or GPT-6 Astra rather than letting a silent default decide, and rerun a small set of known inputs to confirm the output still meets the bar you approved it against.

Why bother with that last step if the replacement is newer and better on benchmarks? Because better on average is not the same as unchanged for your task. A model swap can change formatting, refusal behaviour, verbosity, tool calling patterns and how a coding agent handles a large diff. We have seen the same pattern with Claude Code, Cursor and Devin model roster changes this year: the tool kept working, but a review checklist, a parser or a downstream automation quietly assumed the old behaviour. Codex agents that open pull requests are the obvious case. If the new model writes larger changes or touches files the old one left alone, your human review step needs to know that before the first merge, not after.

There is also a cost and capacity angle. GPT-6 Astra is the more capable option for Codex, but more capability usually means more tokens per task and different usage limits on plan seats. If you move a busy automation from GPT-5.5 to Astra because it sounds like the safe upgrade, watch consumption for the first week. If the workflow was fine on GPT-5.5 and only needs continuity, the API path may be the cheaper way to keep the exact model for a while, provided the data handling terms for API use suit the data the workflow touches. That is a decision to make on purpose and write down, not something to discover from an invoice.

For compliance teams this is a routine change record, and it is worth doing properly because it is the kind of evidence auditors ask for. Under ISO 27001 it sits in change management and supplier service monitoring: a supplier changed a service you depend on, you assessed it, you acted. Under ISO 42001 it is a lifecycle change to every AI system in your inventory that used GPT-5.5 through ChatGPT or Codex, so update the inventory entry with the new model and the date, and note any retest. Under SOC 2 it belongs in vendor management and change management. If you run your programme in Vanta or Drata, attach the OpenAI notice and your sweep results to the OpenAI vendor record so the timeline shows the review happened before 14 October.

The longer lesson is the one our model deprecation guide keeps returning to. Named models in product surfaces are not stable dependencies, and the retirement notice period for consumer and business apps is measured in weeks, not quarters. Keep an AI inventory that records the model and the access method for each workflow, not just the vendor. Prefer configuration in one place over model names scattered through scripts. Keep a small regression set for any workflow that matters, so a swap becomes a ten minute check rather than a guess. And subscribe someone, by name, to the release notes of every AI tool your teams depend on.

A practical plan for the next 48 hours. Search code and configuration for GPT-5.5. Ask the ChatGPT admin for pinned settings, custom GPTs and scheduled tasks. Split Codex usage into plan login and API key, and fix only the plan login path. Move affected workflows to GPT-5.6 Sol or GPT-6 Astra on purpose, run your known inputs, and tell reviewers what changed. Then log the whole thing against the OpenAI supplier entry. It is a small piece of work, and doing it before Tuesday is far cheaper than explaining a broken automation on Wednesday.