Feature Request: Provider Management, GUI Selection, and Automatic Failover

What variant of Codex are you using?

App,IDE Extension

What feature would you like to see?

Feature Request: Provider Management, GUI Selection, and Automatic Failover

Summary

I would like to propose a more complete model provider management experience for Codex Desktop and IDE extensions.

Codex already has the concept of model_provider and supports custom providers through configuration. It would be useful to expose this capability through the GUI while also providing an advanced configuration mechanism for users who need multiple providers for the same model.

The feature could consist of two related parts:

1. GUI provider/model selection
2. Advanced provider routing and automatic failover

---

1. GUI model provider selection

The model picker in Codex Desktop / IDE extensions could expose both the provider and model.

For example:

Provider: [ OpenAI ▼ ]
Model:    [ GPT-5 ▼ ]

or:

OpenAI / GPT-5
Azure OpenAI / GPT-5
Provider A / GPT-5
Provider B / GPT-5

Users should be able to see which provider is being used by the current session.

Custom providers defined in config.toml should ideally also appear in the GUI model picker.

---

2. Advanced provider configuration

For advanced users, providers could continue to be configured through config.toml.

For example:

[model_providers.provider-a]
name = "Provider A"
base_url = "https://provider-a.example.com/v1"
env_key = "PROVIDER_A_API_KEY"

[model_providers.provider-b]
name = "Provider B"
base_url = "https://provider-b.example.com/v1"
env_key = "PROVIDER_B_API_KEY"

The GUI would then automatically discover these configured providers.

This would allow the GUI to remain simple for normal users while configuration files provide more advanced routing capabilities.

---

3. Automatic failover for the same model

A particularly useful advanced feature would be allowing multiple providers to serve the same logical model.

For example, both providers may expose gpt-5:

provider-a → gpt-5
provider-b → gpt-5

The user could configure a fallback order:

[model_routes.gpt-5]
providers = [
    "provider-a",
    "provider-b",
]

The first provider would be preferred:

gpt-5
   │
   ▼
provider-a
   │
   ├── available → continue
   │
   └── unavailable
          │
          ▼
      provider-b
          │
          └── continue

This would allow Codex to automatically retry the request through provider-b when provider-a is temporarily unavailable.

---

4. Distinguish model identity from provider

I think it would be useful for Codex to treat these as separate concepts:

Logical Model
     │
     ├── Provider A / gpt-5
     ├── Provider B / gpt-5
     └── Provider C / gpt-5

rather than treating every provider/model combination as an entirely separate model.

This would make provider routing and failover much easier to reason about.

For example, the user could simply select:

Model: GPT-5

while Codex internally applies:

GPT-5
  → Provider A
  → Provider B (fallback)
  → Provider C (fallback)

---

5. Failure conditions

The failover mechanism could distinguish between different types of errors.

For example, automatic failover could potentially apply to transient errors such as:

• connection failures
• timeouts
• HTTP 429 / rate limiting
• temporary service unavailability
• HTTP 5xx errors

While errors such as invalid API keys, invalid model names, or malformed requests might require different handling rather than immediately retrying with another provider.

The exact retry/failover policy could be configurable.

For example:

[model_routes.gpt-5]
providers = ["provider-a", "provider-b"]
max_retries = 1
failover_on = ["timeout", "429", "5xx"]

---

6. Optional load balancing

Once provider routing exists, a future extension could support load balancing in addition to simple priority-based failover.

For example:

[model_routes.gpt-5]
strategy = "priority"
providers = ["provider-a", "provider-b"]

or:

[model_routes.gpt-5]
strategy = "round_robin"
providers = ["provider-a", "provider-b"]

Potentially other strategies could be added later, such as latency-based or health-based routing.

This does not need to be part of the initial implementation. Priority-based failover alone would already be very useful.

---

7. GUI representation

The GUI could expose the simple case while keeping advanced routing in settings.

For example:

Model
┌─────────────────────────────┐
│ GPT-5                    ▼  │
└─────────────────────────────┘

Provider
┌─────────────────────────────┐
│ Automatic               ▼  │
└─────────────────────────────┘

With an advanced configuration such as:

GPT-5 routing

Primary:
  Provider A

Fallback:
  Provider B
  Provider C

Strategy:
  Priority / Failover

The normal user would not need to understand provider routing, while advanced users could configure it explicitly.

---

Why this would be useful

This would be particularly useful for users who:

• use multiple OpenAI-compatible providers
• have both primary and backup API endpoints
• use organizational API gateways
• need redundancy for long-running coding sessions
• have different providers with different availability or rate limits
• want to switch providers without manually editing configuration files

It would also make Codex more resilient when a provider experiences a temporary outage or rate limit.

The important distinction is that the user is still selecting the same logical model, while Codex handles provider selection and failover underneath.

---

Proposed scope

A possible implementation could be incremental:

Phase 1

GUI support for:

Provider → Model

including custom providers defined in configuration.

Phase 2

Configuration-based provider routing:

logical model → ordered providers

Phase 3

Automatic failover:

Provider A
    ↓ failure
Provider B
    ↓ failure
Provider C

Future

Load balancing, health checks, latency-aware routing, provider-specific retry policies, etc.

This would provide a useful advanced provider-management layer without making the normal Codex experience more complicated.

Additional information

No response

No source files, tests, or entry points are identified. Start by locating the existing model_provider and config.toml handling and the model picker in Codex Desktop/IDE extensions; narrow the proposal to one phase and define acceptance criteria for provider selection or failover.