Repository navigation
[FEATURE]: Return OpenCode Go usage with each response and keep it on the message #53044
Description
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
There is no way to see OpenCode Go usage from inside OpenCode; you have to open the console. #25875 and #27698 asked for it in the TUI. The usage endpoint from #16513 exists, but nothing in OpenCode uses it.
Proposal: the gateway already loads the Go usage on every request to check the limits, and already adds a cost field to each response (a ping chunk with cost at the end of streams). It could add the same { rolling, weekly, monthly } object that /zen/go/v1/usage returns, for example:
{ "type": "ping", "cost": "0", "goUsage": {
"rolling": { "status": "ok", "percent": 62, "resetsAt": "2026-10-06T10:15:00Z" },
"weekly": { "status": "ok", "percent": 81, "resetsAt": "2026-10-12T00:00:00Z" },
"monthly": { "status": "ok", "percent": 37, "resetsAt": "2026-10-18T03:20:00Z" } } }OpenCode would then store it on the assistant message, next to tokens and cost.
What this gives:
- The TUI can show Go usage (sidebar or footer) and keep it current without any extra request.
- Nothing has to poll
/zen/go/v1/usage. Status bars and tray apps can read the last value from the local database instead of calling the API with the user's key, the same way Codex writesrate_limitsinto its session log. - The key never leaves OpenCode.
The value only changes when Go is used through OpenCode, but resetsAt lets a reader handle resets without asking the server.
Context: I maintain a Windows tray app that shows plan usage for several coding tools. It only reads what the tools themselves record or report and never handles credentials, so today it can't support Go.
If you'd want the server side, I'm happy to send the client side (reading the field and storing it on the message). A smaller alternative would be an opencode usage --format json command over the existing endpoint.
Prior: #9281 and #40584 (closed), #32913 (CLI command plus endpoint, now conflicts with #16513), #41824 (exposing Go usage through the OpenCode server, closed by the PR cleanup).
Activity
github-actions commentedon Oct 4, 2026
This issue might be a duplicate of existing issues. Please check:
/usageor/statuscommand for Go plan limits, including rolling, weekly, and monthly windows.\usagecommand with usage statistics, quota, and reset timers.Fishforgithub commentedon Oct 4, 2026
Re the duplicate check: #27698, #25030 and #25875 were auto-closed for inactivity, and #40584 was closed in favour of #16017, which only added the server endpoint. This issue is the client side that is still missing. A TUI plugin (as suggested in #25875) could show the numbers inside OpenCode, but it would have to read the key itself, and it doesn't help tools outside OpenCode.
[-][FEATURE]: opencode usage command for OpenCode Go limits (with --format json)[/-][+][FEATURE]: Return OpenCode Go usage with each response and keep it on the message[/+]opencodejr commentedon Oct 27, 2026
Thanks for the detailed proposal and the background on prior attempts!
To restate it: you'd like the Go gateway to return the
{ rolling, weekly, monthly }usage with each response (for example on the finalpingchunk next tocost), and OpenCode to store it on the assistant message. The TUI could then show it, and outside tools could read it locally without handling the API key.The main development branch has some related, unreleased work. OpenCode now reads
/zen/go/v1/usageitself using the stored OpenCode Console sign-in, and the local OpenCode server exposes the result atGET /api/experimental/usage/limits. The response includes agoobject withrolling,weeklyandmonthly, each withpercent,limitedandresetsAt. It's experimental and not in a release yet. Go usage still isn't recorded on messages, so your per-response proposal is still open. The endpoint may be enough for the TUI part, and for tools that can reach a running OpenCode.Related:
/zen/go/v1/usageThe maintainers will consider this. Thanks also for offering to write the client side.