How to depend on an AI tool that might be switched off
Read the notice period before you commit, test the export while you still have time, and keep the wiring somewhere the vendor cannot retire.
on this page · 0 / 0 checked
On 9 July 2026, OpenAI published a release note titled “Retiring Atlas” saying the browser would stop working on 9 August 2026 [2]. Atlas had launched on 21 October 2025, worldwide on macOS, to Free, Plus, Pro and Go users [1]. That is a product life of about nine and a half months and 31 days between the notice and the lights going out. The announcement post that introduced it now opens with a note above the original text: “This post introduced ChatGPT Atlas. Atlas has since been deprecated” [1].
Nothing about that is unusual, which is the problem. The capability survived the product. OpenAI pointed people at the ChatGPT desktop app for deeper browser work and the Chrome extension or sidebar for help while browsing, and said it was “building on what we learned from Atlas to bring a more capable browser experience to ChatGPT” [2]. What did not survive was the container and its contents: “Atlas browser data, including bookmarks, open tabs, and browser history, will not transfer automatically” [2]. This guide is for someone who has real work running through a tool a single vendor controls, and who wants that work to survive the vendor changing its mind. It is not a guide to picking tools, and it is not for teams with procurement, a contract and a vendor manager, who have instruments a solo operator does not.
The capability survives, the container does not
Every AI tool you adopt is two things at once. There is a capability, which is what the model does: browsing a page and summarising it, drafting the reply, transcribing the call. And there is a container, which is the specific application holding your settings, your history, your saved items and whatever you arranged inside it. Vendors move capabilities toward whichever surface already has users. They retire containers.
That split is exactly what the Atlas notice describes. The browsing capability moved into surfaces people were already in, the desktop app and a Chrome extension [2]. The container went away, and the bookmarks, open tabs and history went with it unless you moved them by hand, by exporting cookies and passwords to the ChatGPT desktop app and bookmarks to Chrome [2].
One detail in that notice is worth more than the rest of it. OpenAI wrote that “Your ChatGPT conversation history is separate and will remain available in ChatGPT, subject to your plan, workspace settings, and account access” [2]. There is your seam, qualifiers included. Material held in the vendor’s core account survived. Material held in the retired shell did not. Before a tool carries anything you would miss, work out which side of that seam your work is sitting on. If you depend on the capability, a shutdown costs you an afternoon of relearning. If you depend on the container, it costs you whatever you put in it.
The notice period is published, and it depends which layer you bought
The useful discovery is that vendors already tell you how much warning you get, in writing, on a page most people never open. They just do not tell you on the page where you sign up.
OpenAI’s deprecations documentation commits to minimum notice before a model or endpoint is shut down: at least 6 months for generally available models, at least 3 months for specialised variants such as chat and deep research variants, and much shorter notice for preview models, such as 2 weeks [3]. The stated reason is operational rather than decorative: “These notice periods give customers time to evaluate recommended replacement models, test application behavior, and complete migrations” [3]. The same page lists dated shutdowns well into the future, including legacy GPT snapshots on 23 October 2026 and transcription models on 26 February 2027 [3].
Anthropic publishes a floor and a vocabulary. It “provides at least 60 days’ notice before model retirement for publicly released models”, notifies affected customers “by email and in the documentation”, and names a recommended replacement with an assigned retirement date [4]. Its four lifecycle states are defined: Active is fully supported, Legacy “will no longer receive updates and may be deprecated in the future”, Deprecated is “still functional but no longer recommended”, and Retired means “requests to retired models will fail” [4]. Google’s Gemini documentation is thinner but still numeric: preview models “will be deprecated with at least 2 weeks notice”, and for the latest alias, Google says that “For breaking changes, a 2-week notice will be provided through email before the version behind latest is changed” [5]. Changes it does not classify as breaking carry no stated notice at all.
Now compare those to 31 days, from the same company that promises 6 months one layer down [2][3]. The developer surface publishes a floor you can plan against. The consumer product does not, and Atlas is the demonstration.
“Preview” is a notice period, not a marketing label
Read the label as a number and it becomes useful. On OpenAI’s terms, preview means the shutdown notice could be around 2 weeks [3]. On Google’s, preview models get at least 2 weeks, and experimental models are described as unstable, typically unsuitable for production use, and subject to more restrictive rate limits [5]. On Anthropic’s, Legacy is the state where you should already be planning the move [4].
Atlas carried that signal from the first day. Agent mode, the part that actually did work on your behalf, “launched in preview to Plus, Pro and Business users” [1]. Windows, iOS and Android were listed as coming soon [1]. A preview feature inside a first-generation product is a reasonable thing to try. It is not a reasonable thing to put a client deadline behind.
The practical rule is boring and it holds. Demo previews, schedule stable things. When a vendor gives a feature a version identifier and a retirement date, it has told you it will keep the feature long enough to be worth wiring up.
The export is slower than you think, so run it early
People plan their exit as though downloading their data takes an afternoon. It does not. A ChatGPT data export “can take up to 7 days to arrive”, and once it does, “the download link expires 24 hours after you receive it” [6]. A Notion workspace export “can take up to 30 hours to process, depending on the size of the workspace” [7]. Set a 7-day queue against a 31-day shutdown window and start in the final week, and you may simply not get the file.
Exports are also lossy in ways you only find out by opening one. Notion cannot export a Form view of a database, restricts you to the current view or the default view when exporting a database, and omits “pages that the exporter doesn’t have access to, such as private pages of other users” [7]. A ChatGPT export “cannot restore chats that have already been deleted” [6]. Both are honest documents. Neither promises you a working copy of the thing you had.
There is a legal floor under all of this, and it is worth knowing precisely what it does. GDPR Article 20 gives you the right to receive personal data you provided in a “structured, commonly used and machine-readable format” and to transmit it to another controller, and to have it moved directly between controllers “where technically feasible” [8]. That means a file has to exist. It does not mean the file will rebuild your workspace, and no regulation is going to hand you back your tab arrangement.
So run the export in the first week you adopt a tool, while nothing is on fire. Open the archive. Read what came out. The gap between what you expected and what is actually in the folder is the real number you needed.
routines × hours to rebuild each. Compare the result against the notice period the vendor publishes. Computed in the page; nothing is sent anywhere.
Keep the wiring outside the tool
What a shutdown usually takes is not the data. It is the arrangement: the prompt you refined over four months, the order the steps run in, the saved instruction that made the output usable, the template you stopped thinking about because it always worked. None of that is in the export, because the vendor does not think of it as yours.
Keep the source of truth somewhere you control. Prompts belong in a plain text file. Procedures belong in a document you can export as Markdown, which Notion does for any non-database page, with full-page databases coming out as CSV [7]. Automation logic belongs written down in prose as well as configured in a host, because the prose is what lets you rebuild it somewhere else in an hour instead of a weekend.
The same reasoning tells you where to keep things inside a vendor. Conversation history sat in the ChatGPT account and survived Atlas being retired [2]. The closer a store is to the vendor’s core business, the longer it tends to last. A shiny new surface is the least durable place to leave the only copy of anything.
Buy the capability at the layer that carries a version number
If a workflow earns money, run it against something that has an identifier and a calendar. Anthropic’s deprecation table is the clean example: claude-opus-4-1-20250805 was deprecated on 5 June 2026 and retired on 5 August 2026, with a named replacement [4]. That is a thing you can put in a diary. OpenAI’s page does the same for its endpoints and snapshots, with shutdown dates published months out [3].
Consumer surfaces change underneath you with no version number at all, which is the trade you are making when you use them. That trade is often correct. Most work does not need a pinned model, and a chat window with no version number is faster and cheaper than the alternative. Just make the choice deliberately, and reserve the versioned layer for the two or three routines that would actually cost you a client if they broke on a Tuesday.
The last piece is a fallback you have actually run once. Not a plan to have a fallback. An hour spent doing the job the manual way, so you know it takes 40 minutes and not a day, and so the shutdown notice is an inconvenience rather than an emergency.
What still goes wrong
You cannot tell in advance which product dies. Atlas got a worldwide launch on the vendor’s main announcement channel, availability on the free tier, and a roadmap for three more platforms [1]. None of that predicted a release note eight and a half months later. Anyone claiming they can read the signals is reading them after the fact, and the honest position is that this is a risk you manage rather than a call you make correctly.
Published notice periods are policies, not contracts, and they cover the things they say they cover. OpenAI’s 6-month commitment is about models and endpoints on the developer platform [3]. Nothing on that page applied to Atlas, and nothing on it stops the policy being rewritten. Treat a published deprecation page as evidence that a vendor thinks in migration windows, which is genuinely useful, and not as a guarantee you could enforce.
Export is not restore, and that is the gap that hurts. A ZIP of Markdown files is a record, not a running system, and the hours in the calculator above are rebuild hours, not download hours. Meanwhile the obvious hedge, running two tools so you always have a second one, usually costs more in attention and subscriptions than the risk it removes. For most solo operators the correct answer is one tool, good notes, a tested export, and the acceptance that some Tuesday you will spend an afternoon learning where the buttons moved.
- 01OpenAI — Introducing ChatGPT Atlasopenai.com
- 02OpenAI — ChatGPT release noteshelp.openai.com
- 03OpenAI — Deprecationsdevelopers.openai.com
- 04Anthropic — Model deprecationsplatform.claude.com
- 05Google — Gemini API modelsai.google.dev
- 06OpenAI Help — How do I export my ChatGPT history and data?help.openai.com
- 07Notion — Export your contentnotion.com
- 08GDPR — Art. 20, Right to data portabilitygdpr-info.eu