WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=q4Tr-DknG2M

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/q4Tr-DknG2M.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.920 --> 00:00:21.640
Please welcome to the stage the machine learning engineer model behavior at cursor Lee Robinson.

s3
00:00:36.160 --> 00:00:37.880
All right.

s4
00:00:37.880 --> 00:00:39.320
Hey everyone.

s5
00:00:39.320 --> 00:00:40.440
Uh, I'm excited to be here.

s6
00:00:40.440 --> 00:00:47.160
Excited to be back at AI engineer and talk a little bit about how we're training models at cursor.

s7
00:00:47.160 --> 00:00:54.600
So, how we train the models and also how the model learns to train itself or recursive model improvement.

s8
00:00:54.600 --> 00:01:01.000
So, our goal at cursor is to build the best possible AI models, which might make sense.

s9
00:01:01.000 --> 00:01:06.240
You might have heard of this equation of if we just give the models more compute, we can get a better model out.

s10
00:01:06.240 --> 00:01:16.480
And I think this is a helpful simplification of the problem, but I want to actually click in a few layers deeper in the talk today and talk about all the different pieces that go into training these models.

s11
00:01:16.480 --> 00:01:19.360
So, we can think about this loop.

s12
00:01:19.360 --> 00:01:25.760
We put a model out into the world and then we get feedback from you all when you use the model, what goes well or places we can improve.

s13
00:01:25.760 --> 00:01:29.920
We use that to scale and improve the data that we do for the next round of training.

s14
00:01:29.920 --> 00:01:35.120
We also then increase the amount of compute and scale up training overall to make a new model.

s15
00:01:35.120 --> 00:01:38.200
And this is a loop that can just go over and over again.

s16
00:01:38.200 --> 00:01:45.680
However, if you see my helpful snail or turtle to bunny meter down in the bottom right, it's pretty slow.

s17
00:01:45.680 --> 00:01:50.880
This is going to be a serial process and you can only do in this instance one big run at a time.

s18
00:01:50.880 --> 00:01:57.960
So, we want to make this a little bit faster, but I'll actually go another layer deeper and add some more color here.

s19
00:01:57.960 --> 00:02:01.720
There's actually two loops, the outer loop and the inner loop.

s20
00:02:01.720 --> 00:02:07.400
On the outer loop, we have the feedback coming in, but we also have data like online metrics.

s21
00:02:07.400 --> 00:02:11.920
So, running AB tests and seeing what users prefer a different checkpoint of a model.

s22
00:02:11.920 --> 00:02:26.959
That's going to then flow into hopefully making better high-quality evals that help ensure we're getting the right behaviors we want out of the model, and also being able to create much more difficult problems for the models to try to solve where we then can kind of shape the rewards

s23
00:02:26.959 --> 00:02:28.680
that we want to get during training.

s24
00:02:28.680 --> 00:02:32.720
So, we want to climb that inner loop as well.

s25
00:02:33.240 --> 00:02:41.080
We have been training models for about a year at the large scale at Cursor, and I want to talk about some of our progress so far.

s26
00:02:41.080 --> 00:02:48.600
So, we put out Composer 2.5 in May, and it's now the most popular model in Cursor, which is exciting.

s27
00:02:48.600 --> 00:02:59.800
And we scaled up training here quite a bit by generating more RL environments, trying out some new methods for learning, and also just making more ambitious problems for the models to solve.

s28
00:02:59.800 --> 00:03:03.480
And the results have been pretty promising so far.

s29
00:03:03.480 --> 00:03:05.920
Like I mentioned, this is still a new effort for us.

s30
00:03:05.920 --> 00:03:16.120
ML has really been in the blood of Cursor since the start, where we were training more specialized models for things like tab or code auto complete, but really in the past year we've staffed up and built a team

s31
00:03:16.120 --> 00:03:22.480
with ambitions to train, you know, state-of-the-art models, and we've made some pretty good progress just in the last 12 months.

s32
00:03:22.480 --> 00:03:29.640
People like Composer right now, I think because it is both fast and pretty smart, and also cost-effective.

s33
00:03:29.640 --> 00:03:37.200
And as we've heard from other speakers today, I think there is a space in the market right now for that type of model, in addition to also having the most

s34
00:03:37.200 --> 00:03:42.360
intelligent models in the world, and we think it's important to have a good selection of both of these type of things.

s35
00:03:42.360 --> 00:03:46.440
So, Composer we think is serving a good niche here.

