I run many Cursor Automations and rely on Composer for this work. When Composer 2 was replaced by Composer 2.5, I had to open each automation and change the model one by one. With a large number of automations, that does not scale, and it is easy to miss one and leave it on an older model.
Problem
Today, the Automations model picker does not offer Auto (dynamic routing) the way the IDE does. There is also no “Latest Composer” (or equivalent) option that would keep an automation on Cursor’s current Composer default when you ship a new version. Every Composer upgrade becomes a manual migration across all automations.
Proposed behavior
Please add two choices in the Automations model settings (and in the API when supported):
Auto — Cursor selects an appropriate model for the run, similar to the IDE.
Latest Composer — This automation always uses the current default/latest Composer family model (e.g. 2.5 now) without editing each automation when a new Composer version is released.
Why this matters
I want automations to stay on the model I prefer without repeating the same update across every automation whenever Composer moves forward. For teams running many automations, that would remove a lot of operational toil and reduce the risk of stragglers on old models.
Question about this: let’s say the next version of Composer costs a little more than Composer 2.5 (there are no plans around this, purely theoretical). Would you still be okay with being automatically migrated?
Thanks for the question — that’s exactly the point I was weighing too.
Honestly, no — for a version that changes pricing, I would prefer not to be migrated automatically. Automations can run in the background, so an unexpected cost increase feels riskier than simply staying on an older model.
That said, my ideal outcome would be for the Composer line to keep evolving within the same stable/default pricing tier. If Cursor ever introduces a significantly more capable and more expensive model, I’d personally prefer it to be treated as a separate model line rather than as the next “Composer.”
In that world, “Latest Composer” stays very intuitive: it just means “use the latest model in the standard Composer line,” with no pricing surprises.
Of course, I understand the future of the model lineup is hard to commit to here, so I don’t expect this to be guaranteed — it’s just my preference.
And for the cases where I do need to move automations to a new (possibly pricier) model, a bulk action to update the model across multiple automations at once would go a long way toward reducing the maintenance burden.