feat(cli): degrade status-line ctx segment to ?/window when usage is unavailable (#3371)

[me2seeks]

Summary

The TUI status-line ctx segment (#1067) only rendered when both the model context window and a token_usage contextRemaining were present. On connections whose provider does not report per-step input tokens (e.g. opencode-go), the status line shows no context indicator at all — the user cannot distinguish "provider doesn't report usage" from "not measured yet" from "window unknown".

In renderMakaPiStatusLine (packages/cli/src/pi-transcript.ts), the ctx segment is lifted out of the if (usage) block:

• window known + contextRemaining available → unchanged: ctx 20k/500k 4% with the existing 80%/95% color thresholds
• window known + no usage yet → new: dim ctx ?/500k fallback, following pi-mono's footer design (?/200k when context usage is unknown)
• window unknown → unchanged: no segment

The follow-up from the issue — verifying whether the opencode-go relay reports per-step input tokens — is not in scope here.

Fixes #3371

Verification

• pi-transcript.test.js 59/59 (new unit test covering all four combinations: no usage / usage without contextRemaining / unknown window stays hidden / measured rendering unchanged)
• pi-tui-runner.test.js 119/119 (including the existing ctx 20k/500k 4% integration assertion)
• biome format clean; full dependency chain + cli build (typecheck) pass

AI use

• Generative tooling made a substantive contribution
• No generative tool made a substantive contribution

Tool(s) and scope: Maka (AI coding agent) authored the design, implementation, and tests; the diff was human-reviewed before push. Generated-by: Maka trailer is present on the commit and retained on this branch.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Thanks — this is a small change that gets a distinction right, and the distinction is the part worth naming: the status line now separates "the window is unknown" from "the window is known but nothing has been measured yet." Those are different states and they were collapsing into the same blank.

Reviewed at exact head 2a7230c0249c2e555bbb793f37cc58bcbd3314d4 against base a2f4e6f808c8647c62194aa41bb683f6829b08f1 (real merge-base 57e08d83497d1d7ace7d6eff88e4e5267a0345b5). No findings — no P0, P1, P2 or P3. No checks have run on this head, so this stays a COMMENT; it is not an approval.

On whether ? degrades or hides. This was the question we most wanted to answer against you, because a placeholder is exactly how a real regression gets papered over. It does not hide anything here: the runtime clears contextRemaining when the latest step carries no input tokens, so ? cannot be a stale measurement wearing a fresh label. The condition is also correctly asymmetric — window && remaining renders the measured value, window alone renders ?/window, and an unknown window still renders nothing at all, because ?/unknown would be noise rather than information. cost and cache stay behind if (usage), so nothing else moved.

On whether the problem is real. It is, and on the ordinary path rather than a failure path: a session before its first step has no usage by construction, and a provider that does not report per-step input tokens has none persistently. That is a normal state being rendered as if the window were unknown.

On scope. The residual ambiguity — "not measured yet" versus "this provider never reports" — is not resolvable from the data available at this layer, and your description defers it explicitly rather than papering over it. We think that is the right call and the right way to say it.

Verification, stated plainly. Two of us reviewed this independently without visibility into each other's conclusion, and a third checked the factual claims underneath both. The targeted suite (pi-transcript) was run against a merge of this head with current main — the CI-equivalent tree rather than the bare branch — and passed 60/60, including the four-way matrix your tests add (no usage, usage without contextRemaining, unknown window, and the measured case unchanged at 20k/500k 4%). We separately confirmed those four cases exist in the test source rather than taking the run at its word.

The one thing missing is not yours to fix from the code side: this head has zero check runs — not green, not red, never executed. Everything above is our verification, not the project's. A push to trigger CI would put that right.

---

This review was AI-assisted. Findings were verified against the exact head listed above; any mistakes are ours to correct — please push back where we got it wrong.

[Astro-Han]

Following up now that CI has run on this head — test is green.

Still at 2a7230c0249c2e555bbb793f37cc58bcbd3314d4, unchanged since my earlier review, so that conclusion still stands: no findings.

The distinction this makes — "window unknown" versus "window known, nothing measured yet" — is the part worth keeping. And ? doesn't hide a stale reading, because the runtime clears contextRemaining when the latest step carries no input tokens.

Approving.

---

This review was AI-assisted. Findings were verified against the exact head listed above; any mistakes are mine to correct — please push back where I got it wrong.