Claude Code 2.1.316 lets subagents run at a lower effort than the parent session

Subagents no longer inherit the session's effort

Claude Code 2.1.316 introduces an environment variable, CLAUDE_CODE_SUBAGENT_EFFORT, that sets the effort level subagents run at whenever nothing else names one. Until now, a subagent with no effort setting of its own inherited the session's level, so a session pinned to high effort dispatched even its read-only exploration agents at full reasoning depth. The changelog entry is dated October 31, 2026, and according to the dev.to write-up by Gabriel Anhaia that is still the only official word on it — the environment variable reference has not listed the variable yet.

Where the new variable sits in the precedence chain

Effort controls adaptive reasoning: lower levels are faster and cheaper for straightforward tasks, while higher levels buy deeper analysis. Levels run low, medium, high, xhigh and max depending on the model, and Opus 5.5, Sonnet 5.5 and Haiku 5.5 default to medium when nothing sets one. Thinking tokens are billed as output tokens, so effort shows up directly in the bill.

Several mechanisms already name an effort for a subagent, and all of them outrank the new variable. An effort field in the subagent's frontmatter overrides the session level; an effort parameter Claude passes at spawn time — available since v2.1.292 — overrides the frontmatter; and CLAUDE_CODE_EFFORT_LEVEL takes precedence over both. CLAUDE_CODE_SUBAGENT_EFFORT only decides anything when none of those apply. Anhaia flags the practical consequence: if you export CLAUDE_CODE_EFFORT_LEVEL in your shell, the new variable has nothing left to decide.

Explore is the workload it targets

The clearest beneficiary is the built-in Explore subagent. It is read-only, used for file discovery, code search and codebase exploration, runs on the main conversation's model, and carries no documented effort level — so unless Claude passes one at spawn time, it is exactly the case the new variable covers. Effort and model are separate knobs: setting CLAUDE_CODE_SUBAGENT_MODEL alone does not change which model Explore and Plan run on.

Measuring the savings, and the traps

The dev.to post walks through a comparison: two git worktrees, the same read-only search task, model and session effort pinned in both runs, with CLAUDE_CODE_SUBAGENT_EFFORT=low set in only one. Headless JSON output reports total_cost_usd including subagent requests, but those figures are client-side estimates built from token counts at list price. On subscription plans the dollar amount is not what you pay; the token counts are the useful signal of which run consumed more of your limits.

Transcript accounting needs care. Subagent transcripts land per agent under ~/.claude/projects/{project}/{sessionId}/subagents/, and a single API response containing several content blocks is written as several assistant entries that share one message id and duplicate the same usage numbers. A maintainer confirmed in issue #87303 that consumers are expected to count each message id once; the reporting sample overcounted cache writes by 1.92x when summed naively. Per-step output token figures in transcripts are placeholders, so output totals should come from the run's JSON instead.

Fan-out adds noise on top: Claude decides how many Explore agents to start and how thorough each one is — quick, medium or very thorough — so the same prompt can behave differently across runs. The post's advice is to run each side three times, alternate which goes first, and compare medians. One guard is worth knowing: since v2.1.302, headless runs start in Manual permission mode when nothing sets one, so any call needing approval is denied with nobody there to approve — which suits a read-only comparison.

Why it matters

Subagent fan-out multiplies spend. A high-effort session that spawns several Explore agents has been paying high-effort prices in each of them for work that rarely needs deep reasoning, and every thinking token is billed as output. The new variable decouples the two: keep expensive reasoning where it pays, in the parent session, and send the scouts out cheap. That makes it one of the few direct cost and latency levers available to agent users without weakening the session itself. The open question is documentation — until the variable appears in the official reference, its behaviour rests on a single changelog line plus the effort rules around it.