claude-code - 💡(How to fix) Fix [BUG] Cowork: Agent tool `model` parameter silently ignored — all sub-agents routed to Haiku [3 comments, 3 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

In Cowork mode, all sub-agent model routing is silently ignored. All sub-agents are routed to Haiku 4.5 (claude-haiku-4-5-20251001) regardless of which mechanism is used to specify the model. This includes the model parameter on the Agent tool, custom agent definitions with model: frontmatter, and any other configuration. No error or warning is returned. The tool schema accepts the parameter and validates it, but the override happens server-side before the API call.

Observed on both Max 5x and Max 20x plans. Behaviour is identical on both.

Evidence:

1. Self-identification: All sub-agents, regardless of the model parameter passed, self-identify as claude-haiku-4-5-20251001 when asked.

2. Capability testing: A standardised 50-question capability exam was administered to sub-agents spawned with different model parameters. All three ("opus", "sonnet", "haiku") scored identically at ~46-52%, matching Haiku's expected range. Opus should score 80-86%.

3. Response timing: Sub-agents spawned with model: "opus" return in 1-2 seconds, consistent with Haiku. Actual Opus responses take considerably longer.

4. Token counts: All sub-agents report consistent ~39k system prompt tokens regardless of requested model.

5. Transcript verification: Exported session transcripts (JSONL) confirm the model field shows Haiku for all sub-agents.

6. Historical persistence: Same behaviour in transcripts dating back to at least March 16, 2026, suggesting this has been the case since Cowork's launch.

7. Claude Code comparison: The same Agent tool with the same model parameter works correctly in Claude Code CLI, confirming the override is Cowork-specific.

8. Compaction agent exception: The compaction agent (a system-level operation) does receive Opus, confirming the platform can route to different models. The restriction applies only to user-spawned sub-agents.

Note: This is distinct from #43869 (CLI sub-agents resolve to parent model/Opus). In Cowork, the direction is reversed: sub-agents are forced down to Haiku regardless of what is requested. Different symptom, different platform, likely different root cause.

What Should Happen?

Either:

1. The model parameter should be respected and sub-agents should run on the requested model, or
2. If there is an intentional restriction (e.g. cost control), the tool should return a clear indication that the model was overridden, and the tool schema should not accept model values that will be ignored.

Error Messages/Logs

No error messages are shown. The override is completely silent. The only way to detect it is by testing sub-agent capabilities or checking session transcripts.

Source code investigation via Electron developer tools (`index-BTcH7cdH.js` under `file:claude-ai/v2/assets/v1`) found the `YukonSilverConfig` mechanism which controls model routing for sub-agents:


, gSt = "cowork-extended-thinking-enabled";
function xSt(e) {
    const t = ACe()
      , [n,s] = mI( () => {
        const e = localStorage.getItem(gSt);
        return null === e || "true" === e
    }
    , !0)
      , a = u.useCallback( () => {
        s(e => {
            const t = !e;
            return localStorage.setItem(gSt, String(t)),
            Co.info(xo.DESKTOP_API, "Extended thinking toggled", {
                enabled: t
            }),
            t
        }
        )
    }
    , [s]);
    return u.useEffect( () => {
        if (!BG)
            return;
        const s = e && !n ? {
            ...t,
            maxThinkingTokens: 0
        } : t;
        Co.info(xo.DESKTOP_API, "Pushing YukonSilverConfig with extended thinking setting", {
            gateEnabled: e,
            enabled: n,
            maxThinkingTokens: s.maxThinkingTokens
        }),
        BG.setYukonSilverConfig?.(s)
    }
    , [n, t, e]),
    {
        enabled: n,
        toggle: a
    }
}


This `YukonSilverConfig` appears to be the configuration object pushed to the sub-agent orchestration layer. The model override likely occurs within or downstream of `setYukonSilverConfig`. The config is set before sub-agents are spawned and does not incorporate the user's requested model parameter.

Steps to Reproduce

1. Open Cowork mode with Opus 4.6 as parent model
2. Spawn a sub-agent with model: "opus" — e.g. ask Claude to dispatch a sub-agent for research
3. Have the sub-agent self-identify its model ("What model are you?")
4. Observe: it reports claude-haiku-4-5-20251001
5. Repeat with model: "sonnet" — same result
6. Repeat with custom agent definitions using model: frontmatter — same result

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude for Windows Version 1.1617.0 (8d6345)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related issues:

• #43869 — Subagent model routing broken in CLI (opposite direction: resolves to parent Opus)
• #1098 — Unexpected Model Selection: Claude 3.5 Haiku Forced by Statsig Configuration (closed, CLI, 2025)
• #16115 — Task tool subagents fail with 404 'model: haiku' (closed as duplicate, CLI)
• #29768 — Explore subagent inherits parent model instead of using Haiku as documented

Root cause hypothesis: The override occurs server-side in Cowork's orchestration layer, after tool schema validation but before the API call is made. There is no user-accessible configuration to change it.

Impact: Sub-agents are a core capability for complex multi-step tasks. Users relying on Opus-level reasoning in sub-agents (research, code review, planning) are unknowingly getting Haiku-level output. The silent nature of the override means users have no way to know unless they explicitly test for it.