Prepare Agent Router for Codex
Enterprise Tier
OpenAI's Codex CLI sends its model calls to the Responses API, and for newer models in a compact form called Responses Lite. Tetrate Agent Router serves both from data plane 0.7.0, to OpenAI and Azure OpenAI. Four things are set up on the administrator side before Codex works for developers.
Developers configure their own side separately, in Codex CLI. Nothing on the Agent Router side, and no flag on tetrate agentrouter integrate codex, turns Lite on or off: Codex decides per model. What the format is and how the gateway handles it is covered in Codex Responses Lite requests.
1. Run data plane 0.7.0 or later
Codex sends Lite requests for gpt-6-sol, gpt-6-luna, gpt-6-astra, gpt-6.1-sol, and the gpt-5.6 models (as of codex-cli 0.160.1). A data plane before 0.7.0 rejects these requests, and Codex reports an error that contains:
cannot unmarshal unknown input type: additional_tools
The data plane's release is in the Version column of the data plane list under Directory → Data Planes in the Admin Console. A data plane below 0.7.0 is upgraded as described in Upgrade the data plane. Older models, gpt-5.5 and before, are sent as standard Responses requests and work on earlier data planes too.
2. Serve Codex models from OpenAI or Azure OpenAI
Codex uses the Responses API, which the gateway routes to OpenAI and Azure OpenAI only. Enable an OpenAI or Azure OpenAI provider in the organization catalog and on the project the developers use, as described in Add providers and models to a project.
An Azure OpenAI provider needs a dated API version. Set the provider's API version to a dated release such as 2025-04-01-preview. With preview, Azure answers Codex's requests with 404 and Resource not found.
3. Enable the models developers send, and assign them to the project
Codex has its own built-in list of models. It does not read /v1/models from the gateway, so the models it offers and the models enabled in Agent Router are two separate lists. Enable the ones the developers pick, and assign them to their project. A model that is not enabled, or not assigned to the project, is rejected with 400 (model_not_found).
Whether a request is sent as Lite follows the model name Codex sends, matched against Codex's catalog by prefix. A catalog model named gpt-6-sol or gpt-6-sol-<suffix> receives Lite requests.
4. Keep fallback chains for Lite models to Lite models
A fallback chain for a model that receives Lite requests lists only models that accept them. The provider rejects a Lite request sent to any other model: gpt-5.5 returns 400 for the Lite header, and Azure OpenAI gpt-5.2 rejects the Lite body. A hop to such a model fails the request instead of rescuing it. Every hop also stays on OpenAI or Azure OpenAI, as for any Responses request. Chains are managed in Manage fallback policies in the Admin Console.
Checking it works
Ask a developer for one Codex prompt on a Lite model, then open Request Logs in the Console. The request appears as a /v1/responses request with the provider's token counts and cost, the same as any Responses request. Guardrails inspect the user message and the developer messages, which is where Lite places Codex's instructions.
| Symptom | Cause | Fix |
|---|---|---|
cannot unmarshal unknown input type: additional_tools | The data plane is older than 0.7.0. | Upgrade the data plane (step 1). |
404 with Resource not found from Azure OpenAI | The provider's API version is preview. | Set a dated API version (step 2). |
400 with This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite. | A fallback hop resolved to a model without Lite support. | Keep the chain to Lite models (step 4). |
400 with model_not_found | The model is not enabled or not assigned to the project. | Enable and assign the model (step 3). |
Where to go next