Rehearse the Provider Cutoff: Model Failover for Agent Fleets

The move

Build a model dependency inventory, give each workflow a tested fallback, and rehearse losing one provider. Finish with a routing or handoff plan, measured task quality, an affordable capacity envelope, and a rollback procedure. This is the continuity layer beneath your multi-agent command center and organization’s agent gateway.

The news, once: a proposed shutoff date

On August 28, OpenAI announced its intention to wind down model access supplied to Cursor following Cursor’s acquisition by SpaceX. It named November 12, 2026 as the proposed shutoff date and said it would not provide future models under that arrangement. As checked September 6, that announcement still describes a planned contractual cutoff, not a completed shutdown.

The scope matters: the announcement concerns OpenAI’s supply agreement with Cursor. It does not announce the end of every developer’s direct OpenAI API access, nor say Cursor itself will stop working. Keep the Cursor acquisition analysis alongside your dependency inventory, and check the actual account and integration that each workflow uses.

The operational lesson extends beyond this contract. A model can become unavailable through a changed agreement, retired version, exhausted quota, regional incident, or revoked account. Each is a different failure mode. A second logo in your settings is useful only if the workflow can reach it under the conditions you are rehearsing.

Why acting agents changed the requirement

A provider failure can interrupt a tool-using agent between planning an action and recording its result. A review may stall; a scheduled job may retry; an already-issued tool call may finish after the model becomes unreachable. The failure is a state-reconciliation problem as well as a model-selection problem.

Before starting the same task with another model, determine what already happened. Otherwise, the fallback can repeat a write, reopen a completed operation, or overwrite work whose transcript ended too early. Preserve the task boundary, workspace state, and destination evidence during every handoff.

The runbook: model failover in six steps

Start with a disposable project and one important workflow. The registry and helper commands below illustrate a system you implement; they are not a shared configuration standard or built-in Automater commands. Extend the drill only after the first path works.

Step 1: inventory dependencies and failure domains

Search the places you control, then inspect settings that live inside products. A filename-only search avoids copying adjacent credentials into an inventory report. This Bash example includes hidden configuration files and reports missing directories without suppressing genuine search errors.

# Run in Bash from the repository you want to inspect.
paths=()
for path in . "$HOME/.claude" "$HOME/.codex" "$HOME/.config/opencode"; do
  if [[ -d "$path" ]]; then
    paths+=("$path")
  else
    printf 'Not present: %s\n' "$path" >&2
  fi
done
rg -l --hidden -i \
  -e 'gpt-[0-9]|claude-[a-z0-9.-]+|gemini-[0-9]' \
  -e 'ANTHROPIC_MODEL|OPENAI_MODEL|model_provider' \
  -e '"model"\s*:|^\s*model\s*[:=]' \
  --glob '!.git/**' --glob '!node_modules/**' --glob '!*.lock' \
  "${paths[@]}"
# rg exit 1 = no matches; exit 2 = a search error to investigate.

Inspect matching files locally. Extend the patterns for your providers; a search cannot discover every dynamic default. Follow each workflow to its account, model ID, region, runtime, tool schema, and owner.

Dependency	Where to inspect	What to record
CLI default	User and managed settings	Effective model, provider, authentication
Child agents	Definitions and invocation overrides	Inherited versus explicit model
CI and hooks	Workflow files, secret names, launch scripts	Job owner and noninteractive fallback
IDE sessions	Model picker and organization settings	Current selection and allowed alternatives
Model-calling MCP server	Server configuration and deployment	Its independent provider dependency
Router	Upstream mapping and fallback rules	Shared accounts, regions, and suppliers

Cursor documents separate current-conversation selection and the default in Settings → Models. Inspect both; do not assume a repository file controls them. An MCP server can also call a model independently of its host agent. Give every uncovered path an owner.

Step 2: define roles and supported transitions

Keep exact model versions in one reviewed registry, then give workflows stable roles such as planner, grinder, and judge. Pin a verified version behind each role so an alias update becomes an intentional rollout. Preserve the effective model in every run record.

# models.yaml — illustrative planning schema, not native CLI config.
roles:
  planner:
    primary: { provider: A, model: '<verified-primary-id>' }
    fallback: { provider: B, model: '<verified-fallback-id>' }
  grinder:
    primary: { provider: C, model: '<verified-primary-id>' }
    fallback: { provider: D, model: '<verified-fallback-id>' }
  judge:
    primary: { provider: D, model: '<verified-primary-id>' }
    fallback: { provider: C, model: '<verified-fallback-id>' }
    require_independent_family_from: planner
