feat: display provider usage limits in settings#1732
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 This PR introduces a new feature for displaying provider usage limits with significant new logic across multiple provider drivers and state management. Multiple unresolved P1 review comments identify potential bugs in usage limit caching and persistence logic that require attention. 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
- 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
|
@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
…imits # Conflicts: # apps/web/src/components/settings/SettingsPanels.browser.tsx
There was a problem hiding this comment.
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 a89f9b4. Configure here.
| method: "session/update", | ||
| payload: input.rawPayload, | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Unconditional turnId inclusion inconsistent with sibling functions
Low Severity
makeAcpUsageUpdatedEvent always sets turnId: input.turnId even when the value is undefined. Other functions in the same file with optional turnId (e.g., makeAcpToolCallEvent) use the conditional spread pattern ...(input.turnId ? { turnId: input.turnId } : {}). Including turnId: undefined produces a different runtime object than omitting the key, which can affect serialization and consumers checking key presence with "turnId" in event.
Reviewed by Cursor Bugbot for commit a89f9b4. Configure here.
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 across contracts, server probes, runtime event ingestion, and UI rendering; risk is mainly around provider status probing latency/fragility (PTY-based Claude probe, extra Codex API call) and correctness of new event parsing.Overview
Provider snapshots now optionally include
usageLimits(session/weekly windows with % used + optional reset time), with schema support added to@t3tools/contractsand snapshot/cache plumbing updated to preserve it.Server-side probes now populate usage where possible: Codex fetches subscription rate-limit windows, Claude can probe quota via a PTY-driven
/status→/usageflow (with parsing + fallbacks) and also stamps runtime events withproviderInstanceId; Cursor parses ACPusage_updatenotifications intothread.token-usage.updated, and OpenCode derives usage for official managed providers.Adds
ProviderUsageStateLiveto ingest runtime events and remember the latest per-provider/per-instance usage, wires it intoserver.ts, and updates the SettingsProviderInstanceCardto render usage progress bars (warn/destructive thresholds) while filtering quota telemetry from the chat work log.Reviewed by Cursor Bugbot for commit a89f9b4. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Display provider usage limits (session/weekly windows) in provider settings cards
ServerProviderUsageLimitsto the contracts schema and propagates it through provider probes for Codex, Cursor, Claude, and OpenCode providers.ProviderUsageStateLive, a new server-side service that maintains per-provider usage state from runtime events (Cursor token usage, Claude rate limit telemetry) and exposesget/set/cleareffects.claudeUsageProbe.ts, which spawns a PTY to parse Claude's/statusand/usageoutput into normalized session/weekly usage windows.ProviderInstanceCardwith color-coded fill (warning ≥70%, destructive ≥90%) and reset timestamps; shows an unavailable message when data cannot be obtained.account.rate-limits.updated,account quota updated) from the session work log viaisHiddenWorkLogTelemetryActivity.ProviderUsageStateand PTY adapter dependencies wired in from the server layer.Macroscope summarized a89f9b4.