Cursor Release Notes

Hosting Git repositories at scale is a nightmare

When Linus Torvalds designed the first version of the information manager from hell (that's actually the tagline for Git, look it up), he had a very specific use case in mind: his own. He wanted to replace BitKeeper, the distributed version control system that was being used to develop the Linux Kernel. Of course, the replacement had to be distributed too. The Kernel is an unusual software project; it is extremely decentralized, with many different maintainers for its many different subsystems. A distributed version control system is a natural fit for this workflow.

Twenty years later, Git has become an industry standard, but the truth is that its distributed nature is more of a hindrance than an advantage. The average open-source software project doesn't operate with a decentralized workflow. The average company definitely doesn't. They use the many advantages of the distributed model (such as being able to work offline, delay pushes, etc) but they very much rely on a centralized host. And hosting a Git repository, it turns out, is an incredibly hard thing to do.

What's hard about Git?

The challenge in hosting Git repositories at scale is inherent in the design of Git itself: a distributed version control system means that all instances of a repository are identical. There's nothing special about the repository on a Git server that doesn't apply to a repository on a developer's laptop. Although at first it may appear that this makes hosting Git repositories straightforward (simply put an HTTP daemon in front of an on-disk copy of a repository and you've got a Git server going!), there are many hard scalability and reliability challenges that make this quite the opposite.

In a normal Git repository, your code and metadata (files, commits, trees) are compressed and stored in packfiles — a simple binary serialization format which is convenient to deal with on a local machine, but not ideal to manage at scale on a server. Packfiles are the fundamental building block of Git storage and Git networking. When you push or fetch data from a repository, it's transferred as a packfile.

This is how Git works by design, but it would be fair to think that it needn't be that way. After all, you do not control the Git client (at least not without annoying your users and adding a lot of friction), but within the walls of your own server, you can do anything you want. Nothing ties you to using packfiles — Linus is not going to come over and check. The only restriction is that you do need to receive and send packfiles over the network for all Git operations.

Over the years, companies that tried hosting Git repositories at scale noticed that this packfile-based design was a major limitation on both availability and scalability. Packfiles are large binary files that must exist on a filesystem for Git to access them. The simple approach of having an HTTP server in front of a repository on disk has a very low ceiling. Ideally you'd want the repository to exist on many disks and many machines (this lets you run many Git operations in parallel, and keeps your repository available when a server crashes). But how do you do that?

There are broadly three possible approaches to accomplish this, in increasing order of complexity: distribute the filesystem, distribute the packfiles, or distribute Git itself.

Git without packfiles

Git is a content-addressable data store. All objects in a Git repository (blobs, trees, commits, etc) are keyed by the SHA-1 of their contents. This is something that intuitively maps very well to a distributed key-value store (the key is the SHA-1; the value is the actual object), and could provide a clean way to scale out the storage of a repository. But this actually doesn't work.

Here's the issue: the actual layout of a Git repository is a directed acyclic graph (DAG for short). You can look up any object via its SHA, but to perform even the most trivial operation in the repo, you must actually walk the DAG step by step.

If you want to do an operation like listing the recent changes in a repository, you must process its commits. When you process a commit, you get a pointer to the root of its tree. From that tree, you get pointers to each file and each subtree. From the original commit, you get a pointer to its parent (the one that comes before it in the history). Crucially, at every step of this walk, you don't know the value of the next pointer until you fetch the previous one. If every fetch requires a round trip to a distributed store, things become very expensive very fast.

This approach to distributing Git at the object level has been tried before, many times, and it often fails at scale. The most promising implementation was attempted by my former mentor Shawn Pearce when he was working on the version control systems team at Google. His approach was storing the objects in a distributed hash table. This was only possible thanks to JGit, a custom Git implementation in Java. Like any good ol' Java library, JGit provides enough interfaces and factories and interface factories to abstract all the details of a normal Git repository, including replacing its on-disk packfiles with a DHT. Although the system worked and results were good enough for normal Git operations, the limitations of the Git protocol (which again, require packfiles to be sent over the network regardless of how you store data on the server) made the git clone performance bad enough to discard the design altogether.

GitHub and filesystems

A couple years after Git started to escape its Linux Kernel bubble, a scrappy startup was born in San Francisco. GitHub was founded in 2008 as a social coding platform with a very prescient tagline, "Git repository hosting: no longer a pain in the ass." I'm not joking here either, look it up. There was, all the way back in 2008, a broad consensus that despite (or perhaps because of) Git's distributed design, you actually needed a centralized way to host Git repositories to make them user-friendly, and doing this was very painful. GitHub was set on changing that.

Its platform started as (and mostly still is) a Rails monolith. The very first versions were running off a single, albeit beefy, machine, with a Ruby server and copies of the repositories on disk next to it. Scaling a Rails app is easy: deploy more instances of it. But in this particular case, since Git is involved, they quickly ran into the recurring question we're trying to solve here: If the Rails app needs to access the Git repositories on disk, how do you deploy more copies of them?

Being a thrifty bunch of misfits, the early systems engineers at GitHub tried the simplest approach that could possibly fix their scaling problems. The thinking was that, if they focused on distributing the filesystem (instead of packfiles, or Git itself), they could keep the Rails app unchanged and spend their time shipping more features for the ever-growing user base, instead of doing weird stuff with Git. Very pragmatic. It didn't work.

The team attempted many approaches to a distributed filesystem for Git data: the most obvious one, using NFS to store all repositories on a centralized server, was quickly discarded. The default implementation of Git makes a lot of assumptions about filesystem semantics (locking, tearing, reading, syncing...) that ensure decent performance on the local filesystem of a slow developer laptop, but pay no attention to how they behave over a networked filesystem. It was slow, and it was buggy.

Further attempts were made with (frankly, in retrospect, horrific) technologies that replicated the filesystem at the block level. A short-lived deployment with GFS. A longer-lived deployment based on DRBD. They all hit a wall. They were terrible to operate day to day, and they didn't make up for it with good performance. It all boils down to the design of packfiles on disk.

We've already seen how Git's graph-like data structures make round-trips prohibitively expensive. Unfortunately, a very similar principle also applies to the underlying data on-disk. There is no correlation between the layout of objects in the DAG and the way they're placed in a packfile. The key heuristic used when generating packfiles is minimizing their size; objects are placed randomly throughout the pack, they are compressed, and crucially they're rarely stored whole. Most objects are stored as a delta on top of another object in the same packfile. Reading an individual object, after following the many logical hops in the graph data structure, also involves following physical hops in the on-disk format.

This kind of random walk across gigabytes of data, which must happen for every single Git operation performed on a repository, just doesn't play well with a networked filesystem (whether it replicates at the file or at the block level). The only way this works without slowing down to a crawl is if you can cache the whole file locally. But with hundreds of thousands of repositories in the same filesystem, caching is not an option.

