Openai Audio Realtime Deprecation Model Id Audit 2026

• Date: 2026-08-19
• Track: api-backed-poc
• Endpoints used: GET https://api.openai.com/v1/models, GET https://api.openai.com/v1/models/{id}, POST https://api.openai.com/v1/realtime/client_secrets, POST https://api.openai.com/v1/chat/completions
• Account: one standard Effloow OpenAI API account (not organization-verified for restricted models)
• Purpose: OpenAI announced on 2026-07-20 that nine audio / realtime / transcription model IDs shut down on 2027-01-20. Ask the live API a narrower question: if a team never reads the deprecations page, would anything in an ordinary API response tell them their voice model is scheduled for removal?
• Safety boundary: no audio was captured, uploaded, or synthesised. The only prompt sent was the literal string Reply with exactly one word: ready. No confidential, customer, credential, or private data was sent. No API key appears in this note or in the saved artifact.
• Token cost: 0 tokens on the audio-model calls (both returned HTTP 400 before inference). The past-date liveness spot check also returned 404/400 with no billed usage. Budget guard: scripts/proof_budget.py.
• Script: scripts/audio-model-deprecation-probe.py
• Raw artifact: data/lab-runs/openai-audio-realtime-deprecation-model-id-audit-2026.openai.json

Reference source

Deprecated IDs, replacements, and dates come from https://developers.openai.com/api/docs/deprecations, fetched 2026-08-19.

• Announced 2026-07-20, shutdown 2027-01-20 (not 2026-01-20; the backlog entry carried the wrong year and is corrected here).

Command 1 — is the deprecation visible in the model object?

req = urllib.request.Request(
    "https://api.openai.com/v1/models",
    headers={"Authorization": f"Bearer {key}"},
)
data = json.load(urllib.request.urlopen(req))["data"]

Result: 126 models returned. Every record carries exactly five fields:

['created', 'id', 'object', 'owned_by', 'shutdown_date']

shutdown_date is the answer to the question. Two representative records, verbatim:

{"id": "gpt-realtime",     "object": "model", "created": 1756271701, "owned_by": "system", "shutdown_date": "2027-01-20"}
{"id": "gpt-realtime-2.1", "object": "model", "created": 1782254687, "owned_by": "system", "shutdown_date": null}

shutdown_date is documented (OpenAI API reference, Model object: "The date when the model will shut down, or null if not announced"). It is not new. It is simply not something most teams poll.

52 of the 126 models (41%) carry a non-null shutdown_date. Full machine-derived calendar as returned on 2026-08-19:

Command 2 — retrieve each ID named on the deprecations page

urllib.request.Request(f"https://api.openai.com/v1/models/{mid}", headers=...)

404 body for the four that do not resolve, verbatim:

{"error": {"message": "The model 'gpt-4o-audio' does not exist", "type": "invalid_request_error", "param": "model", "code": "model_not_found"}}

So four of the nine names on the deprecations page are family labels, not callable IDs — at least from this account today. Whether they are callable from an account with different model access is [DATA NOT AVAILABLE]; we tested one account.

Command 3 — do realtime sessions warn?

payload = {"session": {"type": "realtime", "model": mid}}
urllib.request.Request("https://api.openai.com/v1/realtime/client_secrets", data=..., method="POST")

All four accepted the identical request body. The returned realtime.session object echoes model, output_modalities, audio.input.format, turn_detection, and the rest of the session config — and contains no deprecation field of any kind. Ephemeral secret values were stripped before writing the artifact.

Command 4 — request-shape parity between old and new audio model

{"model": mid, "messages": [{"role": "user", "content": "Reply with exactly one word: ready."}],
 "max_completion_tokens": 16}

Both gpt-audio and gpt-audio-1.5 returned the same HTTP 400 with the same message:

{"error": {"message": "This model requires that either input content or output modality contain audio.",
 "type": "invalid_request_error", "param": "model", "code": "invalid_value"}}

