Agent tool missing 'model' parameter for team agent model selection

This is true not only in Teammate Mode, but in general, for ALL subagents fired in or out of Teammate Mode (although I do have the beta flag on).

Our organization uses Claude Code agents extensively and routes to different models based on the type of problem being solved, not based on a static agent definition.

Architects and implementers → opus (complex reasoning) Assistants/verifiers → sonnet (verification work) Utility/ephemeral agents → haiku (lightweight tasks)

This is consistent with how we have our Orchestrators work.

This routing decision is made dynamically at invocation time by the parent agent based on the problem context. Without a model parameter on the Agent tool, we cannot do this. The only current workaround is to define a separate agent .md file for every model variant (e.g., researcher-haiku.md, researcher-sonnet.md, researcher-opus.md), which is brittle, duplicative, and defeats the purpose of dynamic routing (not to mention incompatible with 3rd party plugins).

Expected behavior

The Agent tool schema should accept an optional model parameter (e.g., "model": "opus", "model": "haiku", "model": "sonnet") that overrides the default model for that subagent invocation. This would allow the parent agent to make cost/capability-appropriate model selections at runtime.

I support the idea of being ABLE to declare a DEFAULT model for an agent, but that is not mutually exclusive with overriding a model in response to dynamic issues, and this is a big miss for us.

This behavior of assigning a specific model on teammate spawn was working just fine for me up until this morning.

Now all teammates spawned via Agent Team prompt use same model (originally it was using Opus, now something has changed in the last hour and everything is spawning with Sonnet), no matter what is specified in the team definition.

Spawning generic subagents with the a given model has been a really useful way to do adhoc tasks without needing to create agent definitions up-front (outside agent teams).

This is a pretty significant regression, not an enhancement.

Took a crack at this with Claude Code and it has a report:

---

Reverse-engineering findings from binary analysis (2.1.68 vs 2.1.70)

I did a comparative binary analysis between 2.1.68 (where model worked) and 2.1.70 (where it doesn't). Here's exactly what changed and where the fix points are.

1. Schema removal

In 2.1.68, the Agent tool's Zod schema included:

subagent_type: N.string().describe("The type of specialized agent to use for this task"),
model: N.enum(["sonnet","opus","haiku"]).optional().describe("Optional model to use for this agent..."),
resume: N.string().optional()...

In 2.1.70, the model field is gone from the schema entirely. additionalProperties: false causes Zod to strip it before the handler ever sees it.

2. Override slot hardcoded to void 0

The model resolution function (minified as Vv$ in 2.1.70, WV$ in 2.1.68) accepts an override parameter in its third argument slot:

// Deobfuscated signature:
function resolveAgentModel(agentDefModel, mainLoopModel, override, permissionMode, agentType) {
  if (process.env.CLAUDE_CODE_SUBAGENT_MODEL) return resolveAlias(process.env.CLAUDE_CODE_SUBAGENT_MODEL);
  // ... bedrock handling ...
  if (override) return resolveAlias(override);  // <-- This is the per-call override path
  let model = agentDefModel ?? "inherit";
  if (model === "inherit") return resolveInherit({permissionMode, mainLoopModel, exceeds200kTokens: false});
  return resolveAlias(model);
}

In 2.1.68, the call site passed the tool call's model parameter as the override:

// 2.1.68 - L is the model from the Agent tool call
let j = WV$(z.model, U.options.mainLoopModel, L, P, z.agentType);

In 2.1.70, that slot is hardcoded to void 0:

// 2.1.70 - override hardcoded to undefined
let C = Vv$(v.model, q.options.mainLoopModel, void 0, E, v.agentType);

The resolver function itself is unchanged and fully functional -- it's just never given the override value anymore.

3. Disabled feature flag for new infrastructure

There's a new getAgentModel function in 2.1.69+ that doesn't exist in 2.1.68. It's gated behind a hardcoded feature flag in the UI renderer:

let A = !1;  // hardcoded false
if (H.model || A) {
  let L = getCurrentModel();
  let D = A ? getAgentModel(void 0, L, H.model, void 0, H.subagent_type) : resolveAlias(H.model);
  if (A || D !== L) /* show model badge */
}

When A is false: no model badge is displayed, getAgentModel is never called. This looks like a staged rollout flag for new model resolution infrastructure that hasn't been enabled yet.

4. Teams path has separate model handling

The Teams spawn path (handleSpawnInProcess) reads model from the agent definition and defaults to NgA() which resolves to a provider-specific map:

{ firstParty: "claude-opus-4-6", bedrock: "us.anthropic.claude-opus-4-6-v1", ... }

So teammates without an explicit model default to Opus, not to the parent model. This is different from the non-team path where general-purpose agents inherit from the parent.

Summary

This appears to be a "remove old, build new, reconnect later" refactor where the reconnection hasn't shipped:

• The old path (tool call model param -> override slot in resolver) was removed
• The new path (getAgentModel + feature flag) was added but disabled
• The resolver function itself is intact and would work immediately if the override slot received a value again
• The simplest fix is re-adding model to the Zod schema and passing it to the third argument of the resolver instead of void 0

The internal plumbing is all there. This is a one-line schema fix and a one-line call site fix to restore the old behavior while the new infrastructure is completed.

---

I genuinely wish I could finish whatever internal implementation is planned, 'cause it looks good but it's... clunky.

Ok thanks for this report. The intention was to use custom subagent definitions that specify the model in the front-matter. I understand this is inconvenient with the general subagent (since you'd need a few different ones) but it didn't seem insurmountable. For those of you relying on this for teammates, can you say how this works?

Ok thanks for this report. The intention was to use custom subagent definitions that specify the model in the front-matter. I understand this is inconvenient with the general subagent (since you'd need a few different ones) but it didn't seem insurmountable. For those of you relying on this for teammates, can you say how this works?

This was actually supported in February and stopped being supported around Feb 26 (when I was setting up my Claude Code environment in January, it explicitly asked me what agent I'd like to use for the model and respected that setting)
Now when I launch subagents from the root session they inherit the default session model by default

The regression was a two-step failure
On the first time that appeared Claude stopped respecting the model field in frontmatter, but I was able to work around it by storing the agent launch configurations in memory
Now when the Agent tool does not have a model field this has become impossible to work around

We're going to put back this param, thanks again for the feedback. I was hoping to have this in today's release but it missed the cut. I'll make sure it goes out with 2.1.72

Is there any way for you guys to actually start respecting agent
frontmatter model field as well?
Because right now it's ignored, and I feel it shouldn't be, since Claude
asks what model would I like to use with the agent once it's created

yes, the break on model param in agent front matter is a separate issue. sorry about that! this field is back in the SDK as of 2.1.72

let's chase down the issue with agent front matter in #32415

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.