Eventually, the systems engineers at GitHub bit the bullet and gave up distributing the filesystem. They started developing an RPC system so that repositories could live on dedicated fileservers, and updated the Rails app to do all operations remotely. This provided a good chunk of horizontal scalability, but didn't fix their availability, nor the performance for the busiest repositories. After all, every repository was still stored only on a single machine.

Spokes and Consistency

Spokes was originally developed at GitHub around 2013, and it has since become an industry standard. Most Git hosting services use a variant of the Spokes approach (application-level replication for Git repositories) in their architecture. The main reason Spokes has worked well for many years is that it made three fundamental choices that, over time, have been proven to be optimal:

• It doesn't distribute Git itself; it works at the packfile level.
• It stores all data as actual Git repositories on local NVMe disks.
• It replicates the Git data, but keeps all copies consistently in sync.

Because of the random read patterns across packfiles we've just discussed, storing plain Git repositories on NVMe drives is basically a requirement to ensure all basic Git operations remain fast. They also keep clones efficient because you don't have to transform the data into what the Git client expects. They also let you focus on building a product on top of Git, as opposed to maintaining a fork of Git yourself that can operate on your weird repositories.

Keeping all the copies of the data consistently in sync is also, crucially, very good. This is something you find out the hard way, but the Git client really doesn't play well with eventual consistency. If your local Git client pushes a commit and then fails to read it immediately after a fetch, that's bad news. Git finds that very confusing. If you run your CI pipeline across a hundred runners and three of them don't find the commit they're supposed to test after cloning your repository, that's bad news. It's also a very poor user experience.

Working with an eventually consistent view of a Git repository has a lot of sharp edges, whether it's on the client or in the backend. Hence, Spokes pays a very high complexity cost to ensure the system is always fully consistent. Let's see exactly what this means.

Spokes is a consensus-based distributed system. It works by storing several copies of your Git repository on different servers. Whenever you push new data, an orchestrator fans out your push so that every instance of your repository receives a copy. The "fan-out" is synchronized with a classic consensus algorithm called 3PC (three-phase commit) so that a push is only accepted if a majority of the nodes acknowledge it.

