What you need before you start
Three things: a DeepSeek platform account with a positive prepaid balance, an API key generated at platform.deepseek.com, and the base URL https://api.deepseek.com. Every tool below speaks the OpenAI chat-completions dialect, so the integration is the same three fields in a different UI: base URL, key, model ID. If a tool asks for an /v1 suffix, use https://api.deepseek.com/v1 — DeepSeek accepts both, but some clients append paths naively and end up calling /v1/v1/chat/completions, which returns 404.
Generating and scoping your API key
In the DeepSeek console, open API keys and create a separate key per tool. Desktop clients such as AnythingLLM and Cursor store keys locally in plain config files, so a shared production key is a bad idea. Name keys after the tool so you can revoke one without breaking the others. DeepSeek is prepaid: when the balance reaches zero the API returns 402 and every client will surface it as a generic connection failure, so check the balance first when several tools break at once.
AnythingLLM setup
- Open Settings → LLM Preference and choose the 'Generic OpenAI' provider (or the native DeepSeek provider if your build lists one).
- Base URL: https://api.deepseek.com/v1 — API key: your DeepSeek key.
- Chat model name: deepseek-chat. Token context window: 64000. Max tokens: 4096 is a safe default.
- Leave the embedding provider on AnythingLLM's built-in model — DeepSeek does not serve an embeddings endpoint, and pointing embeddings at it produces 404s during workspace indexing.
- Save, then send a test message in a fresh workspace. A reply within a few seconds means the wiring is correct.
Open WebUI setup
- Go to Admin Panel → Settings → Connections and add an OpenAI-compatible connection.
- API Base URL: https://api.deepseek.com/v1, API Key: your DeepSeek key, then click the refresh icon to pull the model list.
- You should see deepseek-chat and deepseek-reasoner appear in the model dropdown; if the list stays empty, the key or base URL is wrong.
- Open WebUI streams by default, which works with DeepSeek. If replies arrive all at once instead, a reverse proxy in front of Open WebUI is buffering server-sent events.
Cursor setup
- Cursor Settings → Models → OpenAI API Key → 'Override OpenAI Base URL' and set https://api.deepseek.com/v1.
- Add deepseek-chat as a custom model name and enable it; add deepseek-reasoner separately if you want the reasoning model for hard refactors.
- Click Verify. Cursor validates by calling the models endpoint, so a failure here is almost always a bad key rather than a model-name issue.
- Note that Cursor's proprietary features (Tab completion, Composer indexing) keep using Cursor's own backend — the override only changes chat completions.
deepseek-chat vs deepseek-reasoner: which to select
deepseek-chat is the V3 general-purpose model: fast, cheap, good at routine code edits, refactors, explanations, and tool use. deepseek-reasoner is the R1-series model: it emits an internal chain-of-thought before answering, which raises accuracy on multi-step logic, tricky algorithms, and debugging, at the cost of higher latency and more billed output tokens. In an IDE, keep deepseek-chat as the default and switch to deepseek-reasoner deliberately when a task is genuinely hard. In a RAG tool such as AnythingLLM, deepseek-chat is almost always the right choice because answers are grounded in retrieved context rather than derived from scratch.
Temperature and sampling for R1
DeepSeek recommends a temperature near 0.6 for the reasoner; pushing it to 0 tends to produce repetitive loops in the chain-of-thought, and pushing it above 1.0 destabilizes the reasoning. For deepseek-chat, use 0 to 0.3 for code generation and structured output, 0.7 for prose. Do not send top_p and temperature at very low values simultaneously. Also avoid sending a system prompt that instructs the reasoner to 'think step by step' — it already does, and the extra instruction wastes tokens and can degrade the output.
Verifying the connection from the command line
Before blaming a client, prove the API works: send a POST to https://api.deepseek.com/v1/chat/completions with an Authorization: Bearer header, a model field of deepseek-chat, and a one-message array. A 200 with a completion means the key and network path are fine and the problem is in the tool's configuration. A 401 means a bad or revoked key, 402 means an empty balance, 429 means rate limiting, and 5xx means a provider-side issue you can confirm on the live DeepSeek status dashboard.
Troubleshooting common connection failures
- 404 on chat completions — the base URL already contained /v1 and the client appended another. Drop the suffix.
- 401 Unauthorized — key typo, trailing whitespace, or a key revoked in the console.
- 402 Insufficient balance — DeepSeek is prepaid; top up before debugging anything else.
- 429 Too many requests — concurrency from several tools sharing one key. Split keys and add exponential backoff.
- Timeouts on long prompts — the reasoner can think for a while; raise the client's request timeout to 120 seconds or more.
- Empty model dropdown — the client cannot reach the models endpoint at all, which usually means a proxy, VPN, or corporate firewall between you and api.deepseek.com.
Keeping the setup healthy
Once the integration works, the failure modes shift from configuration to availability. Watch for clustered 5xx responses and sudden latency jumps, which indicate provider-side load rather than a local problem. Keeping a second OpenAI-compatible provider configured in the same tool — one extra saved connection you can switch to — turns a provider outage into a ten-second inconvenience instead of a lost afternoon.