s36
00:03:46.440 --> 00:03:51.680
And when we released it, we were honestly pretty impressed with some of the public evals.

s37
00:03:51.680 --> 00:03:54.880
Did a little better than we expected on artificial analysis.

s38
00:03:54.880 --> 00:03:56.920
It was a a pretty modest jump.

s39
00:03:56.920 --> 00:04:02.280
However, there were a lot of behaviors that we found that we really wanted to improve for the next version of the model.

s40
00:04:02.280 --> 00:04:05.000
Notably, we wanted to have a much bigger and smarter model.

s41
00:04:05.000 --> 00:04:13.840
We wanted to control every aspect of training, so ideally doing a full pre-train from scratch versus the previous open-source base of Kimmy that we were using.

s42
00:04:13.840 --> 00:04:20.880
We wanted to infuse new data so that we can make the model great outside of more things than just coding, but more of a general model.

s43
00:04:20.880 --> 00:04:24.080
And then also just scale up every part of the training process.

s44
00:04:24.080 --> 00:04:29.280
More data, more compute, and really pushing RL as far as we can.

s45
00:04:29.280 --> 00:04:35.040
So, first I want to talk about improving the outer loop, and then we'll drill drill into the inner loop.

s46
00:04:35.040 --> 00:04:41.760
If you haven't used Cursor in a while, you might think about it as this IDE or tab autocomplete thing.

s47
00:04:41.760 --> 00:04:47.400
And in reality, uh the vast vast majority of our revenue today comes from agent usage.

s48
00:04:47.400 --> 00:04:55.040
And that means that all of the data inside of Cursor is also coming from agent usage, and we can use that to train better models.

s49
00:04:55.040 --> 00:04:57.919
So, for example, we kind of have two different buckets of feedback.

s50
00:04:57.919 --> 00:05:04.600
On the external side, when you're using the product, you can thumbs up or thumbs down different responses and give feedback.

s51
00:05:04.600 --> 00:05:12.640
And we use that to then classify places where, for example, Composer maybe doesn't do as good of a job, and we want to improve that for future versions.

s52
00:05:12.640 --> 00:05:17.640
And then also on the internal side, we're heavy dog fooders of our models and our products.

s53
00:05:17.640 --> 00:05:23.000
We're very critical and want to make sure we're using good models, and we of course use them all day.

s54
00:05:23.000 --> 00:05:30.880
So, we have a good mix of manual reports, automated reports internally, and just lots of ways we're trying to get the best behaviors out of the model.

s55
00:05:30.880 --> 00:05:35.600
And if we do that over and over and over again, we can get better models out into the world.

s56
00:05:35.600 --> 00:05:40.280
But really the place where we can make massive speed ups is improving that inner loop.

s57
00:05:40.280 --> 00:05:50.320
So, just to zoom back in on that again, we have these high-quality evals, we have these very difficult training tasks, and we want to climb these evals as quickly as possible

s58
00:05:50.320 --> 00:05:57.240
so that we know if we make a new checkpoint of the model, we're actually making progress on the things that we want to measure.

s59
00:05:57.240 --> 00:06:07.640
So, for example, some of the evals that we have introduced or have already had are things like understanding what you really meant when you have included maybe 50 skill files.

s60
00:06:07.640 --> 00:06:11.080
It gets kind of hard for the models to figure out your actual intent.

s61
00:06:11.080 --> 00:06:20.800
Or trying to figure out the line between when you push back and ask the user to clarify a question versus when you trust their judgment and they said, "No, I really wanted to do this."

s62
00:06:20.800 --> 00:06:24.000
There's just kind of a fine line, and people have different preferences.

s63
00:06:24.000 --> 00:06:31.080
So, a lot of these evals are trying to shape a lot of those different behaviors, and also model what it feels like to be a software engineer.

s64
00:06:31.080 --> 00:06:34.800
We ask the models to do really ambitious things like, "Hey, we just had this sev.

s65
00:06:34.800 --> 00:06:42.640
Could you have actually went and read through all the data dog logs, read through Slack, read through Notion, and came to the same conclusion or the same fix that we did?"

s66
00:06:42.640 --> 00:06:45.800
Uh and a lot of models are just not very good at this today.

s67
00:06:45.800 --> 00:06:52.120
And that uh backs a lot of the evals that we create based off these software engineering tasks.

s68
00:06:52.120 --> 00:06:58.080
Now, as the models get smarter, they also find very creative ways to hack the evals.

