feat: pace-based utilization tracking in menu bar and popover#33
Open
rshivane wants to merge 3 commits into
Open
feat: pace-based utilization tracking in menu bar and popover#33rshivane wants to merge 3 commits into
rshivane wants to merge 3 commits into
Conversation
Usage percentage alone can't answer whether the current burn rate will
exhaust a quota window early or leave paid capacity unused - 20% of the
weekly quota used means opposite things on day 1 vs day 6.
Track a pace ratio (usage fraction / elapsed window fraction) for the
5-hour session and 7-day weekly windows and surface it in both surfaces:
- menu bar: flame/snowflake badge when off pace (>1.2x / <0.8x), with a
tooltip anchoring the ratio as "used X% vs Y% expected by now"
- popover cards: expected-by-now tick on the progress bar, pace line,
and rate projections ("hits limit ~1:10 PM, 50 minutes before reset",
"on pace to end at ~29% (71% unused)")
- pace-first display mode: the burn ratio replaces quota % as the
primary metric, colored by pace tier (blue <0.8x, green 0.8-1.2x,
orange 1.2-2.5x, red >2.5x), with quota % demoted to secondary
- weekly pace basis setting (5/6/7 days) so sustainable pace matches a
working week instead of the calendar week
Underuse only signals on the weekly window in quota-first mode: idle
time inside a 5-hour session isn't waste, weekly leftover is. Overuse
signals on either window and the hotter one wins. Ratios are suppressed
until 5% of a window has elapsed to avoid post-reset noise.
This was referenced Jul 18, 2026
|
@rshivane I ported the project to Tauri v2 and included pace based tracking: https://github.com/mpecan/rusted-claude-meter |
The pace signal could read "On Pace" or fall back to a green "Safe" while a window was already projected to exceed its limit. Two causes, both relative to the pace feature as shipped: - Only the lockout date escaped the 5%-elapsed grace; the pace ratio and projected-end stayed suppressed for the whole grace window, so a front-loaded burst showed no pace signal until 5% of the window (up to ~8h weekly) had elapsed. - Overuse started at 1.2x and heavy overuse at 2.5x, so a burn projected to end between 100% and 120% still read green "On Pace". Changes: - Ratio and projected-end now surface as soon as usage clears minimumUsageForProjection, matching the lockout date, so a real burst is graded immediately instead of waiting out the elapsed grace. - Lower minimumUsageForProjection 5% -> 2% (~one work-hour of usage). - Rebase pace bands on the limit: overuse >1.0x (was 1.2x), red >1.2x (was 2.5x). Anything on track to exceed 100% is now flagged and colored by severity. - Color the "hits limit" projection line by pace band instead of a fixed orange, so it matches the ratio.
Author
Neat! I pushed a new commit with a fix here @mpecan |
In pace-first mode, when neither window is off-pace the menu bar fell back to the session ratio unconditionally. An idle session (e.g. 0.1x) then hid a more meaningful on-pace weekly (1.0x), surfacing a reassuring-looking 0.1x that misrepresents the state. Fall back to the higher — worst, nearest to or past a sustainable pace — of the session and weekly ratios instead. The off-pace-signal path is unchanged; this only affects the no-signal fallback.
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
2 participants
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.
Usage percentage alone can't answer whether the current burn rate will exhaust a quota window early or leave paid capacity unused - 20% of the weekly quota used means opposite things on day 1 vs day 6.
Track a pace ratio (usage fraction / elapsed window fraction) for the 5-hour session and 7-day weekly windows and surface it in both surfaces:
Underuse only signals on the weekly window in quota-first mode: idle time inside a 5-hour session isn't waste, weekly leftover is. Overuse signals on either window and the hotter one wins. Ratios are suppressed until 5% of a window has elapsed to avoid post-reset noise.
Used 27% of weekly but only 0.6x pace - underuse:
Used 11% of weekly but 2x pace - overuse:
Settings:
