[Bug]: Pi subagent rows omit the reasoning level, so delegated effort cannot be verified#30442

opened7d agobyPProphetOfDoom-PoD

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to investigate the problem.

Area

apps/web — the subagent row label (with packages/client-runtime involved). Observed on desktop.

Steps to reproduce

  1. Use the Pi provider with a model that advertises thinking levels (I used opencode-go/deepseek-v4.1-flash).
  2. Set the composer to Thinking = Max, then tell the agent it may vary the reasoning level per task. My instruction was: "You may only change the reasoning level of the model. Use a lower reasoning for simpler quicker tasks. You can use … (Max), … (High) & … (Low)."
  3. Let the agent delegate work with delegate_task and explicit target.options, e.g. "options": [{ "id": "thinking", "value": "high" }].
  4. Inspect the subagent row in the thread timeline, and the Agents panel.

Expected behavior

Each subagent row shows the reasoning level it runs at next to its model, the way Claude (effort), Codex (reasoningEffort), Cursor (reasoning) and OpenCode (variant) subagent rows already do. Show nothing when T3 cannot know it.

Actual behavior

The row shows only the model. The level is dropped even though T3 has it: the parent ran at Max while the delegated children ran at High and Low, and the UI renders them identically.

Why it matters

I asked the agent to spend less reasoning on small tasks. It did — 13 delegate_task calls in that session carried explicit options, 12 at thinking: high and 1 at thinking: low — and there is no way to confirm that from T3. Every delegation looks like it ran at the parent's level, which makes per-subagent effort impossible to audit or tune for cost.

Evidence

  • The effort suffix on a subagent row comes from one allowlist, REASONING_EFFORT_OPTION_IDS (packages/client-runtime/src/state/threadExecution.ts, lines 151-158):

    ts
    1["reasoningEffort", "effort", "reasoning", "variant", "reasoning_effort", "thinking_level"]

    and apps/web/src/components/chat/SubagentTooltipContent.tsx:75 maps only those ids over the child's saved selection.

  • The Pi provider's option id is thinking (packages/provider-pi/src/server/thinkingCapabilities.ts: id: "thinking", label: "Thinking", levels off…max). thinking appears only in REASONING_DESCRIPTOR_IDS (packages/client-runtime/src/modelTraits.ts, lines 14-17), which recognises the composer's reasoning control; it is deliberately kept out of the effort-label allowlist, so the subagent lookup returns nothing.

  • The client already receives the value for app-owned children: SubagentTooltipContent resolves childSelection = props.modelSelection ?? (props.origin === "app_owned" ? props.childThread?.modelSelection : undefined).

  • The server side has no effort for plain subagents either: projectedSubagentsToRuntime sets effort: null (packages/client-runtime/src/state/subagentRuntime.ts), so the Agents panel has nothing to show for these children.

Data from my install (v0.1.6, commit 2359643cffa6, Windows desktop)

From ~/.t3/userdata/statev2.sqlite (projection tables), same model on parent and child:

  • parent thread modelSelection.options = [{"id":"thinking","value":"max"}]
  • its delegated child thread modelSelection.options = [{"id":"thinking","value":"high"}]
  • of 423 projected subagents, json_extract(payload_json,'$.effort') is null for all 423

So the per-child level is recorded and differs from the parent's, and nothing renders it.

Suggested fix

Resolve the subagent label the way the composer already does — recognise a reasoning control whose id is thinking — or populate RuntimeSubagent.effort from childThread.modelSelection for app-owned children, keeping the composer's separate Thinking behaviour intact.

Prior art

  • #10185 — "[Bug]: Codex subagent rows omit model and reasoning-effort labels" (closed, fixed). Same class of bug for another provider.
  • #15214 — "[Bug]: Orchestrator V2 shows no reasoning effort for subagents" (closed, completed). Shipped effort labels for the providers in the allowlist.
  • Discussions #6938 ("Always show each subagent's model in the Agents panel", whose example row reads GPT-5.6 Luna -max) and #11778 ("The child's model, effort, and token count") ask for the same visibility.

No existing issue, PR or discussion covers Pi.

Workaround

Read the child's Pi session log, or query statev2.sqlite directly. Nothing in the app.

Note

🤖 GPT 6.1 Sol responding on behalf of StiensWout

The maintainer closed our independent #33346 as a duplicate and is retaining #30489 for Pi subagent thinking-level metadata. Our PR retains shared selection-precedence tests and wide/narrow client captures. Once a build containing the retained fix is available, could you verify delegated High/Low/Max labels on web and mobile, including app-owned children with their own saved selection, and close this issue if each child’s actual level is shown after the fix lands?