Why Your Business Shouldn’t Run on a Single AI Vendor
Models get deprecated, prices move, and outages happen. Here’s how to build a little redundancy into your AI stack before you need it.
| Anthropic’s minimum deprecation notice | At least 60 days before a model retires (Claude Platform Docs) |
| OpenAI’s minimum deprecation notice | At least 6 months for GA models, 3 months for specialized variants (OpenAI API Docs) |
| A real, documented outage | ChatGPT, the API, and Sora went down for roughly six hours on Dec 11, 2024, after an internal config change (TechCrunch) |
| Models actually retired in the past two years | Claude 1 and Instant (Nov 2024), Claude 2, 2.1, and Sonnet 3 (Jul 2025), among others (Claude Platform Docs) |
| The fix | Treat your AI vendor like any other single point of failure — hosting, payments, a key supplier |
If your business runs a critical workflow through one AI model, called from one vendor, with no plan for what happens if that access changes, you have a single point of failure sitting in the middle of your operation. That is not a hypothetical. It’s how the industry actually behaves right now, and it’s worth understanding before it becomes your problem instead of a line in a blog post.
This isn’t a warning about any one company doing something wrong. It’s the opposite: deprecating old models, adjusting pricing, and occasionally going down are all things every serious AI vendor does, on purpose, as a normal part of running the business. The mistake is building as if none of that will ever touch you.
Models get deprecated — on a schedule, not a whim
Every major AI lab retires older models on a rolling basis, and they publish exactly when. Anthropic’s documented policy is to notify customers with active deployments at least 60 days before a model retires, moving models through a public lifecycle of Active, Legacy, Deprecated, and finally Retired. In practice, Anthropic has already retired multiple model generations this way: Claude 1 and the Claude Instant models were retired in November 2024, and Claude 2, Claude 2.1, and Claude Sonnet 3 followed in July 2025, each with advance notice published on Anthropic’s model deprecations page.
OpenAI runs a similar process with a longer runway for generally available models: at least six months’ notice, three months for specialized variants like chat or coding-tuned snapshots, and as little as two weeks for models explicitly labeled “preview.” OpenAI’s own deprecations documentation lists a steady cadence of shutdown dates stretching out over the coming year, covering everything from early GPT-4 snapshots to older completion endpoints.
None of this is a red flag. It’s a maturing industry doing normal lifecycle management, the same way your CRM or accounting software eventually sunsets an old API version. But if the exact model ID your app calls is hardcoded somewhere, and nobody on your team is watching the deprecation calendar, you’ll find out about a retirement the day your integration starts returning errors instead of the day the notice went out.
Outages happen to everyone, including the biggest players
On December 11, 2024, ChatGPT, OpenAI’s developer API, and its Sora video tool all went down at once. The outage started around 3pm PT and services were largely restored by 9pm, roughly six hours later. OpenAI later said the cause was an internal configuration change that knocked many servers offline — not an attack, not a security incident, just an ordinary operational mistake at a company running enormous infrastructure, reported at the time by TechCrunch.
Six hours doesn’t sound catastrophic until it lands on a day your support bot, your order-processing pipeline, or your content workflow is fully dependent on that one API responding. Every large cloud and AI vendor has had a bad day like this at some point, and every one of them will have another. That’s not cynicism, it’s just what running software at scale looks like.
Pricing and access terms aren’t fixed either
Beyond deprecations and outages, the commercial terms underneath AI APIs are still being worked out in public. Rate limits get adjusted. Usage tiers get restructured. Pricing per token has moved in both directions across the industry as vendors compete and as the underlying compute costs shift. None of that is unusual for a young technology market finding its footing — it’s the same pattern cloud computing went through in its first decade. The point isn’t that any specific change is coming. It’s that a business plan which assumes today’s price, today’s rate limit, and today’s access level will hold indefinitely is planning on an assumption the vendors themselves haven’t made.
Treat this like any other single-vendor risk
Business owners already understand this pattern from everywhere else. Nobody keeps 100% of their revenue running through one client, one payment processor, or one hosting provider without a backup plan, because a bad week from that vendor becomes a bad week for the whole business. If your payment processor announced a rate hike or a policy change, you’d already have a sense of what your options were. AI vendors deserve the exact same treatment: not paranoia, just ordinary vendor-risk hygiene applied to a newer category of supplier.
The businesses that get burned aren’t usually the ones using AI aggressively. They’re the ones who never asked “what happens if this specific model or vendor is unavailable next Tuesday” until the day it actually happened.
What building in redundancy actually looks like
You don’t need a full multi-vendor architecture on day one. A few concrete habits go a long way:
- Build against an abstraction layer where practical. Route model calls through a thin internal layer or a routing library instead of calling one vendor’s SDK directly everywhere in your codebase. Swapping a model or provider later becomes a config change instead of a rewrite.
- Keep prompts and logic portable. Avoid leaning on vendor-specific quirks for anything mission-critical. A prompt that only works on one model’s exact phrasing habits is a liability, not a feature.
- Know your fallback for every critical workflow. For each process that touches AI and actually matters to revenue or customers, write down the honest answer to “what do we do for a day if this vendor is down.” Sometimes the answer is a second model. Sometimes it’s a manual process for 24 hours. Just have an answer before you need one.
- Read your vendor’s deprecation and SLA policy once. Anthropic and OpenAI both publish theirs, with concrete minimum notice periods. Knowing the number in advance turns a surprise into a scheduled task.
- Pin model versions deliberately, and track the calendar. Auto-upgrading to “latest” can break things without warning; pinning a specific model version without tracking its retirement date is just a slower way to get the same surprise.
None of this requires running two AI vendors in parallel at all times. For most small businesses, it means picking your two or three highest-stakes AI workflows and making sure each one has a documented answer to “then what,” the same way you’d want a documented answer for what happens if your web host disappears overnight.
Where this leaves you
AI vendors are not going away, and using them aggressively is still the right call for most businesses. The point isn’t to hedge so hard that you lose the speed AI gives you. It’s to spend one afternoon identifying your single points of failure before a deprecation notice, a rate-limit change, or an ordinary bad day forces the conversation on someone else’s timeline.
If you want a second set of eyes on how your own AI workflows are wired together, and where the actual exposure sits, get in touch or take a look at how we approach this in our AI strategy work.