Identical rejection is the useful signal here: the replacement enforces the same audio-modality precondition as the model it replaces. This is a request-shape check only. It is not a quality, latency, or transcription-accuracy comparison — those need an audio harness we do not have, and are [DATA NOT AVAILABLE].

Command 5 — is the model list a liveness signal?

15 models in the list on 2026-08-19 carry a shutdown_date already in the past (13 dated 2026-07-23, 2 dated 2026-08-10). Spot check on two of them:

404 body, verbatim:

{"error": {"message": "The model `gpt-5.1-chat-latest` has been deprecated, learn more here: https://platform.openai.com/docs/deprecations",
 "type": "invalid_request_error", "param": null, "code": "model_not_found"}}

gpt-4o-mini-tts-2025-03-20 was also checked and returned a 400 for the wrong reason (it is not a chat model), so it is not evidence either way and is excluded.

Conclusion: presence in GET /v1/models does not mean a model is callable. shutdown_date compared against today's date does. The dates are enforced — gpt-5.2-chat-latest was dead 9 days after its listed date.

Command 6 — header scan

Every response above was scanned for Deprecation, Sunset, Warning, Link, X-Deprecation, X-Sunset (RFC 9745 and common practice). Requests scanned: 1 list + 13 retrieves + 4 realtime sessions + 2 chat completions = 20 responses.

Zero deprecation signal headers found on any response. This matches what Effloow found on a different API surface in prompt-tooling-sunset-migration-scanner-2026, with one important difference: there, the API was silent everywhere. Here it is silent in the headers but explicit in the body, on a field almost nobody reads.

Observation worth flagging: the alias carries the flag, the snapshot does not

This inverts the usual "pin the dated snapshot" advice in a way that is worth stating carefully. The observed fact is that the alias rows are flagged and two of the underlying dated snapshots are not. Whether that means those snapshots genuinely survive 2027-01-20, or simply that the flag is applied at the alias level, is [DATA NOT AVAILABLE] — OpenAI's deprecations page lists the alias names, not the snapshots. Do not read a null on a snapshot as a safety guarantee.

Limitations

• One OpenAI account, one point in time (2026-08-19). Model visibility varies by account tier and verification status.
• No audio was sent. Nothing here says anything about voice quality, latency, interruption handling, or transcription accuracy on the old versus new models.
• Community reports of tool-calling regressions when moving to gpt-realtime-2.1 exist on OpenAI's own forum but were not reproduced here and are not treated as measured.
• The four non-resolving family IDs were tested from one account only.
• shutdown_date values reflect what the API returned on 2026-08-19. Dates can move.

Correction issued during finalization (2026-08-19)

An earlier version of this note claimed that content/articles/openai-realtime-audio-api-voice-agents-guide-2026.md (published 2026-05-14) "references gpt-realtime 29 times and now recommends a model with a shutdown date," and flagged it for refresh.

That was wrong, and the cause is instructive. The count came from a substring match. Exact-ID counts on that file:

$ grep -oE 'gpt-realtime[a-z0-9.-]*' content/articles/openai-realtime-audio-api-voice-agents-guide-2026.md | sort | uniq -c | sort -rn
  15 gpt-realtime-2
   9 gpt-realtime-whisper
   7 gpt-realtime-translate
   ...
$ grep -coP 'gpt-realtime(?![-a-z0-9.])' content/articles/openai-realtime-audio-api-voice-agents-guide-2026.md
0

The guide never mentions bare gpt-realtime. It recommends gpt-realtime-2, gpt-realtime-translate, and gpt-realtime-whisper, none of which appear on OpenAI's deprecations page. No refresh is owed.

Prefix collisions inside the gpt-realtime* family, from catalog_scan.voice_family_rows in the saved artifact:

2 of 10 prefix matches are actually deprecated. This is now a finding in the published article rather than a follow-up item: migration scans must match whole model IDs, not prefixes.