Pre-flight checklist
Problem / motivation
I am running codex-lb 1.22.0 with multiple ChatGPT OAuth accounts.
The current API-key workaround requires separate keys or client providers. For example, one key can be restricted to gpt-5.6-sol and assigned to Account A, while another key can be restricted to gpt-5.6-luna and assigned to Account B.
This works, but the client must select the correct key/provider. A single key or endpoint cannot automatically route different models to different OAuth accounts.
Proposed change
I would like a first-class model-to-account routing configuration.
Example:
gpt-5.6-sol -> Account A
gpt-5.6-luna -> Account B
Requested behavior:
- The proxy should select the configured account pool based on the requested model.
- API-key account and model restrictions should still apply.
- A request must never silently fall back to an account outside the model route.
- If the mapped account is unavailable or does not support the model, the request should fail with a clear routing error.
- Sticky sessions and account continuity must not override a strict model route.
- The proxy must avoid replaying encrypted reasoning state across different OAuth accounts.
- The behavior should apply consistently to /v1, /backend-api/codex, HTTP, WebSocket, compact, and control requests.
- Model aliases should be normalized before route matching.
- The dashboard/API should expose the configuration, and request logs should identify that model-account routing was used without exposing account email addresses.
This is different from global single-account routing and from capability-based model filtering. The desired feature is deterministic operator-configured routing from one model to one account or account pool, while keeping one client endpoint and key.
Alternatives considered
No response
Area
No response
Additional context
No response
Pre-flight checklist
Problem / motivation
I am running codex-lb 1.22.0 with multiple ChatGPT OAuth accounts.
The current API-key workaround requires separate keys or client providers. For example, one key can be restricted to gpt-5.6-sol and assigned to Account A, while another key can be restricted to gpt-5.6-luna and assigned to Account B.
This works, but the client must select the correct key/provider. A single key or endpoint cannot automatically route different models to different OAuth accounts.
Proposed change
I would like a first-class model-to-account routing configuration.
Example:
gpt-5.6-sol -> Account A
gpt-5.6-luna -> Account B
Requested behavior:
This is different from global single-account routing and from capability-based model filtering. The desired feature is deterministic operator-configured routing from one model to one account or account pool, while keeping one client endpoint and key.
Alternatives considered
No response
Area
No response
Additional context
No response