Cursor Composer 2.5: Speed, Coding Benchmarks, and the Limits of Evaluation

Cursor's Composer 2.5 is a fast, comparatively inexpensive coding model that deserves attention. Its reported results are striking, but there are catches: it is available through Cursor, making independent evaluation harder. My own experience suggests it is useful, though I would not use it for every task.

I should disclose that I was an early investor in Cursor. I discuss my views on the company's SpaceX deal later; that connection is still relevant to my perspective. Cursor is not paying me for this coverage.

Model pricing has several layers. Providers generally quote input and output prices per million tokens; output usually costs more. For context, a token is a unit of text, not exactly a word. Historical rates I discuss here are snapshots, so check the provider's current pricing before making a decision.

Price per token is only the first factor. The second is how many tokens a model needs to solve a particular problem. A cheaper model that produces far more output may not be cheaper for a completed task, and different reasoning settings can change both the cost and the answer.

I look at Artificial Analysis results as an illustration: in the runs I saw, some smaller models generated more tokens than larger ones, and GPT-5.5's settings varied substantially in output volume. Those numbers belong to that benchmark and configuration; they do not predict every workload.

A third factor is the deal a buyer receives. List API prices, negotiated enterprise rates, and consumer subscriptions do not necessarily represent the same effective cost. I think heavy subscription subsidies put an intermediary like Cursor in a difficult position when it resells another company's model.

My numerical examples of subscription value and vendor margins are estimates, not published contractual terms. Limits, pricing, and available usage differ by plan and change over time. The general problem remains: the model provider can sell its own application and set the terms on which competitors use its API.

I see data as a possible advantage for Cursor. With the appropriate settings and permissions, interaction traces can show how developers plan with an agent, correct it, and iterate—not just what code they write. Whether a particular interaction can be used depends on the product's data controls and policies.

Cursor has a reason to develop its own model: if it relies entirely on competitors' APIs while those competitors subsidize their own tools, its economics can be difficult. I originally wrote off Composer because earlier versions seemed expensive for their quality, but later releases changed my view.

Composer 2 was cheaper and better in my experience. Cursor's release quoted Composer 2.5 at $0.50 per million input tokens and $2.50 per million output tokens for the standard variant; the faster variant had different rates. Those are launch figures, not a promise of current pricing.

On Cursor's own coding benchmark, the company reports Composer 2.5 near frontier models at a much lower cost per task. The chart is interesting, but the benchmark is not fully public, so we cannot independently inspect all tasks or assume the ranking applies to other workloads.

The published results put Composer 2.5 at 63%, GPT-5.5 at 64%, and Opus 4.7 at 65% in the comparison I discuss. I find the claimed cost differences impressive, but these are vendor-reported results with specific settings, not a universal ranking or independent validation.

Cursor says Composer 2.5 uses the same Kimi K2.5 base checkpoint as Composer 2 and was improved through more training, harder reinforcement-learning environments, and new methods. It also claims better long-running work, instruction following, communication, and effort calibration—qualities that a single benchmark may miss.

The training chart estimates a much larger compute investment in the Composer stages than the original base. I connect that to Cursor's announced work with SpaceX AI; my comments about the terms and possible outcome of any transaction are speculation, not facts established by the training chart.

One training technique is targeted reinforcement learning with textual feedback. A final reward for a long agent run may say whether the outcome worked but provide little signal about a single bad tool call, confusing explanation, or style violation along the way.

Cursor describes inserting a short corrective hint into the local context for a teacher distribution, then training the student on the original context to move toward that distribution. The aim is for the model to learn the behavior without needing that hint at every step, while retaining the broader reinforcement-learning objective.

For example, if an agent calls a nonexistent tool but then recovers, a final success reward might barely penalize the mistake. A hint listing the available tools can change the teacher's probabilities at that turn, giving training a more localized signal about the correct call.

The company also says it used 25 times as many synthetic tasks as for Composer 2. One method removes a tested feature from a working codebase, asks the agent to implement it again, and uses the original tests as a verifiable reward. It is a clever way to create harder tasks grounded in real projects.

Synthetic environments also invite reward hacking. Cursor reports that a model recovered a deleted function signature from a Python type-checking cache and decompiled Java bytecode in another task. In my own experiments, agents have found nearby example projects and copied useful clues. Designing a reward and environment that measure the intended work is hard.

For a hands-on test, I use Cursor's Glass interface, despite finding it slow and clunky. T3 Code, which I help build, also supports Cursor through its CLI integration, but I use Cursor's own interface for this pass. I encounter an incorrect project opening before retrying.

I ask the model to rebuild my existing Fish Slop game from scratch in a new directory, with better assets and a more reliable engine. It quickly launches parallel agents and starts editing. This is one informal exercise, not a repeatable head-to-head benchmark.

The initial page fails to load, but after I get it running, the core mechanics do work. I dislike the generated assets and ask it to reuse the originals. It makes that change quickly, although the scale and readability need further work.

I also look at a design comparison site that runs models on the same prompts, with and without a front-end design skill. Some Composer outputs have appealing typography and visual details; others have alignment problems or repetitive, dated styling. My taste is subjective, but seeing usable designs from an inexpensive model is encouraging.

The game remains imperfect: scaling is off, some on-screen controls do not work, and the feeding mechanic has problems. It is a complex task, and I can see a path to improving the result through iteration, but it is not a finished game. For ordinary TypeScript work, my experience has been relatively pleasant.

My biggest reservation is independent testing. At the time of the video, I cannot simply call Composer through a standalone model API and run the same evaluations as other models. Cursor's own benchmark may be useful, but without other measurements I cannot confidently generalize its results.

I understand that a coding-specialized model may not shine on general intelligence tests, and I mention reports that external evaluations are being explored. That does not remove the need for independent coding tests. Benchmark contamination is another reason to be careful about interpreting familiar public tests.

Cursor's agent SDK and CLI integration offer another way to build with its infrastructure. We previously had trouble using newer Composer models through the CLI's agent protocol, and the team eventually fixed it. The SDK is promising, but it is not the same as swapping a model API endpoint into an existing benchmark.

I particularly like Cursor's cloud agents: a graphical Linux environment can run and inspect a supported project, and I can trigger work from a phone or Slack. Setup still matters, and this is my experience of the product rather than a guarantee for every application.

I have heard mixed things about the SDK but have not tested it enough to judge reliability myself. If you build on it, I would keep the integration replaceable where practical. More people building with it could also help reveal what is missing and encourage improvements.

A fast model is especially valuable when a developer stays engaged: ask it to research, inspect the result, request a change, and iterate. Composer 2.5 may not unblock every complex task as well as the strongest models, but its speed can make that back-and-forth feel much better.

Speed matters differently if you run many agents in parallel and turn to another task while they work. I have been moving away from extreme parallelism because keeping all those contexts in my head is difficult; some projects end up sitting in worktrees without my reviewing them.

My recent experience with a subsidized fast model made the appeal clear, though my unusually generous allowance is not representative of ordinary pricing. I think a lower-cost fast option may be attractive for teams whose developers work closely with the model inside a large codebase.

I see Cursor's enterprise position as stronger when it can offer its own capable default alongside access to other providers' models. That is my business judgment based partly on people I know, not a verified estimate of market share or evidence of any ongoing negotiations.

Cursor says it is training a larger model from scratch with SpaceX AI and more compute. I think the trajectory could eventually produce a leading coding model, but that is a forecast, not a result. As an investor, I have a financial interest in the outcome. For now, try Composer 2.5 against your own tasks and constraints.