Before you report this, we’d appreciate if you can search this forum to see if this issue has already been reported.
If you have done so, please check this box.
on
Describe the Bug
After two successful prompts where the Composer successfully used my Deepseek-V3 API key to create and edit code, I ran into a random issue. Now when I try to run another prompt, we get an error: “The model deepseek-chat does not work with your current plan or api key”. Why this is odd is it worked correctly for two prompts totalling 102k tokens (input + output). Only “deepseek-chat” is the active model; the rest are disabled as per instructions.
Steps to Reproduce
Go to Models in Settings and disable all existing models. Add new model “deepseek-chat”. Enable only this model.
No further information - I upgraded today to Pro to take advantage of custom API keys. Two prompts and 102k tokens later, custom Deepseek model stops working.
Hey, your API keys don’t work in Composer, they only function in Chat. As for the two successful requests, you might have used an existing session with a different model, and when you switched to the DeepSeek model, Composer continued using the previous model.
Thank you. I hear you, but that could not have been the case. Please see attached, I only used Deepseek-V3 with Cursor today. Nowhere else. It looks like 102,346 tokens successfully came through from Cursor. I also looked into my API keys in platform.deepseek.com and it shows today’s date as “Last used”.
Are you saying an existing session allowed these to come through? Why is it Deepseek-v3 keys don’t work in Composer?
Don’t mean to be difficult. I just specifically signed up and paid for one month of Cursor Pro to use Deepseek-V3, so may be looking for a refund if this is not supported.
API keys don’t work in Composer because it’s configured to work with supported models, ensuring the process doesn’t disrupt the code of created applications. By the way, we’ve started testing the DeepSeek model, and if it performs well, we’ll add it to Cursor, so you won’t need to use an API key.
@deanrie Hi, want to ask for any updates on this. I can’t wait to test it, I also face the issue above today. Is there any ETA?
Or is there a nightly build or alpha test version of the cursor, that we also can help to test and give feedback?
We’re currently looking at DeepSeek support internally but can’t offer an ETA on this at this time.
We’re always evaluating new models and we’ll add them to the editor as long as we see noticeable improvement above and beyond the existing models available!
I just used DeepSeek for 2 weeks using just chat functionality. I decided to jump up to the pro version and now it refuses to work. I have found it to be the best option. Why is Cursor choosing to do this?
Yeah I assumed I could plug in a custom openai endpoint, api key and add the model, and use whatever model I wanted to do the coding (testing deepseek-ai/DeepSeek-R1-Distill-Qwen-32B on our dedicated HF inferrence endpoint was my desire)…
However, that turns off the “apply from chat” feature, which is literally the only reason I use cursor. I’m not clear on why ‘apply’ needs a custom model, nor why they can’t just have two keys - one for the custom functions, and another for the main coding model.
It’d be great if they could let you apply an API key / openai endpoint and bind it to a custom coding model. All the core capabilities needed to do that are already in the app.
The T&C’s claim a default position that they don’t use data captured for training, but there’s nothing there that would prevent them from havesting the ‘apply’ generated code, so long as they don’t train with it, which is a bit unnerving.
Also, the interface suggests you’re hitting openai’s standard endpoint, but that might not be the case?
I’m going to wireshark the app later and monitor where it’s talking to, but yeah… really I’m agreeing with the OP… it would be good to see the ability to add any openai endpoint compatible model. Maybe .cursorrules could let you customise the prompt format too.
