GPT-5.6 Luna resolves to a missing internal engine for non-Codex originators using ChatGPT OAuth

What issue are you seeing?

A request to the ChatGPT Codex Responses backend using a valid ChatGPT OAuth credential and the public model slug gpt-5.6-luna fails with:

Codex error: Model not found gpt-5.6-luna-free-1p-codexswic-ev3

The same ChatGPT account can successfully use gpt-5.6-luna through Codex CLI 0.144.1.

The authenticated models endpoint also returns gpt-5.6-luna with supported_in_api: true. Its model metadata specifies:

• minimal_client_version: 0.144.0
• use_responses_lite: true
• visibility: list

The internal model name in the error does not appear anywhere in the client implementation. It appears to be generated by the backend while resolving the public model slug to an internal deployment or engine.

We tested the request identity independently with the same OAuth credential and request payload:

| Originator | Version | Result |
|---|---:|---|
| pi | omitted | Model not found |
| codex_cli_rs | omitted | Model not found |
| pi | 0.144.1 | Model not found |
| codex_cli_rs | 0.144.1 | success |

Additional controlled tests showed:

• Using the official Codex User-Agent alone did not change the result.
• Sending the Responses Lite header alone did not change the result.
• The successful identity/version combination also completed a Responses request containing a function tool definition and returned the expected tool call.
• These identity-header changes were made only to isolate the routing behavior, not as a proposed integration workaround.

This suggests that backend model routing may depend on the combination of originator, version, account plan, and rollout cohort. The cohort selected for the pi originator appears to resolve Luna to an unavailable internal engine.

What steps can reproduce the bug?

1. Authenticate with a ChatGPT account that has access to gpt-5.6-luna.
2. Confirm that the authenticated Codex models endpoint includes gpt-5.6-luna.
3. Send a Responses request to:

``text
https://chatgpt.com/backend-api/codex/responses
``

using:

• model: "gpt-5.6-luna"
• the ChatGPT OAuth bearer token
• the corresponding chatgpt-account-id
• originator: pi
• no version header

1. Observe:

``text
Model not found gpt-5.6-luna-free-1p-codexswic-ev3
``

1. Run the same model with the same account through Codex CLI 0.144.1:

``shell
codex exec --ephemeral --sandbox read-only -m gpt-5.6-luna \
"Reply with exactly: ok"
``

1. Observe that the official CLI request succeeds.

The third-party client used for reproduction is based on @earendil-works/pi-ai. Version 0.80.6 still sends originator: pi and does not send a Codex client version header.

What is the expected behavior?

If the authenticated models endpoint advertises gpt-5.6-luna for an account, the backend should either:

1. accept the model for supported third-party Codex OAuth clients using their own originator and version; or
2. return an explicit unsupported-client or minimum-version error.

It should not resolve the public model slug to a missing internal engine.

It would also help to clarify the supported contract for third-party Codex OAuth clients:

• Should each client send its own originator and semantic version?
• Does an originator need to be registered or enabled server-side for new models?
• Should the authenticated models endpoint filter models based on the requesting originator?
• Is Responses Lite required for model availability, request semantics, or both?

Additional information

A similar internal engine naming pattern was previously exposed during an official Codex backend incident:

• https://github.com/openai/codex/issues/15045

That incident exposed an internal model name ending in 1p-codexswic-ev3, and it was later identified as a brief backend outage. This makes the current Luna error look like a backend deployment-routing failure rather than a client-generated model identifier.

No access tokens, account identifiers, or private request data are included in this report. I can provide sanitized request and response headers or request IDs if needed.