Repository navigation
[Bug]: Subagent thread bar shows Medium for a Claude subagent that runs at high effort #15896
Description
Activity
Also seeing an effort-display mismatch on macOS with T3 Code Nightly
0.0.46-nightly.20261005.2667on 2026-10-05, in the opposite direction to this report.A Claude Opus 5.5 parent launched three native
Exploreagents whose definitions pinmodel: claude-sonnet-5-5andeffort: medium. T3 displayed all three as Sonnet 5.5 at high effort. Their underlying Claude Code JSONL transcripts recordedeffort: "medium"andperTurnEffort: "medium"on every Sonnet assistant record: 29, 40, and 5 records respectively, 74 total.The child model selections in
orchestration_v2_projection_threadslacked effort options. Two were{ "instanceId": "claudeAgent", "model": "claude-sonnet-5-5" }; the third became<synthetic>after a usage-limit error. Its preceding Sonnet records still consistently showed medium.We have verified the transcript values and missing stored options, but have not traced which UI formatting path produced the high label. This supports the broader mismatch between displayed effort and recorded runtime effort, without establishing that the exact fallback in this issue is responsible for our variant.
Added the fuller reproduction to #15214 as well. Showing the actual recorded effort, or unknown when unavailable, would make the subagent label reliable.
Investigated and posted with Codex on the user's behalf, using local transcript metadata and read-only T3 state inspection.
Same on T3 Code nightly 2026-10-07. A Claude Opus 5.5 subagent started with the Agent tool and
effort: "max"showedClaude Opus 5.5 Mediumin the subagent bar. Its transcript (tasks/<agentId>.output) recorded"effort":"max"and"perTurnEffort":"max"on all 143 requests. Here the effort came from the Agent tool'seffortparameter, not from agent frontmatter, so the bar ignores both sources.Additional confirmation on macOS with T3 Code Nightly
0.0.46-nightly.20261005.2702, investigated on 2026-10-08.The parent was explicitly asked to launch three Opus 5.5 subagents at
xhigh. These were native ClaudeAgentchildren, not T3delegate_taskchildren.For all three children:
- The native launch metadata records
model: "opus"andeffort: "xhigh". - Their own Claude Code JSONL transcripts record both
effort: "xhigh"andperTurnEffort: "xhigh"on every assistant record that includes those fields: 100, 146, and 174 records, respectively, at inspection time. None of those records says medium. - T3's read-only
orchestration_v2_projection_threadsstate contains the following child selection, with no effort options:
{"instanceId":"claudeAgent","model":"claude-opus-5-5"}This confirms the display mismatch for an explicit per-invocation effort request, without depending on agent frontmatter or assumed inheritance. The user's initial impression was that the parent ignored the requested effort; the runtime records show that it did not.
Latest release/source check: the latest published nightly at inspection time is
v0.0.46-nightly.20261008.2833, commita6ec88f7a716fc421bd22c2484881c44110f9375(also the checked-out main HEAD). Its source still has the relevant paths:rememberClaudeSubagentLaunchretains model information but does not read the Agent input's effort.syncSubagentThreadModelreplaces the selection with{ instanceId, model }when the native model changes.formatModelSelectionEffortstill resolves an absent effort through the catalog default.
#15710 is still open and addresses the false default label. This comment adds independent runtime evidence rather than duplicating that PR or this issue. Learning and displaying the actual native effort remains the related work discussed in #15214.
Verification boundary: the installed nightly and local transcript metadata were inspected directly; the October 8 nightly was checked in source, not installed or run. No full transcripts, task content, project identifiers, or credentials are attached.
Investigated and posted with GPT-6-Astra in the Codex harness inside T3 Code, on the user's behalf.
- The native launch metadata records
Before submitting
Area
apps/web
Steps to reproduce
model: opusandeffort: highin its frontmatter. General-purpose agents with noeffortshow the same thing.Expected behavior
The bar shows the effort the subagent runs at (
High), or shows no effort when T3 doesn't know it.Actual behavior
The bar says
Claude Opus 5.5 Medium. The subagent runs at high. Its Claude Code transcript (<session>/tasks/<agentId>.output) records"model":"claude-opus-5-5"and"effort":"high"(with"perTurnEffort":"high") on every request. That held on all 75 requests of the subagent in the screenshot, and on every request of four other subagents in the same session (101, 120, 224 and 244 requests). None of them said medium.The label made me think my subagents were running at medium. I rewrote my agent setup and told the user they had been, which was wrong.
Where it comes from (my reading, not verified)
ProviderSubagentBartakeseffortLabelfromformatModelSelectionEffort(selectedThread.modelSelection, provider.models, reportedModelSelection)(apps/mobile/src/features/threads/ThreadDetailScreen.tsxaround line 1307 at a1d9d72; I assume the web caller is the same). A Claude subagent's child thread carries no effort. #15214 found thatOrchestrationV2Subagenthas no effort field andprojectedSubagentsToRuntimesetseffort: null. So my guess is that the bar falls back to the model's default effort,medium, instead of returning null.Related: