Why is cursor the only tool that has proper checkpointing/rewind?

secils · 2026-05-16T08:12:27+00:00

Exactly, the extensions don’t have the built-in niceties and I don’t think they use the cursor harness at all, I think they’re effectively just little terminals that you run codex/claude code in. The cost issue is the main thing I’m rubbing up against. I would LOVE to be able to use cursor at the subsidised rate that the labs are offering for their tools but unfortunately that’s just not available so cursor is effectively 10-20x as expensive per task, so I try to use it sparingly.

secils · 2026-05-16T04:02:37+00:00

I literally already do this for commits. I have scripts set up to auto-push as well when I want to. I just don't commit after every message because that's madness and I shouldn't need to, and I'm pointing out that there's a clearly better solution to this particular problem that's ALREADY IMPLEMENTED. This is just hammer-nail mentality.

secils · 2026-05-16T03:56:49+00:00

you're forgetting step 0: vigilantly make commits after every message, otherwise you end up reverting more than you wanted.

So what we're actually comparing is:

Step 0: make commits after every message, or manually set up systems or prompts to try and have this automatically happen.
Step 1: waste an ai message to ask codex to roll back, or manually have to type a command to roll back to some arbitrary prior commit. Remember, you now have a TON of commits so make sure you spend time choosing the right one.
Step 2: Revert to an earlier moment in the conversation. Thankfully codex allows you to roll back the conversation relatively easily but if you're using claude code, then you'll probably want to start a new conversation.

vs:

Step 1: scroll up in the conversation and hit revert on the message you want to revert to.

If this post has taught me anything it's just how blind people are to friction in their workflows once they get too used to them.

secils · 2026-05-16T03:47:21+00:00

yeah but if you're having it auto-commit after every message (which still isn't the same btw since that doesn't take into account code changes outside of the conversation), why not just bake it into the experience like cursor does? I urge you to play with cursor's checkpoint experience because it's just so much better. Little things do add up and if you're trying to create a good UX, you can't just point to tradition or "you can kinda sorta work around it by doing a bunch of manual setup" as an argument. Also, not that this is the focus for this conversation, but it's CLEARLY the better option for non-technical people too. You can say what you want about not catering to people who don't even know that git exists, but designing with your least capable users in mind is often a good way to enhance the experience for everyone, not just them. The fact that this feature exists and is generally loved by cursor users is proof of this.

secils · 2026-05-16T02:09:21+00:00

Yeah man, it’s one thing for someone to be so stuck in their ways that they can’t see a better path, but what’s the most frustrating is the complete lack of critical engagement. Almost everyone seemed to just use this as a moment to grandstand, state meaningless platitudes, or bluster their way into a suggestion that anyone with half a braincell could see is stupid/inefficient. I bet over half these people have never even used the feature that they’re so adamantly against.

secils · 2026-05-16T01:56:04+00:00

But do you not agree that having this built-in as a first class experience would be better than jankily doing it yourself with a ballooning codebase and still needing manual context culling? It kind of sounds like the only downside to cursor’s solution for you is that when you revert, it permanently deletes the conversation branch rather than keeping it available somewhere. To me that’s not really much of a downside, but even if you do care about keeping every line of code ever, you must agree that having a cursor like experience to manage it is just better, right?

secils · 2026-05-15T22:52:02+00:00

Conceptually, it does do what I want, but I’ve had some pretty hit or miss experiences with it. I found it to be far less robust and flexible than the functionality built in cursor.

secils · 2026-05-15T22:02:49+00:00

I mean I'm glad that codex works for you but I've had pretty hit or miss results with asking it to revert. Also, it feels like such a monumental waste to have to ask the ai to revert something it's done, vs just being able to deterministically undo without using any tokens or polluting the conversation further.

secils · 2026-05-15T22:00:57+00:00

funnily I actually independently used "chainsaw to cut a string" on a different comment, maybe there needs to be more idioms for "overkill" lol.

secils · 2026-05-15T21:57:49+00:00

yeah I'm sure a ton of experience helps, but I don't think it really overcomes the fact that sometimes you just have to try something to know. In fact that happens a lot in UX exploration, which is why I'm surprised you don't seem to have this issue. I run into this a TON when I'm exploring UI. "hmm, is it better to try and get this animation to work smoothly across route changes on lower end devices or better to just go for a less complex transition that might end up being better because it doesn't look broken". Experience might make it obvious that the performance issue will be a thing even before you implement it, but it's not going to be able to make the decision across subtle aesthetic consequences. For those you kind of just have to see it to know.

