Show model & reasoning effort on Codex sub-agent tabs (parity with Claude sub-agent tabs)

[dpfwpfahs1-coder]

Summary

Codex sub-agent tabs don't show which model and reasoning effort the sub-agent runs with. Claude sub-agent tabs already show this in the header.

Current behavior

• Claude sub-agent tab: the header shows e.g. opus-worker · Opus 5.5 · Max · 526.1k tokens.
• Codex sub-agent tab: opening a tab for a child thread created with spawn_agent (e.g. build_reader) shows the conversation only. There's no role, model or reasoning effort.

Why this matters

Codex roles and spawn_agent can set model / reasoning_effort per child. When the parent (orchestrator) picks different models and efforts per task, the user has no way to see in Paseo which model and effort a given child is actually using.

The data already exists on the Codex side

Each child rollout file records it:

• session_meta.payload.source.subagent.thread_spawn → agent_role, agent_nickname, agent_path, parent_thread_id
• turn_context.payload → model, effort

Example: agent_role=sub-readonly, model=gpt-6.1-sol, effort=low

Request

Show role · model · reasoning effort (and token usage if available) in the Codex sub-agent tab header, the same way Claude sub-agent tabs show it.

Environment

• Windows 11
• Paseo Desktop 0.11.1 (desktop-managed daemon)
• Codex CLI multi-agent (spawn_agent with agent_type, fork_turns)

---

Moved from #6356 (closed because issues are for bugs; ideas belong in Discussions). Another user also asked for this there.

[Phototonic]

We have a related need with plugin-provided OmO Native workers on Paseo Desktop 0.12.0 (Pop!_OS 24.04), using pase-omo. Adding it here rather than opening a duplicate request.

Workflow

An orchestrator delegates to workers with different model routes. Opening a worker shows its transcript and the running indicator, but no persistent model/reasoning readout near that indicator. Our plugin currently puts a summary such as this at the start of the transcript:

Example worker task (unspecified-low · zai/glm-5.3)

This is synthetic task text. unspecified-low is a routing category, not a reasoning-effort setting. Scrolling back to the initial message is cumbersome, and a launch-time summary cannot establish which model is currently active after a fallback or model change.

Plugin extension limits found in source

AI-assisted source inspection, checked against v0.12.0 and current main 0d61cca50c10c2943f94247c518ab77f4d6a05b2:

• The read-only provider-subagent panel renders the stream and child track, without a model/effort footer or a plugin contribution slot there.
• Plugin session.opened accepts title/description, but no provider-owned subtitle or model/effort metadata on that event.
• The plugin bridge's acceptChildEvent projects timeline/lifecycle events, but does not propagate child session.config model/thinking updates into the provider-subagent descriptor.
• The client descriptor already supports an optional provider-owned subtitle, and the panel can render it at the top. The current plugin child-event path does not populate that field.

Desired behavior

A compact, persistent readout for the selected worker, e.g. GLM-5.3 · reasoning: high, in the header or beside the bottom running indicator. For plugin workers, a supported way to publish and update this context would let the plugin supply native information without modifying the desktop package.

Please distinguish the actual/effective model and reasoning setting from the requested routing category. Unknown effort should stay unknown; model/fallback changes should update the readout, and the last-known metadata should survive reconnects for completed workers. It should not infer the worker model from the parent session.

No screenshot is attached because the original contains private project content. No desktop/daemon package modifications, live session reloads, or new model generations were performed for this investigation. The source inspection establishes the current extension limitation, not an implemented or tested UI fix.

[kushaldotdev]

+1, Need the same models name and thinking for the Pi as well as opencode on subagents.