s69
00:06:58.080 --> 00:07:05.000
So, as we've been training for a new version of our model, we also noticed there was some interesting reward hacking going on.

s70
00:07:05.000 --> 00:07:12.280
Um the models learned how to really just go back in the Git history and figure out if there was a solution or a part of a solution.

s71
00:07:12.280 --> 00:07:20.240
Uh they figured out good ways to go online, and if it was a public eval, just see if there was a fork of the eval anywhere they could look up the results from.

s72
00:07:20.240 --> 00:07:23.760
And this affected our own models as well as other models.

s73
00:07:23.760 --> 00:07:35.200
So, we did a little research here and found that if we did just a couple small changes on measuring public uh evals, we could have a pretty noticeable uh change in the scores that were reported.

s74
00:07:35.200 --> 00:07:41.280
So, first off, we would delete the Git history at the start, and we could restore it at the end, so that wouldn't affect the run.

s75
00:07:41.280 --> 00:07:47.840
And then also, we can have a network allow list or just some basic controls on the sites that the uh the agent can go and talk to.

s76
00:07:47.840 --> 00:07:55.080
And I think this is helpful for public evals which often are the things that people are using to calibrate whether a model is good when it gets released.

s77
00:07:55.080 --> 00:07:58.080
You know, you see that big chart of all the benchmark numbers.

s78
00:07:58.080 --> 00:08:01.960
But this isn't really a true test of what it feels like to use these models.

s79
00:08:01.960 --> 00:08:04.720
Like in reality you have access to the internet.

s80
00:08:04.720 --> 00:08:08.720
You can do whatever you want on the internet with these models and you're definitely using Git.

s81
00:08:08.720 --> 00:08:11.960
So you want to be able to test the true capabilities of the models.

s82
00:08:11.960 --> 00:08:13.360
And that's why we have Cursor Bench.

s83
00:08:13.360 --> 00:08:27.600
We have this private eval set that is mostly made up of things that happen in our code base which is held out from the evals so we ensure that the models aren't trained on it and it's based on those real-world engineering tasks.

s84
00:08:27.600 --> 00:08:33.280
Now another part of climbing that inner loop is trying to make very very difficult problems for the models to solve.

s85
00:08:33.280 --> 00:08:43.280
As the models get better, you might have noticed if you're looking at an eval and all the models are scoring like 90% probably time to retire that eval and try to get something more difficult

s86
00:08:43.280 --> 00:08:47.480
and that the half-life of those evals will go down as the models get smarter.

s87
00:08:47.480 --> 00:08:50.360
And to do this it requires a lot of things.

s88
00:08:50.360 --> 00:08:54.800
It requires some amount of research or taste in what these problems should be.

s89
00:08:54.800 --> 00:08:58.400
It requires a lot of compute so you can try a lot of different ideas.

s90
00:08:58.400 --> 00:09:06.360
Some of them are going to are going to work, some of them are not going to work and there's a race against the clock here so you want to try as many in parallel as you can.

s91
00:09:06.360 --> 00:09:17.160
Just to put a example to this of one of those type of problems, let's say that on the left for example you have each one of those squares is representing files in a code base and then on the bottom you have the tests.

s92
00:09:17.160 --> 00:09:26.560
One thing you can do is generate a very complex application or environment for a very ambitious application or task and then you can delete part of it.

s93
00:09:26.560 --> 00:09:30.880
You can delete a feature, you can delete files and the test will then fail.

s94
00:09:30.880 --> 00:09:43.200
And then you can ask these models to go and basically figure out however it wants to re-implement that feature and it has a very verifiable goal of all the test passing to be able to get some reward back at the end.

s95
00:09:43.200 --> 00:09:51.400
And this actually works out pretty well and has allowed us to scale making these interesting problems for the you know, the frontier models to solve.

s96
00:09:51.400 --> 00:09:56.440
Additionally, we have found some new learning methods which I personally think are really interesting.

s97
00:09:56.440 --> 00:10:00.440
The first one is you can teach the model to kind of coach itself.

s98
00:10:00.440 --> 00:10:07.960
So, for example, if you think about an RL rollout or a conversation with an agent, this can be hundreds of thousands of tokens.

s99
00:10:07.960 --> 00:10:15.800
And if you think about trying to grade at the end of this where the model made a right decision or a wrong decision, that's kind of hard, right?

s100
00:10:15.800 --> 00:10:18.840
You have all these tool calls, you have thinking blocks.

