feat: display provider usage limits in settings#1732
feat: display provider usage limits in settings#1732Aditya190803 wants to merge 74 commits intopingdotgg:mainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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. Comment |
github-actions
Bot
added
vouch:unvouched
|
For now, I’ve added two images to illustrate the UI: 1. Free tier viewThis 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.
|
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 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".
| state?.usageLimits | ||
| ? usageLimitsRepository | ||
| .upsert({ | ||
| provider: PROVIDER, | ||
| usageLimits: state.usageLimits, |
There was a problem hiding this comment.
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 👍 / 👎.
| const usageLimits = isResolvedCodexAccountState(account) | ||
| ? (account.usageLimits ?? cachedUsageLimits) | ||
| : cachedUsageLimits; |
There was a problem hiding this comment.
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 👍 / 👎.
ApprovabilityVerdict: Needs human review New feature introducing provider usage limit display across multiple providers with new service infrastructure. Multiple unresolved P1 review comments identify potential issues with cache/persistence precedence that need resolution before merging. You can customize Macroscope's approvability policy. Learn more. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
Hey @juliusmarminge, could you take a look at this PR when you get a moment? Thanks! |
|
Randomly found this PR because wanted to add usage to T3. I think this is great as a user but also I think the UI should match the Codex App usage,it's minimal and clean, would be better than AI tabs You would need to redo the settings button though,something Julius needs to approve. I genuinely think settings button should match Codex App, would love to open PR for that. |
|
A few concerns after checking the code:
I can test further and commit to this PR if you're okay with it, @Aditya190803. Genuinely want to see this merged - it would be super useful |
|
this is on my list to review still! Just dealing with some larger prep work so haven't had time yet. As for the "it must be more visible and sjhould be 1:1 like codex app": How often do you guys check your limits to warrant it being one click ??? I check it at most a few times a week, so hiding it in settings next to the provider status is fine! |
I've been checking usage a lot in Codex - a couple of times daily since I was on the $20 plan with 2x limits till April, so I was curious how it was going. My take is that the current settings are genuinely fine, but I think it'll get crowded soon. With usage, OpenCode and Cursor support, and I'm sure there are PRs that extend the settings further it's going to contain a lot of content before long. 
|
|
Yes when the single settings page gets too large we'll split it to subpages. We already did the work adding the sidebar when adding the archive |
|
can't see claude limits: |
juliusmarminge
left a comment
juliusmarminge
left a comment
There was a problem hiding this comment.
implementation seems way overcomplicated.
why cache the data? the provider check runs once per minute. we can get fresh data on every tick?
how i imaagined this working:
- extend the
checkProviderprobe in ServerProvider to include a newusageLimitsproperty. - on the auth check probes (app server / claude), extract usage data
- stream it down to client as part of the normal provider snapshot
- render the UI on settings page
given i haven't looked into exactly what's possible to probe and not, why is this PR so much more than that?
github-actions
Bot
added
size:XXL
Cherry-picked from upstream pingdotgg#1732 Conflicts resolved manually.
Aditya190803
force-pushed
the
feat/provider-usage-limits
branch
from
f9aabcd to
171df70
Compare
github-actions
Bot
added
size:XL
github-actions
Bot
added
size:XXL
…d union and simplify usage limit label generation
- Refactor claudeUsageProbe to use shared PtyAdapter instead of ad-hoc node-pty - Add parseClaudeRuntimeUsageLimits for SDK rate-limit event parsing - Add ProviderUsageState layer with tests - Integrate usage state into ClaudeDriver and ClaudeProvider - Add migration 029 for auth session compatibility columns (keep 021 intact) - Update server and tests for usage limits wiring
…unused checks for pairing_links
…improve server layer integration
… from server layer
…ions in usage limits
…te migration entries
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit fee4110. Configure here.
|
@juliusmarminge |
Resolved merge conflicts and fixed typecheck errors introduced by origin/main's stricter Effect lint rules (importFromBarrel, globalDate, globalDateInEffect). Migrated barrel imports to subpath imports and replaced Date.now()/new Date() with Effect DateTime/Clock APIs.
…a190803/t3code into feat/provider-usage-limits
4 participants
Fixes #228.
What Changed
Added provider usage limits to the settings flow end to end for all 4 providers (Codex, Claude, Cursor, OpenCode):
Note: For OpenCode, only the official OpenCode-managed providers (OpenCode Go, OpenCode Zen) are shown.
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
Note
Medium Risk
Adds a new
usageLimitsfield to the provider contract and wires it through multiple provider probes plus a new runtime state tracker; mistakes could surface incorrect quota info or add latency (notably Claude PTY probing) but does not touch auth/permissions logic.Overview
Provider snapshots now include quota/usage metadata. The
ServerProvidercontract gains optionalusageLimits(session/weekly windows, reset timestamps, availability + reason), and snapshot building/caching is updated to persist and hydrate this field.Server-side usage sourcing is added per provider. Codex fetches rate-limit windows during probe, OpenCode derives usage from managed upstream providers, Cursor converts ACP
usage_updatenotifications intothread.token-usage.updated, and Claude can probe usage via a PTY-driven/status→/usageflow; a newProviderUsageStateLiveservice listens to runtime events (Cursor token usage + Claude rate-limit telemetry) and exposes the latest per-provider/instance usage back into status checks.UI surfaces usage in Settings and reduces noise elsewhere.
ProviderInstanceCardrenders usage progress bars with threshold coloring and reset times, and the work log filters out account quota telemetry activities; minor React hook dependency fixes and new tests cover parsing/mapping and rendering behavior.Reviewed by Cursor Bugbot for commit 94ba4ac. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Display provider usage limits with progress bars in settings panel
usageLimitsto theServerProvidercontract with session/weekly usage windows, availability status, and optional reset timestamps, sourced from Codex, Claude, Cursor, and OpenCode providers.ProviderUsageStateLive, a new in-memory service that tracks per-provider usage by consuming runtime events (thread.token-usage.updatedfor Cursor,account.rate-limits.updatedfor Claude)./status+/usageCLI flow (probeClaudeUsageLimits), parsing ANSI terminal output into normalized session/weekly windows.ProviderInstanceCardwith threshold-based colors (warning at 70%, destructive at 90%) and optional reset timestamps.account.rate-limits.updated,account quota updated) from the session work log.Macroscope summarized 94ba4ac.