[Feature]: Show remaining provider usage limits and reset times in the T3 Code UI

[ElliotDrel]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web, provider integrations, account status, settings, and T3 Connect

Problem or use case

When using subscription-backed providers such as Claude Code and Codex, I cannot easily see how much usage I have left without leaving T3 Code or waiting until a provider warns me that I am close to or have reached a limit.

Providers may expose multiple independent usage buckets, such as a rolling five-hour allowance, a weekly allowance, model-specific allowances, or other subscription-specific limits. I want T3 Code to show all available usage buckets directly in the app so I can decide which provider or model to use before starting a long task.

Proposed solution

Add a provider-usage view that shows the remaining subscription usage for Claude Code, Codex, and every other supported provider that exposes reliable quota information.

For each provider/account, T3 should display every available usage bucket rather than collapsing everything into one generic status.

Expected behavior

For each configured provider account, show:

• current usage and remaining usage;
• percentage used and percentage remaining;
• the limit period, such as rolling five hours or weekly;
• the exact or provider-reported reset date and time;
• a countdown until reset;
• any separate model-specific, premium-model, review, or other sub-limits exposed by the provider;
• whether the data is live, recently refreshed, estimated, unavailable, or stale;
• the account and T3 environment to which the usage applies.

The UI should support at least:

• Claude Code: all usage windows and sub-limits the authenticated Claude account exposes;
• Codex: all usage windows and sub-limits the authenticated OpenAI account exposes;
• Other providers: equivalent quota information whenever their CLI, SDK, account endpoint, or authenticated status command exposes it reliably.

UI placement

Usage should be visible without digging through logs. Useful placements could include:

• a compact meter beside the provider/model selector;
• an expandable provider-status popover;
• a full Usage page in Settings;
• warnings in the composer when a selected provider is close to a limit.

A compact view could show the most constrained bucket, while the expanded view shows every bucket separately.

Example:

Claude Code
5-hour usage: 63% remaining · resets in 2h 14m
Weekly usage: 28% remaining · resets Monday at 3:00 AM
Premium-model usage: 12% remaining · resets Friday at 8:00 PM

Codex
5-hour usage: 81% remaining · resets in 4h 02m
Weekly usage: 47% remaining · resets Sunday at 7:00 PM

The exact labels and limits should come from the provider rather than being hard-coded, because plans and limit structures can change.

Refresh behavior

• Refresh usage when T3 starts, when the provider account changes, and after completed provider turns when reasonable.
• Provide a manual refresh action.
• Avoid excessive polling or requests that could affect provider access.
• Carry the provider-reported observation time so remote clients can tell whether the value is current.
• Update the display promptly when a provider reports a rate-limit or quota change.

T3 Connect and multiple environments

Usage is often account-wide rather than machine-specific, while authentication may differ between environments.

T3 should therefore:

• identify which provider account each environment is using;
• avoid presenting duplicate meters as separate allowances when multiple environments use the same account;
• show account-wide usage consistently across T3 Connect clients;
• distinguish separate accounts when different environments are authenticated differently;
• indicate which environment supplied the latest usage data.

Accuracy and fallback behavior

T3 should use provider-supported quota data whenever available. It should not invent a remaining percentage from token counts or local activity unless the UI clearly labels it as an estimate.

If a provider does not expose reliable remaining usage:

• show Usage unavailable rather than a fabricated value;
• optionally show the last provider-reported reset or rate-limit event;
• explain whether the limitation comes from the provider, authentication method, plan, or CLI version.

Notifications and warnings

Allow optional warnings when a usage bucket falls below a configurable threshold, for example:

• 25% remaining;
• 10% remaining;
• nearly exhausted;
• fully exhausted;
• reset completed and usage is available again.

Warnings should identify the provider, account, specific usage bucket, and reset time.

Why this matters

Provider limits materially affect which agent I should start a task with. Without visibility, I may begin a long Claude Code or Codex run and hit a five-hour or weekly limit partway through it.

Showing remaining usage inside T3 Code would make provider selection informed and predictable, especially when managing several providers, accounts, and remote environments from one interface.

Smallest useful scope

• Add a Usage popover or Settings section.
• Support Claude Code and Codex first.
• Show every reliably available provider-reported usage bucket.
• For each bucket, show percentage remaining and reset time.
• Include a manual refresh action and a stale/unavailable state.
• Display the correct account when multiple provider accounts or T3 environments are configured.

Related but distinct issue

• [Feature]: Multi-Account Session Rotation for Claude & ChatGPT Subscriptions with Automatic Failover #2471 requests multi-account rotation after an account reaches its limit. This issue is only about making remaining usage and reset information visible before that happens.

Risks or tradeoffs

• Providers may not expose an official or stable usage endpoint through every authentication method.
• Usage limits and labels may vary by subscription, model, region, account, or provider policy.
• Scraping human-facing provider pages would be fragile and should not be presented as authoritative without clear labeling.
• Usage information can be account-sensitive and should not leak between users, environments, logs, or remote clients without the same authorization used for the provider account.
• Polling must be conservative and should not create unnecessary provider traffic or trigger security controls.

[TempAccountNull]

If the authors need a heads up on how to implement this. Or have notifications.
I have Open sourced my tool that supports the following providers:

• Codex
• Claude
• Grok
• Z.Ai

https://github.com/TempAccountNull/AIQuotaChecker

[roc-ops]

Upvote for some version of this! today in claude code I use a single line update like so: ⏱ 16% 3h47m 📅 27% 8/12 | 🌙 | ⎇ main | ctx 87% | AI● Code● , which tells you (claude specific) % used and time til reset for 5h quota, %used date of reset for weekly quota, whether we are in prime time or not, ctx % and AI and Claude indicators from api status on claude.ai color coded so at a glance you cna see where you are. This data is mostly sent every API return from Claude, so you can monitor it on exisitng API calls rather than polling for it other than API status but I think they have a few ways to consume that. but I would welcome an at-a-glance view per AI provider to tell where I am quota wise. Either side of the Chat box is unused real estate that seems like it would work well for a condensed view

[tlmader]

Evaluating T3 Code right now for juggling multiple Claude/Codex accounts, and the only reason I still need the Claude/Codex apps open are to check usage limits!

[pmakowski23]

What about possible auto retry? When you get to usage limit after it gets restored it could just continue.

[ViolentVotan]

I think everyone has this in their statusline, this is definitely something we need

[dsfortescue]

What's funny is that one of the sponsors in Theo's videos has an excellent in-app solution. They also have a great system monitor.

trayer.ai

The tool is similar to T3, with much worse remote management features (which was the deal breaker for me) but interesting cross platform agent communication features (think herdr in the GUI).