s101
00:10:18.840 --> 00:10:22.880
It's pretty hard to figure out where to assign that credit to the root issue.

s102
00:10:22.880 --> 00:10:24.720
So, the more precise we can be the better.

s103
00:10:24.720 --> 00:10:27.840
You know, was it one of the tool calls, was it a thinking block?

s104
00:10:27.840 --> 00:10:29.200
It's pretty hard.

s105
00:10:29.200 --> 00:10:34.600
And one thing that we've done to improve this process is something called textual feedback.

s106
00:10:34.600 --> 00:10:44.280
So, we want to zoom in on one specific part of that rollout, and ideally we can hint or kind of nudge to the model, "Hey, by the way, here's a way you could improve."

s107
00:10:44.280 --> 00:10:50.080
And then look at the probabilities again and nudge up the ones we want or you know, down weight the ones we don't want.

s108
00:10:50.080 --> 00:10:57.720
Uh for example, on the left you have this student case where you have a rollout and it tries to call a tool, and the tool call fails.

s109
00:10:57.720 --> 00:11:02.240
It should have known that this tool was there, but it just decided not to work for this time.

s110
00:11:02.240 --> 00:11:07.080
We can then use a teacher, we can use the same model, but we include this hint.

s111
00:11:07.080 --> 00:11:10.600
And we say, "Hey, as a reminder, you have all of these tools available."

s112
00:11:10.600 --> 00:11:17.600
And then we like I mentioned, we can just upvote or up weight the probability is such that we can get the behaviors that we want.

s113
00:11:17.600 --> 00:11:22.400
And this example is with, you know, adherence to tool calling, but we can really use this for anything.

s114
00:11:22.400 --> 00:11:25.040
We can use this for making style changes.

s115
00:11:25.040 --> 00:11:33.600
We can use this to get any behavior we want to influence the models during RL, and this has proven to be uh very valuable for us.

s116
00:11:33.600 --> 00:11:39.920
Now, how we scale these loops, both the inner and outer loops, also comes down to scaling the amount of compute we have.

s117
00:11:39.920 --> 00:11:49.920
Um we announced back in March that we are partnering with SpaceX to get access to a lot more compute, and this allows us to train very large models from scratch,

s118
00:11:49.920 --> 00:12:01.240
not only the product, but also the models down to the supercomputers or the data centers where we're training these models with Colossus, and then increasingly to the chips as well with Terafab.

s119
00:12:01.240 --> 00:12:06.920
And that just allows you to do some pretty interesting things in taking advantage of that full stack.

s120
00:12:06.920 --> 00:12:10.240
If you haven't seen Colossus, I think it's really interesting personally.

s121
00:12:10.240 --> 00:12:22.400
They were able to train uh they were able to build out this supercomputer in 122 days for 100,000 GPUs, and then added another 100,000 GPUs in 92 days.

s122
00:12:22.400 --> 00:12:23.680
So, very impressive.

s123
00:12:23.680 --> 00:12:35.440
They had to do some pretty creative things to get this done and kind of take over this old factory in Memphis, and it's kind of shown they can stand up these data centers really quick, which is of course very helpful for our model training efforts.

s124
00:12:35.440 --> 00:12:40.280
And for Terafab, I think it's also very interesting that they're building their own chips.

s125
00:12:40.280 --> 00:12:51.000
I mean, to put the size of this into perspective, if you just think about how large this physical structure is, I know you're all thinking it, it's like the size of 100 Buckee's,

s126
00:12:51.000 --> 00:12:55.839
which for my for my folks from the south, you know, we love Buckee's.

s127
00:12:55.839 --> 00:12:57.440
I'm not even from the south and I love Buckee's.

s128
00:12:57.440 --> 00:13:02.160
This is like the crown jewel of the south, the premium gas station experience.

s129
00:13:02.160 --> 00:13:06.680
It's It's a lot of stuff, but that just puts it into perspective the size.

s130
00:13:06.680 --> 00:13:11.760
So, going back to this equation at the start, more compute in, you get a better model out.

s131
00:13:11.760 --> 00:13:15.720
I think it's sometimes hard to understand what does that compute even do?

s132
00:13:15.720 --> 00:13:17.480
Where Where do you actually put that compute?

s133
00:13:17.480 --> 00:13:21.000
Let's say you have access to a bunch of GPUs, like what do I do with it?

s134
00:13:21.000 --> 00:13:23.960
And I think it's helpful just to step through a few of the things.

