Effort levels in Claude Code subagents
A Claude Code session has an effort setting (Low, Medium, High, Extra, Max) that controls how much the model reasons before answering, and the session can spawn subagents that do work on its behalf. On 2026-09-28 Oskar and I ran experiments to answer three questions. Can the parent session set a subagent's effort? Does a subagent pick up a change to the session's effort between its own turns? Does a change throw away the prompt cache? The parent can set it through the Workflow tool but not through the Agent or SendMessage tools. A subagent does pick up a session-level change between turns. A change does not throw away the cache; the misses we saw all had a different cause.
Setup
The session ran on Sonnet 5.5. I spawned three subagents with the Agent tool, one each on Sonnet 5.5, Opus 5.5 and Haiku 4.5, and asked each to quote any effort setting visible in its own context. Where a model supports effort, its context carries a <reasoning_effort> tag. Oskar then stepped the session through Low, Medium, High, Extra and Max in the UI. After each change I resumed the Sonnet and Opus subagents with SendMessage and asked again; Haiku was resumed once, at Medium. Later a workflow script launched 36 fresh probes: three models, five explicit effort overrides plus one launch with no override, two replicates each. Afterwards I read the session transcript, a JSONL file on disk that records every assistant turn with its token usage and an effort field.
Parent control
The Agent tool takes a model, an isolation mode and an agent type. SendMessage takes a recipient, a message and a summary. Neither has an effort parameter, so a subagent started or resumed through them runs at whatever level the session has at that moment.
The Workflow tool is different. Its agent() call accepts an effort option (low, medium, high, xhigh or max). All 24 Sonnet and Opus probes launched with an override reported the tag for the level requested, while the session itself sat at Extra, and the transcript's effort field matched each request. The two replicates agreed on every cell. Probes launched without an override took the session's level. Haiku 4.5 accepts the option without an error and ignores it: none of its 12 workflow probes showed an effort tag.
Effort between turns
Every resumed Sonnet and Opus subagent turn used the level the session had at that moment. The tag number for a level depends on the model, and the transcript's effort field names the level itself.
| Level in the UI | Transcript effort |
Sonnet 5.5 tag | Opus 5.5 tag | Haiku 4.5 |
|---|---|---|---|---|
| Low | low |
4 | 5 | none |
| Medium | medium |
5 | 10 | none |
| High | high |
10 | 15 | none |
| Extra | xhigh |
30 | 40 | none |
| Max | max |
max |
max |
none |
The resumed subagents and the workflow probes produced the same numbers. Opus at Low showed 5, which is what Sonnet showed at Medium, so the numbers are not comparable across models, and I don't know the scale behind them. Haiku 4.5 got no tag and no effort field at any level. Whether its API requests carry an effort value I can't tell from inside the session; nothing in its context or its transcript records one.
Prompt cache
Prompt caching reuses the already-processed start of a conversation when the next request begins with identical content and arrives before the cache entry expires. Each assistant message's usage block reports how many tokens were read from cache and how many were written, split by lifetime tier.
The parent's first request after the switch to Medium read 97,839 tokens from cache and wrote 94 new ones, which is the entire previous request. A later request, at Max, read 188,764. Every cache write in the parent session went to the 1-hour tier.
The subagents write only to the 5-minute tier, and their cache behaviour followed the gap between turns and nothing else:
| Resumed after | Level change | Result |
|---|---|---|
| 197 s (Opus) | Low to Medium | Hit, 53,765 read |
| 235 s (Haiku) | Low to Medium | Hit, 40,005 read |
| 869 s (Sonnet) | Low to Medium | Miss, 54,097 rewritten |
| about 2,990 s (both) | Medium to High | Miss, about 54,500 rewritten each |
| 36 s and 34 s (Sonnet, Opus) | High to Extra | Hit, 54,630 and 54,764 read |
| 61 s and 64 s (Sonnet, Opus) | Extra to Max | Hit, 55,034 and 55,091 read |
Every miss came after a gap longer than five minutes. Every resume inside five minutes hit, and five of those hits, on Sonnet and Opus, came across a level change. In the workflow run, 32 of the 36 fresh probes read from cache on their first request, so agents on the same model share a cached prefix. I did not find out why the other four missed.
Practical consequences
Set the session's effort level before starting work, because a subagent started through the Agent tool runs at whatever the session has when it starts or resumes, translated per model. When a subagent needs a different level from the session, launch it from a workflow script with the effort option. Haiku subagents run without an observable effort setting whatever you request. A subagent left idle for more than five minutes pays to rebuild its whole prefix on resume, which was about 54,000 tokens for a bare general-purpose subagent here, before it has read any task context.
Correction, 2026-09-28: the first version of this post said a parent session cannot set a subagent's effort. That holds for the Agent and SendMessage tools only. The Workflow tool's agent() can, as tested above.