Your AI product needs a tested way to keep working when its primary model becomes unavailable. A second model name in a settings file is not enough.
Decide which tasks can switch to an alternative, which need human review and which must pause. Test those decisions before customers depend on the feature.
What the 2026 access suspension showed
On 12 June 2026, Anthropic said it had suspended customer access to Fable 5 and Mythos 5 to comply with a US government directive. Its other models remained available. The company later announced that both models were available again on 1 July. See its suspension statement and release updates.
Access returned, but the engineering question remains: what would your product do during that interruption?
Availability can change because of an outage, a commercial decision or a regulatory requirement. Build around that dependency instead of assuming any provider will always offer the same service.
Six things to prepare
1. Separate the task from the provider
Define what the product needs to do: summarise a document, extract fields, draft a response or review an answer.
Keep provider-specific requests behind a common interface. That gives the team a place to change providers without rewriting the entire workflow.
2. Choose a route for each task
A short summary and a sensitive hiring decision do not need the same treatment. Set requirements for accuracy, response time, cost and data handling.
Use those requirements to decide whether a task goes to the primary model, an alternative or a person. A cheaper route is useful only if it meets the task's requirements.
3. Test the alternative before you need it
Run representative tasks against the backup model. Record where it performs acceptably and where it fails.
Check its access arrangements, capacity and data-handling terms too. An alternative that cannot receive the relevant data or handle the workload is not a usable backup.
Example: a document-summary feature might switch providers after passing the same accuracy checks. A consequential recommendation might pause for human review instead. These are design choices to test, not guarantees that every model can perform both tasks.
4. Define acceptable quality
Keep a set of examples with expected outcomes, including difficult cases. Check factual accuracy, missing information, formatting and any task-specific risks.
Set the acceptance threshold before comparing models. Re-run the checks when a model, prompt or workflow changes. A response that arrives successfully can still be wrong.
5. Give users a useful fallback
If the normal feature is unavailable, explain what the user can do next. Depending on the task, that may mean waiting in a queue, using a simpler feature or requesting manual review.
Do not silently present lower-quality output as equivalent. If a task cannot be completed reliably, say so clearly and retain the user's work where the product supports it.
6. Assign incident responsibility
Name the person who decides when to switch, pause or restore the feature. Prepare customer messages and an internal escalation route.
Monitor answer quality as well as uptime. A service can be online while producing results that no longer meet your standard.
Keep the important knowledge inside your team
Your team should own its task definitions, evaluation examples, quality thresholds and operating decisions. Keep those materials current and accessible to the people maintaining the product.
This does not mean every company should train its own model. It means the team can assess an alternative using its own evidence instead of starting again whenever a provider changes.
What this means for hiring
When hiring for an AI product, ask candidates to explain how they would handle a model outage or a drop in answer quality. Look for clear decisions about testing, privacy, user communication and human review.
For candidates, a useful portfolio example shows the task, the checks and what happened when the preferred model failed. That demonstrates more than familiarity with one tool.
If the hiring process itself uses automated video, read why an AI video interview may not show the real candidate.
Before your next release
Write down the answers to these four questions:
- What stops working if the primary model is unavailable?
- Which alternative has passed our checks, and for which tasks?
- What will users see and do during the interruption?
- Who owns the decision to switch, pause and restore?
If an answer is missing, turn it into a concrete task before relying on that feature in production.
