Opening Keynote, Michael Truell | Compile 26

Looking at the group of people that are assembled here today and the community we have in front of us, it makes me think back to when we were just getting started as a company.

And so I don't know how many of you all know how Cursor got started and what the first version of Cursor looked like and when it was released.

But we, as an AI company, come from the prehistoric times of January 2022.

That's when we started working on all this stuff, and the first version of Cursor wasn't that long ago, but again, prehistoric from AI times. It

was released in the beginning of 2023.

And the initial phase of the company's life sort of had a little bit of a detour, where we were really excited about working on tools for developers and working on AI coding, but we didn't do it at first. And the reason we didn't do it is the group of people that started this company, it was just four programmers, four really young programmers, that wanted to build things that were useful

but saw the set of people working on AI coding and basically were a bit nervous that we couldn't really compete. At

the time, the sets of companies working on AI coding were already really large.

There were dozens of startups. There were big tech companies, of course. There were

the gargantuan, even though they were small at the time and are much bigger now, but very scary and intimidating AI labs.

And we looked at all of the people working on AI coding in 2022, and we thought, "There's no room. There's not much to do. People have got that covered."

that covered." And we kind of went about our way during 2022, worked on a series of projects. But we kind of caught the bug. We couldn't stay away from it, couldn't

projects. But we kind of caught the bug. We couldn't stay away from it, couldn't help ourselves, and we started working on Cursor at the end of the year, fundamentally because we wanted to build a tool that we really liked and a tool that we would wanna use, and nothing out in the market really checked that box for us. And so we did what any group of introverted, not particularly adept at

for us. And so we did what any group of introverted, not particularly adept at company-building, enterprising developers would do, and we kind of went in a cave, and we coded in our underwear for two weeks.

And we built a prototype. And that was how we got started, and the first initial humble goal was to build a product that could be our development environment, that we could stand using. It didn't make us two X less productive than whatever we were using before. And we got to that goal after a couple of weeks, by cobbling together actually a product that was entirely

built from scratch and wasn't based on the same foundations that the first version of Cursor later became based on. We built kind of the pieces of an open source code editor from scratch.

We built language server integrations, remote SSH, at the time, a copilot integration too because there wasn't even auto-complete within the product.

And we got to something that we could stand using, and then we sent out a beta invite list. It was attached to this kind of movie magic demo,

invite list. It was attached to this kind of movie magic demo, that one of the co-founders made and got a bunch of people signing up and hand onboarded the first 20 users, walked them through how to use the product, got them set up, sat by them. And

the first user didn't really like the product that much. The second user didn't like the product that much. They actually ghost us. They wouldn't talk to us anymore.

And the third and the fourth, it was also a little bit of a tepid reaction. But we

soon got to a place where we got a couple of developers using the product and actually daily driving it every day. And that started the kind of fundamental loop that, all through all this craziness, we followed over the past few years, where every single day we just think about, "How can we make the product better for us, and how can we make it better for the community that we're building with?"

And that initial set of 20 beta testers still email with them back and forth. The next kinda phase of the community was a Discord server that we

forth. The next kinda phase of the community was a Discord server that we had. And we actually hired many members of that Discord server. And

had. And we actually hired many members of that Discord server. And

now events like this are kind of the next extension of that community.

When I look around at what we're building now, I think, yeah, one of the things that I'm most excited about is that through all of this craziness, there's a group of people whose fundamental kind of core ethos is it's a group of developers building for developers, and it's a very deeply product-focused company. And so

we have some big announcements to go through today, three big announcements. Before we

go into those announcements, I'm gonna talk a little bit about some of the ways in which Cursor has changed over the past three months. And changed, we have a lot. That first

prototype, there's not a single scrap or line of code that exists within our code base from that first prototype. There's also not a pixel on the screen that exists at all. And that happened relatively quickly because the code wasn't very good,

at all. And that happened relatively quickly because the code wasn't very good, because on the screen worked very good. But there's been turnover time and time again in Cursor and our goal is really to build something that we'd find useful, that developers in the community find useful. And with the pace of change of the technology, that's changed many times over, and that's definitely changed recently. The first big theme that we've thought of over the past

couple of months and ways in which we wanted Cursor to change is we wanted Cursor to become simpler and more powerful, and in particular, really to be fundamentally built for working with agents, to be agent first.

And that's a transition that's happened over the past year and a half, but it's really, I think, finally come into place over the course of the last three months.

