[FEATURE]: Add Go plan usage/balance API endpoint (rolling/weekly/monthly windows)

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Summary

Expose the Go plan subscription usage data via a public API endpoint. The dashboard already shows this information — rolling, weekly, and monthly usage percentages with reset timers — but there is no way to query it programmatically.

Use Case

Status bar widgets (waybar, polybar, macOS menu bar) showing current usage
Alerts when approaching plan limits before getting throttled
Monitoring dashboards aggregating usage across providers and plans
CI/CD pipelines checking remaining quota before kicking off expensive runs

Current Behavior

The only way to see Go plan usage is the web dashboard, which displays:

Rolling usage: x% (resets in N minutes)
Weekly usage: y% (resets in N minutes)
Monthly usage: z% (resets in N minutes)

No API endpoint exists to retrieve this data.

Proposed API

GET /api/v1/usage/plan
Authorization: Bearer <api-key>

Response:
{
  "plan": "go",
  "windows": {
    "rolling": {
      "usage_percent": 65,
      "resets_in_seconds": 2520
    },
    "weekly": {
      "usage_percent": 30,
      "resets_in_seconds": 259200
    },
    "monthly": {
      "usage_percent": 12,
      "resets_in_seconds": 1728000
    }
  }
}

Related Issues

Feature Request: Add Zen balance API endpoint #10448 — Zen balance API endpoint (pay-as-you-go USD balance; different data model)
[FEATURE] Add unified usage tracking via /usage (#9545) #9281 — Unified /usage tracking in TUI (provider-level: Codex/Copilot/Claude)
Github Copilot: Tracking Premium Requests #768 — Copilot premium request tracking
Request: View token and zen usage with command #3119 — Early request for token/zen usage via command

Additional Context

The Go plan's rolling/weekly/monthly usage windows are a distinct data model from the Zen credit balance (#10448) and provider-level quotas (#9281). The server already computes this data for the dashboard, so exposing it via API should be a relatively small addition.

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

Feature request titles must start with [FEATURE]: (current title: "Feature Request: Add Go plan usage/balance API endpoint...")
The feature request template includes a verification checkbox confirming you've searched for existing issues — please ensure this is included

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

This issue might be a duplicate of existing issues. Please check:

Feature Request: Add Zen balance API endpoint #10448: Also requests a programmatic API endpoint for account balance/usage data (Zen balance endpoint — different data model but closely related functionality)

If you believe this was flagged incorrectly, please let a maintainer know.

Thanks for updating the issue! It now meets our contributing guidelines — the title has been corrected to start with [FEATURE]: and the verification checkbox is checked. We appreciate you taking the time to fix it.

Thanks for updating the issue! It now meets our contributing guidelines — the title has been corrected, the verification checkbox is checked, and the description clearly explains the use case and need. Much appreciated!

@thdxr

submitted a pr #16513. but i don't think can test this locally, so it's not meeting compliance @thdxr

Thanks!

+1. Would love to see this implemented. My use case: integrating Go plan usage tracking into an AI agent CLI as a quick command. Having rolling/weekly/monthly usage data accessible via API (e.g. GET /zen/go/v1/usage) would enable real-time monitoring without the web dashboard.

+1, I would like it too to programmatically check it in a helper script or even inside of OpenCode itself!

If you need a workaround is possible with OpenCode Quota: for OpenCode Go you just have to provide a workspace ID and auth cookie.

been waiting too long since March...

when will this be done? server side issue....
just make this endpoint..

+1 — running opencode serve as a persistent backend for multiple clients (browser, phone, SSH) sharing one Go API key. Heavy parallel use burns the 5h cap fast with zero visibility from the TUI. Currently forced to keep a browser tab on the workspace page or switch to the free tier when limits hit. Would especially love a TUI slash command (e.g. /usage) that shows the three windows with reset timers.

+1 exactly what I need for monitoring my Go subscription usage

why not now? been 5 months.

+1, with a gateway use case that the ones above do not cover.

We run a self-hosted multi-provider gateway (CLIProxyAPI) in front of several coding agents. A Go key is one credential in a pool the router picks from. The router reads per-request token counts from the usage object in the chat/completions response, but it has no way to know how much of the plan is left, so it cannot steer traffic away from Go before the cap is reached. It only finds out at the 429, mid-request, and the whole pool stalls.

There is no in-band signal to fall back on either. Checked from outside today: GET /zen/go/v1/usage, /zen/v1/usage and /zen/go/v1/balance all return the SPA 404 HTML, and normal responses carry no X-RateLimit-* headers.

Recomputing the meter on the client side is not a substitute. We can multiply token counts by the published per-model rates, but that number drifts from what the dashboard reports, as shown in #40280 ($12.42 tracked against $19.20 displayed). Only the server knows its own accounting.

What would be enough for us is the shape already proposed here: the three windows with usage_percent (or remaining USD) and a reset timestamp, authenticated with the plain API key. The workspace-ID plus session-cookie route that opencode-quota uses works for a desktop, but it is not something a headless server can hold. Rate-limit headers on ordinary responses would cover most of the need as well, and would be cheaper to ship.

when will it be possible....
its so simple, why take 5 months.... when please when..

I've made small TUI plugin to display the stats - https://github.com/and7ey/opencode-go-usage

Correct what OpenCode exposes: Go's limits are open to its key

feat(aiquotas): add opencode provider for OpenCode Go subscription qu…

Navigation Menu

Repository navigation

[FEATURE]: Add Go plan usage/balance API endpoint (rolling/weekly/monthly windows) #16017

Feature hasn't been suggested before.

Describe the enhancement you want to request

Summary

Use Case

Current Behavior

Proposed API

Related Issues

Additional Context

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Add Go plan usage/balance API endpoint (rolling/weekly/monthly windows) #16017

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Summary

Use Case

Current Behavior

Proposed API

Related Issues

Additional Context

Activity

github-actions commented on Mar 4, 2026

github-actions commented on Mar 4, 2026

github-actions commented on Mar 4, 2026

peculiarnewbie commented on Mar 7, 2026

StephanMeijer commented on Mar 8, 2026

alansong63 commented on Apr 28, 2026

LuisHerreraG commented on May 2, 2026

slkiser commented on May 2, 2026

26 remaining items

PowerfulShell commented on Aug 4, 2026

PowerfulShell commented on Aug 4, 2026

bertrell commented on Aug 5, 2026

0pilatos0 commented on Aug 5, 2026

PowerfulShell commented on Aug 6, 2026

artile commented on Aug 7, 2026

PowerfulShell commented on Aug 12, 2026

and7ey commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions