Use Codex with a custom OpenAI-compatible API

Codex can use an OpenAI-compatible endpoint through environment variables. nexinfer exposes that endpoint at https://api.nexinfer.com/v1.

1. Set the base URL and key

export OPENAI_BASE_URL=https://api.nexinfer.com/v1
export OPENAI_API_KEY=sk-nexinfer-xxxx

Use a key generated in your nexinfer dashboard. Do not commit the key to a repository or paste it into public logs.

2. Run Codex

codex

If Codex reports an authorization or model error, check the key’s assigned group and the current model list in the dashboard.

Use the OpenAI SDK

The same endpoint works with SDK clients that allow a custom base URL:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.nexinfer.com/v1",
    api_key="sk-nexinfer-xxxx",
)

response = client.responses.create(
    model="gpt-5.5",
    input="Reply with OK",
)
print(response.output_text)

gpt-5.5 was observed in recent successful production usage on July 10, 2026. Availability can change, so confirm the current model list before deploying.

Verify the setup before relying on it

A custom provider can pass a basic call and still fail inside Codex. Check these layers in order — each step isolates a different failure mode:

1. Authentication and endpoint. List models with your key:

curl -s https://api.nexinfer.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"

A 401 {"code":"INVALID_API_KEY"} means the key is wrong or inactive; a model list means the endpoint and key work. The gateway accepts the key in the Authorization: Bearer header, x-api-key header, or x-goog-api-key header.

2. A minimal completion. Run the SDK snippet above (or the equivalent curl against /v1/responses). This confirms the model is available to your key’s group.

3. Codex itself. Start codex and run a small task that triggers a tool call. Steps 1–2 passing while step 3 fails usually points to a Codex-side custom-provider issue, not your configuration — see below.

Known Codex issues with custom providers

These are open issues in Codex itself (verified against the official repository on July 18, 2026). They affect any non-ChatGPT provider, including Azure:

• 400 errors from hardcoded model metadata (codex#31882): recent Codex CLI builds compile model metadata into the binary; some models carry ChatGPT-backend-only flags (use_responses_lite, multi_agent_version) that custom providers cannot accept, producing 400 responses such as “only supports function tools”. Workaround from the issue: point model_catalog_json at a local catalog file that disables those flags.
• Model works but metadata does not resolve (codex#32349): a custom model can complete requests while Codex fails to resolve its metadata (model picker, context-window display). Request success and metadata resolution are separate layers — verify both.
• Codex Desktop hides existing Projects/Chats after switching provider (codex#31627): after configuring a custom provider, previously created sessions may disappear from the Desktop UI. No local data is deleted — the history simply becomes inaccessible from the UI; sessions created after the switch display normally. Plan for this before switching a machine with history you care about.

If you hit an error not listed here, compare the raw HTTP response (step 1–2 style curl) against Codex’s behavior to determine which side it comes from before filing a report.

Using Claude Code instead? Follow the Claude Code custom API guide.