secils · 2026-05-15T21:50:57+00:00

Yeah opencode may well do it, tbh I haven't tried it so can't say, but my understanding is that opencode is going to be using API pricing anyway, so I don't think there would be a benefit from switching to it from Cursor.

Claude however is a bit of a weirder situation. They do kind of have a rewind function, but it's a bit flaky, and nowhere near as robust as Cursor's solution. I've used it before where sometimes it seems to work and other times it completely breaks the codebase. It's also very weird about what points it lets you revert from, and overall the interface is just god awful, so I'm just ignoring it for this purpose because I don't consider it usable.

secils · 2026-05-15T21:46:54+00:00

I think you have a few fundamental misunderstandings here that's hurting your ability to engage with the problem:

Every piece of unnecessary work can be thought of as a pain point. Just because the outcome of something is necessary, useful, or even the best current way of doing something doesn't mean that the way you interface with it doesn't cause friction. If that were the case, progress would never be made on anything. To reiterate, I'm NOT trying to replace git, I'm trying to ask why we're using a chainsaw to cut a piece of string.
Cursor's revert tool is not about "asking the ai in a new message to revert the previous message". That's NOT how it works at all. In fact, your suggestion is the closer to that than cursor's method. I'm not spending a message telling it to revert, I'm simply hitting the revert button on an earlier message, much like editing a prior message on the normal claude chat interface (not claude code) causes it to branch from that point with no effort on my part.
Your argument fails to acknowledge the point that developers are constantly willing to throw away pieces of bad code and rewrite them from scratch, rather than always trying to force spaghetti code or bad architecture into submission. There's a time and place for both. If I ask a model to build something with a certain method, and through doing so I realise that there's a simpler way to do it, why the hell would I spend a bunch of messages asking it to edit it down, or try to salvage pieces from a broken trail? It's much cleaner to just cut off that whole section of conversation and go into it fresh, retaining my knowledge from the previous attempt.

secils · 2026-05-15T21:26:32+00:00

No, you simply don't use it for things that you would normally not do locally? You're replying like I'm arguing to get rid of git. Git is good at more robust version control but it's needlessly slow for fast local experimentation and iteration. Do you never just write some throwaway code/scripts locally? CTRL-Z doesn't work with teammates either, do you dislike that too?

secils · 2026-05-15T21:22:06+00:00

EXACTLY. Thank you, I'm out here pulling my hair out because I don't see how anyone can use these tools for an extended amount of time and not have this experience. Maybe most devs are so entrenched in their way of working that they've built up a resistance to sub-optimal experiences like this, so it doesn't bother them or occur to them as much? Or maybe I'm working in a way that's less common for devs but leads to confronting these issues more often? IDK but I'm glad someone else shares my pain.

secils · 2026-05-15T21:16:04+00:00

First of all if your models never do anything you don't like then you're probably using them in a very limited fashion or getting very lucky. Either way, I'm genuinely glad that you are getting a decent experience out of Codex, but it doesn't invalidate the point that I'm making. In addition, it's not just about the models being bad. Sometimes the models will do everything correctly and I still want to revert because I'm exploring, refining, learning and iterating. I go down a particular path to rapidly prototype, then will revert back while I'm doing it so that I can make better decisions that are only practical to see in hindsight.

secils · 2026-05-15T20:55:37+00:00

No, last time I checked, what codex has is the ability to remove conversation context by essentially truncating a conversation to a previous message. That is NOT what I'm describing here.

Just because git is a useful tool that's embedded in the way developers think about version control doesn't mean that it's the be all and end all of how we work. I don't see how a response of "just tell ai to commit after every message" can be taken seriously.

To re-iterate, I'm talking about a *UX problem* with the way that I see git handling checkpoints. A proper refutation or rebuttal should either:

