Praxis can sit between Codex and an upstream provider that supports the native OpenAI Responses API. Codex sends Responses requests to Praxis; Praxis rewrites the configured model name, adds effective-model routing metadata, and forwards the request to the selected backend.
The passthrough path preserves request fields such as input, instructions, tools, streaming flags, and function_call_output. Praxis does not run Codex tools or own the tool loop.
An operator deploys Praxis between Codex and an OpenAI-compatible inference provider. Codex uses a client-facing model name, while Praxis rewrites it to the provider’s deployed model name and forwards the native Responses request without changing the rest of the protocol.
Praxis supports two credential patterns:
-
Pass-through authentication
- Codex provides the upstream provider API key.
- Praxis forwards the credential to the provider.
-
Proxy-held authentication
- Codex authenticates to Praxis only.
- Praxis injects the provider credential before forwarding the request.
- The upstream credential remains outside the Codex environment.
An operator wants Codex users to access a managed provider without distributing the provider API key. The operator configures Praxis to inject the upstream credential, while Codex only receives access to the Praxis endpoint.
Codex or curl sends model: "codex-oai-demo" to Praxis. Praxis rewrites the model to $OPENAI_MODEL, forwards the request to OpenAI, and returns the native Responses result. The response exposes x-praxis-ai-effective-model: $OPENAI_MODEL.
An operator wants users to request a stable internal model name while retaining the freedom to change the actual OpenAI deployment. Praxis maps the internal name to the current OpenAI model without requiring client changes.
A streaming /v1/responses request passes through Praxis to OpenAI. Praxis forwards the upstream SSE stream to the client while retaining the native Responses event protocol.
An operator wants Codex and other Responses clients to receive real-time output through Praxis without buffering or converting the provider’s SSE stream.
Codex is configured with a Responses provider whose base URL is Praxis. Codex receives a tool call from the upstream model, executes it locally, sends the resulting function_call_output through Praxis, and receives the final response.
The demo captures Codex JSONL output, the proof-file result, and both Responses requests.
A developer uses Codex through Praxis to complete a coding task. Codex can call its local tools and continue the tool loop normally while Praxis applies model routing and authentication policy in the request path.
A direct /v1/responses request with no model field reaches Praxis. Praxis injects the configured default model before forwarding it to OpenAI.
An operator supports simple or legacy Responses clients that omit a model. Praxis supplies the approved default model so the request can be served without client-specific configuration.
- The upstream must support native /v1/responses.
- The full Codex tool-loop demonstration additionally requires compatible SSE and function-call events.
- Praxis does not translate Responses requests into Chat Completions.
- Live OpenAI runs validate interoperability, not proxy-only latency. Provider inference and network time dominate end-to-end timing.
- Use a scoped, disposable OpenAI project key for live demonstrations.
-
Custom provider configuration is required. Codex must be explicitly pointed at Praxis with model_provider, base_url, and wire_api = "responses". A normal Codex session will continue using its configured OpenAI endpoint.
-
Codex login is not an upstream-provider credential. A ChatGPT/Codex login cannot be reused as a generic credential for another OpenAI- compatible provider. A live upstream needs its own API key, bearer-token command, or headers.
-
Provider configuration cannot live in the project config. Codex ignores model_provider and model_providers in a repository’s .codex/ config.toml. Use user-level Codex config, a named profile, or explicit codex exec -c ... overrides as the demo does.
-
The upstream model must be capable enough for Codex. Codex can send Responses requests to a custom provider, but successful coding-agent behavior depends on the upstream model understanding Codex’s instructions and tool definitions. A generic Responses-compatible model may return text successfully but still fail to use tools correctly.
-
Tool-loop compatibility is the key live risk. Codex advertises local tools and expects compatible streamed function-call events back. Praxis preserves that protocol; it does not make a provider emit valid Codex tool calls.
-
Codex owns execution and safety controls. Praxis does not execute commands, approve actions, enforce Codex sandbox policy, or manage the Codex workspace. Those remain Codex configuration concerns.
-
Only the Responses request path is demonstrated. The feature covers Codex’s /v1/responses traffic. Any additional endpoints or provider- specific behavior Codex may use must be independently routable and supported.
-
Codex upgrades need regression coverage. Praxis preserves unknown request fields, which reduces coupling, but new Codex versions can change request fields, tool schemas, or event expectations. The real Codex E2E test should run against supported Codex releases.
-
Pass-through keys are visible to Praxis. When Codex uses an upstream API key, Praxis receives it. For shared environments, use a dedicated proxy credential and Praxis-side upstream-key injection instead.