Hello! I’m experiencing an issue with BYOK.
After my workspace (Team plan) was migrated from request-based usage to token-based usage, the included token allowance is exhausted within just 1–3 days.
To work around this, I tried using BYOK with Anthropic. It mostly works, but there’s an issue with subagents: they cannot use a different model from the one currently selected.
For example, if I select Sonnet 4.6 as the main model, all subagents automatically inherit Sonnet 4.6 instead of using their configured models (such as Haiku or Opus).
Steps to Reproduce
Enable BYOK for Anthropic.
Select Sonnet 4.6 as the active model.
Ask the assistant to run the Explorer subagent (or any custom subagent configured to use a different model, such as Haiku or Opus).
Observe that the subagent uses Sonnet 4.6 instead of its configured model.
Expected Behavior
Any Anthropic model should be able to launch a subagent using any other Anthropic model. Subagents should use their configured model rather than inheriting the currently selected model from the main conversation.
Subagents inheriting the main model defeats a lot of the point of configuring them separately.
For BYOK especially, model choice is not just quality preference. It is also cost control. If a lightweight review or explorer agent silently runs on the selected premium model, the user loses the main benefit of having per-agent model settings.
Hi @KirillSaltykov Thanks for reaching out! This is working as designed for how BYOK sessions currently behave: when you use your own API key, subagents are pinned to the model selected for the parent conversation. Because of that, the configured Explore model is not applied during a BYOK session, even though Settings still shows Composer 2.5 or a different model.
For now, you can either switch the parent conversation to your desired model before launching the subagent, or temporarily disable BYOK to have the configured per-subagent model selection honored through Cursor-managed usage.
I’m having the same issue, and I see the current behavior as a bug.
If I want to use the same model in my BYOK environment, I simply don’t tell the agent to select another model, and it inherits the current one. However, if I explicitly tell the agent to use a different model—regardless of whether that also runs via BYOK or not—I would expect Cursor to respect that choice.
Fable (and future Fable-tier models) spend most of their tokens on subagents because they’re heavily RLVR’d as orchestrators.
Since your BYOK forces those subagents onto the parent model, BYOK is pointless. I’m paying Fable prices for work GLM could do for 10x less.
Open-source already support this. Cost is all that matters. No number of Cursor features makes up for costing 10x more because subagent model selection is effectively disabled.
Until BYOK respects my model choice, I have no use for Cursor.
