OpenAI removes the Assistants API on August 26, 2026, seven days from now. Requests to /v1/assistants and /v1/threads, including the nested messages, runs, and run steps routes, stop resolving on that date. OpenAI published the deadline on its API deprecations page and announced it on August 26, 2025, so the notice period ran a full year.
That date is the outlier in a run of shutdowns OpenAI has stacked into late 2026 and January 2027. Most of the others cost you one model string. This one moves your conversation storage, your run lifecycle, and your tool-call loop onto different objects. Sorting the cheap deadlines from the expensive one is the first job, and it is a reading exercise rather than an engineering one.
What OpenAI means by deprecated, shut down, and legacy
OpenAI treats deprecation as an announcement, not an outage. The moment OpenAI publishes a deprecation, the model or endpoint becomes deprecated and keeps working. The shutdown date, which OpenAI also calls the sunset, is the day requests stop resolving. A third label, legacy, marks models and endpoints that still work but no longer receive updates, and OpenAI states you can expect legacy items to be deprecated later.
- Generally available models: OpenAI commits to at least 6 months of notice before retirement.
- Specialized variants of generally available models: at least 3 months. OpenAI names chat variants such as gpt-5.1-chat-latest, Codex variants such as gpt-5.3-codex, and deep research variants such as o3-deep-research.
- Preview models, identified by the word preview in the model name: as little as 2 weeks. OpenAI writes that it does not recommend preview models for business-critical production workloads unless you can migrate on short notice.
- Safety or compliance exceptions: OpenAI reserves the right to move faster than any of these windows and promises only as much notice as is reasonably possible.
Those three tiers are the planning input most teams skip. If your product depends on a name containing preview, you have built a two-week migration obligation into your roadmap, and OpenAI told you so in writing.
Every confirmed shutdown date from here to January 2027
Each line below states the date, what stops working, and what the migration actually costs. Verify against the deprecations page before you build a ticket from it, because OpenAI edits that page as it announces new retirements.
- Jul 23, 2026, already passed: OpenAI shut down computer-use-preview, gpt-5-chat-latest, gpt-5.1-chat-latest, and the gpt-5-codex through gpt-5.2-codex snapshots, plus the search preview and deep research snapshots. Cost was near zero for teams that read model names from config, and an outage for teams that hardcoded them.
- Aug 10, 2026, already passed: gpt-5.2-chat-latest and gpt-5.3-chat-latest stopped resolving, with gpt-5.6-sol as the replacement. OpenAI announced this on May 8, 2026, which is barely past the three-month floor it promises for chat variants.
- Aug 26, 2026: the Assistants API stops responding. Migration cost is high, because threads, runs, run steps, and tool orchestration all move to the Responses and Conversations APIs.
- Sep 24, 2026: the Videos API shuts down along with sora-2, sora-2-pro, and their dated snapshots. OpenAI’s table lists no recommended replacement, so if video generation sits in your product you are waiting on a new OpenAI surface or sourcing another vendor, not swapping a string.
- Sep 28, 2026: gpt-3.5-turbo-instruct, babbage-002, davinci-002, and gpt-3.5-turbo-1106 shut down, with gpt-5.6-terra as the replacement. Cost is low unless you still rely on completions-style prompting.
- Oct 23, 2026: a large batch of legacy snapshots shuts down, including gpt-3.5-turbo, gpt-4, gpt-4-turbo, gpt-4o-2024-05-13, gpt-4.1-nano, o1, o1-pro, o3-mini, o4-mini, and gpt-image-1. Cost is low for the base models and high for the fine-tunes, because OpenAI removes ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano-2025-04-14, ft-babbage-002, and ft-davinci-002 on the same day and you cannot replace a fine-tune with a config edit.
- Oct 31, 2026: existing evals in OpenAI’s hosted Evals platform become read-only. Cost is nothing on the day and a lot afterwards, since this is your last chance to export eval definitions while you can still edit them.
- Nov 30, 2026: the Evals dashboard and API, Agent Builder, and the v1/prompts API with its reusable prompt objects all shut down. OpenAI announced all three on June 3, 2026. Agent Builder users get an export to Agents SDK code, but OpenAI’s Agent Builder migration guide warns the export does not convert your workflow graph or guarantee that every behavior transfers unchanged, so budget for manual recreation and testing.
- Dec 1, 2026: gpt-image-1-mini, gpt-image-1.5, and chatgpt-image-latest shut down, with gpt-image-2 as the replacement. Cost is low, though image output shifts enough between families to warrant a visual review.
- Dec 11, 2026: older GPT-5 and o3 snapshots shut down, including gpt-5-2025-08-07, gpt-5-mini-2025-08-07, gpt-5-nano-2025-08-07, gpt-5-pro-2025-10-06, o3-2025-04-16, and o3-pro-2025-06-10. OpenAI announced these on June 11, 2026.
- Jan 6, 2027: existing fine-tuning customers lose the ability to create new fine-tuning jobs. Inference on fine-tuned models continues until the underlying base model is deprecated, so this is a capability loss rather than an immediate outage.
- Jan 20, 2027: legacy audio, realtime, and transcription families shut down, including gpt-realtime, gpt-audio, gpt-4o-realtime, gpt-4o-audio, the mini variants, and gpt-4o-mini-transcribe-2025-03-20. Cost is moderate, because voice stacks need latency and word-error retesting rather than a string swap.
Which deadlines cost a config change and which cost a rewrite
Model retirements are usually one string and a round of testing
Seven of the twelve dates above retire model snapshots and name a direct replacement. OpenAI points gpt-5-nano at gpt-5.6-luna, the same model our post on the GPT-5.6 Luna rollout covered as the new free ChatGPT default. The edit is trivial. The testing is not.
Reasoning behavior, refusal boundaries, tool-calling reliability, and token economics all shift between model families, and none of that shows up in a diff. Teams that discover this on the shutdown date are debugging quality regressions and an incident at the same time.
The Assistants API retirement changes your object model, not your URL
OpenAI’s Assistants migration guide maps four objects onto new ones. Assistants become prompts, threads become conversations, runs become responses, and run steps become generalized items. Every one of those is a different storage and lifecycle contract, so a find-and-replace on the base URL gets you nothing.
The run lifecycle is the part that surprises teams. A run was an asynchronous server-side process you created against a thread and then polled until it left the queued or in-progress states. When the model wanted a function call, the run paused and waited for your code to submit tool outputs, and OpenAI expired the run if you missed roughly ten minutes. The Responses API inverts that: you send input items, you get output items back, and your application owns the tool-call loop explicitly.
- Conversation storage: threads only held messages, while conversations hold items including tool calls and tool outputs, so your read and render paths change shape.
- Tool orchestration: your code now drives the loop, retries, and history pruning instead of polling a server-side state machine. Treat that new loop as security-relevant surface and re-check it against an agent-security checklist and the OWASP agentic top 10 procurement rubric.
- History: OpenAI states plainly that it will not provide an automated tool for migrating threads to conversations. The migration guide instead shows a backfill script and recommends you move new conversations first and old ones only as needed.
- Tools you keep: vector stores are not part of this retirement. They still power the Retrieval API and the file search tool, so your indexed files carry over even though the surrounding objects do not.
- Tools you gain: the Responses API adds MCP connectors, deep research, and computer use, which is worth scoping deliberately rather than enabling by default. The same-origin risks in agentic browsers apply to computer-use tooling as well.
OpenAI’s Assistants migration path points at an object that shuts down 96 days later
Step one of OpenAI’s own migration guide tells you to open the dashboard and click Create prompt on each assistant, which turns every assistant object into a reusable prompt object. Reusable prompt objects shut down on November 30, 2026, which is 96 days after the Assistants deadline. OpenAI now carries a warning about this inside the migration guide itself, telling readers to review the prompts deprecation timeline before adopting prompt objects in a long-lived integration.
Skip the intermediate step. OpenAI’s guide to migrating off prompt objects describes the destination you actually want: keep prompt text in a small module in your repository, pass the built messages as input on the Responses call, replace prompt variables with typed function arguments, and version prompts through git and pull requests. Keep static content ahead of dynamic content in the message so prompt caching still hits, since cache hits depend on exact prefix matches.
Azure customers share the date but not the destination
Microsoft retires the Azure OpenAI Assistants API on August 26, 2026, the same day OpenAI does. Microsoft documents this in its Azure OpenAI Assistants concepts page and directs customers to the Microsoft Foundry Agents service instead of straight to the Responses API. The concept mapping is the same underneath: threads become conversations, runs become responses, and agent creation moves to versioned agent definitions.
Microsoft ships something OpenAI does not, and it is worth knowing the limits. Microsoft’s Foundry Agents migration guide offers a tool that automates code constructs such as agent definitions, thread creation, message creation, and run creation, but Microsoft states the tool does not migrate state data like past runs, threads, or messages. Both platforms leave conversation history to you. For where this sits in Microsoft’s wider strategy, see our read on Microsoft’s path after OpenAI and the Microsoft Copilot profile.
Run the migration in this order
Inventory first. Teams that start by rewriting code discover missed call sites in production; teams that start by listing model strings finish the cheap deadlines in a day and spend the remaining time on the Assistants rewrite.
- Grep your repositories, notebooks, serverless functions, and infrastructure config for every OpenAI model string and every /v1 endpoint path. Include vendor SDK defaults, evaluation scripts, and anything a contractor wrote.
- Tag each call site with its shutdown date from the deprecations page. Anything with no date on the page is currently safe; anything containing the word preview is on a two-week clock regardless.
- Move model names out of code and into config or environment variables, so the next retirement is a deploy rather than a pull request. Do this before you migrate anything, because it makes every later step reversible.
- Build an eval harness you own, running in your own CI, on your own fixtures. This is the step that converts every future model swap from a gamble into a measurement.
- Handle the Assistants rewrite as its own project. Rebuild the tool-call loop in your application, move prompt content into source control rather than into prompt objects, and decide explicitly whether you backfill old threads into conversations or start conversations fresh.
- Stage the cutover behind a feature flag, at low traffic percentage, with both paths instrumented. Compare eval scores, latency, token spend, and tool-call failure rates side by side.
- Keep the old model or endpoint as a runtime fallback until its shutdown date. This is free insurance right up to the deadline and worthless one second after it.
- Put every date from the schedule above into the calendar your on-call team actually reads, with an owner’s name attached. Re-read the deprecations page monthly, because OpenAI adds rows to it.
Own the eval harness before the vendor’s platform goes read-only
The Evals timeline is the clearest argument in this whole wave for keeping measurement in your own repository. OpenAI freezes hosted evals to read-only on October 31, 2026 and shuts the dashboard and API down on November 30, 2026. Any team that stored its quality baseline only in OpenAI’s Evals platform loses the ability to prove whether a forced model swap made the product worse.
- Export eval definitions and datasets before October 31, 2026, while they are still editable. OpenAI publishes a migration path to Promptfoo in its cookbook if you want a documented landing spot.
- Keep fixtures and graders in version control next to the prompts they test, so a prompt change and its eval change land in the same review.
- Score on tasks that mirror your product rather than public leaderboards. Our note on reading AI benchmarks without being misled covers where index scores diverge from real workloads, and the agent evaluation framework covers multi-step tasks specifically.
- Track cost per successful task, not price per million tokens. Vendor pricing moves independently of deprecations, as DeepSeek’s API price increase showed developers this month.
- Run the same harness against a second provider. Portable evals are what turn a forced migration into a real choice between ChatGPT, Claude, Gemini, and DeepSeek.
Do the inventory this week. Open the deprecations page next to your codebase, list every model string with its date, then compare ChatGPT, Claude, and Gemini profiles on Bookmarkit and save the shortlist you would fall back to if a replacement model fails your evals.
