I received the following email and wanted to clarify one detail:
Hi Simon,
On March 16, 2026, you will be automatically moved from Composer 1 to Composer 1.5, which is both more intelligent and includes more usage as part of our new Auto + Composer usage pool.
No action is needed. We are retiring Composer 1 on March 16, 2026 to reallocate capacity to serve Composer 1.5 due to high demand.
See details about models and pricing in our docs.
Best,
Cursor Team
Does this mean that Composer 1 will be completely retired and no longer selectable on any plan, or is it only being removed from the Auto + Composer usage pool, while still potentially remaining available as a manually selectable model?
Composer 1 will be completely retired on March 16, 2026, it will no longer be available as a selectable model on any plan. As the email states, the capacity is being reallocated to serve Composer 1.5, so Composer 1 will not remain available in any form after that date.
All users currently using Composer 1 will be automatically moved to Composer 1.5, which draws from the Auto + Composer usage pool and includes significantly more usage.
That’s honestly quite sad to hear, as I rely heavily on Composer-1 in my workflow. A few examples of how I currently use it:
Planning with frontier models (e.g., Opus or GPT-5.4) and sometimes Composer-1.5.
Validating whether the plan is already sufficient by executing it in a separate chat using Composer-1.
Linking results back by referencing the execution chat.
Beyond that, I often use Composer-1 to:
Explore repositories in Ask mode (quickly finding relevant code or files).
Execute deterministic “skills” or tasks that are more execution-oriented and don’t require heavy reasoning.
Overall, Composer-1 has been extremely valuable because of its speed and cost efficiency. From my experience, Composer-1.5 feels noticeably slower (likely due to additional reasoning), and while it may replace some frontier-model tasks, it doesn’t really cover the same use cases that Composer-1 serves for me.
Would there still be any possibility of reconsidering this decision?. For example, keeping Composer-1 explicitly available on something like the Ultra tier?
Also, regarding the usage pools mentioned in the email: on the Ultra tier it currently looks like there’s only a single pool. I may be misunderstanding, but I’m not sure how the Auto + Composer pool change would affect Ultra users. Would Composer-1.5 at least be priced differently on that tier, or otherwise help address the cost difference compared to Composer-1?
Huge +1. Composer 1 has been vital to my workflow; the combo of Opus 4.6 (Plan) and Composer 1 (Execute) provided the perfect balance of speed and cost-efficiency.
Unfortunately, Composer 1.5 has been a downgrade for me, or at least it doesn’t play in the same category—slower and unreliable compared to Composer 1, and pricier than Sonnet. I’ve been moving back to Haiku 4.5 as a replacement in light of the recent email, and I’ll likely stick with it if Composer 1 gets retired. A bit sad to see such a useful tool deprecated on such short notice and without equivalent from Cursor.
I’m open to suggestions for achieving a similar workflow if Composer 1 gets cut.
I agree here! Composer 1 was my go-to model. I suspect part of the issue is that Composer-1 had lower per-token input and output pricing, which was potentially here due to adoption of Composer-2. This does seem like a rather self-interested and user-hostile move on the part of Cursor.
I’ve switched only to using Haiku 3.5 in the situations where previously I would have used Composer-1 and am openly looking into using Kilo Code code and Opencode so that I can have a little more choice in the variety of models and the tradeoffs that we’re making for our team.
If Cursor is willing to bring back the model, I would definitely stop the search and think a lot harder about switching over to other low-coding adjacent platforms. It’s a great platform, and I really have enjoyed using it and evangelizing it to our team of engineers in the past