Repository navigation
[FEATURE]: Expose OpenCode Go usage history through the API key #43983
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
It would be great if we could expose our OpenCode Go usage history through an API-key-authenticated endpoint.
OpenCode Go and Zen can be used with the same API key. The existing Go usage endpoint exposes the current rolling 5-hour, weekly, and monthly limits, but there is no supported way to retrieve historical Go usage using that key.
The local OpenCode database is not a reliable replacement because it is client-local and does not represent server-side accounting, usage from other machines, or the server-side records and counters used to calculate Go limits. The Console already records individual usage entries and displays usage history in the web interface.
A new endpoint such as:
GET /zen/go/v1/usage/history?page=1
Authorization: Bearer <existing-api-key>
could return paginated Go usage records containing the timestamp, model, provider, token breakdown, documented server-calculated usage/cost fields, and session ID. It should return only the authenticated user's Go usage and should not expose prompts, API keys, or data belonging to other users.
This would allow status bars, CLI tools, dashboards, and monitoring integrations to show separate Go usage history and aggregate it by day or model. It would also allow users to track usage across multiple machines and better understand how usage relates to the rolling, weekly, and monthly limits.
This is distinct from #16017 (and it's duplicate, #31084), which covered the current rolling/weekly/monthly Go usage summary and are now closed. This request is specifically for historical usage records.
I'm happy to have a go at an implementation if this is deemed an acceptable feature.
Activity
SpacemanPete commentedon Aug 21, 2026
I would also like to see this feature added.
I just bumped up against my rolling 5 hour cap without warning. I looked into building a VSCodium extension to add the three Opencode Go usage meters from the web dashboard into the bottom bar of the IDE so I can monitor usage during work and switch models as needed to make efficient use of my available cap, but I find out the endpoints aren't there yet.
I hope they'll be added soon.
vulturetone commentedon Aug 21, 2026
@SpacemanPete You can already do what you are looking for - e.g.
What you can see though is that only usage from Zen shows in the "Recent usage" of this plugin. No 'Go' usage history is recorded.
This feature request is specifically for getting historical info. Similar to what
https://opencode.ai/workspace/wrk_<KEY>/usagedoes:SpacemanPete commentedon Aug 21, 2026
@vulturetone
Interesting... Thanks for the feedback. I just started with Opencode two weeks ago so still learning.
How are you able to pull up that usage screen btw? Is that from a VSCode extension? or an OS level integration?
I'm running OC integrated into VSCodium and the
ctrl+pcommand list doesn't show anything related to usage that I can see.I'm running on Linux Ubuntu, so I'm not sure if there are any feature differences between Windows, Mac, and Linux version.
Would love to see those three meters as a slim set of bars in one of these three places. Preferably in the bottom of the VSCode bar, so they're always visible at a glace.
vulturetone commentedon Aug 21, 2026
You should be able to get to that data through the API. I don't know of any plugins for vscode/codium though - sorry.
The current Go quota endpoint is:
Call it with your API key as a Bearer token:
E.g.
curl \ -H "Authorization: Bearer ${OPENCODE_GO_API_KEY}" \ https://opencode.ai/zen/go/v1/usageIt returns the current quota windows, which I think is what you want. You could probably just ask an agent to make you the vscodium extension :)
I use Omarchy. The new version V4/Quattro just came out so there is a massive influx of plugins and this Opencode plugin is one of them. It uses the available endpoints to gather the quota data, but as specified in the main issue, the Go usage history isn't available.
This plugin in particular pulls the data from the local opencode db, which isn't enough for what I need. I use both a separate windows laptop machine with the official opencode cli, and also this machine with pi, which means I can't get the correct data from a single db on a single machine
SpacemanPete commentedon Aug 21, 2026
hehe yeah, the plan was to task an agent to build it =)
good to know i can tap that endpoint, thx for the catch thumbs-up
btw, Omarchy looks pretty dope. I used to be suuuch a sucker for leading edge distros and arch flavors and omarchy looks like a slick package =)
In the end I settled on Ubuntu Studio for the low-latency kernels for music production and so I could spend less time fiddling with my machine and more time working on projects.
Pi looks real interesting. How do you like it compared to opencode?
RayyanMasood commentedon Sep 22, 2026
They replaced the workspace endpoint with "console" and also removed any type of breakdown. Disingenuous people. Before, per usage, I could see a breakdown alongside the total model quota. Now, they have removed it from the console. This is deliberate.
dadofsambonzuki commentedon Sep 30, 2026
Coming at this from the client side, to add a concrete consumer's requirements — plus what I could verify about the current surface.
Who needs it. Omarchy's agents panel (the bar widget that tracks AI coding subscriptions) wants to show OpenCode's per-model usage. Today it cannot, so it does what every other client does: scans local stores — opencode's own
message/session_messagetables, pi/omp transcripts, and, for the machine I tested on, the harness that spent most of the subscription (only part of that account's traffic ran through the opencode CLI). There are currently seven open PRs against Omarchy adding OpenCode collectors to that panel, each hand-rolling its own local-store scan for exactly this reason. One API endpoint would replace all of them.What I could verify on a live Go account.
?group=model(and other parameters) change nothing.GET /zen/v1/models,/zen/go/v1/modelsand/zen/go/v1/usageare the only GETs the public proxy maps (packages/console/app/src/lib/inference-proxy.ts); everything I tried beyond them 404s:subscription,plan,account,me,limits,credits,balance,activity,generations,stats,keys,billing,workspace,organization, on both/zen/v1and/zen/go/v1, plus the/inference/go/v1/*twins.Meanwhile the account clearly knows:
packages/console/core/src/schema/billing.sql.tsstores one row per usage event withmodel,provider,inputTokens,outputTokens,reasoningTokens,cacheReadTokens,cacheWrite5mTokens,cacheWrite1hTokens,cost,keyIDandsessionID, andsubscription.tsderives the three percentages above from an aggregate of it. On my test machine those percentages were 25/29% while the per-model truth (recoverable only from client stores) was 144 calls ondeepseek-v4.1-flash— 21.7M input, 6.09M output, 675M cache-read — plusglm-5.3-flashandkimi-k3. The account has that breakdown; the API hides it.What I'd ask for on the API-key surface, in rough order of how much each unblocks:
GET /zen/go/v1/usage?group=model&window=day. Sinceusagerows carrykeyID, an optional per-key grouping would also let a client separate "what this key spent" from the account total.planType(go/go_plus) alongside the windows would fix that.With (1) alone, the panes of every client — and this issue's original request — become a single GET, and the local-database scans can go away.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed request, @vulturetone! To restate it: you'd like an endpoint authenticated with your existing API key that returns your OpenCode Go usage history, paginated, with timestamp, model, provider, token breakdown, server-calculated usage/cost and session ID. Tools could then show and aggregate Go usage across machines.
The only Go usage endpoint today (
/zen/go/v1/usage) returns just the current rolling, weekly and monthly limits, so this would be a new server-side addition. A plugin can't fill the gap, because the records are kept server-side in the Console.Related issues:
Maintainers will consider this request. Thanks for offering to implement it; it's best to wait for a maintainer to say whether this endpoint fits before starting work.