Before submitting
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
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.
Before submitting
Area
apps/web, provider integrations, account status, settings, and T3 ConnectProblem 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:
The UI should support at least:
UI placement
Usage should be visible without digging through logs. Useful placements could include:
A compact view could show the most constrained bucket, while the expanded view shows every bucket separately.
Example:
The exact labels and limits should come from the provider rather than being hard-coded, because plans and limit structures can change.
Refresh behavior
T3 Connect and multiple environments
Usage is often account-wide rather than machine-specific, while authentication may differ between environments.
T3 should therefore:
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:
Notifications and warnings
Allow optional warnings when a usage bucket falls below a configurable threshold, for example:
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
Related but distinct issue
Risks or tradeoffs