ENGINEERING

Point Cursor at your own OpenAI-compatible gateway

August 2026 · 4 min read

Why point Cursor at your own gateway

This isn't an announcement. It's a settings change most teams running Cursor across more than a couple of developers end up making anyway.

By default, Cursor sends chat and Composer requests straight to the vendor's model backend. That's fine for one person kicking the tires. It gets uncomfortable once a team adopts it: every prompt, every file Cursor pulls into context, and every generated diff leaves your network through a connection you don't operate and can't inspect. Put your own gateway in front of that traffic and you get the same things any AI tool gains from this pattern:

• Data containment. Chat and Composer requests terminate at infrastructure you control before going upstream.
• Predictable cost. One gateway key per developer or team instead of a single shared vendor bill nobody can break down.
• Model swaps without a team-wide config push. Change the upstream model behind the gateway; nobody edits their Cursor settings.
• An audit trail. Requests logged by key, not just "someone with API access called the model."

The compliance case is the one that actually forces the decision. A security reviewer asking where code context and prompts go in transit wants an answer better than "to the vendor, over TLS", they want to know who operates the endpoint, what's logged, and how long it's retained. Routing through your own gateway turns that into an answer you can stand behind instead of one you're hoping nobody asks about too closely.

Step 1: The two settings

Cursor → Settings → Models
  ☑ Override OpenAI Base URL:  https://tokens.4clouders.com/v1
  OpenAI API Key:              sk-your-gateway-key
  + Add model:                 isol-4.9   (custom model name)

Cursor supports this natively, no extension, no wrapper, no forked build. Open Settings → Models, and there are two fields to fill in:

1. Paste your gateway key into the OpenAI API key field.
2. Enable Override OpenAI Base URL and point it at your endpoint, e.g. https://tokens.4clouders.com/v1.

Save, and Cursor's chat and Composer model calls route to that base URL with your gateway key as the bearer credential. The gateway validates the key, signs the real upstream request with the actual vendor credential, and the developer's machine never holds that credential at all. Revoke a leaked gateway key centrally; the vendor credential behind it never needed to change.

What this covers, and what it doesn't

Be precise about scope here, because it matters for anyone doing this for compliance reasons. The base URL override covers chat and Composer/agent model calls, the requests that carry your prompts and code context to a language model. It does not cover Cursor's other proprietary features: codebase indexing and embeddings, and Tab autocomplete both still run through Cursor's own infrastructure regardless of this setting. If full data containment, including indexing and Tab, is a hard requirement, evaluate Cursor's own privacy mode or enterprise controls separately; a base URL override alone won't get you there on its own. For teams whose concern is specifically "where do my chat prompts and generated code go," this setting is the whole answer. For teams whose concern is "nothing about my codebase should reach Cursor's servers in any form," it's a partial one, and worth saying so plainly before anyone signs off on it as a complete control.

Step 2: What the Verify button actually does

Don't take the settings screen's word for it. Ask Cursor's chat a question, then check your gateway's request log for a matching entry, model, timestamp, and token count should line up with what you just asked. If nothing shows up, the override didn't take; double-check the base URL includes the /v1 suffix your gateway expects, and that the key field isn't still holding a vendor key from before the change.

Configuration from Cursor's official documentation, checked 2026-08-04.

Gotchas we hit in production

• The gateway needs an OpenAI-compatible chat completions surface with SSE streaming. Cursor expects /v1/chat/completions semantics; LiteLLM gives you that out of the box, translating to whatever model actually sits upstream.
• List only the models your team is allowed to use. Cursor shows whatever the gateway's model list returns, an unpruned list just invites someone to pick a model with the wrong cost profile.
• Budget per key, not per team. Composer sessions can chain a lot of calls quickly; a hard cap on each key keeps one runaway session from eating everyone else's allocation for the month.

Try it on ours

Our gateway (iSol API) runs exactly this setup on sovereign infrastructure, US$ 99/month, 14-day trial.

See plans →

Step 3: Verify at the gateway, not at the client

Whatever the tool's UI says, the source of truth is the key's ledger, every request lands there with tokens and spend. If nothing shows up, the change didn't take:

curl -s https://tokens.4clouders.com/key/info \
  -H "Authorization: Bearer sk-your-gateway-key" | jq .info.spend

Every session print on this page was captured against the live iSol gateway on 2026-08-19.