GPT-4 API Deprecation: Inventory and Migration Checks

The October 14, 2026 GPT-4 API deprecation notice targets specific GPT-4o and GPT-4.1 snapshots, with shutdown on January 14, 2027 and GPT-6 Luna as the recommended replacement. Older GPT-4 and GPT-4 Turbo entries have a separate, earlier deadline. Inventory the exact model IDs used by your application before changing code, then test the replacement against the behavior your users depend on.

Which GPT-4 models are affected?

OpenAI's API deprecations page, checked October 15, 2026, lists these snapshots in the new notice:

The notice says fine-tuned versions follow their underlying base model's shutdown schedule. Include fine-tuned IDs in your inventory instead of searching only for standalone base names.

This is an API lifecycle notice. It does not establish that all ChatGPT features or every model with “GPT-4” in its name disappears on the same date. Use the entry for the exact model and product rather than expanding a family label into a universal shutdown claim.

Do not merge the October and January deadlines

The same page contains an earlier April 22 notice covering older GPT-4 and GPT-4 Turbo entries with October 23, 2026 shutdowns. It recommends GPT-5.6 Sol for those listed GPT-4 routes. An application using one of them has a different migration schedule from an application using a snapshot in the new table.

Build the inventory with a separate deadline per model. Keep the official source entry next to the ID and recommended replacement. A team-wide task called “migrate GPT-4 by January” can miss an earlier dependency if it collapses those rows.

Distinguish deprecated from already inaccessible. The current deprecation page explains that an announced deprecated model has a shutdown date; access ends at shutdown. The useful action during the notice period is to complete the migration and validation before that date, not merely acknowledge the announcement.

Inventory model IDs beyond application code

Search source, deployment configuration, environment mappings, scheduled jobs, prompt templates and evaluation scripts. Check shared wrappers and fallback routes too. A production service can keep reaching an old model through a default that never appears in the feature's own code.

Record the requesting application, endpoint, configured ID and observed response model when available. For aliases, consult the current official model mapping rather than guessing the snapshot from the alias's spelling. An inventory of configuration text and an inventory of actual requests are complementary evidence.

OpenAI documents optional shutdown_date information on model-list and model-retrieve responses. Use it as another current check in your authorized account. Do not treat a missing field as a permanent availability guarantee; retain the applicable published notice as well.

For each dependency, identify an owner and a representative request. Mark rows as unverified until the loaded application's request path has been inspected. A repository edit alone does not prove that a running process or scheduled job picked up the new setting.

Run an offline affected-model check

This small scanner recognizes the five snapshots in the October 14 notice and their fine-tuned forms. It deliberately does not resolve aliases or encode every historical deprecation.

TARGETS = {
    "gpt-4o-2024-08-06",
    "gpt-4o-2024-11-20",
    "gpt-4o-mini-2024-07-18",
    "gpt-4.1-2025-04-14",
    "gpt-4.1-mini-2025-04-14",
}

def affected_base(model_id):
    if model_id in TARGETS:
        return model_id
    if model_id.startswith("ft:"):
        parts = model_id.split(":")
        if len(parts) > 1 and parts[1] in TARGETS:
            return parts[1]
    return None

assert affected_base("gpt-4o-2024-08-06")
assert affected_base("ft:gpt-4o-mini-2024-07-18:example:label:synthetic")
assert affected_base("gpt-6-luna") is None

An equivalent local fixture was executed with the five base snapshots, one synthetic fine-tuned ID and gpt-6-luna. It identified the listed base snapshots and synthetic fine-tuned ID as affected, while excluding the replacement. That proves the offline classifier's behavior for those inputs; it does not prove a live application migration or that an unrecognized model has no other deadline.

Use the output as a review queue. Follow unrecognized aliases and older GPT-4 entries back to the current catalog and notices. Do not make “not in this set” the only condition for a production-ready label.

Choose a replacement and test the contract

Start with the official replacement as a candidate, then verify your workload. Preserve the existing expected output and permissions while testing. Changing the model string can be necessary, but it cannot establish compatible behavior on its own.

For structured output, check that required fields remain present, types are correct and refusal or incomplete responses are handled. For tool use, inspect arguments before executing them and retain the existing authorization boundary. For streaming, test how your client detects completion and errors. For images, verify the actual input path and output needed by the application.

Keep request validation separate from task quality. A successful response can still omit a required field or propose an invalid action. Log usage and latency as observed values, and include retries when comparing the replacement's operating cost.

Use a local regression set or your current supported evaluation tooling. The deprecations page lists a separate transition for the legacy Evals platform; building a new migration dependency around that retiring service would require another lifecycle decision. This guide does not report a live model benchmark or use the old platform as a required step.

Keep endpoint migration a separate change

OpenAI's Responses migration guide describes Responses and the continuing Chat Completions path. A model shutdown and an endpoint migration are related planning questions, but they are not the same change.

If your existing endpoint supports the replacement and its required features, validate that route first. If you also migrate to Responses, separately review input shapes, state handling, tool results and streaming events. Changing both at once without separating their tests makes a failure harder to diagnose.

Record the before-and-after model and endpoint combination. Keep an explicit compatibility checklist rather than treating the endpoint name as proof of completion. The application's final result is what matters to its user.

Plan rollout before the shutdown date

Use a bounded rollout with observable acceptance criteria. Confirm the intended deployment loaded the new configuration, send an authorized representative request, and inspect the result. Include background jobs and fallback paths in that readback.

If a serious failure appears, stop expansion and diagnose it. Any temporary rollback to a retiring model must account for its actual deadline; a fallback that disappears at shutdown is not a durable recovery plan. Preserve in-flight work and avoid duplicating external actions when retrying tool-based tasks.

Keep one record per dependency: inventory complete, replacement request accepted, task checks passed, production route observed and legacy usage removed. Mark unresolved steps separately. This prevents a changed configuration file from being reported as a completed operational migration.

Build a migration tracker with Atoms

Atoms' AI app builder can help prototype a register for these records. Use synthetic IDs and outcomes first, then inspect the generated workflow before entering operational evidence.

Build a model migration register with synthetic application records.
Store configured ID, observed model, endpoint, deadline, owner,
replacement, regression result and production readback separately.
Flag the five October 14 snapshots and their fine-tuned forms.
Keep aliases unresolved until reviewed. Keep older deadlines separate.
Do not mark a row complete from a configuration edit alone.
Allow JSON import/export. Do not connect API credentials.

The QA dashboard guide explains a related approach: show release evidence alongside tests instead of relying on totals. Atoms supports application building and iteration, while your model requests and deployment checks still supply the evidence.

Conclusion

Bind each deadline to the exact model ID, then validate the replacement's behavior and the loaded production route. Keep endpoint changes and fine-tuned dependencies visible. Build the migration register in Atoms to coordinate the checks before the relevant shutdown date.