AI Engineer Code 2025
Building Cursor Composer
Read the talk
Building Cursor Composer: Fast Agents Need Real Environments
Composer combines low-latency generation with learned tool use, backed by reinforcement learning infrastructure that closely matches the environment where developers actually work.
From a talk by Lee Robinson
Before you start: Basic familiarity with coding agents and tool calls is helpful; no reinforcement learning background is required.
How fast can a useful coding agent be?
Can a coding agent be fast enough to work alongside a developer while still being smart enough for real software engineering? Composer, Cursor’s first agent model, targets that combination. Lee Robinson introduces the work of Cursor’s engineering and research teams, building on an earlier presentation by his colleague Sasha. On Cursor’s internal benchmarks, Robinson places Composer above the best open models and slightly below the then-current frontier represented by Sonnet 4.5 and GPT-5.1 Codex.
Robinson reports roughly four times the token-generation speed of models at a similar intelligence level. That is a generation-speed comparison, not a claim that every coding task finishes four times faster. Cursor’s published benchmark methodology uses its internal harness and tokenizer-normalized tokens per second; the model comparisons here describe the release-era landscape.
The precedent was Tab, Cursor’s autocomplete model: low latency already mattered when suggesting the next edit, and the team wanted to bring that responsiveness to agents. Early prototypes released under the cheetah name earned encouraging feedback about speed. But users did not find them capable enough to serve as their daily coding model.
Cursor therefore built an internal benchmark around its own repositories and development work. The practical acceptance criterion was a checkpoint that Cursor’s developers would choose every day to build the product. Two changes helped reach it: calling tools in parallel and using semantic search effectively. Fast generation needed to be paired with competent decisions about what to do next.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keeping the investigation in the foreground
The demonstration uses Cursor 2.0, its new agent view, and the model labeled Composer One. While investigating an issue in an open-source repository, the agent makes parallel grep calls, reads files, runs shell commands, edits files, and maintains a to-do list. The distinctive feature is the succession of visible actions: the investigation keeps moving while the developer watches.
That creates a different interaction from launching an agent and returning much later. Robinson uses a roughly twenty-minute wait as an example of a task long enough to encourage context switching. A responsive agent instead lets the developer stay with the problem and follow its progress. From there, he turns to the training and infrastructure that make this style of programming possible, explaining them from his perspective as an engineer rather than an ML researcher.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Training on complete tool-using attempts
A user query arrives at Cursor’s backend, and the agent decides which tools to call. Robinson describes roughly ten available tools, highlighting five categories: reading files, editing files, searching the codebase, inspecting lints, and running terminal commands. The agent also chooses whether calls should happen serially or in parallel. The reinforcement learning environment aims to reproduce those production choices as closely as possible.
The unit of experience is a rollout: one attempt to respond to a query through a sequence of actions. Training can explore different attempts from the same initial state:
- Start with the same query and environment.
- Let the model choose and execute a sequence of tools.
- Repeat from that starting point, allowing a different sequence.
- Score the outputs and compare the attempts.
- Update model parameters using the resulting feedback.
In the illustrated pair, one attempt reads and edits a file; another includes codebase search before reading and editing. The completed slide marks the first with an X and the second with a check. It makes the training signal concrete: alternative paths through the tools can produce different outcomes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The simple loop becomes an infrastructure problem
Scaling this loop introduces three constraints:
- Training and sampling alignment. Composer is a large mixture-of-experts model distributed across thousands of GPUs. Training must be fast, while remaining closely matched to the model used to generate rollouts.
- Uneven rollout duration. Robinson describes attempts consuming hundreds of thousands to millions of tokens and hundreds of tool calls. Different paths take different amounts of time, so completion is irregular.
- Production tool fidelity. Training needs the same tool formats and responses as the product, but its demand arrives in large bursts rather than the pattern of ordinary production traffic.
These begin as requirements for learning useful behavior, but satisfying them depends on the systems around the model.
The architecture separates three server roles:
| Server | Responsibility | Technology named |
|---|---|---|
| Training | Update model parameters | PyTorch |
| Inference | Generate and coordinate rollouts | Ray |
| Environment | Execute tools in a Cursor-like workspace | Coding environments |
The inference side sends rollout advantages back to the trainer: signals that nudge learning toward or away from the behavior in an attempt. The trainer uses that feedback to produce updated parameters. Keeping environment execution separate lets the system reproduce the coding workspace without making it part of the training server itself.
To accelerate the large model, Cursor developed custom kernels for very low-precision training. Robinson describes two benefits: faster training and an easier handoff to inference. He reports approximately 3.5× speedup for the mixture-of-experts layer on NVIDIA Blackwell chips. The corresponding kernel report distinguishes that layer result from approximately 1.5× end-to-end training throughput on Blackwell against BF16; the layer improvement should not be applied to the entire training run.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keeping rollouts busy in real coding environments
After a training update, the new weights return to the inference server for further rollouts. Those rollouts do not finish together. One may perform a long sequence of tool calls or install a package while another completes quickly. A naive schedule leaves capacity idle around those differences. Cursor load-balances work across threads and processes so that uneven attempts do not create as much wasted time. Throughout a rollout, inference sends tool requests to environment servers and receives their results.
Owning both the coding product and the model work offered a useful opportunity: Cursor was building Cloud Agents alongside Composer’s reinforcement learning system. A Cloud Agent can run away from the local IDE, launched from a phone, the web, or Slack. Its cloud VM loads the user’s code and provides a secure sandbox for file changes and tool execution.
That same infrastructure supplies realistic RL environments. Instead of creating an unrelated approximation of a coding workspace, the training system can use the infrastructure built to run agents for users. The remaining difficulty is operational: training demand is much spikier than Cloud Agents traffic. Robinson describes orchestration across many clusters and a fleet of hundreds of thousands of VMs, showing an internal fleet dashboard that the team built with Composer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Becoming a practiced user of semantic search
Why reproduce the actual environment rather than mock its tools? Semantic search shows what the extra fidelity buys. Cursor trains its own embedding model and indexes a repository so the agent can locate relevant files with natural-language queries. This gives the model a way to look for the meaning of code, rather than relying entirely on exact text matches.
In the semantic-search study, Cursor compared agents with and without semantic search on Cursor Context Bench, which tests codebase questions. Robinson reports benefits for nearly every model in Cursor’s harness, with Composer benefiting particularly strongly. The displayed comparison shows a 23.5% relative improvement for Composer with semantic search on that codebase-question evaluation. This measures retrieval-assisted question answering, not a general increase in coding-task success.
The explanation connects directly to training: Composer practiced with the same search tool it would have at inference time. It could learn when that tool was useful and how to incorporate its results into an investigation. Environment fidelity therefore affects more than whether a call parses correctly; it gives the model experience with the capabilities that distinguish the product.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Learning to finish sooner and edit more carefully
As training continued, Cursor saw further improvements from additional rollouts and compute. Robinson describes a progression from roughly the performance of the best open model toward frontier coding agents. He sees this as encouragement for applying reinforcement learning to difficult, specialized tasks, with coding as the demonstrated domain and other domains as a possible extension.
End-to-end responsiveness depends on the action sequence as well as token speed. Robinson’s example is reading ten files in parallel instead of reading them one by one. Once the paths are known and the reads are independent, the same scheduling principle can be expressed in Python:
python
from concurrent.futures import ThreadPoolExecutor
from pathlib import Path
def read_files(paths: list[Path]) -> dict[Path, str]:
def read(path: Path) -> str:
return path.read_text(encoding="utf-8")
with ThreadPoolExecutor(max_workers=10) as pool:
contents = list(pool.map(read, paths))
return dict(zip(paths, contents))
Here the result still associates each path with its contents, while independent reads can overlap. The agent-level decision is when such a batch is appropriate: a search that discovers the paths must still happen before reading them. Composer’s training made parallel tool use part of its behavior, improving the experience seen in the earlier demonstration.
Robinson also describes a change in restraint. Early checkpoints made too many edits, including unnecessary ones. With more training, Composer increasingly searched and read files before changing them, finding the relevant code before attempting a fix. Further speed work remained ahead, but the behavioral improvement already went beyond doing the same actions faster: the model was learning a more effective order of operations.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Getting out of the awkward middle
Composer launched with Cursor 2.0 on October 29, 2025—the month before this conference. When Robinson asks who has tried it, the audience response is larger than he expected. His description of the experience starts with airplane Wi-Fi: it works, but it is slow enough to make the activity frustrating.
Coding agents can occupy a similarly awkward middle, which he calls the “semi-async valley of death.” A ten- or twenty-minute task is too slow for continuous interaction, yet may still demand enough attention to prevent the developer from fully leaving it behind. The useful alternatives sit on either side:
| Mode | Developer relationship | Work pattern |
|---|---|---|
| Fast foreground agent | Stay in the loop | Follow progress and respond directly |
| Powerful background agent | Hand off the work | Let it run for an extended period |
Robinson contrasts the frustrating middle with background work that might run for thirty minutes, hours, or days. Those durations describe interaction patterns, not measured Composer completion times. For him, Composer restores some of the enjoyment of writing code by hand because the work feels synchronous again.
His own workflow combines the two strengths at the model level. He uses GPT-5.1 Codex to develop plans, then asks Composer to implement them. The plan supplies prepared context for the faster implementation model—a practical application of the context-engineering work discussed earlier at the event by Dex.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The model and its deployment environment develop together
The first research lesson is about specialization. With high-quality data and substantial compute, reinforcement learning worked well for Cursor’s specific objective: building good coding models. Robinson explicitly separates that objective from pursuing general intelligence. A production-shaped task, environment, and toolset give the training effort a concrete target.
The second lesson concerns the process of building the system. Robinson reports that Cursor’s team uses AI assistance throughout coding and debugging. Improvements there compound across engineering work: the team can try more ideas, ship product changes, and run additional research. The fleet dashboard built with Composer is one concrete instance of the product helping construct its own supporting infrastructure.
The final lesson returns to the relationship between ML and systems engineering. Many of the obstacles to training Composer became infrastructure problems: supplying realistic execution environments, coordinating uneven work, and moving efficiently between training and inference. Robinson connects this to his experience at Vercel, where the experience of using a JavaScript or Python framework depends partly on the infrastructure that runs it. The useful behavior of an agent is shaped by both the model and the environment in which it operates.
He closes with an invitation to help build those coding models: Cursor was hiring across roles and had opened a New York office.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The original announcement of Composer and Cursor 2.0's interface for parallel agents.
A detailed explanation of Cursor's Blackwell kernel optimizations, low-precision training recipe, and layer versus full-training benchmarks.
Offline retrieval evaluations and online experiments measuring semantic search's contribution to coding agents.
Further reading
Cursor's technical account of Composer's evaluation, reinforcement learning, tool use, and training infrastructure.
Read the complete timestamped transcript
- 0:00
[on-hold music] Great to be back in New York, and I'm very excited to be here and talk on behalf of all
- 0:25
of our engineering and research teams at Cursor about building Cursor Composer, our first agent model. And my colleague Sasha actually gave a version of this talk recently, so I'm excited to give my own, uh, my own take on it.
- 0:37
So Cursor Composer is a model designed for real-world, real-world software engineering, and it tries to be both fast and smart. So as we've measured it against our own benchmarks, it's better than the best open source models.
- 0:50
It's, like, up against recent frontier models, but kind of slightly below the latest frontier with Sonnet 4.5, GPT-5.1 Codex. But where it really shines is it's about four times more efficient at token generation than models at a similar level of intelligence.
- 1:05
So we're trying to mesh speed as well as intelligence. So why did we build this model? I mean, obviously Cursor has an IDE. Why are we getting into the model space?
- 1:15
Why do we care about this? Well, our research and product teams have been building a model called Tab, which you can use for autocomplete. Maybe some of you use that inside of Cursor, and we wanted to take that same approach for a very low latency model and apply it to coding with agents.
- 1:29
But honestly, we weren't really sure if it would work. So [chuckles] we started prototyping some early versions of what this model could look like, started to put it out and get some feedback from users, and w- we were pretty surprised that this cheetah slug we released for this model, people actually really liked it.
- 1:45
Uh, they really liked the speed, but the feedback we got was it's not really smart enough yet to be a daily driver for a lot of their coding. So we needed it to be smart and fast.
- 1:55
Definitely needed to be smart. So we really worked on making this internal benchmark that represented our usage on our own repos and how we actually built software. Like, if we had a model that was both fast and smart and a checkpoint that our developers would use every single day to build the product and to build all of
- 2:10
our software, then we knew that we would be onto something. And for example, one big change here that helped actually push this towards a level where we had a checkpoint where people would use it was being able to call tools in parallel and being able to very effectively use our semantic search tool, and we'll talk about that
- 2:26
a little bit more here later. So if you haven't seen it, uh, here's Cursor and, uh, Cursor 2.0 and our new view, and we're going to use the Composer One model.
- 2:35
And you'll notice that it is doing a lot of things very quickly. It's calling a bunch of tools in parallel, like grep, so reading a lot of files. It's making shell commands.
- 2:44
Uh, it's making file edits. It's writing and managing, uh, a list of to-dos. And you can kind of very quickly work through tasks in the foreground here. Uh, in this case, I'm investigating an issue in an open source repo.
- 2:57
And I don't know about y'all, but this has been a quite different programming experience for me, uh, having working with coding agents for a little bit of time now, versus kind of firing off an agent and waiting, let's call it twenty minutes for it to complete where you can kind of context switch away.
- 3:11
This really does help keep you in the flow and is a kind of a different style of programming, I think. So I wanna talk about how we did this in a way that's hopefully accessible for you all.
- 3:20
I, I'm not a machine learning researcher, but I do really enjoy this stuff. Uh, what we learned, some of the infrastructure challenges, and then, uh, a little bit on where we're going, uh, moving forward.
- 3:29
So in Cursor, a user s- kind of submits a query to our back end. The agent reads that query and then decides to make a series of tool calls.
- 3:37
And our agent has about ten tools, uh, give or take, but we're gonna focus on five here. So reading files, editing files, searching your code base, looking at lints, and then also running terminal or shell commands.
- 3:48
And the agent then is able to autonomously decide, do we call these serially or do we run these in parallel? And our goal with reinforcement learning here is to try to mirror the Cursor production environment as close as we possibly can.
- 4:01
So this data that we have in training, we wanna kinda pretend like we're actually calling real Cursor queries. Uh, so to do that, we are running a series of rollouts.
- 4:10
Um, for example, in this rollout, we're calling a series of tools like reading files and editing files, and when we run more rollouts, we can start from that same initial starting point, but we might call a completely different set of tools.
- 4:22
So in this one, we're also doing code-based search. So we score the output, we decide which one is better, and then we update the parameters of our model based on that change.
- 4:32
So conceptually, a pretty simple idea. The challenges come from when you take the simple idea and then you try to scale it up to a very large amount, and so there's kind of three challenges.
- 4:41
The first one is trying to match the training and inference environment, so when the model's actually being used in the product. Um, in this case, with Composer, we're training a large mixture of experts model, and it's being parallelized across thousands of GPUs, and if we don't speed that up, it's gonna take forever to train the thing.
- 4:58
So we wanna make it really fast and match the training and kinda sampling version to be as close as possible. The second challenge is that the rollouts can get pretty complex when you start to look at real world data here.
- 5:10
So models are gonna use hundreds of thousands to millions of tokens. They're gonna make hundreds of different tool calls, and each of these rollouts could take a, you know, a pretty different amount of time.
- 5:20
One might make a lot of tool calls, one might make not as many, and they'll complete at different times, so we have to figure out how to deal with that challenge.
- 5:27
And finally, there's this challenge of consistency. If we want to mimic the production Cursor environment as close as possible, we need to use exactly the same tool format and the tool response.
- 5:37
But in training, we have this really bursty amount of compute, basically. We're, like, doing all of this training all at once, which is different than at production. So it is really an infrastructure challenge.
- 5:49
We have these three machine learning challenges, and all of the solutions, coincidentally, are actually infrastructure problems. So let's talk through a few of these problems and how we solved it at the infrastructure layer.
- 6:00
So our architecture is probably familiar for some of you who have been involved in this space a little bit, but I still think it's really interesting to talk about at kind of a high level.
- 6:09
Uh, we have three different servers. We have an inference server. We have kind of the standard ML stack with PyTorch. We have an inference server, so the rollouts that I just talked about, um, that's where we use Ray, and then we have environment servers, and these are the ones where we're kind of simulating that Cursor environment that
- 6:24
I talked about. And all these servers talk to each other. So for example, the inference server can basically send these advantages back to the trainer, which is like nudging it up or down, uh, b- based on the rollout, and then updating the model and getting new parameters.
- 6:40
So this, this one is a bit more on the ML side, but we're, we're trying to train a model that's very, very large and to do it as fast as possible.
- 6:47
And one way that our team was able to do this on the research side was to develop a library of custom kernels that allowed for very low-precision training. And basically, this just allows us to just speed up the training process in a big way and also make it much easier to ship to our inference server.
- 7:03
So if you're the type of person who loves this, we wrote a blog post going way in-depth on all of this. It talks about our custom kernels. Uh, if you're interested, the TLDR here is we found for the mixture of experts layer was about three and a half times faster, uh, a speed-up on NVIDIA Blackwell chips.
- 7:18
So it made a pretty significant, uh, impact on our training runs. So once we update the weights, we need to send them back over to the inference server, uh, during this training process, and the inference server is the one that's doing all the rollouts that I talked about, calling the tools and kinda managing, um, what we sent.
- 7:35
The challenge here, uh, [chuckles] is that they all complete at different times. So kind of a naive version of this, there will be a lot of wasted time. So what we were able to do is do load balancing across the different threads and processes to basically shift the work around and, and not have a bunch of idle time.
- 7:52
So if one rollout, for example, makes a ton of tool calls, maybe it installs some packages, installs some library, we're not just sitting there waiting for all of the other ones to finish.
- 8:01
The inference server is spending all this time going back and forth, making the tool calls to the environment, uh, and getting the tool results back, so again, communicating between these servers, and we want that environment to be as close as possible to the Cursor product.
- 8:15
One thing that's nice about having both the coding agent, the IDE, as well as what we're doing with the model research and training our own models, is we can kind of co-design these things together.
- 8:24
So as we were building out a lot of our RL work for this model, we were also building our Cloud Agents product. Um, this is how you can run a Cursor agent kind of offline.
- 8:34
You can run it from your phone or on the web or kick it off from Slack, for example. And to do this, we spin up virtual machines in the cloud.
- 8:41
So each one of these VMs loads up the user's code. Uh, it allows the agent to kinda like make file changes, run tools, and edit code in a secure sandbox.
- 8:50
And coincidentally, this is the perfect infra for RL and our use in training. So we have this like fleet of cloud VMs, and we have an environment that very closely matches the production Cursor environment, and we can then use that for training.
- 9:05
This does still have some challenges, though. I kinda talked about how the training workload is very spiky, and it's different than the kind of standard inference when you're running the Cloud Agents product.
- 9:14
So we needed to build infrastructure to support all of these VMs and orchestrating between them. So, you know, we have many different clusters, hundreds of thousands of VMs here, and you can see behind me one of the internal dashboards we built, uh, with Composer actually, to visualize, uh, all of the different VMs in the fleet.
- 9:33
So why spend all this time trying to match the environment to be as close as possible to Cursor production? I've kinda mentioned that a few times. We could mock it.
- 9:43
We could simulate it out. Um, but one of the really nice benefits is we get to give the model, uh, specific tools that we think are very valuable inside of the agent.
- 9:51
So one of those is that we've trained our own embedding model that allows you to do semantic search. So when you use Cursor, we go and index your code base, and then it allows the agent to make natural langua- natural language queries to find files that it might wanna edit.
- 10:07
And we did some research on this recently. We found that semantic search not only helped basically every single model inside of the Cursor agent harness, but it was particularly helpful with Composer, which kinda makes sense when you think about it.
- 10:19
Like, we trained Composer in the exact same environment that we're using at inference time, and so the model kind of becomes a power user of this tool, which is really effective.
- 10:30
So let's talk about, uh, how the release has been going and kind of where we're going next. Um, as we were doing the training process, we kind of knew that RL was working when we were able to continuously improve the model and start to see more and more improvements after more and more rollouts.
- 10:47
So we started about kinda the same performance as the best open model, and then as we trained and kind of threw more compute at it, the performance continued to increase, and to a point today where we're close to the frontier in terms of kind of the best coding agents that are available.
- 11:02
And personally, I think this is a great sign just for being able to take and scale RL and apply it to these very hard specialized tasks, like in our example, coding, but it could be applied to other domains as well.
- 11:14
Uh, RL also allowed us to kind of change properties of the model in a way that was very useful for the Cursor product. We wanted the model to be both kind of fast at generating tokens, but also the end-to-end experience of getting a result that's helpful.
- 11:29
So for example, instead of reading a file one by one, you can read 10 files in parallel with tool calling. And as you saw in the demo earlier, it makes Composer feel much faster when you have that.
- 11:39
And we think this is kind of just the start. There's a lot more we can do in this area to speed up the model. Uh, and the second one is the model learned how to behave better as an agent.
- 11:48
So in the beginning, the model was, was kinda making too many edits. Sometimes the edits were made unnecessarily. But as we trained more and more, the model actually got surprisingly better at learning to search and read files more.
- 12:01
So it would go and find the right thing before it tried to make edits, overall just being, uh, uh, you know, a bit more effective.
- 12:08
So we released Composer last month in Compers-- uh, Cursor two point O, and so far, it seems like people seem to like it. Has anyone here tried the model by chance?
- 12:17
Okay, that's pretty great. That's more than I expected, so that's great to hear. I think from my perspective, using this model and, and using coding agents for some time, I kinda describe this problem as, like, airplane Wi-Fi.
- 12:28
So when you're on airplane Wi-Fi, uh, it works, but it's kind of frustrating. You really want to do whatever you're trying to do, but it's just, it's a little slow, almost to where sometimes you wish that you just didn't have Wi-Fi at all. [laughs]
- 12:39
And I think for some of us who adopted coding agents very early, it kinda feels like airplane Wi-Fi sometimes, 'cause if it's taking ten or twenty minutes, you're in this weird, I think [REDACTED:origin] called it semi-async valley of death, where you either want something that's really fast, or you want the most powerful, most intelligent model that can
- 12:57
run for, you know, a significantly long amount of time, maybe in the background, maybe, you know, thirty minutes, hours, days. And I think when you're stuck in the middle, that's, that's very, very painful.
- 13:06
So for me, Composer, and I think other people, it's brought a lot of joy back to coding with agents that felt more like when you were writing code by hand, where you're very in the loop, very synchronous.
- 13:17
So I'm excited to see more people exploring this space as well. For me daily, uh, I'm writing a lot of plans with kind of the latest, uh, model, like the, the highest frontier, so GPT-5.1 Codex is, is really great for plans.
- 13:29
Uh, and then I'm using Composer to actually take that plan, kinda like what Dex talked about, like, take the context engineering work, and then actually go and build the thing with it.
- 13:38
So, uh, a few reflections from our research and products team on building Composer. The first is that RL can work surprisingly well for training very specific models and, you know, giving it this high-quality data and a decent amount of compute.
- 13:55
You know, at, at Cursor, we're not trying to build general intelligence. We're not trying to build AGI. We're trying to build very good coding models, and our hu- RL has worked surprisingly well for that.
- 14:06
The second one is, uh, how much tools, AI tools like Cursor, it doesn't have to be Cursor, but like Cursor, really help speed up research and development. You know, of course, our entire team uses Cursor to help them write code and debug code more efficiently, but that speed up, that increase really compounds across all of our engineering
- 14:25
efforts, so we're able to try more ideas, ship product faster, try new research, um, so it's been really, really helpful there. And the last one that's, you know, personally pretty interesting for me is that [laughs] it was interesting to see how much of the ML work in the training process was actually also an infrastructure problem.
- 14:43
They were very correlated. And going back to my time at Vercel, we saw a very similar thing where a lot of the magic moments that you can have in working in frameworks in the JavaScript or Python space, you also need to think a little bit about the infrastructure of where they're actually deployed.
- 14:57
So these things are, are more related than people might think. So those are some of our reflections. Uh, sounds like some of you have tried it out. If this is something that you're interested in and working on, we're hiring pretty much across the board at Cursor right now.
- 15:08
We just opened up an office in New York, if you're here based in New York, and we'd love to talk to you about building the best coding models in the world.
- 15:15
Thank you. [audience applauding] [upbeat music]