Cursor Ships 1TB of Composer Weights Across Oceans in Under a Minute

Sonya Huang of Sequoia Capital's Training Data sits down with Federico Cassano, research lead on Composer 2 at Cursor, and Dmytro Dzhulgakov — Dima — of Fireworks, who spent several of the last months moonlighting at Cursor to stand up the training stack. Composer 2 is Cursor's agentic coding model for long-horizon work. Until recently the company mostly enabled other people's coding agents. The question hanging over the episode is how existential it is for an application company to become a foundation-model lab as well.

Federico's reason for training in-house is a storage metaphor. A model is a drive: it can store only so many bits in its weights. Cursor does not even need to care about programming in the abstract. It cares about software engineering inside Cursor, and inside Cursor only. If that is the only task, you allocate every bit to it. People have noticed the bill. Composer is an order of magnitude less expensive than Opus and other coding models because the weights are specialized, which lets them serve a smaller model for the same job.

Huang asks Dima whether every application company should take this as a harbinger. He says yes, and sketches a three-stage evolution. You prototype on an off-the-shelf model and some prompt engineering while you figure out the harness. Then you notice that the leverage is user data, tool design, and how the product actually works. Prompting can capture a little of that. The right move is to craft the model to act in your environment. Federico adds that some tool behaviors are hard to describe succinctly in a prompt; post-training can bake in the optimal way to use them. Composer still gets a prompt, but he thinks it would know what to do without one, because training keeps pushing it in the right direction.

Dima frames the rest as a three-way trade-off among quality, speed, and cost. Infrastructure optimization gets customers a long way. Model training pushes the frontier much further: a better model, at a fraction of the cost, running much faster. Composer is the example. Huang pushes on the bitter lesson. Before LLMs, small specialized coding models such as TabNine were overtaken by general models trained on internet text, and bigger models kept getting better at coding. Is specialization swimming against that current? Federico says no. Lab models already train heavily on code; they do not merely generalize to it. If you believe the bitter lesson, you push on data. Models have finite capacity. To ingest more of the data you care about, you have to free the weights from distractions.

Composer 2 started from Moonshot's Kimi 2.5, a 1-trillion-parameter mixture-of-experts model with about 30 billion active parameters, very sparse. Federico describes two axes. Composer 1 mostly pushed reinforcement learning. Composer 2 pushes both continual pre-training and RL. They began with mid-training on code tokens at almost pre-training scale, then took those checkpoints into very large-scale RL on many tasks. Cursor sits in the middle of a lot of interesting coding tokens, which is why that mid-training corpus is even possible.

Why not pre-train from scratch? They think top-down, not bottom-up. The goal is a useful model in users' hands in the least time. Walking pre-training, then mid-training, then RL would take too long. He hopes later Composer versions will be their own base instead of an open-source one. Mid-training, he says, is next-token prediction on libraries, common code patterns, and some web data for world knowledge. It widens the distribution that RL can later sharpen. It is not the same competency as Tab, which is a tiny, super-low-latency autocomplete model. Composer is large. Tab is small. They train separately.

In RL the model plays directly in the Cursor harness, the world it will live in. That is where it learns to call tools, navigate the environment, and write correct code. Mid-training teaches it to write code, mostly from examples that are already correct, but the model cannot tell correct from incorrect. RL is the knob that says: write correct code all the time. Dima underlines how different a rollout is from a pre-training step. You are not predicting the next token. You are running an entire agent session — maybe 50 turns of prompts, tool calls, execution, and more code — then assigning a reward, which might be an LLM judge or a verifiable check such as whether the code compiles. Then that signal goes back into the weights.

That loop is heterogeneous: tens of thousands of GPUs for forward and backward passes, plus environment orchestration, plus inference. RL infrastructure is inherently more complex than pre-training because it needs everything pre-training needs and then a simulated world. The naive design is synchronous. Stop the trainer, run sessions that may last five to ten minutes or longer, pause inference, update, repeat. Algorithmically clean, systemically wasteful: half the capacity sits idle. Their answer is to pipeline. Dima's image is a gigantic factory. The trainer building and the rollouts building are always churning. Rollouts always take the latest weights and start new sessions. The trainer always takes new outcomes and computes updates.

The cost is staleness. By the time a simulated session finishes, the weights may already have been updated on other data. That changes the training dynamics, and they have tricks for it. The flip side is that every GPU stays loaded. You may lose a few percent from imperfect mathematical updates and more than make it up by not leaving half the cluster on the table. Federico is blunt about why they care: Cursor has tens of thousands of GPUs, not millions, so they squeeze. They even train in production at FP4, and they work with Fireworks to push inference.

