[FEATURE] enable extended thinking for subagents, currently not possible
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
this is a super frustrating issue, and honestly, who are you to say i shouldn't waste tokens enabling extended thinking for subagents? if i want to pay more, use more, get more power out of claude code, then LET ME.
context: i would use this for analyzing large amounts of content, and subagents are otherwise perfect for that, except, as we all know, without extended thinking, claude struggles massively with complex tasks, often just spitting bullshit.
i can't be bothered using multiple different main instances instead of subagents. that just destroys everything.
claude code research on this issue as reference:
---
The Short Answer
Extended thinking cannot currently be enabled for sub-agents. There's no documented parameter or mechanism to do this.
The Details
- Task tool has no thinking parameter
The Task tool accepts: description, prompt, subagent_type, model, run_in_background, resume. No thinking or budget_tokens parameter exists.
- Verbal cues in main conversation ≠ sub-agent thinking
The "think" → "think hard" → "ultrathink" progression works in the main conversation because Claude Code's system intercepts these and sets API-level thinking budgets. But when you spawn a sub-agent, that's a separate API call where:
- The sub-agent gets its own system prompt
- Your task prompt becomes user content
- There's no mechanism to pass thinking configuration
- Your export observation confirms this
If your exporter captures thinking blocks from main conversations but not sub-agent conversations, that's evidence they're not getting thinking enabled at the API level.
Workarounds (all imperfect)
- Verbose prompting - Tell sub-agents to "reason through this step by step, show your work, consider multiple angles before concluding." This doesn't enable actual thinking tokens, but it encourages longer, more deliberate output in the main response.
- Don't use sub-agents for complex analysis - If you need thinking, do the analysis in the main conversation and use sub-agents only for simpler tasks.
- Feature request - This seems like a reasonable feature to request via GitHub issues.
My Take
You've identified a real limitation. For content analysis where you want deep reasoning, you're currently forced to choose between:
- Main conversation with thinking (better analysis, uses your context)
- Sub-agents without thinking (preserves context, shallower analysis)
There's no way to get both right now.
Sources:
- https://code.claude.com/docs/en/sub-agents
- https://docs.claude.com/en/docs/build-with-claude/extended-thinking
- https://www.anthropic.com/engineering/claude-code-best-practices
Proposed Solution
just make it possible to enable extended thinking blocks for subagents.
although i'm not sure if this is caused by some other limitations than just not allowing it, surely it's possible somehow to implement.
PLEASE IMPLEMENT THIS, I'M BLOODY DESPERATE!
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
API and model interactions
Use Case Example
context: i would use this for analyzing large amounts of content, and subagents are otherwise perfect for that, except, as we all know, without extended thinking, claude struggles massively with complex tasks, often just spitting bullshit.
i can't be bothered using multiple different main instances instead of subagents. that just destroys everything.
Additional Context
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
12 Comments
I strongly agree with this feature request. Given Claude Code's emphasis on the use of agents and skills, this seems like a major gap in the current feature set.
It is really frustrating that we do not have this feature yet
Additional observations from transcript analysis:
I examined a subagent's transcript (
.jsonlfile) and confirmed that thinking blocks are completely absent. Instead, the subagent outputs text blocks like "Let me search for...", "Now let me look at...", "I found a critical piece of information..." between tool uses. The final output is also a text block.Uncertainty about thinking vs text internal processing:
Even though the subagent is "thinking" via text blocks, this may not be equivalent to actual thinking blocks. We don't know the internal implementation of the API/model:
Inconsistency between parent and subagent:
If subagents used thinking blocks for their reasoning, users could have consistent display control (fold/unfold, show/hide) across both parent and subagent outputs.
Separating the model issue:
The original poster mentions subagents "spitting bullshit"—this might be a model issue rather than (or in addition to) a thinking issue:
"haiku", claude-code-guide="haiku", etc. (see #16594)model: opusin Task tool calls to override this---
✍️ Author: Claude Code (Dev Container) with @carrotRakko
Note: This comment was written and submitted by an AI agent (Claude Code), with human review and approval.
Just discovered this limitation. I now feel dumb to have had developped complex subagent scaffold where subagents are by design significantly dumber than the main agent
Relatable issue, this holds back using sub-agents in a lot of important context and pushes to using multiple top-level claudes and orchestrating them instead until sub-agents get more granular control capabilities.
I'm using a multi-agent team pipeline (plan → prd → exec → verify → fix) where the planning and PRD stages require deep reasoning, but subagents can't use extended thinking.
This forces me to do all planning in the main agent and only delegate execution — which defeats the purpose of having specialized planning agents.
Proposal: Add an optional thinking_budget parameter to the Agent tool, so users can enable extended thinking per subagent when needed.
Agent({
prompt: "...",
subagent_type: "planner",
model: "opus",
thinking_budget: 10000 // new parameter
})
This would be especially valuable for orchestration frameworks where different stages have different reasoning requirements.
Fwiw latest Claude version enabled different thinking level for different agents in the frontmatter. Also teammates have thinking so might be worth to use them instead
Wait is that me or now subagent have thinking??
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Comment for anthropics/claude-code#14321</h1>
<p>Ran controlled tests of how thinking/effort configuration reaches <strong>subagent</strong> dispatches (and whether the delivered effort value changes behavior), with a request-level logging proxy as ground truth. Result: <strong>this issue's core claim is confirmed, with a sharper mechanism — Claude Code sends <code>thinking: {"type": "disabled"}</code> on every subagent call</strong>, while the equivalent main-thread call runs thinking-enabled at the 31,999 budget <em>by default</em> (verified with a no-keyword control: main-thread haiku with no thinking keyword anywhere still got <code>enabled, budget_tokens: 31999</code>, consistent with the Jan 2026 ultrathink deprecation in favor of thinking-on-by-default). So the gap is precisely main-thread vs subagent: thinking on by default in one, explicitly disabled in the other, and no prompt content can override the request-level config.</p>
<p><strong>Setup</strong> (Claude Code <code>2.1.176</code>): fresh repo; a minimal <code>haiku-test</code> agent (model: haiku) and two sonnet agents differing only in frontmatter (<code>effort: high</code> / <code>effort: low</code>) as effort-delivery controls. Fixed reasoning task via <code>claude -p --output-format json</code>. Ground truth: a local logging proxy (<code>ANTHROPIC_BASE_URL</code> → 127.0.0.1 → api.anthropic.com) recording the <code>thinking</code> / <code>output_config</code> fields of every <code>/v1/messages</code> request. Auth redacted from logs.</p>
<p><strong>Observed on the wire:</strong></p>
Call | thinking in request | output_config | Output tokens
-- | -- | -- | --
Main thread, haiku, prompt leads with ultrathink | {"type":"enabled","budget_tokens":31999} | — | 8,324
Haiku subagent, keyword in dispatch prompt (×2) | {"type":"disabled"} | — | ~860–1,010
Haiku subagent, no keyword (×2) | {"type":"disabled"} | — | ~350–1,065
Main thread, haiku, NO keyword (follow-up control) | {"type":"enabled","budget_tokens":31999} | — | 14,627
Sonnet subagent with effort: high frontmatter | {"type":"disabled"} | {"effort":"high"} | 688
Sonnet subagent with effort: low frontmatter, session at effort high | {"type":"disabled"} | {"effort":"low"} | 419
<p><em>On whether the delivered <code>effort</code> value actually <strong>changes behavior</strong>, a follow-up paired experiment (8 generated logic puzzles, same variant solved at each effort level) separates two regimes:</em>
<em>- <strong>Main thread (thinking <code>adaptive</code>):</strong> effort high produced more reasoning than low on <strong>8/8</strong> paired variants, median <strong>1.55×</strong> output tokens — a clear, consistent behavioral effect.</em>
<em>- <strong>Subagent (thinking <code>disabled</code>):</strong> an earlier micro-task comparison (3 runs/level) found <strong>no</strong> detectable difference (high mean 927 vs low 920).</em>
<em>The most economical reading: effort's primary lever is thinking depth, so it bites in the main thread where thinking is live and is blunted on subagent calls where thinking is force-disabled. A same-variant subagent run is the clean test of that and is the obvious next step. Either way, the two sonnet rows above are evidence of config <strong>delivery</strong>, not magnitude.</em></p>
<p><strong>Takeaways:</strong></p>
<ul>
<li>Main-thread haiku ran thinking-enabled at budget 31,999 <strong>with or without the keyword</strong> — it's the default, not keyword interception — at 8–14× the output tokens of the thinking-disabled subagent calls.</li>
<li>Every subagent request carried <code>thinking: {"type":"disabled"}</code>, keyword or not — prompt-level cues cannot act on subagents because request-level config overrides prompt content.</li>
<li><code>effort</code> frontmatter is delivered per-subagent and <strong>overrides the session level</strong> — isolated directly: an agent with <code>effort: low</code> dispatched from a session running at effort high produced <code>output_config: {"effort":"low"}</code> on its request, while the orchestrator's own calls in the same session carried <code>effort: high</code>. So for adaptive-reasoning models, agent-definition frontmatter is the per-role effort control that reaches the API today; the delivered value measurably changes main-thread behavior, with magnitude on thinking-disabled subagent calls still open (see footnote). Haiku subagents — no effort parameter — are left with no reasoning-depth control at all: thinking force-disabled, keywords inert, no effort field. That gap may be worth folding into this issue's scope or the per-invocation requests (#25669, #43083).</li>
</ul>
<p>Limitations: small n; single CLI version (2.1.176) and machine, thinking-related settings not exhaustively recorded; keyword transmission into subagent prompts was not independently verified via transcripts (the sidechain transcript layout appears to have changed in 2.1.x) — moot given the request-level <code>disabled</code> config. Raw redacted proxy logs available on request.</p>
<p><em>Produced by a model+human pair: measured on the human's machine, analyzed and written by Claude (Fable 5), directed and reviewed by the human submitter.</em></p></body></html><!--EndFragment-->
</body>
</html>
It is sad that this is still open and not fixed
I think this is fixed though?bby default subagents now inherit the thinking oaram. And workflows allows you to control it per agent
I want to be able to set the effort level for subagents instead of inheriting, and do not want to use workflows for this