Debug 0.0% context footer on error termination in pi CLI
Session from pi-mono-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
Investigate why the context percentage in the footer shows 0.0% after a session terminates on error, using session and debug logs to trace the cause.
- +0Prompt · +0On error terminated, the context % footer displays 0.0%. Why? See attached session log.
- +0mAgent did · +0mRead footer.ts and session log; found footer ignores assistant messages with stopReason==='error' and falls back to state.model?.contextWindow||0, causing 0.0%
- +1mPrompt · +1mAlso added a debug log here /pi-debug.log
- +1mAgent did · +1mParsed debug log confirming '0.0%/272k' output; traced it to the estimation path using state.messages which is empty after termination, so contextTokens computes to 0
- +3mPrompt · +3mBut the context was not 0% right before the error happened...
- +4mAgent did · +4mExplained the discrepancy: footer's totals come from sessionManager.getEntries() while the percentage estimate comes from state.messages, which is cleared on error, causing non-zero totals alongside a 0.0% percentage
- +4mPrompt · +4mWould our fixes in this branch resolve this?
- +4mAgent did · +4mChecked branch fixes; confirmed they address compaction/new-session estimation but not the error-termination case, since the code still skips stopReason==='error' and still estimates from state.messages
- +5mPrompt · +5mWhat tweaks would be needed to do this? Don't write any code, but show me a diff
- +5mOutcome · +5mProduced a proposed (unapplied) diff for footer.ts to use sessionManager entries when state.messages is empty and to keep last known usage on error, without making any code changes
I'd start by asking it to trace the footer percentage calculation against the debug log directly instead of reading the code first — that got to the root cause faster. Comparing the session log's non-zero totals against the 0.0% render was the key step that exposed the real bug: the estimate path uses in-memory state.messages, which is empty after an error, unlike the totals path which reads from sessionManager entries. I stopped short of applying any code and just wanted a diff to review before deciding on the fix.