I’ve been playing with Claude CLI and it’s just so much faster, the principle reason for this is it does search/replace applies (probably not too dissimilar to aider).
I get that Cursor team have invested a tonne of effort into building a very fast generative apply model, it’s very clever and kudos to the team for doing it – but it’s still janky, error-prone and slow (not to mention expensive to run). It is by far the biggest source of errors (deleting code, adding random stuff) and lag in the workflow – it’s such a blunt instrument. It seems to have a hard limit on files with >4000 lines of code and then updates take literally >5 minutes per apply. The new Cursor CLI is instantaneous and more robust. I feel that Sonnet 3.7* is much better than people realise because the Cursor approach is introducing so many artefacts.
I think the generative apply model idea was a relic from times when the LLMs were too dumb to give succinct code changes.
I have always felt the “better way” was a half-way house where you use language services to perform precision (and program graph-aware) edits on codefiles.
Been thinking along similar lines. It is clear that whether you use omni.x, sonnet.x - they are all “stupid”, consistently. Which points to the Cursor apply model. If I look at the countless hours spent fixing Cursor apply model snafu’s, it’s outweighing the benefit.
I think the key here is productivity, we have taken a major step backwards here. If I think about what I achieved previously with Cursor iterations vs now, there is no comparison. Major reduction in productivity.
Don’t get me wrong, I love Cursor, but it is obfuscating the true value of the new LLMs.
Not sure what the answer is and happy to help in whatever way possible but honestly feel this needs to be addressed.
Aaah, I get it. I have just switched to another product to get a feel. The Cursor model is also a cost reduction layer. Now I get it. In the other product, the costs are racking up quickly. But, I am happy to pay - I am moving forward!
So fundamentally, the cursor model is the source of our collective frustration.
Also tried Claude Code and it is so much better. It is crazy expensive, true, but it gets things done. It keeps much more context and I totally agree about apply model.
It’s a commandline interface based on Claude API with directory content awareness, for discussing and changing code. Works only on Unix OSes: MacOS, Ubuntu / Debian, WSL. Claude Code overview - Anthropic
Could we have best of both worlds? Cursor offers a separate feature: integration of Claude Code into Cursor UI. Pro users only (as a subscription incentive) but could be based on user’s API keys / login initially (and maybe Linux only) to keep it simpler for the Cursor team.
Edit: I mean it as an enhancement (additional feature), not as a replacement of where Cursor is at or where it’s headed.
I have been trying Claude CLI too. Amazingly good. It’s the aider experience, but better.
But it’s just way too expensive for me as a hobby developer. I spent about 15 euros on a single day, while Cursor is about 20 euros a month.
Cursor can do good work when you prompt it decently. You should treat it as your junior programmer who needs good specs. We are often too lazy to write extensive prompts. Think twice before you hit enter and fine-tune the prompt. Good chance there’s a good result on one shot. That thinking time beforehand pays back because you save time of cursing and making corrections afterwards.
Yeah, it’s expensive - but how much is your time worth? If it has the potential to save you hours of work every day not banging your head against a wall – it’s worth it. The point though is why is a simplistic CLI tool dumped by Anthropic as a side project better than Cursor? 90% of the difference is simply their apply model. The Cursor apply model will get stuck in an infinite loop just trying to fix indentation.
Same here. Lost several hours on this last week. I ran a few rounds with Composer to implement some changes, which initially seemed okay. But when reviewing the code before committing, I noticed many functions had been deleted.
Tried salvaging the new working code, but it was nearly impossible… the deletions were random and extensive and everywhere!
Gave it a few more attempts from scratch; Composer (apply-feature) kept deleting code each time.
Eventually gave up after hours wasted. Just frustrating…
A lot. But I just stopped working and want to continue tinkering around as a retiree. Now I have loads of time for development of websites and such in my homelab. I am not going to pay tens of euros per week for hobby projects. When I could connect Claude CLI to DeepSeek or so then it would be less costly. Anyway… I have all the time to copy paste code from the Claude AI web page. Less sophisticated, but way better for my pension
Also not to mention to be very mindful of if you are in thinking or normal mode, and also force it PLAN OUT a plan and say “step by step” and say DO NOT WRITE CODE - these give me extremelyyyyy accurate results almost never breaks if I prime it with these two magic words “think step by step full plan” and “do NOT write any code” - this has literally been my 10x magic go to command
Been having good times with a debugging prompt containing steps, also this entire thread is not aware of LLMs losing context in the mid, ‘context retrieval’ that Cursor does with their trained LLM reduces costs but its also the current best way to get good results, scientific papers like “chain of agents” show how its better to have a reduced context and Cursor does this and much more like git graph, the way forward is not to increase context but to leverage an agentic workflow that could be also trained as a LLM by Cursor and adhere to our rules, for this step we need less costly endpoints, I’m hopeful the team embraces deepseek R1.