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

URL: https://infro.io/blog/gpt-5-and-o3-shut-down-dec-11-a-replacement-test-plan
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-30
Last modified: 2026-10-30
Last reviewed: 2026-10-30 (next review due 2026-11-29)
Topic: Evaluation and models
Format: Guide

> Replace gpt-5, gpt-5-mini, gpt-5-nano, gpt-5-pro, o3 and o3-pro with the GPT-5.6 models OpenAI lists, but test first. The per-token rates are higher for most pairs, so what matters is reasoning tokens per task, output shape and latency on your own prompts [^openai-deprecations][^openai-pricing].

Key takeaways:
- Six models leave the OpenAI API on December 11, 2026, and Azure OpenAI uses different dates: o3 and o3-pro retire there on November 19, 2026.
- List rates for the named replacements are higher per token for gpt-5, gpt-5-mini, gpt-5-nano and o3, so a cost-neutral swap needs fewer output tokens per task.
- Reasoning tokens bill as output tokens, so compare reasoning_tokens per request at a fixed effort on both models, not the price sheet alone.
- Test output shape separately from quality: incomplete responses, schema validity, tool arguments, length and formatting all change what your parser sees.
- Run a weighted canary and keep a rollback target until the shutdown date, because a retired snapshot cannot be a fallback.

## 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.[1] Generally available models get at least six months' notice, and this one used the whole window.[1] Today, October 30, you have 42 days.

| Retiring id | Recommended replacement |
| --- | --- |
| `gpt-5`, `gpt-5-2025-08-07` | `gpt-5.6-sol` |
| `gpt-5-mini` | `gpt-5.6-terra` |
| `gpt-5-nano` | `gpt-5.6-luna` |
| `gpt-5-pro` | `gpt-5.6-sol` with `reasoning.mode: pro` |
| `o3`, `o3-2025-04-16` | `gpt-5.6-sol` |
| `o3-pro` | `gpt-5.6-sol` with `reasoning.mode: pro` |

Table: OpenAI's listed shutdown set and replacements, from the deprecations page.

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

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.[2] 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.[3] 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.[4] Replace them with your contracted rates if you have any.

| Old model | Old rates | Replacement | New rates | Input ratio | Output ratio |
| --- | --- | --- | --- | --- | --- |
| gpt-5 | 1.25 / 10.00 | gpt-5.6-sol | 4.00 / 20.00 | 3.2x | 2.0x |
| gpt-5-mini | 0.25 / 2.00 | gpt-5.6-terra | 2.00 / 12.00 | 8.0x | 6.0x |
| gpt-5-nano | 0.05 / 0.40 | gpt-5.6-luna | 0.20 / 1.20 | 4.0x | 3.0x |
| o3 | 2.00 / 8.00 | gpt-5.6-sol | 4.00 / 20.00 | 2.0x | 2.5x |
| gpt-5-pro | 15.00 / 120.00 | gpt-5.6-sol (pro mode) | 4.00 / 20.00 | 0.27x | 0.17x |
| o3-pro | 20.00 / 80.00 | gpt-5.6-sol (pro mode) | 4.00 / 20.00 | 0.20x | 0.25x |

Table: list rates (input / output, USD per 1M tokens) and the replacement-to-old ratio.

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.[4] 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.[5] 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.[6] The GPT-5.6 rows list 30-minute and 12-hour cache-write rates; the gpt-5 and o3 rows list none.[4] 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.[5] 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.[5] They show up in `usage.output_tokens_details.reasoning_tokens`.[5] 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.

> **Example: Break-even arithmetic (illustrative figures)**
> Assume an o3 call with 2,000 input tokens and 1,500 output tokens, of which 1,000 are reasoning. At o3's list rates that is 2,000 × $2 + 1,500 × $8 per million, or $0.016. The same token counts on `gpt-5.6-sol` at $4 and $20 cost $0.038, about 2.4x. If the new model needs only 900 output tokens, the call costs $0.026. Cost-neutral needs about 400 output tokens, a 73% drop. These token counts are made up to show the method; your replay set supplies the real ones.

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.[5] 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.

```python
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.[5] OpenAI recommends reserving at least 25,000 tokens for reasoning and output when you start experimenting.[5] 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.[7] OpenAI frames those as observations on Astra to be evaluated on your workload, not guarantees for other models.[7]

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.[5] 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.[5] 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,[5] or Fast mode, which lists `gpt-5.6-sol` at $8 input and $40 output, twice the standard rate.[4] 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.[6] 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.[6] 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.

| Dates (2026) | Work | Exit check |
| --- | --- | --- |
| Oct 30 – Nov 5 | Inventory, freeze replay set, set explicit effort on both arms | Every pinned call site listed with owner |
| Nov 6 – Nov 12 | Offline replay: cost, shape, latency per call site | Per-call-site table of cost per successful task |
| Nov 13 – Nov 19 | Fix caps, schemas, prompts, timeouts; Azure o3 retires Nov 19 | Shape assertions pass; Azure deployments handled |
| Nov 20 – Nov 26 | 5% then 25% canary; re-forecast around GPT-5.6 Sol's promotional window | Error mix and p95 within agreed bounds |
| Nov 27 – Dec 3 | Ramp to 100% on the non-critical call sites first | Spend within the budget you set |
| Dec 4 – Dec 10 | Last call sites, remove pins from code, keep rollback to the new alternate | Zero calls to retiring ids |

Table: a six-week schedule from October 30 to the shutdown. The Azure and promotion dates come from the schedule and pricing pages.

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](https://infro.io/docs/observability/traffic-changes) 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.[8] INFRO sees request metadata rather than answers, so it does not judge quality; the replay set does that.[8] Your providers still invoice you directly, and INFRO takes 0% of model spend.[9]

## 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.[1] 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.

## Questions

### Can I keep calling gpt-5 or o3 after December 11?

Not on the standard API: after the shutdown date the model is no longer accessible. OpenAI says that in some cases developers may be able to provision dedicated capacity for continued access, and points to its sales team for that option [1]. Treat it as a negotiation, not a plan.

### Do the replacement models work on Chat Completions or only on Responses?

GPT-5.6 Sol lists support for both Chat Completions and Responses [6]. OpenAI recommends Responses for reasoning models, and says Chat Completions does not support function calling with GPT-6 Astra or GPT-6.1 Sol, so check the endpoint table on the model page before you pick a different target [5].

## Sources

1. Deprecations — OpenAI. https://platform.openai.com/docs/deprecations (accessed 2026-10-30)
2. Model retirement schedule — Microsoft Learn. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirement-schedule (accessed 2026-10-30)
3. Microsoft Foundry Models lifecycle and support policy — Microsoft Learn. https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/model-retirements (accessed 2026-10-30)
4. Pricing (markdown version) — OpenAI. https://developers.openai.com/api/docs/pricing.md (accessed 2026-10-30)
5. Reasoning models — OpenAI. https://developers.openai.com/api/docs/guides/reasoning.md (accessed 2026-10-30)
6. GPT-5.6 Sol model page — OpenAI. https://developers.openai.com/api/docs/models/gpt-5.6-sol.md (accessed 2026-10-30)
7. Using GPT-6 — OpenAI. https://developers.openai.com/api/docs/guides/latest-model.md (accessed 2026-10-30)
8. Traffic changes — INFRO. https://infro.io/docs/observability/traffic-changes (accessed 2026-10-30)
9. INFRO documentation — INFRO. https://infro.io/docs (accessed 2026-10-30)