Skip to content

Home / Guides / Agentic development

Agentic development

OpenAI model changes: check the workflow as well as the name

What the 14 October 2026 Codex retirement and API deprecation notices mean for saved settings, scripts and repeatable checks.

By Shane Rounce · 2 min read

A model change is a good time to inspect the assumptions saved around your agent. A current chat may work while an old script, scheduled job or project setting still selects a model that is being retired.

Soft blue, orange and white lights on a dark city street.
Ecclesall Road at night, Sheffield. Photograph by Shane Rounce on Unsplash.

Two notices with different scopes

OpenAI's 14 October changelog says GPT-5.5 retired from Codex for users signed in with ChatGPT at 19:00 UTC that day. That notice does not retire it from the API or from API-key-authenticated Codex sessions. OpenAI points affected users towards GPT-6.1 Sol where their plan and client support it.

Separately, the API deprecation page records a 14 October notice for specified GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini snapshots, with shutdown scheduled for 14 January 2027. The listed replacement is GPT-6 Luna. Check the exact identifiers in that notice; this is not a statement that every model with a similar name stops immediately.

Find the saved assumptions

My first step would be an inventory of the settings I actually control: repository configuration, job definitions, saved agent settings and scripts. Search those deliberately. Avoid dumping an entire home directory or environment into an assistant's context just to find one model name.

Record the client version, authentication route and current model alongside each workflow. A subscription-backed coding session and an API application can have different availability and retirement rules even when the model names look familiar.

Try representative work before changing every default

Pick a small set of real tasks: a focused bug fix, a review that should find a known issue, and a task requiring browser evidence. Keep the same acceptance criteria. Compare the resulting diff, checks performed, unresolved questions and usage where it is available.

I would pay particular attention to instruction following. Does the replacement identify the correct repository, preserve unrelated changes and stop at the agreed deployment boundary? A more capable model still needs the context that explains how this project is run.

Leave a migration record

Update one controlled workflow first, record what changed and keep the prior configuration available for diagnosis while it remains supported. Then update the remaining references intentionally. Do not claim a migration is complete because the interactive model picker shows the new name.

For website work, my acceptance test stays the same: the intended change works, the relevant checks pass and the final report accurately describes what reached the live site.

Need a hand with your next project?

I help with website development, with practical advice and hands-on work. Tell me what you are trying to improve.

Email Shane