I am trying to run DeepSeek on my Cursor IDE because I prefer it over any US-based alternative.
Currently, I am getting a Request ID: e5ba674a-166a-4b2e-a978-2ea613a4098b error for.
I am using the following DeepSeek models, not because I want to, but because you need to have them all so that Cursor will allow one of those models to connect.
Models:
deepseek-chat
deepseek-coder
deepseek-r1
DeepSeek-Coder-v1,5
DeepSeek-Coder-V1
DeepSeek-LLM
DeepSeek-V1
deepseek-v3.1
deepseek-r1-0528
deepseek-v3
Additionally, I do not understand why, when I update the Cursor or just randomly, the Cursor will add AI models that I never requested to be added.
I do pay for Cursor Pro, so I do not understand why these issues are happening.
Hey, this isn’t actually a bug. It’s confusion around the model slugs.
From your list, only these resolve correctly right now:
deepseek-v3.1
deepseek-r1-0528
deepseek-r1
Everything else (deepseek-chat, deepseek-coder, DeepSeek-Coder-v1,5, DeepSeek-Coder-V1, DeepSeek-LLM, DeepSeek-V1, deepseek-v3 without .1) is either old or not a real identifier. They don’t map to any deployed model, so the backend returns 404. That’s exactly what happened with your Request ID e5ba674a-166a-4b2e-a978-2ea613a4098b.
I’d recommend deleting all extra entries and keeping only the three valid slugs above. The error should go away.
About models adding themselves after an update, that’s not a bug. It’s the client updating the default model list, and that’s expected.
To see what models are available out of the box, check Models & Pricing Models & Pricing | Cursor Docs. DeepSeek models used to be in Cursor’s default list, but they were removed due to low usage. You can still add them manually using the slugs above.
If you still see errors after cleaning up the list, send a new Request ID and we’ll take a look.
Hey, thanks for the update and the screenshots. I can see both errors.
For deepseek-r1, my previous advice is outdated. That model was removed during the same deprecation cycle as deepseek-v3 due to low TPM (below 0,015). That’s why the backend now returns Model name is not valid. Please remove this slug from your list, it’s no longer available as a first-party model.
For deepseek-r1-0528, it’s a different issue. The error isn’t model not valid, it’s a Provider Error 500. That means the model resolves, but the request to the provider fails. This could be a temporary provider-side issue, or something related to the deployment.
Right now, the only working first-party DeepSeek model is deepseek-v3.1. If you need the r1 family, the option is BYOK with your own DeepSeek API key, but there are separate limitations around reasoning_content in multi-turn tool calls. This is a known limitation and we’re tracking it.
