fix(tui_gateway): don't show cumulative session total as context_used (#50421)

[kshitijk4poor]

Summary

The TUI/dashboard status bar no longer shows impossible context-usage readings like 4m/1m (100% red) when the real context is well within the window.

tui_gateway/server.py::_get_usage() computed context_used = last_prompt_tokens or usage["total"] — falling back to cumulative lifetime session_total_tokens whenever last_prompt_tokens was falsy. In a long session (this report: 348 tool-turns → ~4M cumulative tokens) the bar rendered 4m/1m pegged at 100% red even though each API call only sent ~189k/1M. context_used is a current-window signal; cumulative lifetime usage is not interchangeable with it.

Changes

• tui_gateway/server.py: drop the or usage["total"] cumulative fallback — populate context_used/context_percent only from a real current-occupancy value; emit no gauge when it's unknown (prefer absent over wrong). Clamp the -1 post-compression sentinel to 0.
• Whole-bug-class sweep — the same -1 sentinel (parked by conversation_compression.py after every compression) leaked into other status readers, producing a raw -1 or a negative usage_percent on the transitional turn. Clamped at every sibling site:
  • agent/context_engine.py::get_status() — the ABC default every external context engine inherits (highest blast radius)
  • gateway/slash_commands.py /usage context line
  • cli.py session-usage printout
• tests/: salvaged tests (no cumulative substitution; real occupancy reported) + regression tests for the -1 sentinel in both _get_usage and the ABC get_status.

Root cause

context_used = getattr(comp, "last_prompt_tokens", 0) or usage["total"] or 0 where usage["total"] is cumulative session_total_tokens. When last_prompt_tokens is falsy (0, or the -1 sentinel), the or chain substitutes lifetime totals as the live context fill. The built-in compressor reports a real last_prompt_tokens once a turn runs, so steady-state is unaffected — the bad value surfaces on transitional/edge turns and for external context engines that don't track per-window occupancy (context.engine: lcm).

The -1 sentinel is truthy, so last_prompt_tokens or 0 does NOT neutralize it — the fix clamps <0 → 0 at every status reader, mirroring the CLI status-bar path (cli.py::_get_status_bar_snapshot, which already clamped). Only tui_gateway/server.py had the cumulative-total fallback; the sibling sites had the softer negative-percent variant of the same sentinel class.

Validation

last_prompt_tokens	Before	After
falsy (0) + 4M cumulative	4m/1m @ 100% (red)	no gauge (unknown)
real 189k / 1M	correct	189k/1M = 18%
-1 post-compression sentinel	-1 / negative % leaked	no gauge / clamped to 0

• 328 tests pass across tests/test_tui_gateway_server.py + tests/agent/test_context_engine.py (1 pre-existing unrelated browser-test failure on origin/main deselected). ruff clean.
• E2E-verified with real imports against the reporter's exact scenario (glm-5.2, 1M window, ~4M cumulative).
• All consumers of the now-optional context_used/context_percent/context_max keys verified missing-key-safe across Python, Ink TUI (ui-tui/), and Electron desktop (apps/desktop/).

Salvaged from #50518 by @r266-tech (cherry-picked to preserve authorship), with follow-up commits fixing the -1 sentinel edge case and widening the fix to sibling status paths. Duplicate of the same core line fixed independently in #55940 (@HenkDz) — both credited on close.

Closes #50421

[alt-glitch]

This was generated by AI during triage.

Fix PR for #50421 — related. Overlapping/competing open cluster removing the same or usage['total'] cumulative fallback in tui_gateway/server.py::_get_usage() but for different triggers: #50518 (external context engine / lcm), #55940 (model-switch update_model reset), #55640 (also bounds session recall). Same code site — a reviewer should reconcile these into one fix rather than merge in parallel.