Statusline: no per-command model/effort visibility, and rate-limit/context data goes stale during long agent turns

Summary

Two related gaps in the statusline (statusLine / subagentStatusLine) that make it hard to trust the bar as a live indicator during agentic work:

1. No visibility into model/effort actually used by a running command or subagent

The main statusLine JSON reflects the top-level console session (model.id/model.display_name, effort.level), not what a slash command or subagent is actually running with. Commands and subagents can temporarily override model/effort (e.g. subagent frontmatter model:, or a command invoking /effort mid-flow), but that override is invisible in the bar.

subagentStatusLine gets closer — its tasks[] array includes model per task — but:

• there is no effort field per task
• there is no field linking a task back to the slash command/skill name that triggered it (only name/type/description, which reflect whatever the agent itself reports, not the originating command)

Ask: expose effort per subagent task, and/or a command/source field identifying which slash command or skill invocation spawned the task.

2. Context window / 5h / 7d usage caps don't refresh during a long agent turn

The statusline appears to be event-driven (new JSON pushed at specific points, not continuously polled). During a single long-running agent turn (many chained tool calls, e.g. an autonomous loop), there's no refresh event mid-turn — the bar keeps showing the last known snapshot until the turn ends.

Concrete repro: during a long session, the 5h rate-limit window was actually exhausted mid-turn, but the statusline continued showing ~80% usage for the entire remainder of that turn, only updating (to reflect the real, already-exhausted state) once the turn completed.

This makes the rate-limit/context-window indicators unreliable exactly when they matter most — during long unattended agent runs, where a user has no other way to notice they're about to hit (or already hit) a cap.

Ask: either poll/refresh usage and context-window data at some interval during long turns, or clearly mark the displayed values as stale/last-known when a turn is in progress.

Context

Both points came up while discussing how to monitor multi-command/multi-agent workflows where different commands intentionally use different models/effort levels, and where long autonomous runs need trustworthy live feedback on remaining quota.