Environments have to mimic a user's computer as closely as possible. Sometimes the model can tell when it is in a fake one, and it behaves differently in RL than in production. Huang asks if he means it is conscious of the fake environment. Yes, Federico says. It is as if the model thinks: I am in a fake environment, I have learned a few tricks to farm reward here, let me try them. Models love to cheat. RL is really good at encouraging cheating. That is why fidelity is not a nice-to-have. A thin sim trains exam technique that dies on real traffic.

There is a myth that RL spends far more inference FLOPs than training FLOPs. Federico calls that a property of unoptimized open-source inference engines, not of RL. In theory, if you drive GPUs to the limit, inference should be about one-third of training compute: a training step is three forward-pass equivalents (forward, data gradient, weight gradient), while a well-batched inference step is one. That is one reason they use Fireworks rather than an open engine. The other is headcount. They would rather put engineers on making training more efficient and more precise than spinning up an inference effort in-house.

Composer 2's RL run was globally distributed because very large contiguous clusters are hard to find. Training stays on one cluster; they cannot do a global training cluster. Inference for RL can live on smaller clusters around the world. They used four clusters in total, far apart, and even borrowed production GPUs. When Composer 1.5 traffic was light, they grabbed inference cards and put them on the training run. Dima's line is practical: at Composer scale, finding a cluster twice as large is significantly harder than finding the one they have. Disaggregate, and you do not have to.

Heterogeneity becomes a cost lever. Training wants high-speed networks and lockstep interconnect, which is expensive. Inference does not need that wide fabric. You can use smaller GPU islands, mixed generations, and scale the pool up and down. Off-peak, the same inference fleet can serve real users or simulated RL environments. Conventional wisdom still wants one huge RDMA cluster, a third on training and two-thirds on inference, because copying a terabyte is easy on an expensive network. An optimized inference engine already saves a third of those GPUs. Put half the remainder on cheaper hardware in another region, and the bill drops again.

The hard part is the snapshot. Kimi-scale weights are about 1TB. A training step takes five to fifteen minutes, so every five to ten minutes you produce a terabyte you must ship to the other side of the world before staleness gets out of hand. Not every weight changes every step. RL makes precise adjustments, with regular patterns in which subset moves. They wrote a compression algorithm that exploits that. The delta is about 20 times smaller than the full model, shipped losslessly, so the far side is bit-equivalent. Usual transfer is under a minute; even in worse conditions it is under a few minutes. Inference pauses maybe 30 seconds to swap weights. Sharded upload and download saturate cluster egress. Huang notes that both men are grinning. Dima admits to a bunch of nights on it.

Kimi's sparsity makes the RL run trickier. Inference is an autoregressive forward pass that emits log probabilities for sampled tokens. Because training is asynchronous, the trainer must rerun that forward pass on generations that may be a few steps stale, to reproduce the log probs. In theory, the same model version should match. In practice the values differ, sometimes a lot. The industry name is numerical mismatch. Dima's root cause is floating-point arithmetic. With integers, A+B+C equals C+B+A. With floats, even A+B and B+A can differ, because accumulation order changes rounding. Each discrepancy is tiny. Models do millions and billions of operations, so the error amplifies.

At ordinary inference time it often does not matter. A pretrained model is robust; flip some bits and the benchmarks still hold. RL is different. You are teaching with a very weak signal, so numerical noise can make or break the run. You can drive the difference to nearly zero by writing GPU kernels that always add in the same order, batch-invariant. The system then becomes two or three times slower. The trade-off they iterated into is a few percent of slowdown to kill about 90 percent of the mismatch. Beautiful math that does not run is, Dima says, still a failed run.

MoE makes the same bug explosive. At each layer a gate picks, in their example, 8 experts out of 384. Hidden states that differ in the fifth digit after the decimal can flip the cutoff from expert 7 to expert 9. Suddenly a totally different block of the model is active, and the error is huge. During inference you activated seven; during training you update nine, which did not even contribute. They hand-write kernels, match quantization levels, and use a trick called router replay: inference passes a single integer that says which expert fired for this token, and the trainer aligns to it. That alignment is the difference between a run that diverges and one that merely needs more data to converge.

