feat: add a pace indicator to the usage bars

[carlosresu]

Summary

Adds an opt-in pace indicator that marks where usage should be if spread evenly across the window, so each bar shows at a glance whether you can keep working or are about to run out. Rebased on v1.4.8 and extended to the Antigravity model.

• The expected position is derived from each section's resets_at and the fixed window length (5h / 7d).
• Green — behind pace: headroom to ramp up before the window resets.
• Red — ahead of pace: on a trajectory to exhaust the quota before it resets.
• Two styles: Tick (a thin vertical bar at the expected-pace position) and Solid (a filled band between actual usage and expected pace).
• Drawn on the bars of all three models — Claude, Codex, and Antigravity.

Screenshots

Green = headroom to ramp up; red = trajectory to exceed quota — in either style.

Style	Red — over pace	Green — headroom
Solid
Tick

Settings control

A right-click Settings → Show pace indicator submenu with Off (default) / Tick / Solid as a radio group; the parent entry shows a checkmark while a style is active. Off by default; persists to settings.json via #[serde(default)]. The indicator draws inside the existing bar segments, so it does not change the widget width.

Localization

All pace strings (Show pace indicator, Off (default), Tick, Solid) are translated across all 10 supported locales.

Independence & compatibility

Branches directly off v1.4.8 main (single commit) and contains only this feature — merge it alone, or alongside the detailed-remaining-time (#24) and ETD (#38) PRs in any order: every combination merges with 0 conflicts (verified via git merge-tree + a triple-merge that builds and passes tests).

Test plan

• cargo build + cargo test clean on v1.4.8
• Settings → Show pace indicator lists Off/Tick/Solid; selecting one draws on the 5h/7d bars across Claude/Codex/Antigravity
• Red when over pace, green when behind; Off clears it; widget width unchanged
• Selected style persists across restart

[dustingraham]

This feature is exactly what I was starting to look into. I think the "where am I in the 5 hours" and "where am I in the 7 days" is so useful.

[rohal12]

yes I built the exact same thing. this is what I need. am I on track or am I overshooting and run out of tokens on the last day?

[CodeZeno]

Massive thank you to @carlosresu for building this so thoughtfully, including the Tick and Solid styles across Claude, Codex, and Antigravity.

Thanks also to @dustingraham and @rohal12. You both captured the real value perfectly: knowing where you are within the 5-hour or 7-day window, and whether your current pace will leave headroom or have you running out before the reset.

v2 is now released, and its new Theme Studio addresses this use case in a much more flexible way. Themes now have access to live usage percentages, reset times, calculations, comparisons, conditional rendering, and fully customizable layers. This means the pace indicator can be created and styled directly within any theme instead of being hard-coded into the original v1 widget renderer.

For anyone wanting to recreate it:

1. Right-click the widget or tray icon and select Open Dashboard.
2. Open Theme Studio, select Classic v1, and duplicate it.
3. Add a small child layer inside the relevant usage bar.
4. Use the expression button on its X position. For example:
   • 5-hour Claude window: clamp((1 - claude.session.reset.seconds / 18000) * parent.width, 0, parent.width - 3)
   • 7-day Claude window: clamp((1 - claude.weekly.reset.seconds / 604800) * parent.width, 0, parent.width - 3)
5. Duplicate the marker into green and red versions, then use Render expressions comparing the calculated expected percentage with claude.session.percentage or claude.weekly.percentage.
6. Swap claude for codex or antigravity to apply the same idea to another provider.

A 3px-wide layer gives you the Tick style. The same calculation can drive the X position and width of a filled layer for the Solid style.

This feedback lined up closely with the direction v2 took, and I really appreciate the implementation and conversation around it. I’m closing this PR as addressed by the v2 release rather than merging code tied to the previous renderer.

Thanks again, everyone! 🚀