Cursor
· 6 min

Improved token efficiency for longer agent runs

As agents have matured and learned to tackle more ambitious tasks, token spend has shifted. Agents now work for longer and carry more context from one step to the next, making the way we assemble and manage that context increasingly important. Notes: System & tool defs includes compaction summaries. User text includes manually attached skills. Skills & plugins includes skill descriptions, MCP tool descriptions, and rules that go in static context. Over the past few months we've responded to this shift by improving the efficiency of Cursor's agent harness. The harness gives us direct control over how each request is assembled, how context is reused, and when work is divided across agents. Changes across each of these layers reduced token costs for users by 7% without reducing agent quality. #Trimming the system prompt Every agent turn includes context supplied by Cursor before the model begins working. This includes the system prompt and definitions for the tools the agent can use. Because this context is included throughout a conversation, it had become one of the largest sources of spend that we fully control. When models were less capable, we had to spell out instructions for tool usage, task management, and code-change workflows. We also had to guard against strange behaviors like extremely long hash dumps, binary output, and emojis. As models improved, much of that direction became unnecessary. Instead of long lists of "DO NOT do this," "You must," or "Important" instructions, we could simply define how a tool behaves and models would generally comply. This was true across model families, allowing us to trim roughly 66% of our system prompt. Over time, we continue to add and remove instructions as new models require new guidance, which then flows into the training…

Cursor
· 30 min

Git at any scale

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…

Cursor
· 3 min

Introducing Grok 4.6

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…

Cursor
· 7 min

How Cursor Router chooses the right model for the task

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. #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…

Cursor
· 27 min

Mixture-of-Kittens: our open-source MoE megakernel for NVL72s

Today, we're open-sourcing Mixture-of-Kittens (MoK), our production MoE training megakernel for NVL72s. As we have scaled the training and inference of Composer, our agentic coding model, the mixture-of-experts layer has consistently remained the major bottleneck. Depending on the workload and training configuration, it can consume more than half of end-to-end training time. MoK addresses that bottleneck by fusing all MoE communication and computation into a single, fully deterministic kernel. It now powers Composer training across tens of thousands of GPUs. You can try MoK and explore the code on GitHub. We look forward to your feedback and contributions. MoK grew out of several earlier attempts to speed up the MoE layer. Over the past year, we wrote our own MXFP8 and NVFP4 training kernels and developed the "warp decode" approach for MoE inference. But those techniques optimized only the compute portion of the layer and assumed inter-GPU communication would be handled separately. In our production workloads, communication had become the limiting factor. That led us to redesign the full MoE layer from first principles, with communication built directly into the kernel. In addition, our move to GB300 NVL72s changed the problem in two important ways. First, an NVL72 is a multi-node rack within a single NVLink domain, enabling fast, fine-grained overlap of computation and communication across all 72 GPUs. Second, the integrated Grace CPUs (the "G" in GB300) tend to be slow relative to the GPUs. We found that GPU streams easily caught up to CPU-side work, causing the GPU to be completely idle during that time. So we have to aggressively minimize CPU work and CPU-GPU synchronization. Our solution to this set of challenges is Mixture-of-Kittens (MoK), a highly optimized MoE…

Cursor
· 5 min

How we set up our cloud agent environment

When we decided to give cloud agents computers so they could test their changes, the first step was to make sure they were good at testing them in our own codebase. Getting our monorepo working for cloud agents taught us that the development environment is a product in its own right, only one whose users are agents. You have to make cloud match local development, make the repo legible enough that agents can run and test code without tribal knowledge, and keep that environment healthy as the codebase changes. Building that environment has changed the way we work. In December, cloud agents authored roughly one in ten PRs merged to the Cursor monorepo. Today, they write more than half. #Matching cloud to local development The first step to making cloud agents work well in our repo was making our repo work well in a cloud VM. This stage is familiar to any engineer who has set up a remote development environment for the first time. Most Cursor devs develop locally on Mac machines, but our cloud VMs run on Linux. This meant we had to agnosticize various dev utilities and setup scripts to work on Ubuntu VMs. We added critical dev dependencies to a Cursor-defined Dockerfile that serves as the starting image for cloud agents. We also worked with our security team to add security features to the cloud agent product, so that users could confidently inject required secrets into the agent's environment. These features include network egress restrictions, scoped and proxied git remote access, secret scanning in commits and commit messages, and secret redaction in tool results, which prevents the agent from reading secret values even if it tries. #A simpler interface for agents Even after we had our dev setup working on Ubuntu VMs, agents were still bad at running our code. This…

Cursor
· 13 min

Agent swarms and the new model economics

Earlier this year, we ran experiments to test the limits of scaling agents to cooperate toward a goal. Our hypothesis was that this would unlock a new tier of task scale and complexity. The flagship project was a long-running swarm building a web browser from scratch. It succeeded as a proof of concept, but fell far short of polished software. That work was deliberately empirical. We started from a blank canvas and hill-climbed toward a stable, effective system. Since then, our goal has been to understand the agent swarm well enough to engineer it deliberately. To test that progress, we returned to a task the old swarm had struggled with: building SQLite from scratch, in Rust, from nothing but its documentation. Our initial results have been promising. We ran the old and new swarms on the same task, with the same models and the same time budget, and measured how much of a held-out SQL test suite each could pass. The new swarm did better in every model configuration. Using Grok 4.5, it reached 80% in four hours, while the old swarm spiraled and had to be paused before its second hour. We also varied which models did which jobs. In some runs, one model handled everything while in others, a frontier model planned while a fast, inexpensive model carried out the work. Every mix produced similar quality, but the costs varied enormously.1 #Trees and leaves Descriptions of large tasks naturally take the shape of trees, with a goal at the root that subdivides recursively into basic units of work. Our swarm has two roles, both organized around that same tree-like decomposition: Planner agents, powered by the smartest models, split a goal into pieces and delegate them. Worker agents, generally powered by faster and less expensive models, execute those pieces. The design is a…