Faster / adaptive refresh: 5-minute cadence is too laggy for menu-bar quotas

[KevinXC5]

Problem

Background refresh is hardcoded to 5 minutes with no Settings control (docs/refreshing.md: "a fixed cadence — there's no setting for it"). Manual refresh (footer / ⌘R) still works, but that is not a substitute for choosing how often the menu-bar meters update on their own.

I keep OpenUsage in the menu bar all day as a compact quota strip (Bars style, Codex + Grok pins). Five minutes is a reasonable default, but it is the only option:

• While actively coding against a 5-hour Codex window, 5 minutes is slow — I only find out I am close to the cap after the fact, unless I sit there hitting ⌘R.
• When I am not coding, polling every 5 minutes is more aggressive than I need. A longer interval (15 / 30 min) would cut API traffic, wake-ups, and battery use.

I know this ground has been covered:

• #611 removed Refresh Every from Settings and froze the cadence at 5 minutes.
• #678 asked for 1-minute polling and was closed as not planned, because providers already 429 at 5 minutes and are likely to tighten further.
• #679 sketched a smart per-provider timer; the shipping behavior is still a single global 5-minute loop.

This request is not "poll every minute". It is "give the user a conservative picker again", with 5 minutes remaining the default and a floor that respects the rate-limit lesson from #678.

Proposed Solution

Bring back a Refresh Interval row in Settings (Appearance or a small Advanced / Usage section), defaulting to 5 minutes.

Suggested options:

Option	Intent
5 min (default)	Current behavior, unchanged for existing users
10 / 15 / 30 min	Lighter polling when the Mac is just sitting in the menu bar
2 or 3 min (optional, last)	Fresher session windows while coding; still above the 1-minute floor that #678 rejected

Constraints I think keep this compatible with #678 / #611:

• Do not offer 1 minute. Floor at 2–3 minutes if a faster option exists at all; otherwise floor at 5 and only expose longer intervals. Even a "5 / 15 / 30" picker would already solve the resource side.
• Keep ⌘R / footer click as an unbounded manual bypass, as today.
• Keep one global cadence (no per-provider UI). Per-provider / adaptive scheduling from Smart / adaptive refresh timer with per-provider cadence and exponential backoff #679 can stay a later internal improvement.
• Cache TTL and the "Next update in Nm" footer should follow the chosen interval so the UI does not lie.
• Document the floor and the rate-limit reason in docs/settings.md / docs/refreshing.md, so people do not file "please add 30s" next.

The RefreshSetting type still exists from the pre-#611 code; this is mostly restoring the picker and wiring it back to startPeriodicRefresh, not a new scheduler.

Alternatives Considered

• Live with 5 min + mash ⌘R. Works, but the whole point of pinning meters in the menu bar is glanceable, hands-off numbers. I should not have to babysit the popover.
• Re-open Polling Interval #678 as 1-minute polling. Already rejected for good provider-health reasons. I am explicitly not asking for that.
• Wait for the smart/adaptive timer (Smart / adaptive refresh timer with per-provider cadence and exponential backoff #679). Still the right long-term design, but it does not ship today, and it still would not let me slow down polling when I want to.
• Quit OpenUsage when idle. Defeats the menu-bar use case.

A small, floored picker is the least surprising fix: default stays safe, power users can go slower (or slightly faster), and provider APIs are not spammed.

Additional Context

OpenUsage is the menu-bar tracker I actually want to keep (compact Bars pins, native, much lighter than CodexBar). CodexBar still exposes Adaptive plus 1 / 2 / 5 / 15 / 30 minute presets; I do not need that full set — just a way to choose something other than a locked 5 minutes.

Happy to take "longer intervals only, 5-minute floor" if a faster option is still too risky.

[KevinXC5]

Follow-up on what I actually need, now that I have lived with the 5-minute lock for a bit.

The pain is lag, not wanting to poll less. I pinned Codex session/weekly and Grok in the menu bar so I can glance at remaining quota while coding. With a 5-hour window, five minutes is slow enough that I regularly find out I am close to the cap only after the agent has already started failing. ⌘R works, but then I am babysitting the popover instead of looking at the strip.

Preferred fix: adaptive cadence, CodexBar-style. A fixed 2–3 minute hammer is not what I am asking for (and I understand why #678's 1-minute request was declined). What I want is:

• Faster while I am actually using it (menu recently opened, or local Codex/Grok/Claude activity)
• Back off when the Mac is idle, so providers are not polled harder than today
• Stay in a 2–30 minute band, never 1 minute

CodexBar's Adaptive policy is a useful reference (2 min after recent menu interaction, 5 min while coding/warm, 15–30 min when idle, 30 min under Low Power / thermal pressure). That is kinder to provider APIs than a locked 5 minutes and fresher when it matters.

This is essentially #679 as a user-facing default, not a hidden scheduler. The shipping loop is still a single global 5-minute tick.

If a full adaptive policy is too much for now, a Settings picker with a 2 or 3 minute option (floor above 1 minute, default still 5) would already fix the lag. Longer intervals are nice-to-have; they are not why I filed this.

Happy to take Adaptive-only, with no extra presets, if that is easier to ship without re-opening the rate-limit concern from #678.