404 on /v1/responses in Codex CLI: what wire_api actually means

Q: Would a local proxy that translates Responses API calls into Chat Completions help?

Not for go2llm anymore: /v1/responses already is that adapter, running on go2llm's side, and it's been checked with a live Codex CLI run. For a provider without a Responses API, a proxy could close the gap in principle, but you'd still need to verify tool calls and streaming translate correctly on your own.

Status as of 2026-09-14: this 404 no longer happens on go2llm. POST /v1/responses is published, and a live run of Codex CLI 0.151.0 completed through it: codex exec read a file in a test project, ran tools, and committed a real edit. The working configuration is in Step 0 below. Everything past this box explains the underlying mechanism, and it still holds for any other provider that hasn't published /v1/responses.

Codex CLI returns 404 against a custom provider because it talks to one specific endpoint, /v1/responses, the OpenAI Responses API. Current Codex CLI releases accept exactly one value for wire_api under model_providers: "responses". Set wire_api = "chat" instead, and Codex CLI refuses to start before it sends anything, with the error "no longer supported." A provider that doesn't publish /v1/responses simply can't be reached this way. That much is confirmed by a live request, not a reading of the docs.

Written 2026-09-11.

What the error looks like

With go2llm configured as a custom provider, Codex CLI fails at the routing level: 404 on POST /v1/responses. Before 2026-09-14, go2llm's body for that route looked like this:

{
  "error": {
    "type": "model_not_found",
    "code": "model_not_found",
    "message": "model is not in the published catalog",
    "request_id": "gw_0b74a3e12c9d4f58ae0176b3c82d5e4f"
  }
}

Switching the protocol to Chat Completions instead runs into a second wall, this one inside Codex CLI itself:

# ~/.codex/config.toml
[model_providers.go2llm]
name = "go2llm"
base_url = "https://go2llm.tech/v1"
env_key = "GO2LLM_API_KEY"
wire_api = "chat"   # Codex CLI: "no longer supported"

Two dead ends, not one. wire_api = "responses" used to get a 404 from go2llm. wire_api = "chat" gets rejected by Codex CLI before any request leaves your machine. There was no config-only workaround.

Why it happens

1. Codex CLI hard-requires the Responses API

For custom providers, the model_providers section of ~/.codex/config.toml in current Codex CLI releases accepts only wire_api = "responses". That's the OpenAI Responses API: a distinct protocol from Chat Completions, with its own path, its own request body, and its own stream event format, not a variant of it.

2. Chat mode is switched off inside Codex CLI

wire_api = "chat" gets rejected with "no longer supported" in current Codex CLI releases. That's a decision Codex CLI makes on its own, not a limitation of the provider: even a gateway that's fully compatible with OpenAI Chat Completions can't be reached this way.

3. The provider hadn't published /v1/responses

Hitting /v1/responses on a provider that doesn't publish it lands on a route that doesn't exist, and returns 404. That was go2llm's situation until 2026-09-14: it published POST /v1/messages (Anthropic Messages), POST /v1/chat/completions (OpenAI Chat Completions), and POST /v1/images/generations. Since 2026-09-14, POST /v1/responses is live and was checked with a real Codex CLI run (Step 0 below). Embeddings, image edits, video, and audio still aren't published.

4. This 404 has nothing to do with your key or your balance

Developers usually start debugging by rotating the key, which goes nowhere here. A request to /v1/responses returns 404 for any key, including a valid one, and touches your balance not at all: go2llm reserves cost only once a route and a model both resolve. If the key were the actual problem, you'd see a 401 no-key instead, covered on the 401 page.

5. Changing base_url by itself doesn't fix a missing route

Codex CLI appends /responses to whatever base URL you give it, landing on /responses or /v1/responses. If the route doesn't exist, neither form helps. If it does exist, base_url needs to end in /v1: leave that off and Codex CLI knocks on https://go2llm.tech/responses and gets a 404 anyway.

Fixing it, step by step

Step 0. For go2llm, since 2026-09-14, the fix lives entirely inside Codex CLI's own config:

# ~/.codex/config.toml
[model_providers.go2llm]
name = "go2llm"
base_url = "https://go2llm.tech/v1"
env_key = "GO2LLM_API_KEY"
wire_api = "responses"

