When trying to deploy a marketplace plugin to a group of users, we want to specify the model that the agents within the plugin are using, in order to control for and work towards consistent outputs and quality of work. At this time, agents that are included as part of a marketplace plugin appear to ignore the model:frontmatter variable, compared to local or user plugins - is this considered expected behavior, or will there be a future update that allows for this consistent distribution? Thanks much.
Hey, thanks for the detailed report.
model: is a supported frontmatter field for agents docs Subagents | Cursor Docs so if it works properly for a local or user plugin but gets ignored when the same agent is distributed via a marketplace plugin, that’s not the expected behavior. I want to pass this to the team, but I need a couple details to reproduce the marketplace scenario exactly:
- Cursor version for you and for the users where it reproduces
- An example of the agent frontmatter, specifically how
model:is written, include the full value, including quotes or brackets if any - How you’re checking which model actually ran, agent card, logs, or something else
- A Request ID from one run via the marketplace plugin where the model didn’t apply. To get it: chat menu top right > Copy Request ID. Note that if Privacy Mode is enabled, the Request ID might be limited.
With that, I can compare the local vs marketplace path and pass it to the team. I’ll reply in the thread once there’s an update.
Can confirm this one — here’s the repro info Dean asked for, from our setup.
We ship an internal plugin through a GitHub marketplace URL. It bundles 7 subagents (jira-reader, figma-reader, bug-hunter, …), every one of them declaring a model in its frontmatter, e.g.:
---
name: bug-hunter
description: "Adversarial correctness review of a branch's diff…"
model: claude-sonnet-5
readonly: true
---
- Cursor version: 3.17.19 on macOS
- Verification method: ran each subagent and looked at the model shown for its run — every single time it matched whatever the parent session was on, not the frontmatter value. In the attached screenshot, an agent pinned to
composer-2.5[fast=false]executed on Grok 4.6 Medium (the session model). - Request ID:
92e9d3f7-86f0-4c5f-a701-298f563c8b73
One correction to the local-vs-marketplace framing in the OP: on our side the local route is broken as well — the same plugin wired up via a local symlink (re-checked Aug 24) drops the pins identically. So at least for us the frontmatter model is dead on both install paths, not just marketplace.
Hey, thanks for the detailed repro. That’s exactly what we need.
What you’re seeing isn’t expected. If a subagent sets model: in its frontmatter, it should run on that model, not inherit the parent session model. The extra helpful detail is that the agent card shows the pinned model composer-2.5[fast=false], but the actual run goes to the session model Grok 4.6 Medium. I’m taking this along with Request ID 92e9d3f7-86f0-4c5f-a701-298f563c8b73.
Also thanks for confirming it breaks the same way with a local path. That narrows it down. It’s not about marketplace distribution, it’s about subagent model resolution in general.
We’re already tracking this issue. I can’t share an exact timeline yet, but I’ll post an update in the thread when I have one.
Thanks, Dean. Happy to re-test on a pre-release build whenever you have one — we have the 7-agent repro ready on both the marketplace and local install paths, so we can confirm the fix covers both.
Thanks for keeping the repro ready. It’s great that you’re covering both install paths, marketplace and local. I’ll keep that in mind. Once there’s a build to test, I’ll message you here so you can run your 7-agent scenario and confirm both paths are fixed.