cc-context-monitor THRESH_*/ROLE_CAP: keep as a per-model COST budget, do not raise toward window fractions (closed, no code change)

Sub-tickets

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 · 2026-08-01
  monitor-context-cc / ops
• wi-cli-whey assigned · 2026-08-01
  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.
• wi-cli-venus unblocked · 5w ago
  DECISION (pmmaster-evolutiva-cc, exercising Elazar's standing GO grant of 2026-09-11: 'exercise GO from pmmaster-evolutiva-cc without waiting for me'). KEEP THE NUMBERS AS A COST BUDGET. Do not raise THRESH_*/ROLE_CAP toward window fractions. Three grounds, all verifiable in the current file. (1) The item names the wrong constant. THRESH[haiku|sonnet|opus] is reached ONLY as a fallback inside cap_for() at context-monitor.sh:1545-1553, after the agent's role prefix misses ROLE_CAP. Every named fleet agent (pm/coder/db/audit/bin/nw/hub/support/maintainer/researcher) HITS ROLE_CAP at :1506-1536, so THRESH_OPUS=160k governs almost nothing - it is the unknown-role path. Renumbering the three THRESH_* values would not have changed the alerts the item was filed about. (2) The semantics are already settled IN THE SOURCE, not pending: the comment at :2375 reads 'ROLE_CAP remains a per-model COST budget, explicitly NOT a context-window limit - that part was always right and is not what changed.' A cost budget does not get raised because the window grew; that is the whole point of it being a budget. (3) The item's technical premise is dead as of v4.78 and the file is now v4.108, thirty versions past the last update here. The title says 'Transcript model string lacks the [1m] marker so monitor can't auto-detect window size'. True, and no longer load-bearing: resolve_window() at :2036 obtains the window from session_meta's cwd through the settings chain instead of from the model string, and :2374 records that the old 'these tiers CANNOT be scaled' paragraph was deleted rather than annotated because a retired justification left in place reads as a live one. MSG-207 is closed by the same version. REMAINING WORK, which is why this is todo and not done: monitor-context-cc verifies resolve_window() against four panes measured tonight on venus, because the MODEL LABEL is unreliable in BOTH directions and anyone reintroducing label-based detection must be refuted by data rather than argument - coder-enamel-cc prints model='Opus 5 (1M context)' at a 250k denominator; db-mars-cc prints the same 'Opus 5 (1M context)' at 400k; coder-mars-cc prints plain 'Opus 5' at 400k; bin-venus-cc prints plain 'Opus 5' at 250k. Label and denominator disagree in both directions. If resolve_window() returns the pane's own denominator for all four, close this item. If it does not, the defect is in the settings-chain walk and that is the real OPS-53.
• wi-cli-venus completed · 5w ago
  RESOLVED, NO CODE DEFECT. Verified by measurement, not argument: monitor-context-cc ran resolve_window() live against the four venus pids named in the unblock event and it returned each pane's own denominator in all four cases, with no floor-fallback anywhere - coder-enamel-cc 250000 (resolved via ~/.claude/settings.json), bin-venus-cc 250000 (same path), db-mars-cc 400000 and coder-mars-cc 400000 (both via their own cwd/.claude/settings.json). The label/denominator disagreement that motivated this item is confined to the MODEL-STRING DISPLAY and never reached the resolver: coder-enamel-cc prints 'Opus 5 (1M context)' on a 250k window and coder-mars-cc prints plain 'Opus 5' on a 400k one, so the model string is unreliable in BOTH directions, which is exactly why the settings-chain walk introduced at v4.78 was the right replacement for it. Anyone tempted to reintroduce label-based window detection should be shown those four rows. The decision recorded in the preceding unblock event stands unchanged and is the durable half of this item: THRESH_*/ROLE_CAP stay a per-model COST budget and are not raised toward window fractions - a cost budget does not grow because the window grew, and in any case THRESH_* is only the unknown-role fallback inside cap_for(), so renumbering it would not have changed the alerts this item was filed about. Elapsed: filed 2026-05-21, blocked 113 days on 'awaiting Elazar cap-number decision', closed 2026-09-12 by pmmaster-evolutiva-cc under Elazar's standing GO grant plus one live measurement that took minutes. The lesson worth carrying out of this item is not about caps: a question parked for a human decision was answerable from the code the whole time, and the code had already outgrown the premise thirty versions earlier (v4.78 vs the file's current v4.108).
• wi-cli-venus titleChanged · 5w ago
  RESOLVED NO-OP - do NOT raise THRESH_*: the 100k/135k/160k tiers are a per-model COST budget, not a window fraction, and resolve_window() (v4.78+) already reads the real window from the settings chain. Original title described the opposite fix on a premise dead since 2026-05-21.
• wi-cli-venus titleChanged · 5w ago
  cc-context-monitor THRESH_*/ROLE_CAP: keep as a per-model COST budget, do not raise toward window fractions (closed, no code change)
• wi-cli-venus note · 5w ago
  Title rewritten. The old title was the 2026-05-21 filing text and still carried the pre-v4.78 premise plus the instruction 'Fix: bin-whey-cc updates THRESH_* in cc-context-monitor.sh to real values' - the opposite of the resolution recorded in the unblock and completed events. It has already misfired once: the wi-cli close announcement surfaced that title, monitor-context-cc read it as a conflicting resolution landing two minutes after pmmaster's ruling, and raised it as a live risk of reintroducing the defect just closed. Nothing was applied - context-monitor.sh is v4.108 with THRESH_HAIKU/SONNET/OPUS unchanged at 100000/135000/160000 (:953-955) - and this lane is not editing them. Old title preserved in the titleChanged event. A closed item's title is what the tooling quotes; leaving a stale instruction in it is a live hazard, not a historical record.
• wi-cli-venus note · 5w ago
  CORRECTION to my previous note, and a rename collision. Two things I got wrong or that changed underneath it. (1) THE ORIGINAL TITLE IS NOT PRESERVED BY THE titleChanged EVENT. I wrote that it was. wi rename logs the NEW title as the event body, not the old one - unlike wi describe, which logs the old text. So the 2026-05-21 filing text existed nowhere in this item after the first rename. Recording it verbatim here, from a wi show taken before either rename: '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 cannot auto-detect window size. Fix: bin-whey-cc updates THRESH_* in cc-context-monitor.sh to real values per Elazar decision (true-window fraction vs. relabelled cost-budget). All of 2026-05-21 over-cap wind-downs were triggered by this false cap.' (One substitution: the original used an apostrophe in can't, removed so this body survives the shell.) (2) RENAME COLLISION - my rename overwrote pmmaster-evolutiva-cc's, 8 seconds apart, 00:14:36.732 theirs then 00:14:44.990 mine. We were fixing the same stale title independently, having each been alerted by monitor-context-cc. No divergence in substance - both titles say keep the cost budget, do not raise toward window fractions - so nothing was lost but their wording. Theirs is in its own titleChanged event and is the one to restore if anyone prefers it. Worth noting as a pattern rather than an incident: a broadcast alarm about a stale artifact draws two lanes onto the same one-line fix, and rename is last-writer-wins with no conflict signal.