transition:
  apply_to: new_sessions
  require: [adapter_check, credential_check, task_eval, budget_check]
  on_incompatible_harness: approved_handoff

Letters and model IDs are placeholders. “Independent family” is a review choice that reduces one source of correlated grading errors; it does not guarantee an unbiased judge. Check the relationship after every transition. If no independent automated judge remains, use a qualified human review path rather than routing back to the unavailable supplier.

An alias file does not make protocols interchangeable. The current official documentation draws concrete boundaries:

• Claude Code model configuration supports settings, environment variables, and session overrides. Its gateway documentation explicitly says Anthropic does not support routing Claude Code to non-Claude models. Changing Claude’s hosting provider and changing model family are different operations.
• Codex provider configuration uses a compatible Responses endpoint. Provider and authentication settings belong in user or managed configuration; project-local configuration cannot redirect them. A Chat Completions-compatible URL alone is not enough.
• OpenCode’s model catalog supports provider/model selection, but an existing session’s explicit selection takes precedence over the configured default. Check the session you are actually running.

Render only supported transitions into native configuration. Where the alternative requires another harness, create a fresh session with the task, current branch, completed changes, remaining work, and approval boundaries. Do not imply that a subscription credential becomes a portable API key or that conversation state transfers losslessly.

The registry’s value is a single reviewed decision point. Its adapters still need capability checks, staged distribution, atomic file writes, preservation of unrelated settings, and an effective-configuration report from each client.

Illustrative routes. The adapter must validate protocol, entitlement, and harness support before selecting a fallback.

Step 3: rehearse a controlled provider loss

Choose a staffed window away from releases; Friday morning is one option, not a requirement. Inform the workflow owner and responder. In a test scope, deny the primary route or remove its test entitlement so the drill exercises actual failure detection. Merely selecting the fallback proves selection, not failover.

#!/usr/bin/env bash
# Illustrative adapters you implement; requires GNU timeout.
# Test tenant and disposable work only. Run as a script, do not source it.
set -uo pipefail
command -v timeout >/dev/null || exit 2
timeout --kill-after=5s 60s ./ops/fleet-transition preflight \
  --role planner --target fallback || exit "$?"
