Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Composer: Building a fast frontier model with RL

cursor.com

Post reply on HN
Print view View original

81–90 of 169 posts

Re: Composer: Building a fast frontier model with RL

#81

Post by amilich »

carlosbaraza wrote: post #65

Cursor 2.0 keeps crashing on me while having an agent running and opening the IDE part of the application. I might have to rollback.

Hey - really sorry to hear this - could you email me andrew@cursor.com? Here are 3 suggestions to try- 1. Reset your settings.json - if shared with vscode, sometimes settings can cause perf regressions 2. Could you try cmd-shift-p -> "capture and send debugging data"? Will send us some profiling data to debug 3. Clear your user data (will delete chats) as a last resort - cmd-shift-p, "reveal user data," close the app, then delete this folder and restart the app

Re: Composer: Building a fast frontier model with RL

#82

Post by srush »

dfltr wrote: post #62
srush wrote: post #48

Earlier quoted context omitted.

Cheetah was an earlier (and dumber) version of this model that we used to test production speed. They are both developed in-house. If you liked Cheetah, give this model a try.

Awesome, thanks for the clarification. So are the rumors around Cheetah being based on a Grok model just straight up untrue? I want to try Composer but have a pretty strict no X/Grok policy.

Straight up untrue.

Re: Composer: Building a fast frontier model with RL

#83

Post by srush »

carlosbaraza wrote: post #73
srush wrote: post #48

Earlier quoted context omitted.

Cheetah was an earlier (and dumber) version of this model that we used to test production speed. They are both developed in-house. If you liked Cheetah, give this model a try.

This is nice. I liked Cheetah for grunt work that I want to get out quickly and is not too hard. The speed is really awesome. A model that would run at even higher speeds like the OSS models at groq/cerebras would really be workflow changing, because the slowness of SOTA models really breaks the flow. I find myself taking a ton of breaks and getting distracted while I wait for a model to complete a task (e.g. just no…

Let us know how you like it.

Re: Composer: Building a fast frontier model with RL

#84

Post by neuronexmachina »

For anyone else who was wondering, it looks like the within-Cursor model pricing for Cursor Composer is identical to gemini-2.5-pro, gpt-5, and gpt-5-codex: https://cursor.com/docs/models#model-pricing

($1.25 input, $1.25 cache write, $0.13 cache read, and $10 output per million tokens)

Re: Composer: Building a fast frontier model with RL

#85

Post by az226 »

srush wrote: post #16

Hi everyone, I am an ML researcher at Cursor, and worked on this project. Would love to hear any feedback you may have on the model, and can answer question about the blog post.

How many times have you needed to reset the optimizer during the RL training cycles?

Re: Composer: Building a fast frontier model with RL

#86

Post by asdev »

carlosbaraza wrote: post #79
asdev wrote: post #66

Earlier quoted context omitted.

you can use git worktrees and just have multiple Claude Code terminal instances working on each worktree. That way they don't clash, just delete the worktree when the task is done.

I have never leveraged git worktrees... That is such a crazy useful tool that I am almost ashamed of not having researched it before. Git is such a beautiful piece of software.

I built an open source project to make the whole workflow easier: https://github.com/built-by-as/FleetCode

Re: Composer: Building a fast frontier model with RL

#87

Post by enraged_camel »

infecto wrote: post #68
solarkraft wrote: post #37

Earlier quoted context omitted.

Absolutely. CC can be tuned to not do too much crap on its own, but even with the new extension its IDE integration and multi thread management are still significantly worse, as is its status reporting, which I find to be very important. Also, somehow magically, I’ve found Cursor’s Auto mode to be significantly faster than the specific models I’ve tried, Claude being among them.

Auto is pretty amazing and I think most folks that have issues or complain about cost are simply not using Auto.

Auto is only good for trivial stuff at this point. It is quite subpar at everything else. Th is is probably because it almost always defaults to Claude Sonnet 3.5 (which you can tell if you ask the agent to identify itself and tell you its version), and that is pretty outdated.

Re: Composer: Building a fast frontier model with RL

#88

Post by lubujackson »

infecto wrote: post #68
solarkraft wrote: post #37

Earlier quoted context omitted.

Absolutely. CC can be tuned to not do too much crap on its own, but even with the new extension its IDE integration and multi thread management are still significantly worse, as is its status reporting, which I find to be very important. Also, somehow magically, I’ve found Cursor’s Auto mode to be significantly faster than the specific models I’ve tried, Claude being among them.

Auto is pretty amazing and I think most folks that have issues or complain about cost are simply not using Auto.

Auto had a big improvement a few weeks ago (around when pricing changed)

Re: Composer: Building a fast frontier model with RL

#89

Post by chaidhat »

srush wrote: post #64
chaidhat wrote: post #55

Earlier quoted context omitted.

Which model did you distill it from? Great work! PS getting a few scenarios where it doesn't follow rules as well as sonnet 4.5

The blog talks about the training process. Specifically we trained with RL post-training on coding examples.

that's cool thanks!

Re: Composer: Building a fast frontier model with RL

#90

Post by cwyers »

The lack of transparency here is wild. They aggregate the scores of the models they test against, which obscures the performance. They only release results on their own internal benchmark that they won't release. They talk about RL training but they don't discuss anything else about how the model was trained, including if they did their own pre-training or fine-tuned an existing model. I'm skeptical of basically everything claimed here until either they share more details or someone is able to interpedently benchmark this.
Post reply on HN