GPT-5 and o3 shut down Dec 11: a replacement test plan

What shuts down on December 11, and which dates differ

OpenAI told developers on June 11, 2026 that older GPT-5 and o3 snapshots leave the API on December 11, 2026.¹ Generally available models get at least six months' notice, and this one used the whole window.¹ Today, October 30, you have 42 days.

You can also read the date from the API: GET /v1/models returns an optional shutdown_date per model, null when none is announced.¹

If any of this traffic runs on Azure OpenAI, the dates are not December 11. The Foundry schedule, last updated 2026-09-23, lists o3, o3-pro and o3-deep-research as deprecated with a retirement date of 2026-11-19 and gpt-5.6-sol as the replacement. gpt-5, gpt-5-mini and gpt-5-nano show 2027-02-09, and gpt-5-pro shows 2027-04-07.² A retired Azure model returns 410 Gone. For Global Standard, Data Zone Standard and Standard deployments Microsoft manages automatic upgrades when a version retires, while provisioned deployments are not auto-upgraded.³ An automatic upgrade is a model swap you did not test, so run this plan before that date, not after it.

Price the swap before you test it

Every pair moves to a higher per-token rate except the two Pro models. These are OpenAI's standard-tier list rates per million tokens, and the ratios are computed from them.⁴ Replace them with your contracted rates if you have any.

Three caveats keep that table honest. First, GPT-5.6 Sol's rate is promotional and OpenAI says it is available at least through November 21, 2026, so the rate you forecast on may not be the rate in January.⁴ Second, pro mode bills the aggregated model work at the model's standard token rates, and it does more work than standard mode, so the low per-token ratios for the Pro rows say nothing about cost per task.⁵ Third, for GPT-5.6 Sol, prompts over 272K input tokens are priced at 2x input and 1.5x output for the full request, and cache writes bill at 1.25x the uncached input rate.⁶ The GPT-5.6 rows list 30-minute and 12-hour cache-write rates; the gpt-5 and o3 rows list none.⁴ If your old traffic leaned on automatic caching, model the write line item.

Step 1: find every pinned call and freeze a replay set

Start with an inventory by model id, not by service name. Search code and config for the six ids and their dated forms, then check the request log of whatever gateway or proxy you use for the same ids, because environment variables and per-tenant overrides hide pins. Record, per call site: endpoint (Chat Completions or Responses), reasoning effort, output cap, whether it streams, whether it uses structured outputs or tools, and its timeout.

Then freeze a replay set. Sample real prompts from the last few weeks, stratified by call site, input length and outcome class (success, retry, user complaint). Keep multi-turn conversations whole. Store the old model's answers alongside the prompts so you are comparing against what production actually returned, not a fresh run that may differ. Strip or tokenize personal data under your logging policy before the set leaves production.

Set the effort explicitly on both arms. GPT-5.6 defaults to medium if you omit it.⁵ I did not confirm what each retiring snapshot defaults to, so do not assume the two arms match until you pin them.

Step 2: measure reasoning tokens per task

Reasoning tokens are not visible in the response, but they occupy context and bill as output tokens.⁵ They show up in usage.output_tokens_details.reasoning_tokens.⁵ That makes the output-rate ratios above the number to beat: a replacement at 2.5x the output rate has to produce proportionally fewer output tokens to hold cost flat.

Two behaviors change the input side as well. Models released before GPT-5.6 carry input and output tokens across turns without rendering earlier reasoning, while GPT-5.6 models default to rendering available reasoning from earlier turns; reasoning.context selects either behavior on supported models.⁵ In agent loops and long chats, measure input tokens per turn on both arms, not only output.

Here is a replay harness for one call site. It records cost with the usage fields, the finish status and time to first visible token.

import time
from openai import OpenAI

client = OpenAI()

# USD per 1M tokens: (input, cached input, output). List rates read 2026-10-30.
# Replace with your contracted rates.
RATES = {
    "o3-2025-04-16": (2.00, 0.50, 8.00),
    "gpt-5.6-sol": (4.00, 0.40, 20.00),
}

def run(model: str, effort: str, prompt: str, cap: int = 25_000) -> dict:
    t0 = time.perf_counter()
    first = None
    with client.responses.stream(
        model=model,
        reasoning={"effort": effort},
        input=prompt,
        max_output_tokens=cap,
    ) as stream:
        for event in stream:
            if first is None and event.type == "response.output_text.delta":
                first = time.perf_counter() - t0
        r = stream.get_final_response()

    u = r.usage
    cached = u.input_tokens_details.cached_tokens
    reasoning = u.output_tokens_details.reasoning_tokens
    rin, rcache, rout = RATES[model]
    cost = ((u.input_tokens - cached) * rin + cached * rcache + u.output_tokens * rout) / 1e6
    return {
        "model": model,
        "status": r.status,
        "incomplete": getattr(r.incomplete_details, "reason", None),
        "reasoning_tokens": reasoning,
        "visible_tokens": u.output_tokens - reasoning,
        "ttft_s": first,
        "total_s": time.perf_counter() - t0,
        "cost_usd": cost,
        "text": r.output_text,
    }