s135
00:13:23.960 --> 00:13:34.640
Of course, first you have actually serving the model to end users, but also you're serving up different checkpoints internally, you're running different AB tests, you're trying different variations of the model.

s136
00:13:34.640 --> 00:13:41.920
You have the actual training process itself, but also the sub-pieces from pre-training to mid-training to RL.

s137
00:13:41.920 --> 00:13:50.120
And then also you're then training these derivative models to do other parts of the process like climbing the inner loop, which we'll talk about here in a second.

s138
00:13:50.120 --> 00:14:04.560
You have the data generation and the reward generation, so creating those really ambitious problems that I talked about or when you're doing evals trying to create these rubrics for whether it was successful or not and give it some grade and then actually judging

s139
00:14:04.560 --> 00:14:05.880
those scores.

s140
00:14:05.880 --> 00:14:08.600
Um you also have the evals themselves.

s141
00:14:08.600 --> 00:14:18.400
Ideally on every new checkpoint of the model you want to be continuously running evals to see if you're improving in the places that you're measuring as as well as just developing new evals all the time.

s142
00:14:18.400 --> 00:14:25.760
Like I mentioned the the half-life of these evals as models get smarter, you need to be really continuously investing in making these better.

s143
00:14:25.760 --> 00:14:28.480
Um and there's just the research itself.

s144
00:14:28.480 --> 00:14:37.720
Ideally you want to free up your team of researchers to be able to tweak the knobs, to try ambitious ideas, experiment with new things, as well as do side runs.

s145
00:14:37.720 --> 00:14:43.280
And this all is compute that needs to be, you know, allocated for somewhere.

s146
00:14:43.280 --> 00:14:55.280
But what that ultimately turns into is ideally you can get in a state where you have multiple large training runs happening at the same time, where the researchers are unblocked and they can go try their research

s147
00:14:55.280 --> 00:14:58.160
and you're still kind of contributing back to this core flywheel.

s148
00:14:58.160 --> 00:15:09.200
And if you do that and we revisit our speed meter in the bottom right, you're starting to get to a point where you're getting something that's like RSI or recursive model

s149
00:15:09.200 --> 00:15:14.520
uh and and improvement here where the models are improving much much faster.

s150
00:15:14.520 --> 00:15:19.560
Then the bottleneck becomes how do you scale the folks actually training the models?

s151
00:15:19.560 --> 00:15:27.120
How can you automate the more monotonous parts of machine learning or research so that you can get these useful models out into the world.

s152
00:15:27.120 --> 00:15:30.640
And this is where I think it starts to get really interesting.

s153
00:15:30.640 --> 00:15:38.000
If you think about the model as Mario, if you give it some tools, all of a sudden you're more like a Super Mario.

s154
00:15:38.000 --> 00:15:49.360
And if you give it great context, everything about your organization, all the places that you work, you connect it to all your different tools, that context kind of turns it into the fire Mario or the super fire Mario.

s155
00:15:49.360 --> 00:15:57.120
And just to kind of further prove this point and add a few examples here, I think for tools, a lot of these are pretty obvious.

s156
00:15:57.120 --> 00:15:59.760
The models can write code with a with a harness.

s157
00:15:59.760 --> 00:16:01.200
They can you run shell commands.

s158
00:16:01.200 --> 00:16:02.680
They can look things up on the web.

s159
00:16:02.680 --> 00:16:15.920
But I think increasingly, even with these primitive versions of memory like writing files, these last three I think are just starting to become really popular and more useful, which is the models in the harnesses should be able to use a computer exactly like you would.

s160
00:16:15.920 --> 00:16:19.120
It doesn't need to be just inside of your GUI or your CLI.

s161
00:16:19.120 --> 00:16:22.000
It should be able to control every part of your computer.

s162
00:16:22.000 --> 00:16:30.280
You as a human on Slack or on your tool is basically subscribing to Slack threads in your head so that you can follow them for updates.

s163
00:16:30.280 --> 00:16:34.960
Ideally, you kind of want the models to just follow a thread and then ping you if it needs something.

s164
00:16:34.960 --> 00:16:43.920
And just like we have code bases that store the code, increasingly as these models do more work for us, they kind of need like a Dropbox for themselves.

s165
00:16:43.920 --> 00:16:46.200
Like where do you store the slide decks, right?

s166
00:16:46.200 --> 00:16:51.760
You could put that in code, I guess, but I think there's an increasingly a new opportunity here.

