Cursor Composer vs Claude Code: 400k-Token Repo Benchmarked
I gave Cursor Composer and Claude Code the same 400k-token monorepo and expected a boring tie. One of them embarrassed itself inside twenty minutes.
This is the sibling post to my ChatGPT Codex vs Claude Code piece. Same setup, different challenger. If you skipped that one: I run these comparisons on real work, not toy prompts. The repo here is our internal harness-ops monorepo (around 400,000 tokens of TypeScript, Python, and shell), and the task was a mechanical but wide refactor: renaming one config field and updating every call site.
The setup
Here is what actually landed on both agents on 2026-07-28:
- Repo size: 397k tokens by Anthropic’s tokenizer, 412k by Cursor’s. Call it 400k.
- Task: rename
config.harness.retry_ceilingtoconfig.harness.retry_budgetacross 71 files, adjust three call sites where the semantic changed, and write a migration note. - No RAG, no index: both agents were told “here is the repo, do the thing.” I wanted to see the raw long-context behavior, not the retrieval layer.
- Same prompt for both, delivered verbatim.
I ran each agent three times and took the median. The absolute numbers below are one repo, one week, one afternoon, not a leaderboard. But the shape of the failure was consistent.
The numbers
| Metric | Cursor Composer 2.5 | Claude Code (Sonnet 5, 1M) |
|---|---|---|
| Task completion | 47 of 71 files | 71 of 71 files |
| Wall clock | 22 min | 31 min |
| Input tokens billed | 1.9M | 3.4M |
| Missed call sites | 5 | 0 |
| Broke a test | Yes (3 tests) | No |
Composer was faster and cheaper. It was also wrong.
What went wrong for Cursor
Composer 2.5 advertises a 320k context window. What actually reaches the model on a step-by-step agent loop is more like 70k–120k after Cursor’s internal truncation and re-summarization. That is a smart architecture for latency, and on repos below 100k tokens I still prefer it. But when the working set is 400k, the agent has to re-scan on almost every step, and the re-scan drops files.
Concretely: Composer rewrote 47 files, declared victory, and moved on. The 24 files it missed were the ones it never re-loaded after its first summary pass. The three broken tests were downstream of the same miss: a call site got renamed in one file and not in its caller.
The failure mode was not “the model was dumb.” The failure mode was “the harness never showed the model the whole diff.” That is a design choice, and it is the right choice for the 90% of Cursor sessions where the repo fits. It is the wrong choice for the 10% where the repo doesn’t.
What Claude Code did differently
Claude Code with Sonnet 5 has the 1M context window generally available, no long-context surcharge as of 2026. On this task the agent loaded the repo once, kept it warm, and worked through the 71 files in a single pass. The token cost was almost double Cursor’s (you pay for the window), but the task actually finished.
Two things surprised me:
Sonnet 5, not Opus 4.8. I ran the same task on Opus 4.8 as a sanity check. Opus was slower, cost more, and produced the same diff. On a mechanical refactor at 400k, Sonnet 5 is the pick. This lines up with what I wrote in the cheap-model post: at long context, the ceiling model does not automatically win.
The 1M window is not free-lunch. The Anthropic MRCR v2 benchmark shows real accuracy degrades past 200k, even on frontier models. Which is why the token accounting matters. I paid 3.4M input tokens because the agent kept the full repo in context; a smarter harness with curated context and tighter retrieval would have finished cheaper. But no curated harness = Claude Code shipped. Half-curated harness = Cursor shipped 66% of the task and lied about it.
Where each one still wins
Composer is not bad. I use it every day on repos under 100k tokens. Its latency floor is genuinely lower than Claude Code’s, its diff quality on small edits is often better, and the inline UX is still the best in the category. For the 90% case it is the right tool.
Claude Code wins on the 10% case, which happens to be exactly the case I care about: mechanical work across a big repo, or reasoning that needs to hold multiple modules in mind at once. If your monorepo is under 100k tokens you may never notice this. If it isn’t, this is the split.
What the numbers don’t show
I ran this on one refactor. The failure mode I saw was silent partial completion, which is worse than “the agent errored out.” An error you catch. A confident “done” on 47 out of 71 files ships to production. I only caught it because I ran the test suite twice and saw three new failures. Anyone reviewing the PR by eye would have merged it.
That is my actual takeaway. Both agents are competent. Only one of them tells you when it gave up.
Practical decision
- Repo under 100k tokens: Cursor Composer. Latency, UX, price.
- Repo 100k–400k tokens, mechanical work: Claude Code with Sonnet 5.
- Repo over 400k tokens: neither raw. Curate context first (RAG, indexer, or hand-picked files). At that scale the harness matters more than the model.
The third case is where context engineering stops being a buzzword. I have written about the six components of a good harness elsewhere, and long-context work is the case that makes people finally read those chapters.
The punchline
I expected Claude Code to lose on speed and cost. It did. I did not expect Cursor to hand back a PR with 24 missing files and a straight face. That is the number that will stay with me: 47 out of 71, delivered as “done.”
Pick the tool that fails loudly.
Was this article helpful?