claude-code - 💡(How to fix) Fix Subagents on Pro 1M tier: trivial probes pass, real workloads fail at first tool call (probe-vs-workload divergence)

Summary

On Claude Code v2.1.152 running as Pro 1M-tier (claude-opus-4-7[1m]), Sonnet subagents spawned via the Agent tool exhibit a probe-vs-workload divergence that is not documented in #44117, #61808, #53031, #43869, #45169, or #62143:

• Text-only probe (0 tool calls): PASS (~18k tokens, no error)
• Single-tool probe (1 Read call): PASS (~18k tokens, no error)
• Real HDARP workload (≥4 tool calls): FAIL at first real tool call with "Usage credits required for 1M context" (#44117) — subagent dies at tool_uses=4 or tool_uses=10, 0 tokens emitted, ~23–75s wall time

This means probe-based diagnostics give a false PASS. Workarounds intended to mitigate #44117 (env vars, in-session /model, alias relaunches) cannot be validated via lightweight probes — only by running the actual workload, which is exactly what's broken.

Environment

• Claude Code: v2.1.152 (current as of 2026-05-27)
• Platform: Windows 11 Home 10.0.26200, PowerShell + Git Bash
• Account tier: Pro with 1M context
• Launch alias:

  alias clauded1twohunk='CLAUDE_CONFIG_DIR="$HOME/.claude-d1" \
    ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-7 \
    CLAUDE_CODE_DISABLE_1M_CONTEXT=1 \
    claude --dangerously-skip-permissions'

• /context after launch: claude-opus-4-7[1m] (parent did NOT downgrade despite CLAUDE_CODE_DISABLE_1M_CONTEXT=1 — confirms #53031)
• /model claude-opus-4-7 in-session: banner unchanged, still [1m] (confirms #44117/#61808 not addressable via in-session model command)

Reproducer

1. Launch CLI on Pro 1M tier with CLAUDE_CODE_DISABLE_1M_CONTEXT=1 (env var or settings.json)
2. Verify parent via /context — observe [1m] suffix despite disable var
3. Spawn a Sonnet subagent that does only text (no tools): completes successfully
4. Spawn a Sonnet subagent that does one Read: completes successfully
5. Spawn a Sonnet subagent with a multi-tool workload (e.g. SPHDARP HDARP extraction: ~10 Read calls on PDF chunks + Write outputs): fails at first or fourth real tool call with "Usage credits required for 1M context", emits 0 tokens, dies in 23–75s

The failure is deterministic — observed in two consecutive rounds (rounds 34 and 35 of a 35-round retry sequence in our session).

What Makes This Different

The existing tracked issues describe the wall but assume a uniform entitlement failure mode. In practice the failure is workload-dependent: the same subagent that passes a text probe in seconds dies on a real workload after a few tool calls. This breaks the standard diagnostic flow ("spawn a small probe to see if the wall is up") that operators currently rely on.

We suspect the entitlement check is deferred until a tool-use boundary, and only fires after the subagent's context grows past some internal threshold — but the threshold is small enough (~4 tool calls) that any non-trivial workload trips it while probes don't.

Cross-Project Confirmation (added 2026-05-28)

The failure is not specific to one project or one alias. Within the same workspace and the same launch alias, the wall has been independently reproduced on two distinct projects (Volcker SPHDARP campaign and a second project called "Benjamin"). Both projects use the same HDARP/SPHDARP processing pattern (Sonnet processor subagents dispatched by an Opus parent), and both die at the first or fourth real tool call on real PDF chunks. This rules out per-project state, per-document content, or per-batch configuration as causes — the failure mode is purely entitlement-side and affects any SPHDARP-style multi-tool subagent workload across the workspace.

Why It Matters

For users running long-running parallel pipelines (in our case, HDARP/SPHDARP PDF extraction across thousands of batched documents), this:

1. Breaks pre-flight validation: probe-passes give false confidence
2. Defeats env-var workarounds: operators can't tell whether CLAUDE_CODE_DISABLE_1M_CONTEXT=1 "took" until they burn a real workload
3. Wastes session capacity: each failed real workload consumes parent context and operator attention
4. Blocks parallel pipelines workspace-wide: any project using Sonnet-subagent multi-tool processing is gated on this fix, not just one

Suggested Investigation

• Are entitlement checks deferred until a context-size or tool-count threshold? If so, exposing that threshold to operators would let us size probes correctly.
• Should CLAUDE_CODE_DISABLE_1M_CONTEXT=1 short-circuit the deferred check (since the parent has explicitly disclaimed the 1M tier)?
• Why does /model claude-opus-4-7 not reset the parent's effective tier when invoked in-session?

Related Issues

• #44117 — Usage credits required for 1M context (original report)
• #61808 — Same error fires on 200K parents (canonical parent)
• #53031 — CLAUDE_CODE_DISABLE_1M_CONTEXT=1 documented but unreliable
• #43869 — CLAUDE_CODE_SUBAGENT_MODEL silently ignored
• #45169 — Subagent re-attaches [1m] despite parent overrides
• #62143 — Headless OAuth / usage-page toggle desync