Notes on a custom API endpoint in Cursor

Cursor brings AI assistance into a code editor. You can ask it to explain a function, suggest a change, or help investigate an error. Some of that assistance can use an API key you supply. With a custom OpenAI-compatible provider, supported requests go through the provider you configure.

The setup has three main parts: an API key, a base URL, and a model identifier. Each has a separate job. Getting those three values right is usually the most useful place to start.

What an OpenAI-compatible provider does

An API is a way for one application to send a request to another service. In this case, Cursor sends a prompt and relevant context, and the service returns a model's response.

OpenAI-compatible means the service accepts requests in a format used by OpenAI's API. It does not mean every feature, model, or editor integration behaves identically. Cursor still decides which requests can use a custom endpoint.

Vana API provides one endpoint at https://api.vanaapi.com for accessing models from several providers. It also supports Anthropic Messages and Gemini native protocols. For this Cursor setup, the relevant part is its OpenAI-compatible interface.

Gather the connection details

Create a Vana API account to get an API key and the connection details for your first request. Keep the key private: it authorizes usage billed to your account. Avoid putting it in source files, committing it to a repository, or including it in screenshots.

Before opening Cursor's settings, have these values ready:

• API key: the credential issued by your provider.
• OpenAI-compatible base URL: the full address shown in the provider's connection instructions, including any required path.
• Model identifier: the exact API identifier for an available model.

The service address and the base URL are not always interchangeable. A base URL may include a path such as /v1. Copy the documented value rather than guessing or adding a complete chat-completions route.

A model's display name may also differ from its API identifier. If you choose a model such as Gemini 2.5 Flash, copy its identifier from the provider's current model listing.

Enter the details in Cursor

Open Cursor's settings and find the area for models and API keys. Labels can change between releases, but look for the OpenAI API key field and the option to override the OpenAI base URL.

Enter your provider's key, enable the base URL override, and paste the documented OpenAI-compatible base URL. If Cursor offers a verification control, use it. Add the model identifier through the custom model option if it is not already available, then select that model in chat.

Start with a small request in a non-sensitive project. For example, open a short function and ask Cursor to explain its inputs and return value. A simple prompt makes connection problems easier to separate from questions about the code.

Check the provider's usage records after the response. An editor response alone may not establish which service handled the request; a matching usage entry gives you better evidence that the custom connection worked.

Understand the limits and costs

A custom API key does not necessarily power every Cursor feature. Features such as Tab completion may use Cursor's own systems, and some capabilities may require a Cursor plan. Check the current Cursor documentation for the features you intend to use.

Vana API bills per real token with no monthly fee. Your provider charges and any Cursor subscription are separate. Long conversations, attached files, and large code selections can increase the amount of context sent with a request.

If setup fails, check the key, base URL, and model identifier first. An authentication error often points to the key; a model error may indicate an incorrect identifier or unavailable model. For timeouts or unsupported features, check both services' current documentation before changing several settings at once.