Set GO2LLM_API_KEY in the environment and point a profile at go2llm. The steps below remain valid fallbacks for any provider that hasn't shipped a Responses API.

Step 1. Claude Code, confirmed with a live request, native Anthropic Messages protocol. Set the base URL without /v1, because the Anthropic SDK appends it on its own:

export ANTHROPIC_BASE_URL=https://go2llm.tech
export ANTHROPIC_AUTH_TOKEN=YOUR_API_KEY
export ANTHROPIC_MODEL=claude-sonnet-5
claude

Use ANTHROPIC_AUTH_TOKEN, not ANTHROPIC_API_KEY. With a saved Claude Code login on the machine, the latter can lose to it, and the request goes out past go2llm entirely.

Step 2. OpenCode, confirmed with a live request, OpenAI Chat Completions protocol. Configuration in opencode.json:

{
  "provider": {
    "go2llm": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "go2llm",
      "options": { "baseURL": "https://go2llm.tech/v1" },
      "models": { "claude-sonnet-5": {}, "gpt-5.6-sol": {} }
    }
  }
}

opencode run "Refactor the parse_config function" -m go2llm/claude-sonnet-5

Step 3. Any client that lets you set its own base URL. Cline, RooCode, Continue.dev, and Aider all speak OpenAI Chat Completions when the client exposes a base-URL setting. That's according to their own docs; go2llm hasn't run a manual check against any of them. Kilo Code is in the same spot. There's no instruction for Cursor at all: no live test has been run against it, so this page takes no position either way.

Step 4. Prove your client's protocol with one curl call before you configure anything. A 200 here means Chat Completions is healthy on go2llm, and any remaining problem is on the client's side:

curl -s -o /dev/null -w "%{http_code}\n" https://go2llm.tech/v1/chat/completions \
  -H "Authorization: Bearer $GO2LLM_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"gpt-5.6-sol","max_tokens":32,"messages":[{"role":"user","content":"Reply with one word: online"}]}'

Avoiding this in the future

Before wiring any coding agent to a third-party gateway, check which wire protocol it actually speaks, not whether it calls itself "OpenAI-compatible." Chat Completions and the Responses API are different protocols with different paths, so that label alone says nothing about whether a given client will connect. Codex CLI needs responses. OpenCode needs chat. Claude Code speaks Anthropic Messages natively.

For coding agents specifically, budget by usage shape, not by the input price on a rate card. A typical agent session spends roughly a tenth of its tokens on input, a twentieth on output, and the rest on reading cached context back, so the number that actually decides your bill is the cache-read rate, not the headline input rate. Exact per-model numbers live on the pricing page.

go2llm published /v1/responses on 2026-09-14, and Codex CLI has connected directly ever since (Step 0 above). With any other provider, check first whether it has this route at all: a 404 on this page means exactly that it doesn't. The current list of published models is always available without a key: GET https://go2llm.tech/v1/models.

Related errors

401 authentication_error — why Claude Code needs ANTHROPIC_AUTH_TOKEN.
502 and 503: what's actually safe to retry — routing errors you can retry.
The full error reference.

FAQ

Can I get Codex CLI to talk to go2llm with wire_api = "chat"? No, and now you don't need to. Current Codex CLI releases reject wire_api = "chat" with "no longer supported" before a request even goes out. Set wire_api = "responses" instead; go2llm publishes that route.

Would a local proxy that translates Responses API calls into Chat Completions help? Not for go2llm anymore: /v1/responses already is that adapter, running on go2llm's side, and it's been checked with a live Codex CLI run. For a provider without a Responses API, a proxy could close the gap in principle, but you'd still need to verify tool calls and streaming translate correctly on your own.

Which CLI feels closest to Codex CLI to work with? Claude Code: the same "agent in a terminal with repo access" shape, connecting to go2llm through ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN, using the native Anthropic Messages protocol with no conversion step in between.

Does a 404 from Codex CLI cost anything? No. go2llm reserves cost only after a route and a model both resolve, so a 404 never touches the balance. The actual cost of a successful request shows up in usage.cost_usd.

Get a key and make your first request in 3 minutes → go2llm.tech. Registration credits $1 to your balance. Claude Code and OpenCode setup is in the documentation.