How to Use DeepSeek in Cursor (Agent Mode)

Cursor lets you bring your own model key, and DeepSeek ships an OpenAI-compatible API, so on paper the two snap together: point Cursor at https://api.deepseek.com, paste your key, name the model deepseek-v4-pro. The honest catch is agent mode. Cursor's own docs say custom API keys work with chat models only, and its proprietary agent/Composer models are a separate lane — so what actually runs in Agent when you switch to DeepSeek is the part worth getting right. This guide gives you the verified setup, marks the community-only details as unverified, notes what to expect in agent mode, and shows the gateway alternative that hands Cursor one OpenAI-compatible endpoint for DeepSeek and everything else.

Can you use DeepSeek in Cursor?

Yes for chat — with a caveat for agent mode. Cursor supports bringing your own model key, and DeepSeek publishes an OpenAI-compatible API, so you can wire DeepSeek into Cursor's chat in a few minutes. The important nuance up front, straight from Cursor's documentation:

• Custom keys drive chat models only. Cursor states plainly that "custom API keys only work with chat models. Tab completion continues using Cursor's built-in models." So DeepSeek can answer in the chat pane, but it will not take over Tab autocomplete.
• Agent mode is a separate lane. Cursor's agent/Composer features run on its own proprietary models. Whether a bring-your-own DeepSeek key drives the full agent loop is not documented officially — so treat it as something to test on your own account (see the agent-mode section).

If your goal is simply "use DeepSeek for coding help inside Cursor," the setup below does that. If your goal is specifically the autonomous agent, read the caveat first.

Add DeepSeek as a custom model in Cursor

The verified path is Cursor Settings → Models, then paste and verify your key. Cursor's official flow for a bring-your-own key is short:

1. Open Cursor Settings → Models.
2. Select your provider and paste your API key into the text field.
3. Click Verify to confirm the key works.
4. Click Save.

That four-step flow — Settings → Models → paste key → Verify → Save — is documented on Cursor's official API keys help page.

Working generically within the model-provider settings, you supply three things: the base URL, the model name, and the API key. DeepSeek's values:

# DeepSeek — OpenAI-compatible endpoint
Base URL:    https://api.deepseek.com
Model name:  deepseek-v4-pro   # or deepseek-v4-flash
API key:     sk-...your DeepSeek key...

Enter those in the custom-model / base-URL fields, paste the key, run Verify, then Save. Cursor sends the OpenAI-shaped request to DeepSeek, and DeepSeek answers in the chat pane.

DeepSeek base URL and model ids

Use https://api.deepseek.com and a current deepseek-v4-* id — the old aliases are on a sunset clock. DeepSeek's own docs pass base_url="https://api.deepseek.com" and model="deepseek-v4-pro" in their getting-started example. The full picture:

The two legacy ids — deepseek-chat and deepseek-reasoner — still resolve but are deprecated with a stated sunset date of 2026/07/24. Since that date is essentially now, prefer the deepseek-v4-pro / deepseek-v4-flash ids and verify in DeepSeek's API docs whether the aliases are still live for your account before relying on them.

What works in agent mode

Chat answers will run on DeepSeek; the autonomous agent loop is the uncertain part — and Cursor's docs do not promise it. Here is the layered reality, kept honest about what is documented versus reported:

The nuance that trips people up: Cursor's agent (Composer) capability is built around Cursor's own proprietary models, and the official docs only commit to custom keys working with "chat models." They do not say a bring-your-own model will or will not drive the full multi-step agent loop.

On the community side, some users report Cursor's agent/Composer models returning errors such as "this model does not support custom APIs" when a BYOK key is active. That is user-reported on the Cursor forum, not an official limitation — see the forum thread — so do not take it as gospel. The practical takeaway:

• Expect DeepSeek to work in the chat pane reliably (documented).
• Test agent/Composer with your DeepSeek model selected on your own account. Because there is no official commitment, behaviour can differ by Cursor version and change over time — this is the part to date-check against the current app.
• If the agent loop refuses your custom model, fall back to using DeepSeek in chat, or route through a gateway (below) so the request arrives as a standard OpenAI-compatible call.

What Cursor officially supports (and where DeepSeek fits)

Cursor's bring-your-own-key feature names five providers — DeepSeek is not one, so it rides in through OpenAI-compatible custom-model support. Per Cursor's docs, the officially supported key providers are:

• OpenAI — standard, non-reasoning chat models.
• Anthropic — all Claude models via the Anthropic API.
• Google — Gemini models via the Google AI API.
• Azure OpenAI.
• AWS Bedrock.

DeepSeek reaches Cursor by looking like OpenAI — same request shape, different base URL. That is exactly why an OpenAI-compatible endpoint is the universal adapter for tools like this; the same trick works in Aider, Dify and LangChain. If DeepSeek is your target because of price, the cheapest-LLM-API breakdown puts it in context against the field; for the coding angle specifically, see the best coding models of 2026.

Data privacy when you use your own key

A custom key means Cursor's Zero Data Retention no longer applies, and your requests still pass through Cursor's servers. Cursor is explicit: when you use your own API keys, its Zero Data Retention policy does not apply, and data handling follows the privacy policy of your chosen provider — here, DeepSeek. And importantly, API requests are still routed through Cursor's servers even with a custom key. So bringing your own DeepSeek key changes whose retention terms govern the prompt, not whether Cursor is in the request path. If that routing matters for your data-governance posture, weigh it before switching — and confirm current wording on Cursor's API keys page.

The one-key alternative: a gateway Cursor can point at

Because a gateway is just another OpenAI-compatible endpoint, Cursor can point at one URL and reach DeepSeek — plus every other model — on a single key. The per-provider approach means a separate key, base URL and set of caveats for DeepSeek, then again for the next model. A gateway collapses that: you configure one OpenAI-compatible base URL once, and switch models by name.

# DataLLM Lab as Cursor's OpenAI-compatible endpoint
Base URL:    https://www.datallmlab.com/v1
Model name:  deepseek-v4-pro      # or any other model id
API key:     sk-...your DataLLM Lab key...

This is standard OpenAI-compatible configuration, not an official Cursor integration — DataLLM Lab does not claim built-in Cursor support, it simply speaks the protocol Cursor already sends. The upside for a setup like this:

• One key for many models. Try DeepSeek today, a Claude or an open model tomorrow, without re-entering per-provider credentials. Browse the full model list or compare pricing.
• Routing and failover. If a model is unavailable, the request can reroute rather than fail — see routing & failover and what an LLM gateway is.
• Cost control across agents. One place to see spend and swap to a cheaper model — relevant when an agent loop burns tokens, as covered in cutting token costs in coding agents.

The same caveats as any custom model still apply inside Cursor: chat is the documented path, and agent/Composer behaviour is worth verifying on your account.

FAQ