Depending on a single AI provider concentrates five risks in one supplier: its outages, its model retirement calendar, its price changes, its enforcement decisions about your account, and its API changes. Each one is routine for the provider and can be an incident for you. In October 2026 alone, the vendors read for this article published eight model and API lifecycle changes, one of them sending requests to a different model with no change on the caller's side. The mitigation is not "use every provider". It is a second, evaluated path for the workflows that matter, contracts that give notice, an exit plan that has been written down, and drills that prove the fallback works.
This guide is written for boards and executives who need to judge the risk, and for the engineering leaders who will be asked what is being done about it.
The five risks of a single AI provider
| Risk | What it looks like | Typical warning |
|---|---|---|
| Outage | Elevated errors or full unavailability on some or all models | Minutes; status page during the incident |
| Retirement and re-routing | A model stops answering, or requests are served by another model | Weeks to months; sometimes none |
| Price change | List rate rises on a date | Weeks; published on the pricing page |
| Account enforcement | Restriction or suspension of the organization or a key | Varies; can be immediate |
| API or policy change | Requests that worked start to fail or behave differently | A new API version or SDK major |
Outages
On 3 September 2026, Anthropic's status page recorded elevated errors on several Claude models, including Fable 5.1, Opus 5, Opus 4.8 and Opus 4.6, from 13:26 UTC until impact ended at 16:16 UTC, across claude.ai, the Claude API, Claude Code and Claude Cowork1. In the same afternoon, xAI's status feed recorded an outage-severity incident "affecting All Grok Models" from 13:41 to 17:07 UTC2. The full timeline, including OpenAI's incident on its consumer and Codex surfaces that day, is in September 3, 2026: provider incidents and failover.
Two lessons matter at board level. Incidents are often model-specific: Anthropic's affected some models and not others, so a fallback to another model or another host of the same model would have served much of the window. And incidents can overlap across vendors, so a single fallback is not a guarantee.
Model retirements and re-routing
Providers retire models on their schedule, not yours. In October 2026 the pages read for this article record these changes:
| Date | Vendor | Change | Replacement named |
|---|---|---|---|
| 1 Oct | OpenAI | gpt-5.3-codex, gpt-5.4-nano and gpt-5.1 deprecated, shutdown 1 April 20273 | gpt-6-sol, gpt-6-luna |
| 1 Oct | OpenAI | tts-1, tts-1-hd and gpt-4o-mini-tts deprecated, shutdown 6 January 20273 | gpt-realtime-2.1-mini |
| 6 Oct | gemini-3.1-flash-image deprecated with no shutdown date4 | Nano Banana 2.1 released the same day | |
| 8 Oct | gemini-3.7-flash and gemini-3.5-flash deprecated; API requests automatically routed to gemini-3.8-flash and gemini-3.6-flash; a Deep Research preview set to shut down 23 October4 | Yes, applied automatically | |
| 10 Oct | Alibaba Cloud | Legacy Qwen, Qwen3, audio and third-party models such as DeepSeek, GLM and Kimi "officially cease service" in Model Studio5 | None named |
| 14 Oct | OpenAI | GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini snapshots deprecated, shutdown 14 January 20273 | gpt-6-luna |
| 21 Oct | Anthropic | API version 2026-10-21 released; new SDK majors send it by default6 | Migration guide |
| 24 Oct | Perplexity | Seven OpenAI model ids, from openai/gpt-5 to openai/gpt-5.4, retired from its Agent and Orchestrator APIs at 00:00 UTC7 | Current models in its reference |
Three patterns in that table carry the risk:
- No replacement named. Alibaba's notice lists the retired families and does not name replacements; it asks customers to "complete your business migration before this deadline"5. Choosing and evaluating a successor is entirely your work.
- A different model with no code change. Google's automatic routing keeps requests working but changes the model that answers them4. Output quality, cost and latency can move without any deployment on your side.
- Retirement through an intermediary. Perplexity retired OpenAI model ids on its own platform on its own date7. Every platform between you and a model adds its own calendar.
Anthropic also retires Claude Sonnet 4.5 on 30 November 2026 and names Sonnet 5.5 as the replacement6. A single-provider company still faces this churn; it simply has no alternative ready when a replacement does not fit.
Price changes
Prices change on published dates, and a single-provider budget absorbs the change in full. Google lists Gemini 4 Argon at $2.00 input and $10.00 output per 1M tokens through 30 November 2026 and $4.00 and $20.00 from 1 December 2026, with output including thinking tokens; Gemini 3.8 Flash moves from $0.75 and $3.75 to $1.50 and $7.50 on 1 January 20278. A workload sized at the launch rate costs twice as much from the change date unless it moves.
Account enforcement
A provider can restrict or suspend an account it believes is breaking its terms, and for a company serving many end customers through one account, one customer's behaviour can put the whole account at risk. Anthropic's release notes for 20 October 2026 describe the problem and a remedy: with the new user profiles, a platform or gateway can tell Anthropic which end customer each request is for, so "a safety enforcement action can then apply to one end customer instead of your whole organization"; profiles also show whether Anthropic has restricted or banned one of your end customers6.
Providers are also watching harder for abuse. The joint CISA, NSA and FBI advisory on model distillation asks AI companies to detect anomalous accounts and behaviour, including enterprise-scale throughput and new accounts that jump straight to maximum usage9. Those signals target abuse, but some legitimate workloads share their shape, such as a new production launch at full volume. Talk to your provider's account team before a large launch, and attribute end customers wherever the provider supports it.
API and policy changes
An API version can turn a working request into an error. On Anthropic's API version 2026-10-21, a request that sends temperature, top_p or top_k returns a 400 error, even at the default value, and the new SDK majors send that version by default10. A dependency upgrade can therefore break production on a provider you did not change. Pin SDK versions, read migration guides before upgrading, and test the upgrade on recorded requests.
A risk register for the board
| Risk | Example | Impact | Mitigation | Owner | Test |
|---|---|---|---|---|---|
| Vendor-wide outage | All models of one vendor unavailable for hours | Critical features down | Second vendor evaluated for each critical workflow; routing that fails over | Platform lead | Quarterly failover drill |
| Model-specific outage | Some models error, others serve | Degraded answers or errors | Fallback model on the same account, or the same model on another host | Platform lead | Drill with one model disabled |
| Retirement, no replacement | Alibaba's 10 October retirements | Feature stops on the date | Lifecycle watch; candidate successors evaluated before the date | Product owner per workflow | Monthly review of vendor deprecation pages |
| Silent re-routing | Gemini 3.7 Flash requests served by 3.8 Flash | Quality, cost or latency shift | Record the model each response reports; alert on change | Engineering | Alert fires in staging |
| Price increase | Gemini 4 Argon doubles on 1 December | Margin falls | Budget on the post-change rate; evaluated alternative | Finance + engineering | Re-forecast each quarter |
| Account enforcement | Organization restricted after one end customer's abuse | All traffic on that account stops | End-customer attribution; abuse controls; second account or vendor | Security | Tabletop exercise |
| API or SDK change | 400 errors after an SDK major upgrade | Requests fail after a deploy | Pinned versions; upgrade testing on recorded traffic | Engineering | CI on each upgrade |
| Intermediary dependency | An aggregator or gateway retires ids or fails | Same as the vendor's own risks, plus its own | Know every platform in the path; direct provider access as an exit | Platform lead | Exit drill |
Mitigations that work
A second, evaluated path for critical workflows. A fallback must be evaluated for the task before it is needed: output quality, tool-call behaviour, refusal rate and cost per task. For a model-specific failure, the same model on another host keeps the output you evaluated, such as Claude on Anthropic's API and on Google Vertex AI. For a vendor-wide failure, only another vendor helps. The design patterns are in multi-model API architecture.
Contracts. Ask each provider for minimum notice before retirements and price changes, what requests receive after a shutdown, the notice and appeal process before an account suspension, how end customers can be attributed, and data export on exit. Where you cannot get terms, the architecture has to carry the risk instead.
An exit plan. For each critical workflow, write down the alternative model and provider, the evaluation result, the code or configuration change required, and how long it takes. Keep the provider accounts and keys for the alternative active. Avoiding LLM vendor lock-in covers the portability layers.
Drills. Disable the primary in staging and confirm the fallback serves, including what users see when every option fails. The failover drills guide has scenarios and a schedule.
Where multi-provider loses
A second provider is not free. Each critical workflow needs evaluation on two models and re-evaluation whenever either changes. Features that exist on one vendor only, such as a specific tool or modality, cannot fail over at all. Splitting volume can weaken the terms a single large contract would earn. And every extra platform in the path, including a gateway, adds its own failure modes and calendar. For non-critical workflows, accepting single-provider risk with good monitoring is often the right call.
Spreading provider risk with INFRO
INFRO is a control plane in front of the provider accounts you already hold. Your contracts and accounts stay yours and your providers bill you directly, which also means INFRO can route only across the providers you have connected and cannot get you capacity or terms.
Routes and failover. A route is a name your application sends as the model, backed by up to 10 targets across your connections, walked in order or by weight; failure rules decide per failure kind whether to retry, fail over or stop. A connection can list alternate API hosts for the same key, and INFRO's Google Vertex AI connection serves Claude models, so a route can list the same Claude model on Anthropic and on Vertex. See routes and providers.
Lifecycle and drift. INFRO records each vendor's deprecations and shutdown dates, warns organizations still sending a retiring model, and from the shutdown date refuses it before any provider call with 404 model_shut_down, naming the replacement. It reads the model list your own key returns every three hours and stops offering a model your key no longer lists. Traffic changes raise a finding when a connection starts being answered by a model id it had not reported in the previous 14 days, which is how automatic re-routing shows up.
What INFRO does not remove: it is itself a dependency in the request path, and an INFRO failure affects every provider behind it. Because the provider accounts are yours, the exit is to call your providers directly, so keep that path documented and tested.