Cursor released Composer 1.5, an update to its in-house coding model. The company's one-line description: "Improved reasoning over challenging coding tasks by scaling RL over 20x." Cursor says the new model "strikes a strong balance between speed and intelligence for daily use," and it's available in Cursor now.
Some lineage: Composer 1, from October 2025, was Cursor's first in-house model. Composer 1.5 was, per Cursor, "built by scaling reinforcement learning 20x further on the same pretrained model" — no new base model, just far more training on top of the old one. Cursor calls the result "significantly stronger than Composer 1" and says it can "self-summarize to handle longer running tasks," compressing its own working notes so long jobs don't run out of room.
The detail worth your attention is how it spends effort. Cursor says Composer 1.5 is "trained to respond quickly on easy problems with minimal thinking," while on harder ones it uses "thinking tokens to reason about the user's codebase and plan next steps." Quick when quick is fine, deliberate when it isn't. Note that every claim above is Cursor's own — there were no independent numbers at launch — so treat them like any vendor's launch-day numbers and test on your own work. We won't quote pricing here; current numbers are on Cursor's pricing page.
Match the effort to the problem
A coding model earns its keep on volume work: rename a function, fix an import, write a small test, wire up a form. On tasks like that, a 30-second wait for a marginally better answer is a bad trade — the developer breaks focus, and the tool falls out of the daily loop. Speed on easy problems isn't a compromise. For most of the workday, it's the product.
What Cursor built into one model — little effort on easy work, real effort on hard work — is the same decision your business makes, usually by accident, every time it picks a model. Most companies we talk to have one default, typically the smartest model they can name, and route everything through it: meeting summaries, email drafts, contract review, all at flagship prices and flagship wait times. The vendors have stopped pretending that makes sense — OpenAI now ships three price tiers of the same generation because most work doesn't need the biggest model.
The fix is a two-pile sort. Pile one: routine, repeated, low-stakes-per-item tasks — first-draft email replies, tagging inbound requests, pulling fields off an intake form — where a fast, cheap model plus a human glance wins. That pile holds most of your volume. Pile two: the genuinely hard calls — ambiguous contract language, a multi-step analysis, anything where a wrong answer costs real money — where maximum reasoning is worth the wait. Matching effort to the task is the same discipline we use to scope engagements: not every problem deserves the same size solution.
What to do with this
- If your team codes in Cursor, run Composer 1.5 against your current default on a week of real tickets. Score it on tasks completed and how often output needs edits — not on benchmarks. (Where Cursor's in-house line goes on price is its own story: Composer 2 and the price floor for agentic coding.)
- Write down your routing rule. One sentence per task type: drafts and summaries go to the fast model; contracts and analysis go to the reasoning model. If you can't write the sentence, you're choosing by default, and defaults are expensive.
- Measure the wait, not just the bill. If people stop using a tool because it's slow, its per-token price is irrelevant. Adoption follows speed.
If you want help sorting your workload into fast-model and think-hard piles, that's a 30-minute conversation.