CONTEXT_LIMIT was hardcoded at 200_000 tokens. Users on Claude Opus 4.7
with the 1M context window (model: "opus[1m]") saw the dashboard report
80–90% usage when actual usage was 16–18%, producing constant false
alarms and making the meter unusable on long sessions.
Replace the constant with _detect_context_limit(cwd) which resolves the
limit in this order:
1. CONTEXT_TIMELINE_LIMIT env var (explicit override).
2. "[1m]" / "[1000k]" / "[200k]" suffix in the model field of
<cwd>/.claude/settings.json or ~/.claude/settings.json.
3. 200_000 fallback (current behaviour).
The limit is resolved once per _Builder instance, not per update tick,
so there is no per-event filesystem cost.
No new dependencies (still stdlib only). Default behaviour is unchanged
for users without [1m] in settings.
Verified live on a real Opus 1M session of ~178K tokens: meter went
from 89% (red, false alarm) to 17.9% (cyan, correct).
The `_encode_cwd` function only replaced `/` with `-`, which fails on
Windows where paths use `\` and include drive letters like `D:`.
Use regex to replace any non-alphanumeric character with `-`.
This handles all edge cases across platforms in a single expression.
Before: D:\Claude\mcx -> lookup failed
After: D:\Claude\mcx -> D--Claude-mcx (matches Claude Code encoding)
Persistent local HTTP daemon (port 7878, 1h watchdog) that reads Claude Code
JSONL transcripts and renders a git-graph timeline in the browser — one column
per agent (main + subagents), tool nodes color-coded by type, context-window
sidebar with cache/input/output breakdown. Pure stdlib Python, zero pip deps.
Mario Hernandez