Require a current burn before claiming burning fast - #26
Merged
Merged
Conversation
A quota window's shape (usedPercent ahead of the elapsed fraction) can outlive the burst that caused it — one early weekly burst held the pace deficit for days, so the popover nudged "Codex burning fast. Switch to Grok, OpenCode Go for headroom." while the same card read "no sessions today". "burning fast" is a present-tense claim, so every deficit surface now consumes QuotaPace.effective(lastBurn:now:), which demotes a burn-quiet deficit to on-pace (BurnRecency, 30-minute quiet period). The popover nudge splits into two honest claims: actively burning keeps the old wording, a headline window at 80%+ without a current burn reads "near its limit", and a stale deficit below that no longer nags at all. Pace notifications and the machine report (meterusage json, which now also scans local activity for burn evidence) gate the same way; the 80%/95% threshold alerts stay state-based. Verification: swift build clean and swift test 316/316 (incl. the new BurnRecencyTests regression suite) on macOS arm64, Swift 6.4.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
The popover kept nudging "Codex burning fast. Switch to Grok, OpenCode Go for headroom." while the same card read 0 / no sessions today. The claim is a window-shape artifact:
deficit = usedPercent − elapsedPercentassumes usage spreads evenly across the window, so one burst early in a long window (e.g. Codex's weekly) holds the deficit until reset — days after the burn stopped. The nudge is level-triggered, so it reappeared on every popover open. The same stale-deficit flaw fed pace notifications, the menu-bar ETA chip, the notch banner and pills, and themeterusage jsonreport.The fix
"burning fast" is present tense, so it now requires burn evidence. A
BurnRecencyhelper derives each provider's last observable burn from local sessions (30-minute quiet period), andQuotaPace.effective(lastBurn:now:)demotes a burn-quiet deficit to on-pace. Every deficit surface consumes the effective pace:paceSoftWarning/paceCliff) fire only on a current burn; 80%/95% threshold alerts stay state-based.meterusage jsongates pacing the same way and now scans local activity sources for burn evidence.Providers without a local session store have no burn evidence: they lose pace alerts but keep threshold alerts (documented in
docs/KB.md).Verification
swift buildclean andswift test316/316 passed (0 failures) on macOS arm64, Swift 6.4 — including the newBurnRecencyTestsregression suite (the exact reported case: weekly window 85% used, one-day-old burn → on-pace everywhere and a silent nudge).Model(s): GLM (glm-5.3-flash)
Harness: opencode