You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[UI] Show provider subscription usage in the thread details card on Web / Desktop App
#19056
Subscription limits — the 5-hour / weekly / monthly quota windows a provider
reports for the signed-in account — are only visible in the full Usage → Limits
page (mod+u) or in the ephemeral /usage-limits composer notice, which appears
on demand and dismisses when the thread, model, or turn changes.
Nothing beside the chat answers "how much of this window is left?" while you decide
whether to start another turn. Other agent workspaces like OpenChamber keep a compact usage readout
in the thread-context panel for this reason, and there is already appetite for it
here: #17868 asks for a sidebar warning when a window drops below 10%.
Example from OpenChamber Web UI's Thread Details Card:
Proposal
Add a Usage section to the thread details card (the panel beside the chat that
already shows Workspace, Version Control, Automations, and Lineage). It builds on
the existing provider usage-limits data and the same pooling the Limits page uses,
so it cannot drift from the page:
A collapsible header whose headline is the session provider's window
closest to running out, shown as Session X% used. Another provider's tighter
window never reads as this session's; if the session's provider reports nothing,
no number is shown, and the expanded rows still list every provider.
Expanded, per-provider groups that each expand/collapse, with
provider-prefixed window rows (Codex · Session), each showing its share used, a
thin bar, and the next reset (↻ 1h 50m). Per-provider collapse choices persist.
Quota used throughout, with the number and bar amber past 60% used and red
past 90%.
A Refresh action, plus automatic refresh.
Settings → General gains two controls: Usage refresh interval
(30s / 1m / 5m / manual; default 1m) and Usage headline window (closest to
running out by default, or a fixed session / weekly / monthly).
The section hides itself when no connected provider reports windows, so an
environment without subscriptions gains no empty section.
No server or contract behaviour changes: the report is assembled client-side from ServerProvider.usageLimits and usageLimitSources, which already stream to
clients.
From experimenting with T3 nightly fork:
Before:
After:
Collapsed:
Expanded:
Usage limit over 60% (amber) / over 90% (red)
Usage collapsed, Red headline (over 90%), showing tightest window at 94% used:
Reference to Usage in Settings - General (might not be the best place for this)
Scope / non-goals
Not the Usage page: its Limits and cost/token views are unchanged.
Not the /usage-limits command or the composer notice.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Problem
Subscription limits — the 5-hour / weekly / monthly quota windows a provider
reports for the signed-in account — are only visible in the full Usage → Limits
page (
mod+u) or in the ephemeral/usage-limitscomposer notice, which appearson demand and dismisses when the thread, model, or turn changes.
Nothing beside the chat answers "how much of this window is left?" while you decide
whether to start another turn. Other agent workspaces like
OpenChamberkeep a compact usage readoutin the thread-context panel for this reason, and there is already appetite for it
here: #17868 asks for a sidebar warning when a window drops below 10%.
Example from

OpenChamberWeb UI's Thread Details Card:Proposal
Add a Usage section to the thread details card (the panel beside the chat that
already shows Workspace, Version Control, Automations, and Lineage). It builds on
the existing provider usage-limits data and the same pooling the Limits page uses,
so it cannot drift from the page:
closest to running out, shown as
Session X% used. Another provider's tighterwindow never reads as this session's; if the session's provider reports nothing,
no number is shown, and the expanded rows still list every provider.
provider-prefixed window rows (
Codex · Session), each showing its share used, athin bar, and the next reset (
↻ 1h 50m). Per-provider collapse choices persist.past 90%.
(30s / 1m / 5m / manual; default 1m) and Usage headline window (closest to
running out by default, or a fixed session / weekly / monthly).
environment without subscriptions gains no empty section.
No server or contract behaviour changes: the report is assembled client-side from
ServerProvider.usageLimitsandusageLimitSources, which already stream toclients.
From experimenting with T3 nightly fork:
Before:

After:
Collapsed:

Expanded:

Usage limit

over 60%(amber) /over 90%(red)Usage collapsed, Red headline (over 90%), showing tightest window at

94% used:Reference to Usage in Settings - General (might not be the best place for this)

Scope / non-goals
/usage-limitscommand or the composer notice.(
apps/mobile/src/features/usage/*), and there is no thread-details card there.Open question
Is the thread details card the right home for this? Happy to prepare a focused PR once the direction is approved.
All reactions