Cursor & DeepSeek

Feature Requests
1

Hey everyone,

I think it’s important to address something critical here.

Cursor’s primary revenue comes from subscriptions, and the current pricing model—offering 500 messages for $20—is justified by the high costs of using Claude Sonnet and OpenAI APIs. However, DeepSeek has completely disrupted the landscape for companies like OpenAI, Anthropic, and even Cursor and Codeium.

Now, Cursor faces a decision: will they implement a separate token system for DeepSeek? For example, offering 500 calls for Sonnet and O1, but 3000 calls for DeepSeek R1? If they ignore this, users will quickly realize they can get a better service at a much lower cost, even with token-heavy code extensions.

The days of expensive AI are over. Local LLMs like Qwen 32GB with Deepseek R1 distilled versions are already outperforming Sonnet in benchmarks, and this is just the beginning. DeepSeek is changing the game, and companies need to adapt to survive.

So, Cursor, it’s your move. Make the right decision. The future is here, and it’s cost-effective.

Cheers,
A guy from the future

75 Likes
2

I think you are underestimating the costs of running DeepSeek at scale.

Reserving enough compute to satisfy peak demand is much more expensive than you might think. To the point where—with current compute constraints—it can actually be more expensive to run DeekSeek vs proprietary APIs.

Further, the value proposition of Cursor far extends API requests. Anyone can access these APIs at cost, or run these models locally, for whatever those APIs cost them.

The value proposition for Cursor is that this is all embedded within an IDE, allowing you to seamlessly interact with your code base. This offers extensive productivity benefits to the user outside of making the API requests themselves or flip-flopping between chat windows at ChatGPT/Claude.

And that doesn’t even consider the composer, which literally transforms these API requests into changes in your code base.

To date the Cursor team have shown a commitment to keeping their product competitively priced, and as these models become more efficient and cost-effective to run at scale, will continue to ensure paying users are getting far more value than the subscription price.

28 Likes
3

I completely understand your perspective. While 3,000 calls might be excessive, I agree with @time_traveler that 500 is too restrictive 1,000 seems like a reasonable compromise, though your team should decide based on usage patterns. Striking a balance is crucial. For example, I recently introduced friends to the platform, and they hit the limit almost immediately. New users, especially those experimenting for the first time, often send short prompts (simple queries or brief code snippets) rather than lengthy requests.

Additionally, if I recall correctly, the trial limit was previously 500 calls. Reducing it to 50 now feels counterintuitive beginners trying basic programming tasks or asking simple questions (like those a child might explore) burn through the quota too quickly. This could discourage experimentation, which is vital for new users.

Deepseek solve that issue , the limits, the cost, your margins.

10 Likes
4

Thanks for the thoughtful reply! You raise valid points about scaling costs and Cursor’s IDE integration value.

The goal isn’t just API economics—it’s keeping users inside Cursor. Not to hit our 500 Claude/ChatGpt calls, we tend to switch to free/cheaper tools for boilerplate/docs and simple tasks. This forces us to lose the Cursor’s IDE magic. A mid-tier (e.g., 3,000 DeepSeek/Qwen32b-R1 calls) keeps us engaged while reserving pricier models for harder tasks.

Your composer already saves tokens by bundling edits (vs competitors’ 5x context bloat). Pair this with cheaper models for non-critical work—users stay loyal because you’re the only IDE offering bothefficiency and cost control.

It’s true that testing DeepSeek in a workflow optimized for Claude/GPT (temperature, token limits, etc.) might make it seem inferior. But in a direct chat setting (no optimization), it’s nearly identical—and sometimes better. This suggests that with minimal tuning, Cursor’s composer could achieve similar parity.

Benchmarks: Qwen2-32B R1 distilled version beats Claude Sonnet in some benchmarks. DeepSeek-R1 achieves performance comparable to OpenAI-o1 across reasoning tasks.
OpenAI’s “Frontier Math” benchmark-gaming proves they’re scared. Ignoring this race risks Cursor looking out of touch.

The “Netflix vs password-sharing” analogy is real. Developers will hack local LLMs into their workflow if Cursor feels restrictive. Proactive tiering turns a threat into retention leverage.

A mid-tier system (500 Claude/GPT calls vs. 3,000 DeepSeek/Qwen-R1 calls) could include a big fat warning that premium models perform better for the composer. This lets users choose cost-effectiveness for non-critical tasks while reserving pricier models for complex workflows.

