Skip to content
PifeatureCLI & tooling7 files · +477 −159

Make Pi Session HUD context colours configurable and warn sooner for 1M-token models

Session from pi-session-hud-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk

1h 11msession
4interventions
GOAL

Adjust the pi-session-hud Pi extension so the context usage bar warns at roughly the same absolute token level for large-context (1M) models as it does for GPT-5.5, then iteratively refine which parts of the display (bar, token count, percentage) carry the warning colour, and finally make the thresholds configurable via provider/model overrides.

  1. Prompt · +0
    The context bar's warning colour is too lenient on 1M-context models; make it change sooner, roughly matching GPT-5.5's threshold.
  2. Agent did · +0m
    Investigated the extension's context-bar rendering logic, added a GPT-5.5-sized reference window (272k) so colour scaling on 1M-token models warns earlier while the displayed % and tokens stay accurate to the real window, validated with compile checks, colour assertions, and a visual screenshot check, then left changes uncommitted.
  3. Intervention · +14m
    Reported the fix 'doesn't seem to work'; agent discovered pi was loading the published npm 0.1.7 package, not the local working copy, so the fix was never live.
    Why: The fix looked right in testing but I was still seeing the old behaviour, so I flagged it wasn't actually working.
  4. Agent did · +16m
    Committed and pushed the fix, switched the installed package source from npm to the git repo so the working copy would actually load, and extended the same warning-colour scale to the token-count text.
  5. Intervention · +25m
    Asked that the '/272k' or '/1.0M' denominator stay grey instead of also taking the warning colour, only the numerator should change.
    Why: Colouring the whole fraction was noisy; only the used-token count needed to stand out.
  6. Intervention · +28m
    Asked for the percentage text to be muted grey too, leaving only the token numerator coloured.
    Why: Once the token count carried the warning colour, the percentage repeating it felt redundant.
  7. Prompt · +31m
    Make the colour band thresholds configurable/overridable by provider or model, supporting both absolute token and percentage-based bands.
  8. Fail · +39m
    The pr-reviewer subagent (running gpt-5.5 at xhigh thinking) timed out twice, at 120s and then 300s, before returning any findings.
  9. Agent did · +39m
    Implemented a JSON config surface (global/project file + env override) with default/provider/model precedence and absolute vs percent colour modes, opened PR #4 in an isolated worktree, ran a non-gating reviewer plus an async pr-reviewer that eventually returned clean, merged the PR, and updated the installed git package. Later bumped to 0.1.8 but npm publish failed with EOTP.
  10. Intervention · +1h 7m
    Frustrated that npm publish kept demanding OTP regen; had the agent persist an npm token into ~/.npmrc, then generate and swap in a token with 2FA-bypass enabled so publish would work.
    Why: This kept happening every session and I was tired of regenerating tokens just to let the agent publish.
  11. Outcome · +1h 11m
    @tmustier/pi-session-hud published to npm as 0.1.8 (latest), with git tag v0.1.8 and commit d0b6fac pushed; PR #4 merged; npm auth token with 2FA-bypass persisted in ~/.npmrc for future publishes.
VERDICT

Next time I'd specify upfront exactly which display elements (bar, token count, percentage, denominator) should and shouldn't carry the warning colour, since I ended up correcting that piecemeal over four separate prompts. The intervention that mattered most was catching that the fix wasn't loading at all because pi was pointed at the stale npm package instead of my working copy — without that the whole 'doesn't work' loop would have repeated. Persisting a 2FA-bypass npm token finally fixed the recurring publish friction that had nothing to do with the code itself.

I tried this · 0

Discussion · 0

How Builds work