And so, for instance, at this point, over 95% of users of Cursor use us primarily as an agent. The vast majority of our business is being a coding agent. At this point, even on a request basis, agents are used about five X more than any assistive features, for instance, like Tab. And then when you control for lines of code, it's many orders of magnitude

Tab. And then when you control for lines of code, it's many orders of magnitude more usage on the agent side of things. To get there, there's been lots of changes, both on the product side of things, on building a really great harness side of things, on the model side of things. And in particular, over the course of the past month or two, the way in which people experience Cursor, the pixels on the

screen, has changed a bunch with the release of Cursor 3. This is what Cursor looks like now, and fundamentally, it's agent first. You have agents in the left.

You have agents in the center.

It combines the power of a development environment that's fundamentally built for working with agents, with also all of the power you expect in a professional development environment. And so you still have the ability to edit files, you still have great remote SSH support, you have language servers running always and doing the normal linting operations you would expect from a professional development environment. So there's no compromise

there. And in addition, I think over the past couple of months, we've built a

there. And in addition, I think over the past couple of months, we've built a really great set of pro features for working with agents. And for instance, that includes things like design mode, where you can gesture at the screen that you're building with the agent, and you can ask it to change a particular element of a website. And this is part of a broader theme of we want working with

agents to feel like working with colleagues. You should be able not just to talk back and forth with them over text chat, but point at a screen together.

Cursor 3 comes with advanced features also, like recursive sub-agents.

You can have sub-agents that call sub-agents and have whole teams of agents at your disposal. You can see everything in the context, and many more features like this. A big part too of this next phase of the product has been getting to a place where agents can do entire features, entire bug fixes, and entire projects for you. And I think that most developers haven't gotten to this

point. Most people, whether it's in our product or in competitive tools, they're

point. Most people, whether it's in our product or in competitive tools, they're working with agents and handing them bits of work, 30 minutes worth of work, an hour worth of work, and they're running three to five locally on their computer and having to make local tool calls.

And that's obviously not the future. You're not going to have coding ASI and just be running all these agents locally on your computer and having them bottleneck by falling over each other on the same code base. We need to get to a world where working with agents is really like working with a colleague, and you can treat it just like you have your own team of engineers, and you need to be able to

hand off whole projects and have the agent go work on them for days, and then come back to you with the thing just done, completed and tested.

And so a big part of that has been investing in giving agents their own computer and making that experience especially simple, especially fast, and especially powerful.

And so cloud has gotten a big upgrade and a bunch of performance improvements, and is a big part of Cursor 3 as well.

Another big change in Cursor is going from being this first-party product that just is a closed-walled system that humans interact with, with really being a platform. Coding agents are fundamental infrastructure for teams. They're

platform. Coding agents are fundamental infrastructure for teams. They're fundamental infrastructure for businesses.

They're also, how everyone is coding today. And with a tool that's so central to your work and so central to a team's work, you need to be able to change the tool, and edit it and control all the aspects of it that you would like. So we were excited to announce our SDK. We think it's really important that Cursor is not just something that humans can use directly by

interacting with the product, but something that's accessible with the best UX and formal programming languages, something that's accessible by other agents too. Hackability in building a platform doesn't just come from the SDK.

agents too. Hackability in building a platform doesn't just come from the SDK.

It also comes from letting Cursor use all of the tools that you use. As we

work towards having agents work like colleagues, they need to be able to use the same tools that an engineer uses. So they need to be able to trawl around Datadog or pull from a database or use the same design tools that you have access to. And we have been excited to see the growing and vast space of plugins that

to. And we have been excited to see the growing and vast space of plugins that people have built for Cursor, both internally just ad hoc for their own tools, but also for very popular tools that are used across the user base.

And then a big component of making Cursor increasingly hackable and extensible is also investing more in the CLI. And so over the past couple of months, there have been over 50 individual quality-of-life and polish improvements to our command line interface, which you can use either in headless mode or use as a surface in and of itself. We think it's very important that Cursor is available

anywhere where you want it to be available, on web, on a desktop app, but in many cases, there will always be a time when you wanna use a terminal UI. And then lastly, a big focus for us over the past few months

UI. And then lastly, a big focus for us over the past few months has been building models.

And this is something that we've done ever since the start of the company.

In 2023, not too long after the first hacked-together prototype, where 18 of the 20 beta testers kind of ran away from us kicking and screaming. For

