Skip to content

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

Open

Description

@ProphetOfDoom-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):

    ["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 2359643, 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

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.

Activity

  1. StiensWout commented on Nov 9, 2026

    @StiensWout
    Contributor

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions