Repository navigation
[FEATURE]: typed usage-limit signal (with reset time) for ChatGPT sign-in instead of error text #56798
Description
Feature hasn't been suggested before.
- I have searched existing issues (related but different: bug: infinite retry loop on rate limit without logging ("Free usage exceeded, subscribe to Go") #45989 covers the retry loop; this asks for a typed signal).
Describe the enhancement you want to request
When a ChatGPT-sign-in session exhausts the Codex 5-hour or weekly window, the model call fails with AI.Error.InvalidRequest: subscription_sharing_usage_limit_exceeded: The ChatGPT user has reached their Subscription Sharing usage limit... and the session drains with "Failed to drain Session". Plugins only see this as free text in the retry hook / tool error message, and the TUI user sees a generic failure.
The Codex app-server already exposes the structured data (account/rateLimits/read: primary.usedPercent, secondary.usedPercent, resetsAt, windowDurationMins), and the same backend returns a typed error here.
Request:
- A typed error/event for provider usage limits (vendor, window,
resets_at) surfaced onSessionErrorand in theretryhook, so plugins can decide (stop, switch model/agent, defer untilresets_at) without regex-matching messages. - Optionally surface current usage percentages for the ChatGPT integration (same shape the Codex CLI shows in
/status) via the model/provider API, so routing plugins and the TUI can warn before the window is exhausted rather than after.
Context: we built a budget-aware routing plugin that reads these numbers out-of-band from the Codex app-server; a first-class signal would remove that dependency and make the behaviour available to every ChatGPT-sign-in user. Observed on v2.0.32, macOS 26.
Activity
opencode-agent commentedon Oct 18, 2026
Thanks for the detailed request, @youthtrouble!
To restate it: you'd like ChatGPT sign-in usage-limit failures to come through as a typed signal (provider, window,
resets_at) onSessionErrorand in theretryhook, instead of as free text. Optionally, you'd also like current 5-hour and weekly usage percentages exposed through the provider API, so plugins and the TUI can warn before a limit is reached.On the current code,
subscription_sharing_usage_limit_exceededis already treated as non-retryable, but it is turned into a fixed text message. The window and reset time are dropped, so plugins can't get at them. A plugin can't fill that gap today. It would need plugin API changes, for example a structured usage-limit error variant and a way for provider plugins to report usage. Maintainers will consider it.Related issues and PRs:
razzeee commentedon Oct 21, 2026
I would like to help implement read-only ChatGPT account usage for clients such as T3 Code. T3 already displays Codex quota windows and reset times, but cannot obtain equivalent information when the connection belongs to OpenCode, especially on a remote server.
I checked the Codex backend client and tested its read-only endpoints with an existing OpenCode login. Both returned HTTP 200:
GET https://chatgpt.com/backend-api/wham/usage: usage percentages, window durations, reset timestamps, credit balance, and a reset-credit summary.GET https://chatgpt.com/backend-api/wham/rate-limit-reset-credits: reset inventory, status, type, and expiry timestamps.Requests used bearer authentication and the stored ChatGPT account ID header. No credentials were changed or resets redeemed. The endpoint definitions are in
codex-rs/backend-client/src/client/rate_limit_resets.rsin openai/codex.Compatibility caveat: the tested credential uses the older
chatgpt-browsermethod, withoutchatgpt.tokens.use.directin its JWT scopes. Fresh token-sharing credentials still need verification; success with this login does not establish support for every ChatGPT connection.Proposed initial scope: OpenCode fetches usage for the active connection and exposes a credential-free snapshot through its public API, with reported quota windows, observation time, a connection reference, and explicit unsupported/unavailable states. Credit balances and banked-reset inventory/redemption can follow separately.
Would maintainers support this direction, and should the read API be integration/connection-scoped or part of the provider API? I can work on an implementation once the design is agreed.