> For the complete documentation index, see [llms.txt](https://docs.otari.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.otari.ai/otari/for-integrators/use-with-codex.md). # Use with Codex Codex can call Otari as a custom model provider over the Responses API. Otari serves `POST /api/v1/responses`. ## Route Codex through Otari Create an Otari API key, then add a provider to `~/.codex/config.toml`: ```toml model_provider = "otari" model = "openai:gpt-5.4" [model_providers.otari] name = "Otari" base_url = "http://localhost:8000/api/v1" wire_api = "responses" env_key = "OTARI_API_KEY" ``` ```bash export OTARI_API_KEY="tk-your-otari-key" codex ``` Codex appends `/responses`, so `base_url` must include `/api/v1`. `model_provider` must select the custom provider; otherwise Codex continues using its built-in OpenAI provider. For otari.ai, change the URL and use an API key from otari.ai: ```toml model_provider = "otari" model = "openai:gpt-5.4" [model_providers.otari] name = "Otari" base_url = "https://api.otari.ai/api/v1" wire_api = "responses" env_key = "OTARI_API_KEY" ``` ```bash export OTARI_API_KEY="" codex ``` The official [Codex configuration reference](https://learn.chatgpt.com/docs/config-file/config-reference) is the source of truth for custom-provider keys and supported options. ## Choosing a model Codex sends the configured model string unchanged. Use a model or named instance served by the Otari deployment. A provider with its own Responses API is called natively. Any other provider is served by translating each request into a chat completion, which refuses a few Responses features Codex may use, such as tool types other than `function`; see [Responses on providers without a Responses API](/otari/for-integrators/api-reference.md#responses-on-providers-without-a-responses-api). Codex works best on a provider with a native Responses API. `GET /api/v1/models` lists the models a key can use, both on otari.ai and on a self-run gateway. ## Model metadata Codex associates context windows, reasoning options, and tool support with exact model slugs. An Otari-prefixed selector may not match Codex's bundled metadata, in which case Codex uses fallback metadata. If exact metadata matters, configure `model_catalog_json` with a catalog built for the same Codex version that consumes it. The schema is owned by Codex and can change between releases; avoid copying a version-specific schema into Otari documentation. See the official configuration reference above. ## Troubleshooting * Confirm `model_provider = "otari"` is set at user level. Codex ignores custom provider selection in project-local configuration. * Include `/api/v1` in `base_url`. * Start a new Codex session after changing provider configuration. * Configure provider credentials and pricing in Otari, not in Codex. * If a request fails with a `400` naming a Responses field, the selected provider is being served through Chat Completions; choose a provider with a native Responses API. ## Import Codex usage without routing Codex can export direct OpenAI usage to Otari over OTLP. This is for sessions that do not already route through Otari. Send it to any Otari gateway. Create a dedicated API key with `exclude_from_budget: true`, then configure the HTTP logs exporter with the full Otari logs path: ```toml [otel] environment = "otari" log_user_prompt = false exporter = { otlp-http = { endpoint = "https://otari.example.com/otlp/v1/logs", protocol = "binary", headers = { "Authorization" = "Bearer tk-your-import-key" } } } ``` `binary` sends protobuf; `json` also works. Otari does not accept OTLP over gRPC. Keeping `log_user_prompt = false` avoids exporting prompt content; Otari does not persist it in either case. Imported events are priced for analytics and never count toward budgets. Do not both route and export one session, or its cost will appear twice. See [Importing external usage](/otari/for-integrators/external-usage.md). ## Related documentation * [Models](/otari/for-operators/models.md) * [Use with a ChatGPT subscription](/otari/for-integrators/chatgpt-subscription.md) * [API reference](/otari/for-integrators/api-reference.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.otari.ai/otari/for-integrators/use-with-codex.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.