some reason, our ambitions went higher from that boost of confidence we got from the user base. And we started working on models. And so in 2023, that started with tab models. And the series of tab models we released in 2023 and 2024, I think sneakily were actually some of the most popular coding models over the course of those years and wrote a lot of the world's code. The

next progression in our journey of building models was starting to make the first prototype agents work in 2024 and 2025. And the way we got that to work was kind of by hacking around the API models and building small surrogate models that could patch their weak points, like when they couldn't do tool calling, when they couldn't search throughout a code base. We built models to give them those capabilities.

But over the past year, our ambition has grown a ton, and we've started working on agentic coding models. Models that are fundamentally foundation models that can do all of the actions that you would want Cursor to do. And so that has been our Composer series of models.

It started with Composer 1, which was released in November 2025.

And with Composer 1, we got RL working at scale on the workloads that we care about. And we started with an open source base, maybe famously or infamously. And

did lots of work and dumped in lots of compute to make it more useful for developers. We then scaled that up, that same process up with Composer 1.5. With Composer 2, there were kind of two big paradigm shifts. One was getting continued pre-training working, and not just doing the RL side of things, but training on tens of trillions of tokens on top of the open source models. And then the other was getting

real-time RL working. So having a new model that's updating every five hours as we learn online from what people like, what people don't like, where the models are being productive, where they're not being productive. And then we scaled that up with Composer 2.5. And we have been really heartened to see the fast interest that Composer has gotten, and that's come from a couple of things. And so far, I think it's come from a focus

on speed and a focus on cost. And this is really, really important to us.

We think it would be very sad if the models got very capable, if it was possible for anyone to build anything they'd like on computers with a giant asterisk on it, where those abilities were just gatekept to the largest companies that had lots of capital to spend on these models. We think that that would be a sad world. We want individual developers, solo hackers, to be able to use,

the best performing models that the market has to offer. And so we focused a bunch on cost and on speed so far with the latest set of Composer model releases, and we're seeing people start to notice that it kinda makes sense in steady state to have a couple of models that you use. Maybe a daily driver that's more price performant, and then going to more expensive models sometimes when it makes

sense. I will say our ambitions are to build just overall the most capable coding

sense. I will say our ambitions are to build just overall the most capable coding models, the most useful coding models overall. But it's been nice to see the focus on speed and costs starting to take hold. And so, with that, we have three really big announcements about some new things that we're working on. And so

to hop right into it, I'm gonna hand it over to Kevin, who leads one of our product teams. Thank you, Michael.

Today, I wanna share a little bit about how we're thinking about bringing coding beyond your laptop. As we've seen with Fable and a bunch of these early agent systems, agents will soon be able to run for not only just hours, but days and weeks at a time. If you think about this as critical infrastructure, your agents need

a time. If you think about this as critical infrastructure, your agents need to always be on, and they need to always be running. We don't run production servers off of our laptop for a reason. What you really want is, as Michael mentioned, a teammate that you can turn to, whether that's when you're out visiting a customer or on a run or an idea strikes you right before you're about to

go to bed. A teammate that you can turn to who can actually go and implement that feature request, who can make it real, who can deliver that, a fully productionized version right when the idea hits. We've been working on cloud agents to deliver just that, and I wanna talk about a few of the design principles that we think about

as we've built out cloud agents. The first is that cloud agents need to be autonomous. They need to always be on,

autonomous. They need to always be on, and they need to work from anywhere.

So we have some really exciting updates across these three different dimensions that I wanna talk through. To make agents autonomous, we gave them their own dev environments, so they can work just like you all do.

They have their own computer and their own resources, so they can actually test the code that they're working on, they can deliver demos, and they can act just like you all do as you build software. So what goes into a dev environment? Well, there

are a few different components to this. The first is that obviously agents need code. So they need cloned repos. They need installed dependencies. They

need code. So they need cloned repos. They need installed dependencies. They

need credentials to be able to access build systems and internal tool chains.

And on the other side of that, you unlock this new set of capabilities for what agents can do for you.

They can run those tests. They can verify their work. They can produce screenshots and things that you can visually interact with and circle and describe and continue to prompt. And so it is far more interactive than the agents that you all

to prompt. And so it is far more interactive than the agents that you all may be used to working with. Behind me, you can see what an autonomous agent working in the cloud can do. It's produced a demo of the work that it's just done.

You can review this. You can circle it. You can interact with it. It makes it so much more real when an agent has their own developer environment. Second,

agents need to always be on.

