feat: display provider usage limits in settings

[Aditya190803]

Fixes #228.

What Changed

Added provider usage limits to the settings flow end to end:

• the shared contract now includes the usage-limits schema
• the server persists and exposes provider usage limits
• the web app renders the limits in Settings

Why

Users need a visible place to confirm provider usage limits without digging through logs or backend state. This keeps the value available across sessions and makes the current limits easy to inspect from the UI.

UI Changes

The Settings panel now shows provider usage limits in the provider section.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Medium Risk
Adds new persisted state (SQLite migration + repository) and threads it through provider snapshot/registry refresh paths; mistakes could cause stale/incorrect limits or extra refresh churn, but changes are scoped and covered by tests.

Overview
Adds end-to-end support for provider usage limits (session/weekly windows) and surfaces them in Settings.

On the server, introduces ProviderUsageLimitsRepository backed by a new provider_usage_limits SQLite table and wires it into runtime layers. ProviderService now normalizes account.rate-limits.updated events (Codex/Claude) and persists them, while CodexProvider/ClaudeProvider hydrate persisted limits into provider snapshots and ProviderRegistry refreshes/publishes updates when the cache changes.

On the client/contracts side, extends ServerProvider with optional usageLimits, adds normalization/decoding tests, and renders usage-limit progress bars + reset dates in GeneralSettingsPanel when present.

^{Reviewed by Cursor Bugbot for commit f929f16. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Display provider usage limits (session and weekly windows) in the Settings panel

• Adds a ProviderUsageLimitsRepository backed by a new SQLite table (provider_usage_limits) that persists normalized usage-limit snapshots per provider, ignoring stale upserts.
• ProviderService intercepts account.rate-limits.updated runtime events from Codex and Claude adapters, normalizes the payload via normalizeCodexUsageLimits / normalizeClaudeUsageLimits, and upserts to the repository.
• ClaudeProvider and CodexProvider hydrate persisted usage limits into every provider snapshot they emit; ProviderRegistry refreshes on repository changes.
• probeCodexAccount is replaced by probeCodexAccountState, which concurrently requests account info and rate limits, waiting up to ~150 ms for the rate-limits response before resolving it as null.
• ProviderUsageLimitsSection is added to GeneralSettingsPanel in SettingsPanels.tsx, rendering per-window remaining percentage, an accessible progress bar, and a localized reset-date label.
• ServerProvider in the contracts package gains an optional usageLimits field; existing payloads without it remain valid.

^{Macroscope summarized f929f16.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 77210731-5055-4ca9-936d-64c55e67a510

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Aditya190803]

For now, I’ve added two images to illustrate the UI:

1. Free tier view

This screenshot reflects my current setup. I don’t have subscriptions to Codex or Claude Code, I’m using Copilot Pro (available to me as a student). It shows how the weekly usage limit appears in the interface.

2. Pro tier (mocked example)

This second screenshot uses dummy data to demonstrate how the UI could look for users on a Pro plan (Codex or Claude Code). It includes both session-based limits and weekly limits for clarity.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 80515efa38

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Stop re-persisting stale cached Codex usage limits

This Effect.tap writes the accountProbeCache value back into provider_usage_limits on every Codex status check. Because the probe cache is valid for 5 minutes, a newer usage-limit update persisted from runtime events (via ProviderService's account.rate-limits.updated handling) can be overwritten by this older cached snapshot, causing limits to regress in storage and UI until cache expiry. Please avoid upserting cached probe data unconditionally (or at least reject older timestamps).

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Prefer persisted usage limits over account-probe cache

When both values exist, this branch prioritizes account.usageLimits from the 5-minute accountProbeCache and ignores cachedUsageLimits loaded from persistence. That means even after a fresh runtime usage-limit event is stored, provider refreshes keep serving stale probe data instead of the latest persisted snapshot. Reversing this precedence prevents stale limits from being shown after updates.

Useful? React with 👍 / 👎.

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces a significant new feature (provider usage limits display) with a new database table, persistence layer, contracts, and UI components. Additionally, there are two unresolved P1 review comments identifying potential data staleness bugs in the usage limits caching/persistence logic that should be addressed before merging.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9dfd1d3. Configure here.}