Pointing Cursor at your own OpenAI-compatible endpoint comes down to three things that have to match: the endpoint address, including the /v1 path; a key the endpoint accepts; and model IDs that exist on that endpoint. The configuration itself is small, and almost every failure after it is one of those three coming up misaligned. This guide covers the Cursor-specific setup, what running alongside a subscription actually changes, a triage table for the usual errors, and a five-item verification pass that settles most doubts before you file anything.
Three things that have to match
Start by writing the three values down, because most of this article is about them drifting apart.
The endpoint. For String AI it is https://www.string.ink/v1. The /v1 suffix is part of the address, and both adding it where it does not belong or dropping it where it does are classic 404 generators. When one shows up, this string is the first thing to read out loud against the value in the settings field, character for character.
The key. A platform key from your account page. Keep all key material out of screenshots and chats; the only placeholder this guide uses is YOUR_API_KEY style text you replace locally.
The model IDs. Whatever you type as a model name has to exist on the endpoint right now, not in your memory of it. The platform's model list endpoint, GET /v1/models, is the live inventory, and the documentation's examples include IDs such as gpt-6-astra, gpt-5.6-luna, and claude-opus-4-8.
Cursor is one of several tools that take this same treatment; if you want the multi-tool overview first, the one key across coding tools guide covers the shared model, and this article stays on Cursor alone.
Cursor setup: API key settings and the Override OpenAI Base URL
Cursor keeps its credentials in the editor's model settings. The platform's documentation walks through the Cursor flow at field level: open the settings icon in the bottom-left corner, choose Models in the sidebar, expand the API Keys section, and put your key in the OpenAI API Key field. Then turn on the Override OpenAI Base URL toggle and enter https://www.string.ink/v1 in the field below it. Once saved, the endpoint's models become available inside Cursor.
If this is your first custom API key setup in Cursor, a few mechanics from Cursor's own Bring your own API key page are worth knowing before you judge the result. Custom keys apply to chat models; Tab completion keeps using Cursor's built-in models regardless. If a key is invalid or rejected by the provider, requests using that provider fail until you update or remove the key, so a failed test is itself a data point. And the key is not stored on Cursor's servers: requests are routed through Cursor's infrastructure for prompt building, with the key transmitted per request. One practical consequence of that routing model is worth internalizing early, since it explains several confusing symptoms: your endpoint must be reachable from the public internet, not just from your machine. A hosted platform endpoint like String AI's satisfies that by construction; a laptop-local server will not, unless you tunnel it.
After saving, test in a new chat rather than reusing an old conversation, and if the first attempt still behaves like the previous setup, restart the editor once before you start changing values again. Fresh sessions read configuration most reliably; that habit costs seconds and saves a whole round of misdirected debugging.
Running alongside a Cursor subscription
Bringing your own endpoint does not require abandoning Cursor's subscription, and the two coexist with a few constraints you should understand rather than discover.
The subscription side continues to provide the product-layer experience and Cursor's own model catalog. The endpoint side provides model choice beyond that catalog, usage that lands on your own account with your platform, and configuration you can keep identical across a team. What changes in practice: only chat models use your key, Tab stays on built-in models, and some plan-level metering may still recognize requests made with your own key, depending on plan, so check the official page for your plan's relationship between custom keys and included allowances. One more boundary stated plainly on that page: Cursor's zero data retention policy does not apply when you use your own keys; data handling follows the provider you configured. Enterprise teams can also restrict personal API keys entirely from the team dashboard, so a setting that works on one account may be administratively absent on another.
The friction to watch for is neither side being wrong, but priority confusion when several configurations coexist: a subscription login, a provider key, and an endpoint override all present at once. Treat the coexistence as a set of switches to keep track of rather than a contest; each switch has a job, and your job is knowing which one is on. Keep one source of truth per machine, note which one is active where, and when you later rotate the key or move the whole setup elsewhere, keep the provider switching walkthrough next to this one.
Error triage: from 401 to model not found
The errors below cover almost every first-day failure. Read the symptom, check the layer, apply the fix.
| Symptom | Layer | Fix |
| --- | --- | --- |
| 401 unauthorized | Key | Re-copy the full key from the account page into the OpenAI API Key field; confirm you edited the field you think you did; a revoked or truncated key fails exactly this way |
| 404 not found on every request | Path | The base URL must be https://www.string.ink/v1 with the /v1 path intact; verify the exact string you pasted before touching anything else |
| Cursor reports the model was not found | Model | Your model name does not match the endpoint's live IDs; run GET /v1/models and copy the name exactly; Cursor's own available models page also defines what "model not available" means in its catalog |
| Connection refused or timeouts | Network | The endpoint must be publicly reachable from Cursor's servers; check corporate egress rules and proxies, and note that providers can block regions even when your key is valid, as Cursor's regions reference describes |
| Requests work but some behaviors differ | Protocol | Streaming and tool-calling differences between clients and endpoints are a known class of mismatch; run the compatibility checklist against the endpoint before blaming Cursor |
One meta-rule over all rows: change one field at a time. The table works because each layer fails with a distinct signature, and that signature only stays readable if you have not changed three things since the last test. Write down which single field you changed and what the symptoms were; a 404 after a base URL edit and a 404 with no recent edits are different stories even though they look identical.
A five-item verification pass
After any change, do these in order. Each item isolates one layer, so a failure tells you where to look.
- List the models. Call
GET /v1/modelsfrom a terminal with your key and confirm the ID you plan to use is present and spelled exactly as the endpoint reports it. - Make one minimal call. Send a single small chat completion from the terminal, the same discipline as the five-step quickstart, and confirm a response comes back with your key and endpoint.
- Return to Cursor. Start a new chat, select the model, and send a real request. If step two succeeded and this fails, the problem is in the editor configuration, not the endpoint; if both fail, it is the endpoint or key.
- Check where the usage landed. Confirm the request shows up in your platform's usage records under your account and key, so you know nothing is silently going through someone else's credential.
- Snapshot the configuration. Record which fields you changed and what they now hold, minus the secret itself. That snapshot is what makes the next change a rollback instead of a rebuild.
Terminal first, editor second is the ordering that halves debugging time: it splits every failure into "before the editor" and "inside the editor" before you spend any effort inside either.
Where to go next
- Choosing what to put behind the setup. Choosing a model by constraint is the decision framework for the model-name step above.
- Already connected? The pillar guide, the quickstart, and the checklist linked above cover the full arc from first call to a verified setup.
Match the three values first, verify in the terminal, and let the editor be the last mile rather than the first suspect.