The mid-tier isn’t just about DeepSeek—it’s about future-proofing. Each month, open-source coding models close the gap. By embracing this now, Cursor can lead the market rather than play catch-up.

7 Likes
5

You both raise good points. And I agree offering more dynamic pricing models in future whereby you split requests into premium/mid-tier is a viable option. And will become increasingly viable in future as mid-tier models get more intelligent and cost-effective.

In the very near-term though—ballpark it at 2-6 months—I don’t think the mid-tier models are cost-effective and intelligent enough (multi-optimisation problem) for this to be viable.

The other thing to consider is that while developers can appreciate and understand this kind of granular usage-based pricing, an increasing number of users are using Cursor without much experience in LLMs.

To them, the pricing model is already confusing. Adding increased complexity could be a turn-off for this growing subset of users.

To synthesise: something to consider in the near-medium term as costs come down; need to balance flexibility with complexity.

6 Likes
6

I would love to have option that user can select if the they don’t mind using direct API call to deepseek server (using our own API key) because currently they are more stable and faster than cursor self-hosted.

2 Likes
7

They don’t use their own, they use fireworks as a provider (I guess they have concern about using deepseek api).

Deepseek R1 is performing much better than sonnet 3.5 so far, I have been playing with it and it’s great. I switch back to sonnet and it feel dumb compared to it. I think deepseek R1 is the new king for coding.

3 Likes
8

if they make any money off the 40% requests they need to seriously reconsider that

I just blew through $20 of fast o1 and got almsot nothing done

but deepseek is doing it better for free

or am i just idk singularity

9

Deepseek could solve something else, which is Claude 1022 getting unbearably lazy. When using it through Claude.ai I notice it a little bit, but through Cursor it somehow seems to compound or something, I really can’t take it anymore. I just cancelled my subscription.

One of the issue with R1 may be it’s limited token window.

Google just quietly released their latest reasoning model 2-3 days ago, with a 1 mil context window, and gemini is usually more affordable too.

10

youre using R1 in chat or composer?

11

I have just come across this thread and I posted something similar: I asked DeepSeek-R1 about Cursor's pricing model

1 Like
12

imho, it should be “near” term…

I have already stopped using Cursor since I hit the 500 queries on the first week of the month; with DeepSeek, I can use Cline or Aider, for a fraction of the price and get similar or better quality…

I’m willing to pay Cursor for the value it brings (the features), but I’m not a fan at all of this 500 queries per month… I think sooner or later, it’ll be beaten anyway by open source tools who will keep getting better and catch up at some point… I believe the value of Cursor should be the features, not “acting as a forward-pass of LLM requests”… but again, it’s just my humble opinion…

2 Likes
13

I’m a retired mathematician, retooling to use AI to support my research. New to the party, I’m not finding the advice I need to extend AI’s reach, so I’m making many experiments. Which language is the best choice for parallel code, balancing its ability to shape my thought, the ease which which AI can help (these are related) and runtime efficiency? I’m completing a project which is like a simultaneous chess exhibition, comparing six languages at a time as I evolve a test problem, while at the same time developing project paradigms better suited to AI.

I hoped that this forum would have the most intense futuristic discussions on the web for the “meta” of AI coding. The impression that keeps me away is that all I see here are my younger selves worrying about costs. My best former students are working on startups that in different ways improve focus in such conversations, exactly as we need to learn to improve AI focus in coding sessions. My AI nut is projected to be 6x Cursor Pro, Pro Ultimate for (the-editor-formerly-known-as-Prince), and several direct subscriptions for standalone AI. One could say this is out of hand, but sports fanatics have similar cable bills. My primary concern is achieving my dreams before my father’s dementia arrives. AI has upended my expectations. It’s as if alien ratings were falling for my sluggish loser existence, so the writers had my simulation jump the shark.

Claude 3.5 Sonnet understands my math best; it can understand my iPad drawings, consult effectively on strategies for combinatorial enumeration,…so I work in Cursor with Sonnet because I need to involve a brilliant “cook”. I would never ask my chef to clean the bathroom, so I’m over in “Prince” for housekeeping chores. One experiment I repeat is using Sonnet to coauthor detailed prompts for utility tools, then experimenting everywhere to see which AIs can one-shot the code from the prompt. Have that AI review what might have helped, evolve the prompt, try again…

