cc-context-monitor over-cap caps are stale — false alarms fleet-wide. THRESH_OPUS=160k/HAIKU=100k/SONNET=135k are ~80% of the OLD ~200k-class windows. Fleet now runs claude-opus-4-7[1m] = 1M-token window; a 268k session is 27% full, not over cap. Transcript model string lacks the [1m] marker so monitor can't auto-detect window size. Fix: bin-whey-cc updates THRESH_* in cc-context-monitor.sh to real values per Elazar's decision (true-window fraction vs. relabelled cost-budget). All of 2026-05-21's over-cap wind-downs were triggered by this false cap.

Sub-tickets

Questions

Activity

• system created · 2026-05-21
  wi cli
• system blocked · 2026-05-21
  awaiting Elazar cap-number decision
• bin-whey-cc assigned · 2026-05-21
  assigned to bin-whey-cc
• system commented · 2026-05-21
  Refined (nw-venus-cc framing): two-part fix. (1) RELABEL — unconditional, can ship now without Elazar: 'over-cap ALERT'->'over context-budget', 'cap'/'per-model cap'->'budget', DM 'context cap'->'context budget (cost control)'. The 100/135/160k are soft cost-control thresholds, NOT model context caps; current wording falsely implies context-window overflow. (2) RENUMBER — needs Elazar: keep 100/135/160k as the deliberate spend budget, or raise toward real windows (haiku 200k, opus/sonnet 1M). bin-whey-cc may start (1) now and parametrize so (2) is a one-line change.
• system commented · 2026-05-21
  Part 1 (relabel) done: cc-context-monitor.sh v2.8 - over-cap->over-budget, cap->budget, DM cost-control framing, comments. THRESH_* already named config vars so part 2 (renumber) is a 3-number one-liner. Pushed sh.git 307d60c. Part 2 still blocked on Elazar: keep 100/135/160k as cost budget vs raise to real-window fractions.
• wi-cli-whey assigned · 2w ago
  monitor-context-cc / ops
• wi-cli-whey assigned · 2w ago
  Reassigned bin-whey-cc -> monitor-context-cc per Elazar ruling 2026-08-01: monitor-context-cc handles all context/compact-monitor work and is SSOT for it. Status/content to be corrected per its confirmation.