With MAX mode enabled and a specific model selected (claude-4.6-opus-max), first-level subagents correctly inherit the main agent’s model. However, when those subagents dispatch their own subagents (second level), the nested subagents fall back to composer1.5 instead of inheriting the model.
All my agent .md files have model: inherit in their frontmatter. Per the documentation, omitting the model parameter means “inherits from parent” – but this only works one level deep.
Steps to Reproduce
Enable MAX mode with claude-4.6-opus-max. Set model: inherit on all agent files. Have the main agent dispatch a subagent (level 1), then have that subagent dispatch its own subagent (level 2). Level 1 uses the correct model; level 2 falls back to composer1.5.
Expected Behavior
Model inheritance should propagate through all subagent nesting levels, not just the first.
Hey, thanks for the report. This is a known issue. A few users have said that sub-agents fall back to composer 1.5 instead of using the configured model.
In your case there’s a helpful detail. It looks like level 1 sub-agents work correctly, and the problem shows up only at level 2+ (sub-agents created by other sub-agents). I’ve shared this with the team.
A couple things that would help with debugging:
Can you share the request ID? (Chat context menu, top right, then Copy Request ID, with Privacy Mode turned off.) This lets us check which model is actually used at each nesting level.
Have you tried setting an explicit model name (for example, model: claude-4.6-opus-max) instead of model: inherit in the agent files? I’m curious if explicit model names behave differently at level 2.
Request ID: da57c516-c5a8-4266-9f09-92b23fc01a29. Privacy Mode is enabled and controlled by our org admin. It can’t be turned off.
Regarding explicit model names: I tested setting model: claude-4.6-opus-max explicitly in all agent .md files instead of model: inherit. Same result – level 1 subagents use claude-4.6-opus-max correctly, level 2 subagents still fall back to composer1.5. So the issue isn’t specific to inherit; model configuration is ignored entirely at level 2+.
Hi @deanrie,
Is there a rough timeline for a fix?
We built a framework that relies on multi-level subagent orchestration, and when we started using it we hit this bug — our work has been blocked since.
Hey, unfortunately we don’t have a specific timeline yet. The bug is logged and the team is aware, but I can’t give an ETA since that wouldn’t be fair.
A useful detail from your test is that even explicitly setting model: claude-4.6-opus-max gets ignored at level 2+, which suggests the issue is deeper than just inherit.
Right now there isn’t a workaround. If multi-level orchestration is critical, the only option is to flatten the setup to a single nesting level where the model is inherited correctly.
When I click a subagent, it opens as a file where I can see it running.
For the level-1 subagent (which correctly inherits the model in MAX mode), the file shows at the top the inherited model, and there is a Chat Request window containing the full content from agents/my_agent.md.
For level-2 subagents (spawned by the level-1 subagent), the file also opens the same way, but there is no Chat Request window at all, similar to the built-in subagents like explorer/bash/browser.
This suggests the nested subagent is not only falling back to composer1.5, but also not receiving the full subagent instructions from agents/my_agent.md, so it may not behave as expected.
I’m now on On-Demand Usage (request-based pricing) and it’s working as expected — level-2 subagents correctly inherit the model and no longer fall back to composer1.5. run_in_background also works properly at level-2 now.
I didn’t test it with more than 2 levels.
Not sure what caused the fix though, if it’s because I switched to On-Demand after exhausting my Included-Request quota. It definitely didn’t work on On-Demand before.
I can’t retest on Included-Request until my quota resets at the beginning of next month — and it really matters that it works then, since in my plan On-Demand only kicks in after the Included-Request quota is exhausted.
Hey, that’s a helpful update. It’s interesting that everything works correctly on On-Demand, that’s a good clue for debugging.
When your Included Requests quota refreshes at the start of next month, let me know if the bug shows up again. If it turns out the issue is tied to the billing type, that’ll narrow down what to look at a lot.