s167
00:16:51.760 --> 00:16:59.839
And then for context, of course, you have all the different places you can hook up with MCPs, Slack and Notion, Linear, Data Dog, etc. and the code base itself.

s168
00:16:59.839 --> 00:17:09.880
But I think these last two are really interesting, which is increasingly we find that you have a human working with a team of agents, and then the agents can start working with the other agents.

s169
00:17:09.880 --> 00:17:14.439
It's a little meta, but I think this will be a big trend in the next 6 months.

s170
00:17:14.439 --> 00:17:16.360
Just to kind of to example to this.

s171
00:17:16.360 --> 00:17:23.360
We've created these tools and these systems where researchers can run experiments directly from Slack.

s172
00:17:23.360 --> 00:17:30.200
We want to avoid this state of being bottlenecked on humans launching and reviewing and babysitting runs.

s173
00:17:30.200 --> 00:17:40.880
And we actually have an entire team just working on automating every part of the research work that isn't uh you know, isn't freeing up the researchers' time to work on their most ambitious ideas.

s174
00:17:40.880 --> 00:17:48.200
So, every person on the ML team gets access to this fleet of agents they can basically train models directly from Slack.

s175
00:17:48.200 --> 00:17:56.120
And what a few people on the team have taken this very far where they have these agent systems that can go and do a lot of work for them.

s176
00:17:56.120 --> 00:18:06.040
Maybe they want to go create a bunch of very difficult problems for the models to uh try and solve or they want to create a whole bunch of new evals based on some good ideas that they have.

s177
00:18:06.040 --> 00:18:09.200
And they just want to let the models cook and go work for a while.

s178
00:18:09.200 --> 00:18:18.920
But, if something gets wrong, if the infrastructure goes down, there's some blip somewhere, the model can message them on Slack or just page them directly and say, "Hey, this is really important.

s179
00:18:18.920 --> 00:18:21.760
You don't want to lose 6 hours because your infra was down.

s180
00:18:21.760 --> 00:18:23.560
Like, you should go check this out right now."

s181
00:18:23.560 --> 00:18:30.760
And this like human-to-agent coordination, I think is just starting to be figured out and it will be an increasing trend.

s182
00:18:30.760 --> 00:18:35.640
The last bit here is that the model is learning to train the next model.

s183
00:18:35.640 --> 00:18:38.520
And it it it's a little hard to wrap your brain around.

s184
00:18:38.520 --> 00:18:51.880
The way I like to think about it is every time you release a new version of this intelligence, then you can create or distill these derivative versions that you use to speed up other parts of the training process, both the inner loop and the outer loop.

s185
00:18:51.880 --> 00:18:59.400
So, when you're trying to do your evals, for example, you have different models for doing the judging and you have uh your reward models as well.

s186
00:18:59.400 --> 00:19:05.640
So, when you make the top-level model model smarter, it actually improves the whole system.

s187
00:19:05.640 --> 00:19:16.840
If you think about the multiple training runs diagram I showed, I'm going to throw on a uh a new meter here, which is the brain to galaxy brain meter or the intelligence meter,

s188
00:19:16.840 --> 00:19:20.720
you are a bottlenecked here on the smartest model in your system.

s189
00:19:20.720 --> 00:19:32.680
And if the smartest model then creates those derivative models, when you can improve that, you can actually make every single one of these loops much, much better because you've raised the kind of floor of the intelligence.

s190
00:19:32.680 --> 00:19:42.840
And this is how you start to get to something that feels like this recursive self-improvement, this model that is just improving all the time on your behalf.

s191
00:19:42.840 --> 00:19:53.280
And especially as we bring more and more compute online, I think this is really going to help us scale our model efforts and hopefully make even more useful models for you all to use.

s192
00:19:53.280 --> 00:20:04.800
Uh to conclude, I just like to thank everyone on the Cursor engineering and ML and research teams who have been uh working hard to get a new model out to you all here very soon, hopefully very, very soon,

s193
00:20:04.800 --> 00:20:09.000
uh that we think will be a pretty notable improvement over our last model.

s194
00:20:09.000 --> 00:20:11.080
And we're excited for you to try it.

s195
00:20:11.080 --> 00:20:13.073
Thank you so much.

s196
00:20:13.073 --> 00:20:15.073
[applause]

s197
00:20:30.104 --> 00:20:31.520
[music]

s198
00:20:31.520 --> 00:20:33.520
Yeah.