GPT-5.1, GPT-5.4 nano, GPT-5.3-Codex end Apr 1: what to move

What is ending, and what OpenAI says to use instead

On 1 October 2026 OpenAI deprecated three model entries that stop answering on 1 April 2027. Its page calls it six months' notice and names a replacement for each¹.

Two details matter for inventory. The dated snapshots are listed next to the short ids, so a caller that pinned gpt-5.1-2025-11-13 is hit the same day as one that sends gpt-5.1. And the page defines the end state plainly: at shutdown "the model or endpoint will no longer be accessible"¹. It describes no grace period and no automatic upgrade on OpenAI's own API.

The calendar post already places these three ids on the date line². This guide is what to do with the five months. If you reach OpenAI models through another platform, the date can differ: INFRO's docs note that Azure OpenAI, Amazon Bedrock and Vertex AI run their own schedules³, and the Azure entries for these three ids were not read here. Perplexity has already removed gpt-5.1, gpt-5.4 nano and other older OpenAI ids from its Agent and Orchestrator APIs on 24 October⁴, so a caller on that path is past its date.

Shortlist per model

OpenAI's named replacement is the first candidate, not the only one. The point of a shortlist is to test two or three options on your own prompts and keep the loser's results for the fallback decision.

List rates move the budget, so write them down before testing. The INFRO catalog records OpenAI's published list rates for the nano family and its neighbours (checked 2026-10-05)⁵:

Rates are only half of a replacement decision. Output length, reasoning token use and tool-call behaviour change the real cost per task, which is why the test plan below records cost per successful task rather than rate.

Inventory every call site

The October shutdown post makes the case that traffic is the only complete inventory of callers that ran, and that code search catches ids in config, databases, queued jobs and library defaults that traffic misses⁶. The same three-pass method applies here, with these ids.

1. Traffic, 60 days. Thirty days misses monthly jobs; take sixty and group by the model id as sent, not a normalised family, so gpt-5.1 and gpt-5.1-2025-11-13 show up separately. Use your provider usage export, gateway request log or your own logging, grouped by key and service.
2. Code and config. Search every repository, infrastructure repo and notebook for the literal ids.
3. Data. Prompt and agent configs in a database, per-customer model settings, queued and scheduled jobs, and eval harness definitions.

#!/usr/bin/env bash
# Anchored so "gpt-5.1" does not match version strings like "gpt-5.10".
PATTERN='(^|[^A-Za-z0-9.-])(gpt-5\.1(-2025-11-13)?|gpt-5\.3-codex|gpt-5\.4-nano(-2026-03-17)?)([^A-Za-z0-9.]|$)'
git grep -nE "$PATTERN" -- . ':!*.lock' ':!node_modules' || true
# Also search outside git: env files, secrets-store exports, DB dumps, CI variables.

Then ask OpenAI's own API which models your key lists with a shutdown date. The deprecations page says GET /v1/models returns an optional shutdown_date field, a YYYY-MM-DD string or null when none is announced¹:

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
for m in client.models.list():
    date = getattr(m, "shutdown_date", None)
    if date:
        print(m.id, date)

Record each finding in one row: id as sent, service, owner, environment, call volume, whether it uses tools or structured output, and the target model. A key nobody can name is a finding by itself.

Codex is often not an application call

gpt-5.3-codex is frequently set in a developer's tool config, not in a service. Check coding-agent settings, CI jobs that invoke an agent, and shared config files in repositories. If your agents run through a gateway, the model id will also appear in its request log. INFRO documents Codex and the OpenAI Agents SDK pointing at it by changing the base URL and key³, which makes those calls visible in the same traffic inventory.

Qualify the replacement before moving traffic

A model swap is a behaviour change. For each workload, build the test set from real traffic rather than synthetic prompts, and keep three things fixed: the prompt, the parameters you actually send, and the grader. I did not read the replacement models' pages for this article, so use each model's own page to check every parameter your code sends: reasoning settings, token limits, temperature, tool and structured-output options, and stop reasons.

Run these checks in order:

• Schema and tool validity. Does the output still parse, and do tool calls still name your tools correctly?
• Task success. Score against a rubric or labelled outcomes. If you use a model as grader, calibrate it first.
• Length and truncation. Longer answers raise cost and can hit your max-token limit; shorter ones can drop required fields.
• Latency. Time to first token and total time under your real prompt sizes, because timeouts are set from the old model's behaviour.
• Cost per successful task. Output tokens times the rate you actually pay, divided by successes.

For gpt-5.4-nano workloads (classification, extraction, routing prompts) the interesting question is whether gpt-6-luna holds label agreement against the nano outputs. For gpt-5.3-codex, run your repository tasks, not generic coding benchmarks, and keep a human review on a sample of diffs. The existing playbook on fallback equivalence covers how to decide whether the loser of this test can serve as a fallback: Is your fallback model good enough?.

Put a name you control in front of each workload

Hard-coded ids are why these migrations take five months of calendar. Before you cut over, make the model a deploy-time or gateway-level setting.

With INFRO, the name of a route is a valid model value³, so a service can send summarizer-prod and the route's targets decide whether openai/gpt-5.1 or openai/gpt-6-sol answers. Weighted targets give you the canary split without a code deploy, and routing rules can send a matching slice (a project, a key, a prompt size) to the replacement first. Without a gateway, the same result needs a config layer in your own code: one table of logical name to model id, read at startup, with a per-request override for tests.

Keep one rule: the replacement is named explicitly. INFRO never answers a request with a different model on your behalf; on the shutdown date it refuses a retired id and names the replacement in the error³. That is a safety net, not a migration plan, and it still means a failed request.

The cutover schedule

Five months, working backwards from 1 April 2027. The competing dates are real: OpenAI shuts the GPT-4o and GPT-4.1 snapshots on 14 January and whisper-1 and the GPT-4o transcription models on 26 February⁴, so the same team may be migrating three things.

Monthly jobs are why March is a buffer. A job that runs on the 20th will first reveal its old id in the month you thought you were done. For those, run the job manually against the replacement in staging in February instead of waiting for the schedule.

Catching stragglers before the date

Three controls make a missed caller visible while it is still harmless.

• Block the old ids early in lower environments. An allowlist that excludes the retiring ids turns a stray staging caller into a policy error you can read, long before production is affected. INFRO's allowlists are per project, and environments separate staging from production.
• Alert on any request naming a retiring id. An organization that sent a retiring model in the last 30 days receives a model.retiring alert naming the keys and projects that called it, and the console marks the model with its shutdown date in its pickers³. A recorded retirement also appears in the retirement object on GET /v1/models³.
• Review the request log weekly. Group by model id as sent. The goal is a line that falls to zero and stays there; a long tail of two or three requests a day is a forgotten job.

Outside a gateway, the equivalent is your provider usage export on a weekly schedule, and a CI check that fails when the git grep above finds a retiring id.

What to do if a workload is not ready by March

Decide by the end of January which workloads might not be, not on 25 March. For each, there are four honest options: ship the replacement with a known quality gap and a human check; keep a smaller scope on the replacement and queue the rest; swap in a model from another provider you have already qualified; or ask OpenAI about dedicated capacity, which its page says may be possible in some cases¹. A fifth option, doing nothing, ends on 1 April with failed requests.

Record the decision with an owner and a date in the same inventory table, so that on 1 April the only remaining failures are ones someone chose.