It definitely works great, accomplishes fantastic things, and is very cost-effective i think. Well done, Cursor team. Thank you!
2 Likes
Hey, good to hear, what kind of things, workflows do you use it for? What programming language?
I use it for a Laravel + Vue.js (Quasar) project. Mostly for UI consistency across many pages, feature work, and refactoring. Really useful when a single change touches dozens of files.
Every new model (except gemini) works great, till it doesn’t.
Ref:
Composer-1.5 does seem to be a good model as cursor retrained composer-1 itself and made it expensive - however 5.3-codex is a better deal as its smarter than composer and cheaper.
2 Likes
it’s been a mixed bag for me. for straightforward code generation (“build this component,” “add this feature”) it’s noticeably faster and the output quality is solid.
where i’ve had trouble is scope control. when you give it a task that touches multiple files, it sometimes “helpfully” edits things you didn’t ask it to change. i posted about this in another thread and a few people confirmed the same thing.
the speed difference is real though. for iterating on a single file or focused tasks, it feels like a genuine upgrade over composer 1.0.
@valentinoPereira interesting point about codex being a better deal. i’ve been switching between them depending on the task. for anything that needs deep reasoning or careful refactoring, codex still wins. for rapid prototyping or scaffolding, 1.5 is faster and cheaper.
my workflow has been: use 1.5 for the initial build, switch to codex or claude when things get tricky. anyone else doing something similar?
3 Likes
Technically Composer-1.5 is more expensive than Codex 5.3. I am not sure in what sense you mention it is cheaper. Codex 5.3 (High) seems to do tasks accurately too, so I do not see us re-running and doubling token consumption much as far as composer is concerned.
As far as workflow is concerned, mine is use Auto first, then switch to specific model if things get tricky.