Problem
When Sub2API is used as an OpenAI-compatible relay with multiple upstream OpenAI accounts in the same group, Codex / OpenAI Responses API sessions can fail after a session is resumed.
The client retries POST /responses, but some retries are routed to a different upstream OpenAI account than the account that produced the previous encrypted context. The upstream OpenAI API then rejects the request with an error like:
The encrypted content ... could not be verified. Reason: Encrypted content could not be decrypted or parsed.
Sub2API surfaces this to the client as a 502 Bad Gateway, so Codex Desktop shows repeated reconnect attempts.
Expected behavior
For OpenAI Responses API / Codex requests that carry encrypted context, the same logical session should remain pinned to the same upstream OpenAI account.
Actual behavior
Requests from the same restored Codex session can be routed across different upstream accounts in the same Sub2API group.
When the request is routed to the upstream account that can decrypt the context, it succeeds. When it is routed to another upstream account, upstream returns 400 for invalid / unverifiable encrypted content, and the relay returns 502 to the client.
Evidence from a production incident
An anonymized production trace showed:
- Endpoint:
POST /responses
- Client: Codex Desktop
- Same Sub2API API key and same group
- Multiple upstream OpenAI accounts available in the group
- Successful requests when routed to one upstream account
- Repeated failures when routed to a different upstream account
- Upstream status:
400
- Relay/client status:
502
- Upstream message: encrypted content could not be decrypted or parsed
This suggests that OpenAI Responses encrypted context is upstream-account / organization bound and cannot safely be load-balanced across accounts once a session has state.
Suggested fix
Add OpenAI Responses session affinity for encrypted-context requests.
Possible approach:
-
Derive a stable sticky key from available Responses / Codex request signals, such as:
session_id headerconversation_idprevious_response_id- Codex client request metadata
- request metadata / encrypted context presence where available
-
Bind that sticky key to the selected upstream account after the first successful request.
-
On subsequent requests, prefer the bound upstream account unless it is unavailable.
-
Avoid cross-account fallback for errors that indicate invalid encrypted content, because another upstream account is unlikely to decrypt the same context.
Notes
The codebase already appears to have sticky-session concepts for some gateway paths. The missing behavior seems to be specifically around OpenAI Responses / Codex encrypted-context continuity in multi-account OpenAI groups.
Problem
When Sub2API is used as an OpenAI-compatible relay with multiple upstream OpenAI accounts in the same group, Codex / OpenAI Responses API sessions can fail after a session is resumed.
The client retries
POST /responses, but some retries are routed to a different upstream OpenAI account than the account that produced the previous encrypted context. The upstream OpenAI API then rejects the request with an error like:Sub2API surfaces this to the client as a
502 Bad Gateway, so Codex Desktop shows repeated reconnect attempts.Expected behavior
For OpenAI Responses API / Codex requests that carry encrypted context, the same logical session should remain pinned to the same upstream OpenAI account.
Actual behavior
Requests from the same restored Codex session can be routed across different upstream accounts in the same Sub2API group.
When the request is routed to the upstream account that can decrypt the context, it succeeds. When it is routed to another upstream account, upstream returns
400for invalid / unverifiable encrypted content, and the relay returns502to the client.Evidence from a production incident
An anonymized production trace showed:
POST /responses400502This suggests that OpenAI Responses encrypted context is upstream-account / organization bound and cannot safely be load-balanced across accounts once a session has state.
Suggested fix
Add OpenAI Responses session affinity for encrypted-context requests.
Possible approach:
Derive a stable sticky key from available Responses / Codex request signals, such as:
session_idheaderconversation_idprevious_response_idBind that sticky key to the selected upstream account after the first successful request.
On subsequent requests, prefer the bound upstream account unless it is unavailable.
Avoid cross-account fallback for errors that indicate invalid encrypted content, because another upstream account is unlikely to decrypt the same context.
Notes
The codebase already appears to have sticky-session concepts for some gateway paths. The missing behavior seems to be specifically around OpenAI Responses / Codex encrypted-context continuity in multi-account OpenAI groups.