Before we can talk more about the way Spokes uses 3PC, we need to understand how a Git push works. A Git push has two components: a packfile and a reference transaction. The packfile, which we've already talked about, contains the objects you're pushing to the repository (blobs, trees, and commits with your changes). The transaction is what actually publishes your changes to the repository by updating one or more references (e.g. the branch you're working on) to point to the commits you've just pushed.

This separation is very convenient here, because a pushed commit is not visible ("reachable" in Git parlance) until the reference that points to it has been updated. This means we can implement consensus for our pushes by fanning out the packfiles to all hosts simultaneously (we don't need to synchronize here) and then doing three-phase commit with the reference transaction, which is much smaller and faster to synchronize than the packfile. Git itself has support for preparing reference transactions: it can acquire a lock on the reference, verify that the existing value is what's expected, and then hold the lock until it receives a commit or an abort command for the transaction.

Spokes distributes packs and then performs a three-phase commit for each push’s transaction. You can increase the number of replicas and the latency in this simulator to see how it affects commit throughput.

With this design, we ensure that every push is fully synchronized across all the replicas. Reads (fetches, clones) can then be safely routed to any single replica, because every replica is always up to date.

This is essentially how Spokes works, and it has been working quite well for the past 13 years. Of course, Spokes is not perfect — no system is. In 2026, the way people use Git repositories has changed drastically, and we have learned many important lessons about building distributed systems along the way. Time and experience have shown which of Spokes's choices turned out to be optimal, and which did not.

One flaw that has turned out to be critical is the constrained horizontal scalability of 3PC. When Spokes was initially released, three replicas per repository was the sweet spot. You could serve your average repository from three copies with capacity to spare, with enough redundancy to keep accepting pushes even if one machine went down.

In 2026, things look very different. The average repository for an enterprise company is now a massive monorepo. Three replicas are not enough to serve the traffic for such repos, particularly when it comes to CI. Of course, nothing stops Spokes from running with more than three replicas, except the dreaded tail at scale. Three-phase commit maps very elegantly to the Git transaction model, but as a consensus algorithm, it has fundamental limitations: the latency of every step is bound by the slowest of all the servers in the cluster. The more replicas you add to a cluster, the worse push throughput gets.

This scalability constraint also applies the other way. When agents work with Git repositories at scale, they often operate outside of a monorepo by creating vast numbers of small repositories, many of them throwaway, and most of them barely touched. Spokes struggles here because it still requires three replicas for every one of these repositories. Three mostly idle replicas, which cannot be trimmed down because then the system wouldn't be fully consistent and data loss would be possible. With three-phase commit, the floor is always too high, and the ceiling too low.

Another flaw, impossible to see up front, but painfully obvious after having suffered through it, is that Spokes can be rough to operate at scale. Because the repositories on disk are always the source of truth for consensus, every copy of every repository is very important. You have to treat repositories as pets, not cattle.

This means, for starters, that you need to know exactly where every repository is. This adds a dependency (and a potential availability issue) on an external database that must keep a very large routing table mapping every repository to every machine where it's replicated. Every repository must also be checksummed, and its checksums constantly updated in that table, to ensure the repository remains valid on disk. As soon as something bad happens to the repository (and trust me, bad things happen all the time — Git can be very finicky in practice), you must detect it and schedule a repair job to bring it back to a healthy state. And you must do it very quickly! Because, again, the repositories on disk are the source of truth. A corrupted copy is as bad as a missing one. If two of the three copies are corrupt, the system can no longer accept pushes: there's no quorum.

Continuity

Continuity (Cnt for short) is the Git storage system we've developed at Cursor, with a very clear approach: learning from everything that Spokes did well, and fixing the things that, after many years, we now know are problems.

Cnt is a simple system (a system cannot be easy to operate if it is not simple). The core primitive behind it is a write-ahead log, which we store in S3-compatible object storage. In production, we run directly on S3, but we designed it so it can be deployed on any cloud.

When a repository receives a push, we store the push as a WAL entry in S3. We never acknowledge a push until it has been fully persisted. Each push is stored as a separate object; we write the pushed packfile to disk and upload it to S3 simultaneously. Uploading a WAL entry, however, does not publish it. A push is only visible once we successfully prepare its reference transaction on a local copy of the repository and record a pointer to the WAL entry in the WAL index file, which is its own object in the store. This forces all pushes to be linearizable.

We try not to do one single S3 write per push, because in busy repositories, this puts a hard cap on push throughput based on the latency of the S3 PUT operation. With a carefully tuned batching implementation, and with the only requirement of having to synchronize the reference transaction with a single local repository instead of a quorum of replicas, we have a system that can ingest pushes as fast as our disk allows.

The local copy of the repository is, of course, a normal Git repository stored on a very fast NVMe drive. We do the same thing that Spokes does because I think Spokes got that exactly right. It allows us to reuse all the amazing OSS work of the Git community, including the upstream Git client and its many performance optimizations. It lets us focus on shipping new features, instead of doing weird stuff with Git.

Consensus

We've seen that one thing that makes a Spokes cluster hard to operate is that it's very important to keep track of the location of every repository on each server. Cnt does this very differently. Where does every repository live? The answer is "anywhere". It doesn't matter! We treat repositories like a warm cache on disk, but the source of truth is always the write-ahead log in S3. The system is stateless, and there are no routing tables (and no relational database to operate — hashtag blessed). If a repository is missing from the local disk when accessed on a host, we just materialize it from the WAL. We can do this very efficiently, but of course we don't want to do this all the time, because it'd be wasteful. In production, we use rendezvous hashing to map a repository ID to the list of nodes where we expect it to be. All the state we require to route repositories is the repository ID and the current set of healthy nodes in a cluster. But if this state gets out of sync (e.g., a node becomes unhealthy), that's perfectly fine too. We'll just materialize the repository on whichever node comes next.

What about consensus? Elections? Which server is the primary for a given repository? It also doesn't matter! There's no state and no consensus here. Any server can be the primary. All updates to the write-ahead log are synchronized with an atomic compare-and-swap (CAS) operation on S3, so it's always safe for any instance of a repository to receive a push. Again, just like with routing, letting an arbitrary server act as the primary isn't the most efficient thing (it leads to CAS retries, which can delay pushes), so in practice we always choose the same server as the primary, the first one in the ranked list from rendezvous hashing. But in the corner cases — when there's a deploy, a failover, a network blip — we just don't care exactly which server is the primary. The system is designed to always be correct when degraded, and always fast when healthy.

Replication

Having a write-ahead log in S3 opens a world of possibilities when it comes to scale. We can have literally any number of replicas, because the scalability of S3 is unmatched and all the replicas catch up directly from there. We perform optimistic replication by sending gossip UDP packets around our cluster. The packets contain all the required metadata for each replica to catch up directly from S3 after every push. "That is insane," I hear you mumble from behind your screen across time and space. "UDP is not a reliable transport." Of course it isn't. Nothing is reliable in a distributed system! The wire is not reliable, the routing is not reliable, and the topology is not reliable either. But it's OK: it doesn't matter. Each replica knows the ETag of the last version of the WAL index it's caught up with. When you perform a read operation on a replica, we do a conditional GET to S3 with the ETag we expect. A 304 response with no body (conveniently, an almost instant operation — less than 10ms on average because it's a metadata-only S3 operation) means we're up to date and we can serve the fetch or the clone straight away. A 200 response comes with the newest version of the WAL index, which we use to catch up before serving the read.

It doesn't matter if the replication UDP packet is lost, or if it arrives at the wrong server because the topology shifted. All reads on all replicas are fully consistent, because they're verified against the source of truth, which is S3. The system is designed to always be correct when degraded, and always fast when healthy.

The implications of this are twofold. First, because the system is always consistent, building infrastructure on top of it is trivial. We (our agents, our web interface, our clients) always see a globally consistent view of the repository. And because the system scales in both directions, every repository gets just the right number of replicas. A large monorepo can be deployed across hundreds of replicas to serve all the load from its CI jobs. Millions of tiny repositories created by agents can be served with one replica each; we don't need more than one to ensure availability, because S3 is the source of truth. In fact, an idle repository doesn't even need that: when a replica hasn't received traffic for a while, we garbage collect it from the node's disk, and simply materialize it again from the WAL the next time a fetch comes in.

Compaction

Write-ahead logs require periodic compaction. You cannot let the log grow unbounded: a full restore replays every entry, so the more entries, the more expensive it becomes.

Coincidentally, a normal Git repository also requires periodic compaction, even though Git is not based on a WAL. We've seen that the fundamental unit of storage in a Git repository is the packfile. Each time you push to a remote copy of a repository, or fetch into your local copy, you create a new packfile. This doesn't scale indefinitely: each packfile has its own attached index, which allows Git to efficiently look up the objects it contains, but this lookup is only efficient on a per-packfile basis. If you're looking for a specific object, and your repository has 100 packfiles, you'll need to open the index for each one of them and look up the object until you find it in one of the packfiles. An efficient operation is not efficient if it must be performed hundreds or thousands of times.

Modern Git has gotten very good at working around this; it now supports multi-pack indexes and incremental geometric compaction. But eventually you must bite the bullet and repack your Git repository on disk. Historically, this has been a constant availability issue for systems like Spokes, because repacking is a very CPU-heavy operation, even when done incrementally, and it must be performed on all the replicas of the system. Accidentally triggering a maintenance operation on two or more Spokes nodes for the same repository will easily cause the repository to fail over.

Here, we amortize the cost of compaction. Only the primary does compactions, and the result of the compaction applies to both the on-disk repository and the WAL. Since all replicas follow the WAL, they also follow the compaction events. Replicas don't repack; they simply download the already-compacted packs from S3, trading bandwidth for CPU.

Scale

Replication and compaction are the two key factors that determine how well a Git storage system behaves under load. As we’ve just seen, they’re intrinsically linked: the more pushes per second a repository ingests, the more read performance degrades, because the packfiles of every push must be compacted for Git operations to remain efficient. If you replicate these pushes, the compaction must be either replicated or performed independently on each replica.

Continuity’s WAL-first design offers fully consistent horizontal scalability: you can deploy an arbitrary number of replicas, and the throughput for read-only Git operations grows linearly with them. Because all replicas in the cluster are fully consistent, this allows us to scale the Git protocol (clones, fetches) and all the RPC operations that Origin performs on top of repositories (web UI interactions, the REST API, all our agentic interfaces, etc.)

We have run synthetic stress tests with up to 100 replicas and seen consistent linear scaling for reads, without any regressions in push throughput.

The push throughput of a cluster depends on the latency at which we can update our WAL on S3. Using S3 Standard, we can sustain up to 120 pushes/s while compacting and replicating the compacted data to all other nodes. We have also deployed high-performance clusters on S3 Express One Zone, which has much lower latency for PUT operations. There, we can ingest more than 300 pushes/s, and we are effectively bottlenecked by the speed at which Git can compact the on-disk data. We’re working on innovative ways to lay out this data on disk to reduce the impact of compaction: our goal is to continue optimizing the speed at which a Git repository can ingest code without relaxing our hard durability and consistency guarantees.

WAL as truth

S3 is a great piece of technology. The whole concept of blob storage that was pioneered with the S3 API has turned out to be a very powerful building block for large data storage systems, and this most definitely also applies to hosting Git repositories. The design presented here is novel on many ways, but it's not the first one to store packfiles as blobs. Azure DevOps (Microsoft's own competitor to Microsoft's own GitHub) has a very successful Git storage system that stores packfiles in blob storage and their references in a relational database (MS SQL Server). There are many trade-offs to a system like this. A relational database scales well with large reference transactions. But then you have to operate a relational database. We have a strong belief that the consistency of Git data is more important than any other consideration. This is what really tipped the scales for us into designing a WAL-based system that doesn't depend on external databases.

There are many things that can go wrong with a Git repository in production. Data corruption at rest, bugs during repacking, races during pushes. It's one big collection of corner cases. Most of these have been ironed out in Git upstream. But not all of them. No system is without bugs, not even those that are OSS and widely deployed. Our consistency model ensures that we keep track of every fundamental operation that happens to a repository. We never acknowledge a push until it has been fully persisted to the WAL. We linearize all pushes. Every view of every repository we access is always fully consistent.

Since every push is in the WAL, we can look at every state a repository has ever been in. We have full provenance data for all pushes, and also for all repacks. We can rewind and fast-forward every replica. We don't have to synchronize any state with any external database, whether it's a database that only stores references, or a database that stores all object data. When (not if) we hit a bug in Git, we can pinpoint exactly what happened and revert it. And besides the bugs that already exist in Git, we introduce very few new ones, because throughout all this, all Git operations are performed on a normal Git repository on disk, using off-the-shelf tooling.

Origin

We are acutely aware of how important it is to host somebody's source code. I think everybody who reads and understands this blog post is just as aware of it. A company can grind to a halt if its developers cannot push or pull from its Git repositories. The productivity cost of five minutes of downtime in your CI system is hard to quantify in dollars, but it is, by any measure, a humongous amount.

Agents have fundamentally changed the way we work with software, and in many ways they've made this situation worse. More code, more PRs, more CI runs. Version control is at the core of all of this, and it is possibly the hardest thing to change overnight.

We've faced these difficulties internally at Cursor for many months now, and we've put considerable thought and care into building a platform that solves them for us and that can hopefully solve them for our customers too. Our focus right now is on providing the smoothest possible off-ramp into more reliability, more performance and more scale, and making the migration as painless as possible.

Origin is not an experiment; it is the result of many decades of experience building these same systems, from people who deeply understand the magnitude of the challenges involved. We have an engineering and operational philosophy that has been proven to work, and a strong commitment to continue evolving it as the landscape of version control evolves.

We're hoping you'll place your trust in us and our platform.

Original source

Cursor can now host your code.

Origin begins rolling out today in early beta on all paid plans. We're starting with the essentials, designed for agent scale: repos, pull requests, code browsing, and GitHub sync. Agent-native features ship soon.

Origin Repos

The new Codebase tab is home for Origin repos.

Click +New to create a new repo and name it. Once you do, a page shows you how to install the CLI, with commands for how to clone a repo or push a local project. Push, and your code is hosted on Origin.

Name your codebase when you create your first repo. That name becomes part of every repo's URL: cursor.com/codebase/acme-corp.

Bring your GitHub repos

Your GitHub repos can sit alongside the ones Cursor hosts. Connect GitHub to Cursor, pick your org, and you'll see the repos you can sync. Select one and Cursor pulls it in. You choose what gets synced and can disconnect a repo at any time. Anyone with read or write access to a synced repo can view it in Cursor too.

Synced repos update in real time. Browse, search, and pull from the copy in Origin. Pushes keep going to GitHub, which stays the source of truth for anything started there. Icons next to each repo name tell you which ones Cursor hosts and which came from GitHub.

Pull requests

Every repo has pull requests. Open one to see the timeline, commits, checks, and files changed. Review the diff, leave comments, and merge.

Pull requests on synced repos sync both ways: comment in Cursor and it posts to GitHub, react or reply on GitHub and it shows up in Cursor within seconds. Got a review assigned to you on GitHub? Review and merge it from Cursor.

Agents in every repo

Your code, PRs, and agents are now in the same place. Ask Cursor questions about code you're browsing. It can answer, make changes, update PRs, or push a branch.

App extensions for Cursor repos

We're building an app ecosystem so your whole stack works seamlessly with Origin. Integrations with Vercel, Depot, and Buildkite are already available, with more coming soon.

Connect Vercel from a repo's Apps tab and every PR gets a preview deployment where you can test and make comments. Merge, and it ships to production. For CI, connect Depot or Buildkite. Both run your existing GitHub Actions workflows and Buildkite also runs its native pipelines.

Settings

Every repo has settings. Check sync status for GitHub repos, manage who has access, and see which apps are connected.

Origin is rolling out in early beta to all paid plan users starting today, except enterprise orgs whose admins opt out. Name your codebase and create your first repo.

Learn more in our docs or get started today.

Original source

Agents are only as capable as the environments they run in. Fast, reliable development environments allow agents to take ambitious, long-running tasks from start to finish.

Until now, every cloud session began with extensive setup: boot a machine, clone the repositories, and run the install script. On a large, complex repo, this just-in-time boot could take several minutes before the agent started executing.

Today we're introducing builds: ready-to-use copies of your development environment that Cursor prepares continuously in the background, at no additional cost. When you kick off an agent, it starts in a ready environment so you get a response up to 3x faster.

And when a bad commit or dependency update breaks your environment, agents keep using the last successful build. Your work continues uninterrupted while you debug in the background.

Faster boot times

A build is a copy of your development environment that Cursor prepares in the background. By default, Cursor runs a new build every hour. Instead of setting up the environment from scratch each session, agents boot into a ready version: repos cloned, dependencies installed, and the install script fully executed.

When a build succeeds, it becomes the environment that future agents start from. Cursor keeps warm copies ready with new agents forking a live machine instead of restoring one from disk. This allows sessions to start almost instantly instead of keeping the next agent waiting.

With environment setup already complete, agents get to real work much faster. At Cursor, our internal environments now boot 10x faster and time to first token is 3x faster.

Our customers are seeing the same:

We kick off more than 2,000 automated agent runs a week without any manual prompting. With builds, every run boots quickly into an environment we know is good and broken builds never take down the agent fleet. Our largest, most complex repos now start in just a few seconds.

That combination of speed and reliability is what lets us hand more of our engineering work to agents that run entirely on their own.

Blair McAlpine
Senior Engineer, Faire

More resilient agents

Cloud agents always start from the latest successful build. If a dependency bump breaks your install script or a Docker build fails, that build never becomes active and you're notified of the issue. New and existing sessions keep running safely while you debug the environment in the background, either manually or with an agent.

Better observability and easier debugging

You can now inspect each build directly in your Cloud Agents dashboard, with:

• A Builds tab for each environment, with type, status, start time, and versioning
• Build details with logs and the exact commit SHAs the build captured
• A record that ties each agent run to exactly the build it used
• A configurable threshold for a build's git state so agents don't start too far behind your default branch

Agents can also inspect and manage builds using the built-in Cursor Cloud MCP.

Get started with builds today

For an existing environment, open it in the Cloud Agents dashboard, go to the Builds tab, and click Enable Builds. Or click Run setup agent first to test the migration and review any proposed config changes.

Because builds work by using filesystem snapshots, there are a few things worth checking at this stage:

• Update your install command to cover anything that can be prepared ahead of time, like dependencies
• If install needs credentials for private registries, use team or environment secrets. User secrets stay out of builds and are added when the agent starts.
• The start command still runs when you first prompt an agent. Use it for services that must be fresh when the session begins, like bringing up Docker containers or other long-running processes

On August 17th, all new and existing environments will use builds by default, with no additional cost to you.

Learn more in our docs.

Original source

Agents do their best work when they start in a ready environment: repos cloned, dependencies installed, and your install script already run.

This release introduces builds: ready-to-use copies of your development environment that Cursor prepares in the background. Agents boot into a ready environment instead of setting up from scratch each session. Builds are included with Cloud Agents at no additional cost.

Faster starts

Cursor runs a new build of your environment regularly. When a build succeeds, it becomes the environment future agents start from. Cursor keeps warm copies ready so the next agent does not wait. Internally, our environments now boot 10x faster, with 3x faster time to first token.

Use your install command for anything that can be prepared ahead of time. The start command still runs when you first prompt an agent and should focus on services that need to be fresh in the session.

More resilient agent runs

When a bad commit or dependency update breaks your environment, agents keep using the last successful build. The broken build never becomes active, you are notified of the issue, and your agents keep working while you debug in the background.

Build history and debugging

Each environment has a Builds tab in the Cloud Agents dashboard. You can inspect build status, logs, commit SHAs, and which build each agent run used. Agents can also inspect and manage builds using built-in tools.

Getting started

New environments use Builds automatically. For an existing environment, open it in the Cloud Agents dashboard, go to the Builds tab, and click Enable Builds. Or click Run setup agent first to test the migration and review any proposed config changes.

You can also trigger a Build manually, debug a failing Build with an agent, and control how stale Builds refresh with a configurable threshold.

Learn more in our announcement post and docs.

Original source

Today we are releasing Grok 4.6 together with SpaceXAI.

Grok 4.6 builds on Grok 4.5 with a particular focus on long-running agents and more ambitious interactive and visual work. It stays with complex tasks across many steps, whether researching a topic, analyzing information, working across a codebase, or turning an idea into a polished application or work artifact.

Grok 4.6 achieves frontier intelligence across several agentic coding and knowledge work benchmarks. It matches GPT-5.6 Sol on the Artificial Analysis Intelligence Index, which is a composite score of nine benchmarks.

Grok 4.6 is available today in Cursor and Grok Build. We’re offering 2x included usage inside Cursor and Grok Build for the first week.

Training Grok 4.6

Grok 4.6 underwent a longer supplemental training run than Grok 4.5, with curated model-generated data for reasoning and advanced technical concepts, high-quality engineering data, and an improved optimizer and training recipe. This produced a stronger foundation for the SFT and RL stages that followed.

We then used Grok 4.5 to regenerate the SFT trajectories across reasoning efforts, agent harnesses, and domains such as STEM, software engineering, and knowledge work. We filtered out problematic traces with model-based checks. The resulting SFT checkpoint shows strong performance and improved behavior.

Grok 4.6 is trained on a wide range of agentic RL tasks, including knowledge work, general coding, and domain-specific environments for kernel optimization, web development, computer-aided design, and more.

Turning ambitious ideas into working projects

We tested Grok 4.6 on projects designed to stretch its range and ability to sustain work over many steps. We found the model is especially strong at turning a broad product idea into a working first version. It can research unfamiliar domains, structure the application, implement the core interactions, and continue refining the result through several rounds of feedback.

On longer trajectories, we also started to see more self-testing and verification, with the model checking its own work before moving on.

Grok 4.6 produces stronger first passes on visual and interactive projects than we typically saw with Grok 4.5. Given a concrete product idea, it is able to establish structure and visual language for an application in one pass. This has made it especially useful for projects where the fastest route to a good result was to begin with something substantial and then iterate in the loop.

Safety and capabilities

Grok 4.6's safeguards have been improved and calibrated in line with the model's capabilities.

Our safety stack is designed to maximize utility and security across legitimate use cases, allowing Grok 4.6 to be helpful and safe in domains such as vulnerability patching, accelerating the engineering design cycle, and augmenting AI research.

Our safeguard evaluation work reflects Grok 4.6’s expanded capabilities, with our widest-ever suite of pre-deployment testing for capabilities and safeguard calibration, as well as extensive post-deployment third-party testing.

Get started with Grok 4.6

Grok 4.6 is available today in Cursor and Grok Build. It's also available in the SpaceXAI API and through partners including OpenRouter, Vercel, and Cloudflare.

Pricing starts at $2 per million input tokens and $6 per million output tokens. A fast variant is available at twice the price.

We’re including 2x usage inside Cursor and Grok Build for the first week.

Original source

On July 22, we launched Cursor Router with two new configurations, Auto Intelligence and Auto Balance

Since then, we have continued improving both modes as new models have arrived and our routing system has learned from more production traffic.

Today, Auto Intelligence delivers above Fable-level user satisfaction at 68% lower cost, a further 18% reduction since its launch. Auto Balance outperforms Opus 4.8 at 41% lower cost, a further 8% reduction over the same period, while further increasing user satisfaction by 3%.

We're working towards a Cursor Router that improves alongside the model frontier. This post explains how the current system works.

Cursor Router increases satisfaction and cuts cost vs. frontier models

Numbers in graph reported relative to Opus 4.8

A data-driven approach to routing

Cursor Router is built around the idea that model selection should be learned from how models perform on real developer work, rather than inferred from benchmark scores.

The router makes each decision using signals from the current turn and recent conversation state. These include structured features such as the task category, along with recent tool calls and the broader context of the work.

From there, routing happens in two parts.

First, we need to decide whether a turn is simple enough for a price-efficient model. Compass, our complexity predictor, makes this decision.

Second, if the turn is more demanding, we need to decide which frontier model is most likely to perform well on that kind of work. To make that decision, we classify the turn using a taxonomy of tasks, domains, and modifiers learned from real developer traffic.

Building a dataset

To develop the routing system, we first needed a dataset that reflected the conditions it would encounter in production. We built it from live Cursor traffic so it would preserve the actual mix of developer tasks, the context surrounding each turn, and the effects of switching between models.

As always, we respected users' privacy mode and data retention settings throughout this process.

The dataset contains hundreds of thousands of turns sampled across a range of models. Each datapoint includes the conversation signals available to the router, along with two outcomes we use to compare routing choices.

1. Performance. We infer performance from what the user does next. Moving on to the next task is a strong positive signal, while correcting the agent is a strong negative one.
2. Cost. We calculate cost from API pricing and token usage for that turn. Because the data comes from live traffic, it also captures costs that benchmarks often miss, including cache misses caused by switching models.

Predicting complexity with Compass

Compass estimates the complexity of each turn by predicting whether the user will be satisfied with Cursor's response. We train it on the performance signal mentioned above.

We use the resulting prediction as a proxy for complexity. This works because users rarely ask for corrections after simple tasks, like making a commit, while they're more likely to make follow-up requests when the work is more complex.

We evaluated Compass online and confirmed that its scores are strong predictors of user satisfaction. Turns that Compass rated as most likely to succeed received a positive performance signal 96% of the time, while turns it rated as least likely to succeed received one 71% of the time.

In practice, Compass assigns each turn a continuous complexity score between 0 and 1. We set a threshold within that range to determine which turns stay on a price-efficient model and which are upgraded to a frontier model. Lower thresholds keep more traffic on the price-efficient model, while higher thresholds upgrade more often.

Learning model strengths

After Compass tells us when a turn is complex enough to justify using a frontier model, the next question is which frontier model to use.

To answer it, we built a taxonomy from real developer traffic that describes each turn across three dimensions:

• Domains identify where the work happens: backend, database schemas, frontend
• Tasks identify what the developer wants done: fixing bugs, running commands, writing tests
• Modifiers capture characteristics that cut across domains and tasks, but may change which model performs best: bounded edits, product questions, visual-heavy changes

We then compare how different models perform across those categories. We found that no model dominates every kind of work, and each has categories where it outperforms:

• Grok offers strong value across broad, routine work. Its low inference cost made it especially effective for categories such as Git commands and general database operations.
• Sol performs especially well on planning and codebase comprehension. It also delivered strong results across several implementation tasks at a lower cost than other frontier models.
• Opus performs well on execution-heavy work. It showed particular strengths in devops, database queries, and performance optimization.
• Fable excels at debugging and visual implementation. Its quality gains were most valuable on complex tasks where they justified its higher cost.

Cursor Router uses those differences to match each turn to the model best suited to it.

Combining into an algorithm

Compass and the taxonomy play complementary roles. Compass estimates the model-agnostic complexity of the turn and compares that score with a routing threshold. Depending on where the score falls, we either send the turn to Grok, given its low inference cost, or use the taxonomy to identify the frontier model with the strongest observed performance on that kind of work.

When Compass does send a turn to the taxonomy router, model selection follows two rules:

1. Only route when performance is clearly better. A candidate model becomes eligible only when its observed performance on that task label clears a one-sided 75% uplift threshold against the price-efficient model. Roughly, this means we need 75% confidence that the improvement is real.
2. Choose the best mix within the budget. From the eligible candidates, the optimizer chooses the traffic-weighted combination expected to deliver the largest performance gain while keeping the average cost per turn within the mode's budget.

Together, the Compass threshold and the task router's cost budget define each mode's position on the cost-performance curve. Auto Balance keeps more traffic on the price-efficient path and gives the task router a smaller budget. Auto Intelligence gives the task router more room to select frontier models when the expected performance gain justifies the cost.

Evaluating performance in production

We evaluated our routing policies in two stages. First, we used cross-validation to tune the Compass thresholds and optimization budgets without overfitting to a particular split. We then evaluated the selected policies on a held-out test set that had not been used during training.

This gives us a more reliable estimate of how each policy should perform on new traffic. It helps us eliminate weak candidates and compare expected cost and performance before deployment. But offline analysis still cannot fully capture how a policy will behave in production, and benchmarks are limited for the same reason. Live developer traffic remains the most representative test.

Offline evaluation surfaces candidate policies to test online

*Cost and performance relative to Opus 4.8

We then tested the policies on live traffic, where we could measure user satisfaction and the actual cost of each turn under production conditions. This captures effects that are difficult to model offline, including token usage, caching, and the cost of switching between models.

Before launch, we tested both modes on live traffic and found that each improved the cost-performance tradeoff relative to individual frontier models. Auto Balance delivered higher satisfaction than Opus 4.8 at lower cost, while Auto Intelligence approached Fable-level satisfaction at a much lower cost.

We have since repeated this process as the routing system and available models have improved, moving both modes further beyond the cost-performance frontier.

Keeping pace with the model frontier

Since launching Cursor Router, we've added Opus 5 to the routing mix and improved Compass's predictions. That gives the router both a stronger set of models to choose from and a better signal for deciding when each one is worth using.

Over time, we want the router to become more adaptive by predicting each model's expected quality and cost, learning from production outcomes, and updating continuously. As the system improves, Cursor users will be able to benefit from frontier models where they're needed most, without paying frontier-model prices on every turn.

Read more in our docs.

Original source

Cursor can now read, write, and act across your Google Workspace.

New plugins give coding agents direct access to Gmail, Google Drive, and Calendar, so you can pull context, draft and update files, and manage your inbox and calendar without leaving Cursor.

Install plugins to connect:

• Google Drive: search files and folders, open and download content, create and organize files
• Gmail: search and read mail, draft and send messages, apply labels and manage threads
• Google Calendar: read schedules, create and update events, find free time

Browse the new plugins in the Cursor Marketplace or install them from the Customize page in Cursor. Learn more in our docs.

Original source

Cursor for iPad is now available on all paid plans.

New to both iPhone and iPad: an inbox to stay organized, and a review experience that covers the full PR. Create, review, and merge from anywhere.

Built for the bigger screen

The iPad layout is rebuilt around the extra space. Sidebar chats stay pinned so you can watch several agents run at once. Split screen keeps a review open next to a chat, and file diffs render in full.

Markup gets more room to work too. Attach a screenshot, then tap to drop a comment at a specific point, or draw directly on the image with Apple Pencil.

A full review surface

On iPhone and iPad, the review screen now covers the full PR: comments, checks, and approvals. Add or change reviewers, read comments, and prompt the agent to resolve them. The whole path from agent output to merged PR now travels with you.

Inbox

An Inbox helps you and your agents stay organized. See what's in progress, what needs your attention, and which PRs are in review.

Additional improvements for Cursor on iPhone and iPad

• Bitbucket and Azure DevOps SCM support
• Multi-PR sessions: when one chat creates multiple PRs, you can now open every one of them, not just the last.
• Switch between teams that you belong to directly in the app

Download the Cursor App or read our docs to learn more.

Original source

We're introducing Cursor Start, a new ₹649 monthly plan for developers in India, making daily agentic development accessible and payment easy with local pricing and UPI.

Existing Free users in India can upgrade their plan from the dashboard. New users in India can visit cursor.com/signup and select the Start plan during onboarding.

Start bills monthly with auto-renewal and is available from July 28, 2026.

Cursor Start includes:

• Generous access to Cursor models: Grok 4.5, our most powerful model, and Composer, our most price-efficient coding model, with enough usage to build with agents every day.
• Always-on cloud agents that build, test, and ship code while you keep working.
• Cursor for iOS with remote control, so you can launch and steer agents from your phone.
• Plugins, MCP servers, hooks, and skills to extend Cursor across your workflows.
• Local pricing at ₹649 per month, tax inclusive, billed in INR with UPI or card.

Learn more in our announcement and docs.

Original source

Today we're launching Cursor Start, a new plan for developers in India that includes generous access to Grok 4.5 and Composer for ₹649 per month.

India has one of the most ambitious and active developer communities in the world. Our user base in India has tripled in the past year to more than 3M developers, making it our third largest market globally. It is also home to more power users than any other market in the world, with developers in India running more agent requests per developer than anywhere else.

Behind those numbers are students shipping their first projects, founders building their companies, and engineers and designers at India's fastest-growing startups building ambitious software.

For a long time, our users in India have asked us for two things: pricing that reflects the local market, and the ability to pay with UPI. Cursor Start delivers both. It's a plan built to make agentic development in Cursor accessible, priced in INR at ₹649 per month, payable with UPI, and with generous usage for everyday building.

What's included in Start

Cursor Start gives developers in India expanded access to Cursor's models at a price built for the local market.

With Cursor Start, you get:

• Generous access to Cursor models. Run Grok 4.5, our most powerful Cursor model, and Composer, our most price-efficient coding model.
• More agent requests than the Free plan, across desktop, web, iOS, and the CLI, so you can build every day.
• Always-on cloud agents. Kick off long-running cloud agents that build, test, and open pull requests while you keep working.
• Cursor for iOS. Launch agents or control existing ones from your phone, then pick the work back up on your desktop.
• Extend Cursor across your workflow, with plugins, MCP servers, hooks, and skills.
• Local pricing. ₹649 per month, tax inclusive, billed monthly in INR with UPI or card.

Cursor Start sits between our two other individual plans, Free and Pro.

Free gives you a way to try Cursor with no payment required. It includes access to Composer and a limited number of local agent requests each month.

Pro is for developers who want access to every major model, including the most advanced ones from other labs, along with Bugbot, Auto mode, Automations, the Cursor SDK, and on-demand usage past the included limits. Cursor Start covers everyday building. When you need more, it's easy to change your plan to Pro.

To compare across all plans and see a more detailed view of what's included, visit cursor.com/pricing.

Getting started

Cursor Start is available today for developers in India at cursor.com/pricing.

Existing Free users in India can upgrade their plan from the dashboard. New users in India can visit cursor.com/signup and select the Start plan during onboarding. Pay in INR with UPI, credit, or debit card.

Original source

Auto mode is now powered by Cursor Router.

Cursor Router is our intelligent model router. It analyzes each request and sends it to the right model for the job. Frontier models handle work that demands them. Price-efficient models handle the rest.

Optimization modes

Select Auto, then choose how the router optimizes:

• Intelligence: Frontier quality, matching the most expensive and powerful models that might be out of reach for daily use.
• Balance: Strong quality, matching the frontier models that most people like to daily drive.
• Cost: Good quality, reaching the highest available intelligence while optimizing token spend.

Balance and Intelligence bill at the routed model’s rate. Each mode moves you along the cost-intelligence pareto frontier.

Admin controls

Admins can enable the router per team or group, restrict which optimization modes members can use, set the default mode, and allow or block underlying models.

Cursor Router is available across desktop, web, iOS, CLI, and our SDK. It is on by default for Teams plans. Enterprise admins can enable it from the dashboard.

Learn more in our announcement and docs.

Original source

Today we're launching Cursor Router, our intelligent model router for teams and enterprises.

Cursor Router lets teams automatically route every request to the most capable model for the task, delivering frontier intelligence at a lower cost.

We've observed incredibly strong results on production traffic across thousands of enterprise developers. During our early access period with dozens of enterprises, customers got frontier performance at approximately 30–50% lower cost.

In online A/B tests across millions of requests, Cursor Router delivered frontier-quality performance at 60% savings.

Cursor routes hundreds of millions of coding requests each week across every model and provider, with unique visibility into what users like and what stays in the codebase. Model neutrality has always been core to how Cursor works, and today we're putting that data and expertise to work for your team.

With Cursor Router, our goal is to provide teams with the best performance and experience for every task, without spending more than the work requires.

How it works

Roughly 60% of developers using Cursor pick a single model as their daily driver. This results in routine work being completed at frontier prices, and AI spend growing much faster than output quality. Cursor Router fixes that by classifying each request before a model runs.

At its core, Cursor Router is a classifier that routes users to the best model option based on their query. We trained Cursor Router on 600k+ live requests and evaluated performance in an online A/B test across millions of live requests directed by Cursor Router, optimizing for user satisfaction (AFC) as a reward.

Cursor Router analyzes each request on query, context, task complexity, and domain, combined with what we know about each model's behavior. We learn what each model is best at, and route to the most effective option. Simple work goes to the most price-efficient models, UI updates go to the model with the best taste, and more complex, long-horizon problems go to frontier reasoning models.

We designed our routing classifier for a world in which updated models get shipped early and often. This way as newer and more powerful models are released, we can easily update Cursor Router, so the experience keeps improving.

Cursor Router is cache-aware in both how it is trained and evaluated. It is trained on a dataset where routing results in cache misses, and evaluated in production where our reported cost savings include the cost of cache misses in routing decisions.

Frontier intelligence at lower cost

Cursor Router has three modes: Intelligence, Balance, and Cost which let you adjust where you are on the cost-intelligence Pareto frontier.

We found that Auto Intelligence mode lands near Fable on user satisfaction of output at about 60% lower cost for teams, while also lifting satisfaction about 15% over Opus 4.8 at nearly the same cost.

Similarly, Auto Balance lands above Opus 4.8 on user satisfaction with the results at about 36% lower cost. Against GPT-5.6 Sol, Auto Balance delivers comparable satisfaction at a lower spend rate.

We chose to measure the efficacy of our router using large online A/B tests instead of offline evals. While offline evals are useful proxies for quality, they're limited by their small size, their distance from real-world usage, and the difficulty of reducing success to a rubric.

Offline evals also omit the extra cache-miss cost that comes from switching models. Real routing happens across a conversation: which model to pick, and when to switch.

Online A/B tests put Cursor Router to test in the real world across millions of tasks and conversations. Engineers write code, ask follow-ups, hit errors, and keep going, often across hundreds of requests in a week. Those are the conditions under which a model router needs to perform well.

In terms of quality of output, we measured:

• User satisfaction, classifying agent success based on user responses. Moving on to the next feature is a strong positive signal, while correcting the agent is a strong negative one.
• Keep rate, or how much of the agent-generated code remains in the codebase over time.

We have relied on these metrics to evaluate every model launch and harness improvement in the past nine months.

What customers are seeing

Over the past two weeks, Cursor Router has been in early access with a selection of enterprise customers. We compared what they actually paid against the same traffic, priced entirely at Opus 4.8 API rates.

In early access, three high-volume accounts with thousands of users saved 30%–50% on Auto-routed requests versus routing everything to Opus 4.8, with no decrease in quality.

Cost per request is only half the story. Engineering leaders care whether those savings show up in real shipped work, so we looked at cost per commit, and the pattern held.

For a single commit, we observed Cursor Router had a lower cost per commit of $6.76 for Intelligence mode and $4.63 for Balance.

GPT-5.6 Sol matched the cost of Intelligence but had lower user satisfaction with the output. Meanwhile, Fable 5 and Opus 4.8 produced commits at a cost premium to Cursor Router at $12.69 and $7.34 respectively.

That gap is the practical case for routing. Cursor Router keeps hard tasks on the most capable models and moves routine work off of frontier pricing.

You choose the tradeoff

Cursor designed our router with teams and large organizations in mind. The router uses a data-driven taxonomy, while admins and end users can still choose where it sits on the cost-intelligence Pareto frontier.

Select Auto mode in the model picker, and choose from three optimization modes that move you along the frontier:

• Intelligence: Frontier quality, with performance matching the most expensive and powerful models that might be out of reach for daily use.
• Balance: Strong quality, with performance matching the frontier models that most people like to daily drive.
• Cost: Good quality, reaching the highest available intelligence while optimizing token spend.

Admins can decide how Cursor Router rolls out across teams. You can enable it per team or group, choose which modes members can select, set the default, and allow or block specific models.

What’s next

Cursor Router is one piece of how Cursor drives token efficiency. Choosing the right model only matters if the agent itself stays lean, so we keep cutting waste in the harness around it.

Dynamic tool calling is another clear example where most native tool descriptions are no longer loaded into every prompt. The model looks them up the first time it needs them, following the same pattern we already use for MCPs. This keeps common tools like read and edit hot while less commonly used tools only enter the prompt when the agent actually calls them.

Alongside Cursor Router, we keep raising the floor and the ceiling of the model pool: Grok 4.5 widens what Cursor Router can draw from on harder, higher-cost work. Composer keeps getting better on the everyday path, so lower cost turns stay close to frontier quality without paying frontier prices.

Cursor Router is available today for Teams and Enterprise plans across desktop, web, iOS, CLI, and our SDK.

Read more in our docs and changelog.

Original source

Cursor in Slack now shares a plan before it starts, runs in multi-repo environments, and can work across channels and threads.

Interaction improvements

Cursor now responds with a plan before it begins, so you can jump in and redirect early. As it works, it updates its status so you can follow each step.

We also refined how Cursor's responses look in Slack. In-message buttons are gone, replaced by compact footer links. Tables, PRs, and artifacts now render more cleanly.

Multi-repo environment support

From Slack, Cursor can now start in a named multi-repo environment instead of a single default repository. If your frontend, backend, and shared code live in separate repos, Cursor reads your request and targets the environment that gives it access to all of them.

Mid-task, when Cursor needs a repo outside the current environment, it prompts you with a Switch repository button. Click it, choose the repo or environment, and Cursor picks up right where it left off.

Cross-channel workflows

Cursor can now read from and send messages to other Slack channels and threads. During a task, it can pull context from elsewhere in the workspace and post updates back in the original thread or the relevant channel.

Learn more in our Slack docs.

Original source

This release makes it easier to stay in flow with side chats that run alongside your main chat, the ability to search agent transcripts, and simplified project and repo pickers.

Side chats

Open a side chat to ask questions, explore ideas, and investigate tangents without interrupting your main agent conversation. Use /side, /btw, or the plus button at the top of the chat panel to create a new side chat that has context from the main chat.

Each side chat is a durable, full agent conversation that you can follow up on, revisit later, and at-mention to pull context back into the main thread.

By default, side chats focus on reading, searching, and answering. Use them to ask clarification questions, research alternatives without committing to a pivot, and sanity-check a decision while the main agent continues running.

Conversation search

Find past agent chats faster with search results that go beyond names and PR numbers. In the Agents Window, you can search agent transcripts from the command palette (Cmd+K). Cursor builds a local search index that scales search to thousands of conversations with snappy performance.

You can also search within an existing conversation using Cmd+F. Jump between matches, see a match counter, and keep searching as you scroll through long transcripts.

Redesigned project and repo pickers

We've simplified the project and repo pickers and made them more powerful. You can now stay in the picker for workflows that used to send you elsewhere. For example, you can create a project and connect GitHub, GitLab, or Azure DevOps without leaving the picker.

Search is now scoped to where you're working—This Computer, Cloud, or a specific remote machine—instead of one global search box. You can also remove projects from Recents with one click.

New cloud agent hooks

Cloud agents already support team hooks around tool execution and file/shell work. We've added new hooks that let you observe and control the agent conversation itself: prompts, responses, thinking, subagents, compaction, and turn completion. See all the supported hooks in our docs.

New hooks like beforeSubmitPrompt, afterAgentResponse, afterAgentThought, stop, subagentStart, and more allow you to better observe output and reasoning, control subagents, and build self-correcting loops with cloud agents.

Original source

Today we are releasing Grok 4.5 together with SpaceXAI, our most intelligent model and the first we've built for more than software engineering.

Grok 4.5 can handle difficult, long-running tasks that require creatively using tools to solve problems, whether in software engineering, data science, finance, legal work, or anything else you do on a computer.

Cursor subscription plans for individuals and teams include significant usage of the model with double usage for the first week. We've also added new safeguards reflecting the model's cybersecurity capabilities.

A strong foundation

Grok 4.5 is a mixture-of-experts model that we trained jointly with SpaceXAI.

Training included trillions of tokens of Cursor data which capture a wide-range of user interactions with codebases and software tools. This dataset lets the model learn both from existing software as well as developer-agent interactions, capturing how developers work and how agents interact with their environments.

While we trained our previous model, Composer 2.5, to be a coding specialist, for Grok 4.5 we kept the training data mix deliberately broader. This involved drawing on high-quality STEM tasks, research papers, and other knowledge work, so that the model gained proficiency across a wide range of domains.

Reinforcement learning on difficult problems

We used reinforcement learning on difficult problems in realistic environments spanning both software engineering and broader knowledge work. These environments teach the model to investigate problems, use tools, recover from mistakes, and verify results.

Many of these problems had to be designed to be difficult enough that even frontier models fail at them. As models improve, existing tasks stop teaching them anything new, and problems that once required extensive reasoning become routine.

We developed a distributed agent system to construct these environments at scale. Engineers specify a problem and how a solution is verified, and large groups of agents construct, test, and refine each environment. Some would have taken teams of hundreds of engineers months to build. This is one of the ways in which we used the previous model to accelerate progress on the next model.

Get started with Grok 4.5

Grok 4.5 is available today in Cursor across desktop, web, iOS, CLI, and our SDK.

Individual and team plans include significant usage of the model as part of our first-party model pool, and we are doubling usage for the first week. The base model is priced at $2/M input tokens and $6/M output tokens. There is also a fast variant at $4/M input tokens and $18/M output tokens.

Grok 4.5 and Composer 2.5 are two different model weight classes, and we're excited to support both sizes and weights. Composer 2.5 will remain offered, and we will release new models of this size going forward.

SWE-Bench Pro and Terminal-Bench show self-reported scores for third-party models. For SWE-Bench multilingual, the GPT 5.5 score comes from our internal run.

Grok 4.5 has an advantage on CursorBench because an earlier snapshot of the Cursor codebase was accidentally included in training. The exact impact is unclear. That data has been removed for future models, and in parallel we are working on a larger update to CursorBench, hence the exclusion here.

Original source