Instead of prompting an agent to do work, we're moving towards an era of loops and agent systems where agents are going to continue to be working on our behalf at all times. They'll be kicked off programmatically, and they may even prompt

all times. They'll be kicked off programmatically, and they may even prompt us more than we prompt them. This is only possible if you have really fast and really reliable agents. Building always-on agents is a hard infrastructure problem, and we are learning that the hard way.

Over the last few months, we've made cloud agents three times faster, and we've hit three nines of reliability. Our goal is ultimately to provide you all with that teammate, that reliable cloud agent that can do all of these new amazing things equipped with its dev environment. These reliability and performance gains

really show up when your agents are working 24/7 for you. We

built automations in SDK, to be able to make these loops really easy to build and deploy and to be able to run in the background. One of my favorite automations comes from a customer, Amplitude, who is currently in the process of migrating twenty thousand different instances of React components and swapping them out for their Tailwind equivalent.

This is all running in the background via an automation and a custom migration agent that they've built and deployed on top of Cursor. And it's not just Amplitude.

We've had over six million automation runs since releasing our automations product just a few months ago. And finally, you should be able to work with your agents anywhere. You can now kick off agents from the apps that you're most familiar with,

anywhere. You can now kick off agents from the apps that you're most familiar with, whether that be working with a colleague in Slack or Microsoft Teams, whether that be a new ticket that comes into Jira or Linear. We also have a cloud API and webhooks to be able to invoke these cloud agents. And of course, you can then work

with those agents across these different surfaces, as Michael showed, from our new agents window to your editor and IDE to the CLI in the terminal. But today,

we're really excited to introduce Cursor Mobile in beta.

This has changed the way that we have been building Cursor with Cursor. With Cursor

Mobile, you can now work with agents on the go to unblock them, to dream up new ideas, and to build freely from wherever you are. You can see all your agents running. You can see which ones are blocked. You can connect to all of your

running. You can see which ones are blocked. You can connect to all of your repos. You'll also be able to see the artifacts that the agent is producing.

repos. You'll also be able to see the artifacts that the agent is producing.

Gives you short, verifiable screenshots for you to be able to interact with on the go.

If anything looks off, you can annotate that screenshot, you can prompt your agents, and you can get them back to work. And for those of you who want to continue to work locally, maybe your desk looks like a bunch of Mac Minis right now, or you really just love juggling your laptop half open, Cursor Mobile will include remote control to be able to work with your local agents while you're on the

go. We're making Cursor for iOS available today to anybody in the audience. So

go. We're making Cursor for iOS available today to anybody in the audience. So

I see everybody pulling out their phones already. Please scan the QR code behind me to get access to the TestFlight, and we're really excited to be opening this up to the world in the coming days. We cannot wait to see not only what you build with Cursor Mobile, but also where you start to build from.

Next, I'm really excited to hand it over to Tomas to talk about another surface that we're building.

Thank you, Kevin, and hi, everyone. I am so excited to be here today. So my name's Tomas.

I'm one of the co-founders of Graphite, and I joined Cursor through our own acquisition this past January. For those of you who have built software on teams, you know that building software is about way more than just writing code. It's

about testing, reviewing, merging, and deploying that code. At Graphite, we built best-in-class tooling to accelerate those parts of the workflow. We serve the best and most demanding engineering teams, including Shopify, Snowflake, Notion, Figma, and countless others, and they depended on us every day to power their developers in these critical workflows and keep everyone productive. However, over

the past few years, we've noticed a trend.

As these companies adopted AI tooling, the tools that they relied on started to become unreliable. That's because over the past few years, AI tooling has totally

become unreliable. That's because over the past few years, AI tooling has totally changed our industry. It's enabled every developer to be a ten to a hundred X developer, but that change has required fundamentally different tooling. That's

why when we were acquired by Cursor, we accelerated our most ambitious project to rebuild that tooling from scratch.

Today, I'm incredibly excited to announce Origin, our agent native Git platform.

With Origin, you- Thank you. With Origin, you and your agents can create repos, share code, and

Thank you. With Origin, you and your agents can create repos, share code, and manage changes all within the same ecosystem that you already use and love.

It's scalable, extensible, and built to keep code moving. So let's talk around what agent native really means. When we sat down and started to think around that, the first word that came to mind was scale. As we've seen developers adopt this AI tooling, we've just seen so many more lines of code, commits, pull requests. And

so we went back to basics and architected a novel Git architecture. We leveraged

