(from Cursor's blog)
> Training included trillions of tokens of Cursor data which capture a wide-range of user interactions with codebases and software tools. This dataset lets the model learn both from existing software as well as developer-agent interactions, capturing how developers work and how agents interact with their environments.
This is what the big money was for. Cursor is the first big player that had real-world data from real-world projects, before cc / codex were a thing.
> We used reinforcement learning on difficult problems in realistic environments spanning both software engineering and broader knowledge work. These environments teach the model to investigate problems, use tools, recover from mistakes, and verify results.
> Many of these problems had to be designed to be difficult enough that even frontier models fail at them. As models improve, existing tasks stop teaching them anything new, and problems that once required extensive reasoning become routine.
> We developed a distributed agent system to construct these environments at scale. Engineers specify a problem and how a solution is verified, and large groups of agents construct, test, and refine each environment.
This is where scale comes in. You use the previous gen model to prepare datasets for the next model iteration. The better the models, the better the data, the better the next models. (they also have a comparison with their composer2.5 training run, for people still thinking chinese models are "close to SotA"...)
Reports of xAIs demise (after giving a lot of compute to Anthropic) were slightly exaggerated, it seems.
> Grok 4.5 was trained across tens of thousands of NVIDIA GB300 GPUs
Composer 2.5 finetuned Kimi K2.5[0].
In the blog post, it is unclear whether Grok 4.5 is also a finetune on top of Kimi; they do imply it is also a finetune.
> Training included trillions of tokens of Cursor data… We used reinforcement learning on difficult problems
If xAI pivoted from a frontier base model company, to a finetuning company, it does mark a stark change to their relevance in the industry.
[0]: https://cursor.com/blog/composer-2-5
Well Microsoft has GitHub and Visual Studio and has no good coding model
Cursor has had a good AI product tons of people used for real work for 2yrs (up until recently when the Claude gap widened significantly) while Microsoft/Github has just been pretending they do with Copilot and awful Github AI integrations nobody likes. Meanwhile Github's code has already been vacuumed up by all the models by now.
You would be surprised how many enterprises are allowed to use only Copilot for all tasks due to Microsoft deals.
yeah, but that's due to enterprise commitments that MS won't train on the user interactions
Generally, it seems like if you are not getting returns that outweigh your token spend, you are merely paying to train AI.
well the big money was also in spacex stock, fresh post IPO, so overall a very smart move it seems
> You use the previous gen model to prepare datasets for the next model iteration
I've read multiple times that this approach is harmful in training.
You're essentially describing what many call distillation, but it's only useful in post training to guide behavior, it teaches how to behave, not how to think.
I might be wrong though and would be glad if someone more knowledgeable provided more insights.
There have been papers about model collapse, but the underlying assumption is that you constantly train on only the outputs of the previous model. Later research has shown that as long as you retain some "real" data, training on largely synthetic data is ok.
And in the case the previous poster describes, the other model doesn't generate datasets, it generates environments which the next generation interact with to learn from.
> I've read multiple times that this approach is harmful in training.
There's a lot of nuance here. Note that I said "prepare" datasets and not just "generate" datasets.
First, the "model collapse" paper(s) were highly misunderstood and the "media" / content creators ran with it because negativity sells. In that initial paper the authors took things to the extreme, and presented as a given what happens in the literal worse case scenario. They used small models, they generated data w/ those models and indiscriminately trained on that data. It obviously led to model collapse. But that's not what you do in the real world.
The way you do this in the real world is different. For pre-training data you can do things to improve the quality of your inputs:
First, you can use the models to curate your datasets. And this is something that everyone has done since the days of "chug common crawl into the model and see what comes out". It turns out that quality of the data is very important and common crawl is really bad. So we've seen attempts at curating that data. The better the filtering models, the better the initial pre-training data.
Then you can have data augmentation, where you take some piece of content, and generate augmentations for it. Current models are good enough that you can take a piece of "authoritative" text (say a book on writing style) and a bunch of articles, and "improve" them. Or take a piece of content and "translate" it into simple / advanced explanations. Or take a piece of code and "explain" what it does, based on a paragraph from an authoritative book. And so on.
Then, for the mid-training / post-training with RL:
You need to find both good scenarios (i.e. problems) for your model to solve and a good verification schema. Like they say in the quote above, those problems need to be complicated enough for each new model. Here you can again use old models to prepare datasets for the new models.
One simple approach is to take a codebase, have your current model identify a set of features. Then instruct the model to remove code relating to feature "a" but keep its tests. Then verify that every other feature works in the code, bar the one you removed. Then, during RL, you train your new model on that task (you present it as a "prompt" / "situation") and you score the model based on the new feature passing the original tests.
Then there are more advanced ways of using prev gen models for "open ended" problems. You can't really apply RL if the task is not easily verifiable (like above, with tests). But you can use something like RLAIF (reinforcement learning w/ AI feedback) where you grade responses with the previous gen models. Now, in general this is lower quality / lower signal than RLVR (verifiable rewards) but you can still do smart things. Instead of rating an answer good / bad, or ask it one-shot what answer is better, you can use a method based on rubrics. You can first ask the preparing model to select tasks, and a list of rubrics on how that task should be scored (like they generally do on open ended exam questions). Then while doing RL you grade each response by asking the prev gen model to generate said rubrics. Does the answer touch on subject a / b / c? Does the answer mention x y z? Is this mathematically sound? And so on. You still get better results than nothing, even if the task is "open ended". And, again, as models improve so does your pipeline.
Very insightful, thanks.
There was one highly discussed paper. And about a month after publication much much stronger models were released. The models got better because they used such synthetic data.