Report cost per successful task, not per request: divide total cost by the number of replay items that pass your checks, so a model that fails and needs a retry pays for both calls. Run each item more than once; reasoning-token counts vary per run, so look at p50 and p95 per call site rather than one sample.

Step 3: compare output shape

Quality scoring is its own project; shape is cheaper to check and breaks things first. Check these as hard assertions on the replay set:

• status is completed. If generation hits max_output_tokens or the context limit you get incomplete and may pay for input and reasoning tokens without any visible output.⁵ OpenAI recommends reserving at least 25,000 tokens for reasoning and output when you start experimenting.⁵ An output cap tuned for a non-reasoning or smaller-budget model is the likeliest cause of a new failure.
• Structured output parses against your JSON schema, and tool-call arguments validate. Count the rate of failures per call site.
• Length distribution of visible output: median, p95 and the share near your cap.
• Formatting your downstream code depends on: Markdown, lists, headings, language, citation style.
• Refusal and clarifying-question rate. If you also test a GPT-6 model as a candidate, OpenAI notes that GPT-6 Astra is more likely to ask for clarification than earlier models and tends to use lists, tables and Markdown unless told otherwise.⁷ OpenAI frames those as observations on Astra to be evaluated on your workload, not guarantees for other models.⁷

Keep a diff view of old answer against new answer for the 50 or so items that disagree most. Reading them is how you find a changed default, such as tone, verbosity or list use, that no metric names.

Step 4: compare latency and timeouts

Reasoning models spend time before the first visible token, and the count can run from a few hundred to tens of thousands of reasoning tokens depending on the problem.⁵ So a longer or shorter reasoning budget moves both time to first token and total time. Record both, per call site, at p50 and p95, at the same effort on both arms and then at one effort level lower on the new model. OpenAI describes lower effort as favoring speed and lower token usage, and says high effort suits tasks where quality matters more than latency.⁵ Your evals decide whether a lower effort passes.

Then reset timeouts and UI behavior from the measured p95, not from the old model's habits. Two options exist if p95 is too slow: a short preamble before deeper reasoning, which OpenAI suggests for faster time to first visible token,⁵ or Fast mode, which lists gpt-5.6-sol at $8 input and $40 output, twice the standard rate.⁴ Price that option into the forecast before you rely on it.

Last, check capacity. The GPT-5.6 Sol model page lists rate limits by usage tier; at the Build tier that is 5,000 requests and 1,000,000 tokens per minute.⁶ If your reasoning-heavy traffic was close to its token limit on o3, a model with a different token profile can hit the ceiling at a different request rate.

Step 5: canary and cut over on a calendar

The replacement carries a single snapshot name. gpt-5.6-sol is the only snapshot listed on its model page, and the gpt-5.6 alias routes to it.⁶ There is no dated name to pin to, so the discipline is to watch the id the provider reports and treat any change as an event.

Do not use the old snapshot as the rollback target after you ramp, since it disappears on the shutdown date. Rollback means a second modern model, such as a GPT-6 candidate you also replayed, or a different provider.

Where a gateway helps

Everything above works with plain SDK calls. If you already route through INFRO, a few shipped capabilities map to the plan. Model lifecycle records OpenAI's shutdown dates, warns organizations still sending a retiring model, and from the shutdown date refuses it before any provider call, naming the replacement. A named route with weighted targets over your own connections can carry the canary split. Usage records the model, latency, token counts and estimated provider cost for each request, and you can enter your negotiated rates so estimates use them before list rates. Budgets can cap a project while you ramp. The traffic changes (opens in a new tab) findings flag a model answered by a new snapshot, output tokens per request up by at least 15%, answers cut off by the length limit and slower p95, each with an estimated weekly cost change.⁸ INFRO sees request metadata rather than answers, so it does not judge quality; the replay set does that.⁸ Your providers still invoice you directly, and INFRO takes 0% of model spend.⁹

If you cannot finish by December 11

Cut scope, not the test. Move the call sites that fail loudly first (structured output, tools, hard caps), and leave low-risk prose call sites for the last week. For anything that cannot make the date, the only continuity option OpenAI names is dedicated capacity through its sales team, and only in some cases.¹ A refused request after the shutdown costs more than a day of canary, so keep the schedule's last row for cleanup, not for first tests.