drill() {
  timeout --kill-after=5s 60s ./ops/fleet-drill "$@" --scope continuity-test
}
cleanup() {
  result=$?
  trap - EXIT
  drill reconcile-effects || result=1
  drill restore-primary || result=1
  exit "$result"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM
drill deny-primary || exit "$?"
drill run-goldens || exit "$?"

Prepare the restore procedure before the denial and make it safe to repeat after a partial failure. This wrapper stops on failed preflight and attempts reconciliation and restoration on exit, including failed tests. A failed cleanup remains a failed drill requiring operator attention; an EXIT trap cannot recover from power loss or SIGKILL, so retain an independent restore procedure. The test route must have a distinct identity or namespace so the drill cannot disable production traffic. Record the denied request, selected fallback, effective model, any restarted session, and the final destination state.

Measurement	Evidence
Time to detect	Denial timestamp to alert or operator recognition
Time to recover	Detection to a completed, checked task
Coverage	Every expected client reports its active route
Silent degradation	Quality loss, skipped checks, or unexpected defaults
Repeated effects	Destination records show no duplicate writes

Keep admission denial, timeout, and quota exhaustion as separate cases. They often trigger different retry paths. Start with one case and expand coverage deliberately. Never automatically replay a call whose outcome is unknown: reconcile it first or stop for a human decision.

Step 4: compare real work before declaring parity

Run the same representative tasks on primary and fallback with the same repository revision, tools, permissions, and acceptance criteria. Keep task-level results, not just an average. A model that passes routine edits but fails your one release-critical migration has not passed continuity for that workflow.

Set thresholds before seeing results: required-task pass rate, maximum retry rate, latency, and forbidden actions. Include malformed tool responses, an interrupted stream, an unavailable dependency, and a task that must refuse an out-of-scope write. Re-run nondeterministic cases and preserve failed attempts. The agent evaluation guide helps build that task set.

Judge output independently where practical and include human checks on high-consequence changes. Model diversity helps, but two models can share blind spots. A fallback that misses the bar can still serve a narrower role, such as read-only analysis, while an operator handles writes. Record that degraded service explicitly.

Step 5: price capacity, not just tokens

Measure the fallback under the actual authentication route. For example, Claude Code’s gateway documentation explains that a gateway credential replaces subscription authentication for that session, with traffic billed to the upstream credential owner. A saved subscription and an API account are not interchangeable budgets.

Lane	Measure during the drill	Plan for a longer interruption
Primary	Account, quota, cost, and completed tasks	Which commitment remains payable?
Fallback	Effective model, retries, latency, and billable usage	Is account capacity approved?
Reduced service	Essential workflows only	Which work queues or stops?

Use the token-plan guide to identify the charging boundary, then use observed workload to estimate a range. Include weekends, burst concurrency, longer prompts after handoff, and retries. A daily spend extrapolation is a planning estimate, not a guarantee of quota or throughput.

Verify whether a provider’s “budget” is a hard enforcement control or an alert. If the requirement is to stop spending at a ceiling, enforce admission at a layer you control and test it. Define which roles keep capacity first and how queued tasks expire. Avoid sending sensitive data to a fallback whose approved region or retention terms differ from the primary.

Step 6: keep a continuity record with empty evidence until measured

Put one page beside the registry: owner, trigger, eligible fallback, required checks, restore procedure, and known uncovered clients. Link the evidence from the latest completed drill. Leave measurements empty until they exist.

# continuity.yaml — illustrative template; no drill results asserted.
owner: platform-oncall
role: planner
registry_revision: '<reviewed-commit>'
fallback_route: '<approved-route>'
last_completed_drill: null
evidence: null
time_to_detect_seconds: null
time_to_recover_seconds: null
quality_gate: '<acceptance-criteria-file>'
budget_enforcement: '<tested-control>'
unknown_effects: []
uncovered_clients: []
rollback: '<reviewed-restore-procedure>'
next_drill: '<scheduled-date>'

List any pending effect that must be reconciled before restarting. Record the person who accepts each remaining coverage gap. Repeat the drill after changing the provider, client, tool schema, credential route, or relevant policy; those changes can invalidate last month’s evidence.

What breaks, and how you’ll know

The default changes, the session does not. New work uses the fallback while an existing session or child keeps its explicit model. Compare active-session evidence with the registry revision. Exercise both resumed and fresh sessions during the drill.

The API shape matches, the behavior does not. Streaming, tool selection, context limits, and retries differ. Watch failed schemas, duplicated tool effects, and acceptance failures. A successful text response is only the first compatibility check.

Two routes share the same failure. Different endpoints may use the same model supplier, account, region, or gateway. Map the dependency that was actually denied. A hosting change may cover a regional outage while doing nothing for a supplier-wide contract restriction.

The handoff loses its place. The replacement agent repeats completed work or misses an approval boundary. Reconcile branch and destination state, provide a compact verified handoff, and start with a read-only review of what remains.

The operating-layer frame

Continuity has two parts: the organization controls supported routes and credentials; the operator needs to see which sessions changed, stalled, or need a handoff. Keep both in the rehearsal. A central registry reduces scattered decisions, while evidence from each runtime tells you whether the intended change took effect.

Product note: Automater’s fleet view and local session Library give operators context across supported harnesses during a transition. Use the Library to recover prior work and compare it with provider and destination records; it is not a universal failover router or a guarantee of transcript-format compatibility. Automater Lite is free; current Pro pricing is on the pricing page.

FAQ: model provider failover for agent fleets

What counts as tested model provider failover?

A controlled loss of the primary dependency is detected, the approved alternative completes representative work, and external effects are reconciled without duplicates. Record the effective model, quality, cost, and recovery time. If switching requires another harness, include that handoff in the test rather than assuming it works.

Should agent configurations pin model IDs or use aliases?

Use stable workflow roles backed by verified, pinned model versions in a reviewed registry. Render supported settings into each client and retain the effective model in run records. Uncontrolled floating aliases can change behavior unexpectedly; scattered hardcoded versions can make planned upgrades and emergency transitions difficult to audit.

Can every CLI switch to another vendor through a gateway?

No. Support depends on the harness, protocol, model family, authentication, and account access. Claude Code’s current documentation does not support routing to non-Claude models. Codex requires a compatible Responses interface. Use a validated alternative harness when necessary, and rehearse the task handoff and state reconciliation.

Sources

• OpenAI — Decision on Cursor following its acquisition by SpaceX, August 28, 2026
• Cursor — Changing models
• Anthropic — Claude Code model configuration
• Anthropic — Other LLM gateways, compatibility and subscription boundaries
• OpenAI — Advanced Codex configuration and custom providers
• OpenCode — Model selection, defaults, and per-session overrides