nightly-session-watch

Nightly Session Watch

One sweep over everything that happened in the last 24 hours, in priority order: what broke, what it cost, and what to do about it.

Everything runs through pi session-stats — the same Go code path the session-stats agent tool uses, so there is no second implementation to drift. No LLM call, no network, reads only ~/.pi-go/sessions/*/events.jsonl.

This is the umbrella check. It is deliberately shallow — it finds and ranks, it does not diagnose. Every finding names the skill that goes deeper:

Finding	Goes deeper with
agent loop aborted: ...	pi-loop-forensics
Tool call errors	pi-check-session-logs
Which tools dominate	tools-stats
Slow turns / throughput	token-perf

Do not re-implement those here. If the sweep surfaces three aborted runs, the answer is "run loop-forensics on these three", not a second loop analysis.

Run it

pi session-stats                 # last 24h
pi session-stats --hours 72      # wider window
pi session-stats --all           # include sessions with no anomalies
pi session-stats --json          # counters only, for a cron wrapper

Other flags: --high-tool-calls and --high-turns move the anomaly thresholds, --session-dir points at a different session root.

Steps

1. Run pi session-stats. Present its markdown as-is — it is already ordered by severity.

2. Read the numbers before interpreting them. Three traps:

   • Tool error rate matters more than error count. read failing 5 times in 253 calls is noise; a tool failing 8 of 8 is broken or misconfigured.
   • A heavy session is not automatically a bad session. High tool calls on a long task is work, not waste. Waste is the Token waste section.
   • Prompt tokens dwarf everything else. They are re-sent on every request, so the figure is dominated by the fixed block — system prompt plus tool declarations — not by the task. A large number there is not evidence of a bad night; a large number per session on short sessions is.