When I can’t sleep I’m listening to Nexus: A Brief History of Information Networks from the Stone Age to AI by Yuval Noah Harari, his most recent book in the controversial “mind bender” genre. Such excursions may be of debatable utility for developing human thought, but unfettered “meta” is how we shamans control the dance of the campfire flames, working with AI. When I taught linear algebra to college students, I was witnessing the pack rearrange itself mid-marathon. Students who believed intelligence was innate used their usual tricks for crushing college, and fell behind. Students who saw intelligence as a malleable training effect spent half their time in meta-contortions inventing new ways to learn, and surged ahead. They became mathematicians.

AI rewards this. It’s like ice sailing, there’s no limiting speed, it’s all on us. As an association engine of inconceivable scope, AI is better at these meta-contortions than writing code. Then, with better architecture, we both accelerate. And everyone’s experience is personal, as if AI was a form of digital hallucinogen. What works for me may not work for you.

I was pretty excited by the recent buzz for Deepseek r1. One has to be careful interpretting public benchmarks. When nations devise tax codes, or structure financial markets, a primary concern is how players will evolve to game the rules. If I thought for a moment that math was what I see in these math challenges, or intelligence is doing well at intelligence tests, I’d go paint houses. It’s like art: Most art is boring decoration, but great art shatters paradigms. Can AI help to shatter paradigms? So I run my own experiments.

The one language I’ve tried that chokes every AI is Lean 4. It’s the one language I know that is achieving escape velocity: Its type system supports formal proof verification, and mathematicians are slowly using it to encode all of mathematics. This confuses people and AI assistants who conclude that Lean 4 is a proof assistant. It’s a cleaner, more fluid Haskell for general programming, that has broken the earth’s gravity in ways that facilitate for example formal proof. And AI can’t understand it! AI can write Lean 4 code, but it can’t get the code to work.

Deepseek r1 got further than any other AI at writing Lean 4 code; my test problem runs, but crashes at the scales I want to benchmark. I don’t understand Lean 4 well enough yet to help, but that didn’t stop me in any other language, where general fluency sufficed.

On the other hand, Deepseek r1 flunked my course, iteratively writing a support tool from an evolving prompt document. This experiment was inspired by the Nexus discussion of documents. Both Sonnet and “Prince” could one-shot the code in fresh sessions, after a round or two of prompt tuning. Deepseek couldn’t complete the assignment.

And I find following Deepseek’s interior monologue tedious. One can only watch so much Popeye. (Yeah, I know. I resemble that remark.)

8 Likes
14

I have no idea how you guys (who are pro devs of course) can spend 500 requests “almost immediately”. It could be if you request one very tiny thing from llm with a single request, but it is not the Cursor’s problem. I work with cursor every day professionally and it is “good” if I reach 300-400 monthly requests.
My rules to optimize it: compose as many questions/changes as possible in a single request BUT ask about a single feature you want to create/improve; no ‘codebase-wide’ requests to improve the whole project because you’ll spend your request for nothing; make your own ‘rules for AI’ that adds your context to AI and rules what output you want.
Ans yes, deepseek r1 is like a new breath of air - it does what sonnet cannot nowadays - produces a working result almost from a first go. Love it.

2 Likes
16

The cost is too high based solely on how many queries it takes to get it to “not do something I have explicitly asked it not to do.”

1 Like
17

Is anyone successfully using R1 in composer or does it only work in chat? I don’t see how can can not work in composer since it has so much more utility.

18

Chat, I’m not a fan of the composer. It goes too quick for me.

19

image
image854×1018 80.7 KB

why am i paying for repeat responses that waste hours of my time?
not happy. it fails, often.

any hope of a fix?

thank you

1 Like
20

As someone who has experimented significantly with Cline/Aider and R1, I completely agree with your position. I find I get much better results out of Cursor than other AI coding tools, and think the pricing right now is very reasonable.

With that said, I do think a “mid-tier” being added between premium and free would be very useful when we get another jump in model performance. The thing right now that slows down my workflow the most is manually having to change the model I am using for a request because I don’t want to waste premium calls on a simple task. This takes me out of flow. A mid tier with let’s call it 500 or so calls for cheap open-source/Deepseek-v3/R1 70B distilled would be incredibly nice to keep me in my flow state (especially for ctrl-k changes) so I can keep the flow going and keep my chat/ctrl-k on a single model and not worry about toggling

1 Like
21

I sympathise with the justification for the pricing, but regardless there is market shift that needs to be addressed. You need to renegotiate claude api pricing for your customers because deepseek is just gonna disrupt no matter which way you slice it.

And, 500 requests per month is small. I definitely am on 1000 on a slow month, 2000 is my usual. Its not cheap, ill jump ship the instant i can save that money. I love crusor but im just being honest.

1 Like