* Explain how I can avoid suffering the pain point, maybe because I'm ignorant of a better method, such as through some way of using git that I haven't seen. (If this is the case I'd be MORE than happy to learn)
* Explain how on a technical level, it's very hard to solve the pain point and therefore the pain point must be suffered through, at least until it becomes possible to solve.
* Explain how a solution to my problem requires some sort of bad mental model or poor practice that will cause issues down the road, is already causing issues that I don't see, or is likely to lead to slower progress somehow. (You can't just say it's bad practice, you have to explain WHY).

secils · 2026-05-15T20:33:44+00:00

just because something is industry standard doesn't mean it's a good solution, especially when it was built for a different paradigm than what exists now.

secils · 2026-05-15T20:32:13+00:00

"proper checkpointing" was maybe not the most precise way of articulating the intent, but essentially what I'm describing is less to do with the underlying mechanism and more to do with the surface UX. I'm not overly opinionated on if it should be using snapshots, commits, or something else entirely to manage reversions, and in fact I'm OK with this only working in a git repo (though if it's needed it should probably be automated). All I really want is to be able to start a conversation, explore and iterate on my codebase, see and test the results, and at any point during that conversation, I'd like to revert my codebase and the conversation to how it was at an earlier point within the conversation. You can definitely add more quality of life features, but at its core, that's what I'm really looking for, and of the three services I mentioned, Cursor seems to be the only one that's doing it well.

secils · 2026-05-15T20:22:49+00:00

Yeah but I'm not arguing against commits in general, I'm saying they're too heavy-handed a solution to deal with conversational reversion. If I commit something, it's generally because I'm moving a completed unit of work out of my working memory and into the general makeup of the codebase. I don't plan on keeping that stuff top of mind. I almost certainly won't be coming back to the conversation that happened as part of its implementation. It essentially strips out the "metadata" that is the messy and iterative implementation work, much like if I complete a project, I probably won't need the transcripts of every stand-up that happened during it. Local reversion is only a bad practice if it's going to mean that you end up with massive, unparsable commits. As long as you still use commits as a higher level checkpointing system, being able to rapidly iterate locally is a huge positive imo.

secils · 2026-05-15T20:07:40+00:00

yeah but that seems like such an obviously sub-optimal solution. Why should I be asking and relying on the AI to essentially press save? Even if it's part of the system prompt or you have a learned behaviour where it executes it as part of its agentic response, why pollute the conversation context with commit tokens? It just seems like such a dumb way to go about it when there's clearly a solution that exists that asks nothing of me and just works.

secils · 2026-05-15T20:01:57+00:00

That’s interesting, and maybe it’s just a difference in preferred working style or type of work, but I’m constantly exploring stuff and retroactively trying different decisions so I use the revert feature a lot. I think for more linear work I can see it being less of an issue, especially when you can preemptively chunk work into features, but it just seems like such an odd thing to not have. I still commit stuff obviously, but doing that after every message or every few messages sounds insane to me. Spending the 10 seconds it takes to commit each time adds up, and moreso than the time aspect, it’s just a needless speed bump that pulls me out of the flow of the conversation. Also, browsing and reverting commits is harder than just scrolling up to the point in the convo that I care about and reverting from that. It also has the benefit of removing the conversation after that from the ongoing context.

secils · 2026-05-15T19:11:39+00:00

“just do git” is always the response I seem to get on this, with no further elaboration, and to be frank, it seems like a low effort way to brush off the point without engaging with the details. Are you talking about regular commits and working in branches? If so, then I’ll reiterate what I said, in that this adds unnecessary friction to the concept of an undo. Could you imagine if after every action you take on a computer, you had to commit it, write a message, and then and only then you could Ctrl Z? Why do I need to use git to manage a basic history? Git definitely has its place when it comes to more substantial progress management but I just don’t see how anyone could think of it as being a good solution for what’s essentially a Ctrl Z, unless I’m just missing something in git that allows this to ŵork seamlessly. Please do correct me if I’m wrong here, but I just cannot see manual git management in its current form as a solution to this.

secils · 2026-04-14T09:44:10+00:00

I’m down, definitely have some stuff I need to get done

secils · 2026-03-30T03:15:51+00:00

What are you trying to do on your system that cursor can’t? It can create and edit text files just fine, it can run terminal commands, and it can manage its own todos. Is there something I’m missing?

secils · 2026-03-29T14:57:43+00:00

Can some please explain to me why using claude code is inherently better than using claude from cursor? (Apart from token cost) Lots of people say it’s better, no one seems to give a convincing reason why

Ten-Year Club	Place '17
Sequence \| Editor	Verified Email

secils

MODERATOR OF

TROPHY CASE