fix(clients): subagent bar stops guessing the subagent's effort

[fixfon]

Problem

Opening a Claude subagent's own thread shows a reasoning effort the subagent never reported. For an Opus 5.5 subagent whose agent definition sets effort: high, the status bar reads Claude Opus 5.5 Medium while the subagent itself prints CLAUDE_EFFORT=high and every assistant record in its Claude Code transcript carries "effort":"high".

The child thread's selection is { "instanceId": "claudeAgent", "model": "claude-opus-5-5" } with no options: the adapter writes only the model it learned (child thread creation in ClaudeAdapterV2, and ProviderEventIngestor.syncSubagentThreadModel drops the parent's options on a model change). formatModelSelectionEffort then resolves the label the way the composer's picker does: stored choice, else descriptor current value, else catalog default. Opus 5.5's catalog default is medium, so the bar says Medium. Mobile shares the helper.

Expected: the bar names the effort only when it is known, and shows nothing otherwise, as its effortLabel prop already allows.

Change

formatModelSelectionEffort (packages/client-runtime) returns a label only when the thread's selection states the effort option, or the provider reported one for the same model and instance. A catalog default or current value is no longer taken as the subagent's effort. The check uses a small shared helper, isProviderOptionValueStated, next to the existing report-matching rule in packages/shared/src/model.ts, so both use the same model/instance match.

Unchanged: the composer's effort picker (it resolves defaults through getProviderOptionCurrentValue directly) and the OpenCode variant "Unknown" placeholder from #14978, which carries no value and still shows.

Not in this PR: learning the real effort. A subagent on the parent's model still inherits the parent's full selection, so its bar can still show the session's effort. Reporting the effort the SDK provides (hooks in ClaudeAdapterV2, effort on OrchestrationV2Subagent) is a separate change proposed on #15214.

Scope and approval

Triaged bug: #15214 (bug, via-triage). The triage comment names this surface: "When the model differs, the child selection is only { instanceId, model }, and the bar shows the catalog default rather than the transcript value", and the intended behavior: "show the effort the subagent actually ran at and nothing until it's known". This PR is the "nothing until known" half for the subagent bar. It adds no data and changes no defaults.

Verification

Focused tests (68 pass; 4 new cases: stated effort, reported effort, no stated or reported effort, report for another model):

vp test run packages/client-runtime/src/state/threadExecution.test.ts packages/shared/src/model.test.ts
vp lint <changed files>; vp fmt --check <changed files>
vp run --filter @t3tools/shared typecheck; --filter @t3tools/client-runtime; --filter @t3tools/web; --filter @t3tools/mobile

Live reproduction on the web dev client (macOS, Claude Code 2.1.289, Agent SDK 0.3.276, isolated --home-dir): a Claude Sonnet 5.5 thread at High called Agent(subagent_type: "prober", model: "opus"); prober is defined with effort: high and its only task was echo CLAUDE_EFFORT=$CLAUDE_EFFORT, which printed CLAUDE_EFFORT=high. The projected child thread's selection was {instanceId: "claudeAgent", model: "claude-opus-5-5"} with no options.

Before (main): the bar says Medium while the subagent printed high	After: no effort is claimed

Same thread, same data; only the client changed between the two captures.

Not checked: the mobile client was not run. It calls the same helper from ThreadDetailScreen and already renders nothing for a null label.

Made by Claude Fable 5.1 in Claude Code.

🤖 Generated with Claude Code

Fixes #15896

[macroscopeapp]

Approvability

Verdict: Approved at d133f9d

Macroscope's review found this PR approvable — This is a small, well-scoped bug fix that stops the subagent status bar from displaying catalog-guessed effort values while preserving explicitly selected or provider-reported values. The affected web and mobile display paths are covered by focused tests, with no schema, infrastructure, security, or default-setting changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Important

Review skipped

We couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting @coderabbitai full review.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: bf687706-1d66-421f-9205-601fbb892fa2

📥 Commits

Reviewing files that changed from the base of the PR and between 4ee6bfd and 77d0e99.

📒 Files selected for processing (4)

• packages/client-runtime/src/state/threadExecution.test.ts
• packages/client-runtime/src/state/threadExecution.ts
• packages/shared/src/model.test.ts
• packages/shared/src/model.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

📝 Walkthrough

The change adds a helper that detects explicitly selected or matching provider-reported model options. Thread effort formatting now omits catalog-inferred effort when no value was stated. Tests cover reported values, stored-value precedence, and missing or mismatched reports.

Changes: Model Effort Reporting

Layer / File(s)	Summary
Detect stated model options packages/shared/src/model.ts, packages/shared/src/model.test.ts	The new isProviderOptionValueStated helper recognizes options stored on a selection or reported for the matching model and provider instance. Tests cover stated, inferred, mismatched, and absent values.
Format thread effort from stated values packages/client-runtime/src/state/threadExecution.ts, packages/client-runtime/src/state/threadExecution.test.ts	Thread effort formatting skips catalog-current values when neither selection states the option. Tests cover provider-reported effort, stored-value precedence, and missing or mismatched reports.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to 77d0e

The subagent status bar will stop showing a guessed effort level when the effort is not actually known. No merge-blocking risk was identified.

### Architecture Summary

Architecture risk: 🟡 Medium · up to 77d0e

The change affects 2 systems.

Changed systems: packages/shared, packages/client-runtime

Architecture concerns
No architecture-level concerns identified.

Review details

Systems and components

• observed — packages/shared (library) was modified; 2 changed files map to changed impact.
• observed — packages/client-runtime (library) was modified; 2 changed files map to changed impact.

Before / after behavior

• observed — Modified behavior in packages/client-runtime/src/state/threadExecution.test.ts: Added tests that a reported effort is displayed when no stored effort overrides it, and that a stored effort takes precedence over the report.
• observed — Modified behavior in packages/client-runtime/src/state/threadExecution.test.ts: Replaced expectations that missing stored effort uses the catalog default or current value with null; added a check that a reported effort for a different model also yields null.
• observed — Modified behavior in packages/client-runtime/src/state/threadExecution.ts: The model helper import adds getProviderOptionCurrentValue and isProviderOptionValueStated for distinguishing stated effort from resolved defaults.
• observed — Modified behavior in packages/client-runtime/src/state/threadExecution.ts: The documentation changes from describing a thread’s effective effort—including stored choice, descriptor current value, or model default—to describing provider-native subagent effort based only on stated or provider-reported values; missing effort is unknown.

Reliability and maintainability

• inferred — Risk-relevant change factors for packages/shared: blast_radius_1; direct_dependents_1

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 4 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: the subagent status bar no longer guesses an effort value.
Description check	✅ Passed	The description covers the problem, change, scope and approval, and verification. It also states what was not checked and includes before-and-after screenshots for the UI change.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Dismissing prior approval to re-evaluate 77d0e99

Dismissing prior approval to re-evaluate d133f9d