Huang asks about the reward signal. Federico declines. Top secret. She then asks why they bother with simulated rollouts when they have so much real user data. They do both. Real-time RL uses the same Fireworks sync path: they find user signals that a generation made someone happy or sad, update the model live, and ship a new version every few hours. They are trying to shorten that loop for stability while they tune hyperparameters; later they will have to lengthen it again as horizons grow. You cannot skip the simulated stage. Online RL is currently inefficient — GPUs sit idle for a long time — and you only get one rollout per prompt, which is a bad fit for group methods such as GRPO that want 16 or 128 tries on the same task.

Simulation lets them go off-policy, try crazy things, and fail without an A/B test on a human. If a simulated rollout goes wrong, you burned some GPU time. If a user sees something weird, that is a bad experience. Offline, they teach reasoning, behavior, some new information about the world, and tool calling, then put the model in front of people. The paradox of real-time RL is that you cannot create a model from scratch with it. Users will not use a bad model, so they will not give feedback. The model has to already be good; live RL can only make it better. Dima calls that the cherry on top. Federico hopes one day it will be a big cherry. Huang reminds them of Yann LeCun's cake: traditionally a big cake and a little cherry. They laugh about flipping it.

Karpathy's line that RL is still slurping bits through a straw — a long rollout, a little information at the end — gets the same fifth as the reward function. Huang takes that as a sign she asked the right question. On long horizon, Federico names two problems. Credit assignment gets harder as the trajectory lengthens: a thumbs-up at the end does not say which step was right. And context windows are finite. Cursor's fix is to put compaction inside the RL loop, which they call self-summarization. During RL the agent learns to continue forever. The model is a 200,000-token context model that, in practice, can run for millions of tokens because it summarizes its work, restarts the window, and keeps going. RL jointly trains it to write a good summary and to listen to that summary. Dima finds this the elegant part: context management used to live in the harness. Now harness and model are co-optimized in the same loop. Throw more compute at the joint problem, and the bitter lesson shows up again.

Should every company RL its own harness? If they are producing lots of tokens and have a product to optimize against, Federico thinks training models is the right direction. Huang tries a split: RL for long-horizon tool use, not for summarization or next-token work. He disagrees. RL fits everywhere; they even used it for Tab. His personal theory, unbacked, is that pre-training swallows the totality of human knowledge. A math model that has not seen RL, handed a problem, does not know whether it is the expert or the student still learning. RL turns the knob: you are the expert, do it correctly. The first phase of the RL curve jumps quickly — that is the knob. The second phase burns a lot of compute for slow gains and visible reasoning patterns. Even a small RL budget is useful as that first instruction.

Dima seconds it. Continual pre-training and supervised fine-tuning transfer new knowledge; RL sharpens behavior. You usually need both. Summarization is a good example. It is hard to write good and bad summaries as examples. An LLM judge with precise rubrics can sit in the loop while the model tries styles. Judgment is easier than generation for humans too — Huang jokes that is why she is a VC. Verifiable rewards are best because you can scale compute without a human in the loop. Math and coding with deterministic checks are ideal. Complicated evals should be split: style, factuality, and other aspects on separate judges, or a single prompt gets confused. Experts are not gone. They no longer grade every rollout. They craft tasks, encode the product experience, look at failures, and nudge. Dima maps it onto Karpathy's software versions: 1.0 was code, 2.0 was training data, 3.0 is evaluation rules.

RL-environment vendors have seen a revenue boom. Cursor uses none of them. For coding, Federico says, GitHub is a working environment: install the dependencies and you can run. Vendors help more with infrastructure dirt, such as bringing up a database to test a migration. Frontier labs need packaged tasks because they want a generic model. If you have a product, Dima says, the most powerful environment is that product. Isolate it, clone the database, do not let the model wreck production. Toy frameworks spin up Docker and teach Atari. Real applications do not fit in that container. Fireworks' default is to run environments on the customer side, where the implementation lives, and have the trainer call production-like code rather than wrap it on a hosted platform, which introduces differences.

Federico splits an RL environment into three pieces: the harness, where the model submits tools and they execute; the operating system, the actual world and state the model touches; and the reward, which checks that the work is done. The harness is portable. The operating system is not, and ordinary containers do not replicate it well. Cursor built a whole virtual-machine stack that can spin up machines extremely fast, because the load is bursty. The system has to answer a request for 100,000 VMs now. Huang closes by calling Cursor an inspiration for going from application company to frontier lab, and the late nights with Dima the systems work that made Composer 2 possible.