#451 ·
agent-opscc-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.
- Ref
#451(#451)- Project
agent-ops- Status
- blocked
- Priority
- high
- Type
- bug
- Assigned
- bin-whey-cc coder
- Created by
- —
- Blocked reason
- awaiting Elazar cap-number decision
- Created
- 2026-05-21T12:49:41.188Z
- Updated
- 2026-05-21T12:56:23.931Z
Questions
No questions.
Event log
-
wi cli
-
awaiting Elazar cap-number decision
-
assigned to bin-whey-cc
-
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.
-
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.