the primitives offered by the cloud providers to provide better scalability, reliability, and performance so that we can keep up with these changing demands.

In early load tests, we simulated thousands of agents, and what we've seen is that we can push and pull at the same time to a single repo, enough to keep up with current demands and with what we expect future demands to be. The results

are incredible and give us confidence that Origin is a rock solid piece of Git infrastructure built for scale, both human scale and agent scale. The second thing that came to mind was extensible.

As Michael just told us, Cursor is a platform. And so as we started to think around what it would mean to build an agent native Git platform, our first thought was that we had to make it so that you could build whatever you wanted on top of it. Through our APIs, our MCP, and third-party app platform, you and your agents can use Origin for whatever works for you. With generous rate limits and a

comprehensive API, you are in full control of your own data. The third thing to know about Origin is that we built it to keep code moving. Powered by the same intelligence that powers Cursor, Origin can resolve merge conflicts, fix CI failures, and address comments.

It automatically figures out next steps for each PR and only tags you in when it needs to.

By leveraging the agents to fix and review PRs, it can keep code in motion in more than half time to review.

Origin is already live on cursor.com, both internally and for select design partners, and it will be rolling out to everyone this fall. If you're interested in building the future of collaborative software development with us, sign up for the waitlist at cursor.com/origin.

Thank you, and back to Michael.

Thank you, Tomas.

And one final announcement.

We're excited to talk today, not just about the product side of things, but about our next model. And we are very happy to announce that we are late in the stages of training a very different type of model than we've ever trained before, and it's different in three ways.

First, it's big, and it is as big as Opus and GPT. Second, it's trained from scratch, so it's not starting from open source bases. We love open source, and we want to find more ways to contribute to open source. But starting from scratch will let us control all of the behaviors of the model and tune it even more for the workloads that we and you care about. Crucially, also,

we are running on ten to twenty X more compute than we've ever had access to. Our

last model used a little bit more compute than we had had in the past, but this is really the first model where we're scaling up compute a ton. And this is a very, very, very big deal because in the past, our Composer models, from Composer 1 to Composer 2.5, they were trained on a very small set of GPUs compared to Frontier Labs. And that really limits what you can do. The things that we were doing

Frontier Labs. And that really limits what you can do. The things that we were doing to make the model better and better and better were fundamentally blocked by whether we could run on more GPUs for more hours. And so this scale-up of ten to twenty X really lets us, we think, get to frontier, and hopefully soon leapfrog it, and give you all exciting new powerful capabilities. And then last,

this is going to be a model that's gonna be intelligent beyond just coding.

We think that this is important for what Cursor would like to do. We want to make it so that anyone can build anything they'd like on a computer, and the bottleneck to that is starting to become not just the code-writing side of things, but everything that you would want out of an engineer colleague. And that

means using tools that engineers would use. That means long-range planning.

That means actually testing the software and clicking through buttons. That

means also having great UX around showing users exactly what was changed by the agent. But we're gonna take a step outside of just coding and make this model

agent. But we're gonna take a step outside of just coding and make this model much more generally intelligent. We are deep into training. It's been kicked off and will be released in the next couple of weeks, and all of this is backed by our partnership with SpaceX, which as you all know, is a little bit more than a partnership.

It's been a slow news day.

I think that this is both exciting for this particular project, and kind of the next series of model releases that we're looking forward to, but also kind of hearkening back to what we were talking about at the start. There's so few players and institutions in AI that can really co-design both the product side of things and the model side of things. And I think the fundamental company DNA of the other

players are all that of maybe large tech companies or maybe things that started out as labs and then kind of backed into the developer and builder side of things. And this is a company that,

of things. And this is a company that, for better or for worse, I think for better, is really fundamentally about developers. That's what we started with. That's what we care about. This company is made up of, fundamentally, people that want to build a

about. This company is made up of, fundamentally, people that want to build a tool that's useful for them. And so this next phase of the company, I think, elevates for the first time a group of people with that product ethos, with that developer ethos down to its core, and gives that group the ability not just to edit the pixels on the screen, but also to edit the fundamental capabilities of the

models, which is an important piece of the product.

And so really excited about both this next release and just the series of releases we're gonna see over the next few months. And so there you have it, three big announcements. The app, mobile app being released today,

big announcements. The app, mobile app being released today, the start of taking on GitHub, and a first sneak peek, the first time we've ever talked about it, of this new model, and our plan for models going forward.

Thanks.