Pointing Cursor, [CC], and Codex at a different API endpoint (what actually breaks)

Swapping the model behind a coding tool is usually described as a one-line config change. It is, but only for tools that were built with a provider abstraction in the first place. Here is what differs across the popular ones, and the four things that break in practice.

The common shape

Almost every tool that supports a custom endpoint wants the same three values:

• Base URL — the root that paths like /v1/chat/completions are appended to.
• API key — often any non-empty string, since the gateway does the real authentication.
• Model name — the exact identifier the gateway expects, not the marketing name.

The failures cluster in the details of those three.

Cursor

Cursor's custom API mode lives in Settings, under the OpenAI API section. You set an override base URL and a key, then add models manually by name. Two things trip people up: the model list is not discovered automatically, so a typo in a model identifier looks like an authentication failure; and Cursor sends requests shaped for the OpenAI schema, so a gateway must accept that schema rather than only the native provider format.

[CC]

[CC] reads two environment variables: ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. Set both, then launch normally. The frequent mistake is setting only the base URL and leaving the tool to use its stored login, which takes precedence. Explicitly exporting the token is what makes the override take effect.

Codex CLI

Codex reads a config file (~/.codex/config.toml) with a model provider block. You define a provider with a base_url and env_key, then select it as the active model provider. The env_key names an environment variable rather than holding the secret, so the key never lands in the config file — useful, and a common source of confusion when the variable is unset.

The four things that actually break

1. Trailing slashes and version prefixes. https://host/v1 and https://host are different base URLs. Most tools append /v1/chat/completions themselves, so including /v1 in the base gives you /v1/v1/... and a 404 that looks like an outage.

2. Model identifiers. claude-sonnet-4 is not a universal name. If the gateway expects a namespaced form, the marketing name fails. Check the gateway's model list rather than guessing.

3. Streaming format. A gateway can accept chat completions but emit stream chunks in a slightly different envelope. The tool then hangs waiting for a delta that never arrives, or prints nothing until the response completes. This is the hardest failure to diagnose because the HTTP status is 200.

4. Tool-call schema. Coding agents depend heavily on tool calls. If the gateway translates them imperfectly, the agent loops or silently stops using tools. You notice this as "the agent got dumber," not as an error.

How to test in five minutes

1. Send one non-streaming request with curl to the base URL and confirm a normal JSON completion.
2. Repeat with "stream": true and confirm chunks arrive incrementally rather than all at once.
3. Send one request containing a tool definition and confirm the response has a tool_calls block.
4. Only then wire it into the tool.

Doing those three curls first separates a config problem from a gateway problem before you spend an hour blaming the editor.

Why the base URL matters for pricing too

A gateway is not only a proxy. It decides how you are billed, and that choice is more consequential for coding agents than for chat. Token metering makes the cost of a long agent run knowable only after it finishes. A per-request allowance bounds it by the number of steps you permit.

The gateway I use for this is APIClaw — [OI]-compatible, so the three steps above work unchanged, and priced per request rather than per token. The per-tool setup notes for Cursor, [CC], Codex and about twenty others are in the docs. Whatever gateway you pick, run the three curls before you trust the config.