Cursor or Claude Code?
by•
I love @Cursor. It's enabled me to build (vibe code) so many web apps, sites, extensions, and little things quickly that 1. bring me joy and 2. help me with work or realize personal projects.
However... I'm seeing a TON of movement around @Claude by Anthropic's Claude Code. I haven't personally tried it but it's apparently insane (and can also be expensive?)
I'm curious. Should I switch? What are you currently using? Or do they both have their own use case. I right now like cursor because I can build directly in a GitHub repo or locally and it helps me learn my way around an IDE.
Looking forward to hearing everyone's thoughts!
19K views
Summarized with AI


Replies
I keep bouncing between both.
Cursor feels better when I want IDE-native flow, easy diff review, and less context switching. Claude Code feels better when I want a stronger agent that can chew through a task in one shot.
The part that surprised me was not quality, it was cost visibility. Once you start using both heavily, it gets weirdly hard to tell which workflow is actually cheaper because the usage is split across apps, terminals, and tabs.
I ended up building a tiny macOS menu bar app called TokenBar because I wanted a live token counter while coding. Not an end of month invoice surprise, just a constant read on what I am burning in real time.
My current take:
- Cursor for iterative IDE work
- Claude Code for bigger agent-style jumps
- Some kind of live usage visibility if you care about margins at all
Curious if anyone else here is actively tracking token usage while comparing them, or just going by feel.
I think the real answer is workflow plus visibility.
Cursor usually feels better to me when I want tighter control inside the IDE.
Claude Code often feels better when I want bigger jumps and I am okay working more from the terminal.
The part I think people underrate is cost visibility. A tool can feel amazing in the moment, but if you cannot tell what a coding session is actually burning while you are in it, your preference gets biased by vibes instead of tradeoffs.
That pain is what pushed me to build a tiny menu bar app for myself so I could see token usage live while working. It changed how I use both tools because I got more intentional about when to stay in Cursor and when to hand a chunk of work to Claude Code.
So for me it is not really Cursor or Claude Code. It is knowing when each one is worth the cost.
I’d split the choice by feedback loop, not by model brand. Cursor is still great when visual diffs, repo navigation, and small edits matter. Claude Code feels better when the task is closer to “plan, modify several files, run checks, iterate.”
The strongest setup for me would be: use Cursor to understand and review, use Claude Code/Codex for bounded execution, and keep tests as the handoff between the two.
Honestly been using both for a few months now and they serve pretty different workflows. Cursor is great when you're actively in the codebase and want that back-and-forth inside your IDE, it keeps you oriented. Claude Code is a different beast though, you kind of give it a bigger task and step back, which takes some getting used to but pays off on larger refactors.
For someone who's still getting comfortable with the IDE side of things, I'd stick with Cursor and just try Claude Code on a branch for a contained task. The cost can sneak up fast if you're not paying attention to what you're throwing at it.
Been mostly on Claude Code for terminal-heavy work and bigger refactors; Cursor still wins for quick in-file edits with visible diffs. Honestly I bounce between them depending on the task.
SlimSnap
Funny that half this thread is "same underlying model, so why is the output so different." That's the tell that the editor matters less than what you feed it. Manu's point about too much context killing accuracy is the same thing from the other side.
For UI work specifically, Cursor and Claude Code fail the same way: hand either one a screenshot of a busy screen and it guesses which element you meant, then edits a neighbor. The fix isn't the tool, it's not making it guess. Mark the one element, say what should change in a sentence, and the gap between the two shrinks a lot. Most of the "this one's smarter" difference I've seen is really "I gave this one less to guess about."
Most teams running both end up using Cursor for tight in-codebase edits where IDE context loads fast, and Claude Code when the task spans 5+ files or runs over hours; Cursor's own Series C post (https://www.cursor.com/blog/series-c) confirms tab-completion dominates billable usage which is the in-IDE side of the split. Are you mostly editing within one file at a time, or routinely fanning out across many?
I like the focus on turning product feedback into a concrete workflow instead of another dashboard. Curious how you separate noisy social signals from issues a maker should actually prioritize next?
Loomal
Both in my stack depending on the task:
Claude Code when I want the agent to work autonomously over a longer session — it maintains context better and makes more coherent decisions across files. Cursor when I want to stay in the driver's seat and use AI for targeted suggestions rather than wholesale generation.
The more interesting question for me: what happens when you run either of them truly autonomously — not in a supervised session? That's where I've hit the real gaps, and they're not in code generation quality. They're in the surrounding infrastructure: the agent needs a way to receive notifications, store secrets safely across runs, authenticate to external services mid-task. Neither tool has a good answer for the unattended-agent scenario yet.
Anyone running either in fully autonomous pipelines (not just interactive sessions)? Curious what infra you're stitching together around them.
I’d treat them less as replacements and more as different control surfaces. Cursor is still great when I want to stay close to the diff and understand the code path. Claude Code feels better for a bounded task with a clear acceptance test. The workflow matters more than the model choice: small scope, commit before handoff, then verify the result yourself.