[Bug]: Usage → Limits never reports OpenCode Go for OpenCode 2 Console logins

[BunBnnuy]

What happened

Usage → Limits shows only Codex. My OpenCode Go session/weekly/monthly windows never
appear, even though the subscription is active and OpenCode runs locally. The OpenCode
Console shows 2% / 36% / 22% used for the same account.

This is the case deferred in #11783 ("if this is still an issue once V2 lands, please
reopen or open a fresh PR against the new code"). V2 has landed (#14871), so I'm filing
it against the V2 code.

Diagnosis

• The capability exists and is documented: docs/user/usage.md says "OpenCode Go
  reports its session, weekly, and monthly allowance when OpenCode runs locally in the
  environment." No API-key condition is documented. docs/user/providers-opencode.md
  supports OpenCode 2.0.18+, and [IMPORTANT] Moving from T3 Code Orchestrator V1 to V2 #14871 requires 2.0.18+ for V2.
• readOpenCodeGoUsageLimits resolves credentials from auth.json ("opencode-go" →
  { type: "api", key }) or OPENCODE_API_KEY only.
• OpenCode 2 stores a Console login in its SQLite store (opencode.db → credential,
  integration_id = 'opencode', { type: "oauth", access, metadata: { orgID, ... } }),
  not in auth.json.
• With no resolved credential the probe publishes
  unavailable: { reason: "unsupported" }. The pooled Limits view filters those accounts
  out, so there is no row and no notice.
• Not a V2 regression: the credential-resolution logic is unchanged from V1; it is a
  coverage gap in the existing feature.

Steps to reproduce

1. OpenCode 2.0.22, signed in through the OpenCode Console. No opencode-go entry in
   auth.json, no OPENCODE_API_KEY.
2. T3 Code V2, local OpenCode instance (Server URL empty), provider enabled, refresh
   provider status.
3. Open Usage → Limits.
4. Only Codex appears; the OpenCode Go windows never do.

Version

0.0.46-preview.20261002.2598

Environment

Windows 11 Pro (10.0.26200), x64; OpenCode 2.0.22 (@opencode/cli), local instance.

Evidence

• Before (installed preview build): Usage → Limits shows only Codex, no OpenCode section
  and no notice. [screenshot]
• Expected values, local prototype: Go · Session 98% left, Go · Weekly 64% left,
  Go · Monthly 78% left. [screenshot — local build of main @ 8ed276c246b6 plus a local
  patch, not a shipped build]
• OpenCode Console (Zen/Go): Rolling 2% used, Weekly 36% used, Monthly 22% used.
  [screenshot] Used% + left% = 100 for all three windows; reset times match
  (3h 32m / 1d 21h / 21d 18h).
• With the prototype, server.trace.ndjson shows
  GET https://opencode.ai/console/api/go/status → 200. That is an internal Console
  endpoint, not a documented public API.
• opencode --version = 2.0.22; auth.json contains no opencode-go entry.

Related issues

• [Bug]: Limits bar labels pooled accounts by number, so accounts cannot be told apart #11880 — Claude account "silently marked unsupported" in Limits; same failure shape,
  different provider.
• feat(usage): report OpenCode history and Go quota #11783 — earlier OpenCode history + Go quota PR, closed pending V2.
• feat(usage): show OpenCode Go, Cursor, and Grok subscription limits #12115, fix(shared): merge OpenCode Go limits by credential #14209 — current implementation reads an API key from auth.json/env.
• [IMPORTANT] Moving from T3 Code Orchestrator V1 to V2 #14871 — V1→V2 migration.

Direction

Is the Console-login configuration intended to be covered by the documented behavior?

• If yes, which mechanism would you prefer: reading the OpenCode 2 credential database
  plus the Console status endpoint (internal/undocumented), requiring/documenting an API
  key for limits, or an upstream/OpenCode-provided endpoint?
• If no, would you accept a documentation fix stating that Limits requires an API key?

I have a local prototype for the first option but have not opened a PR without direction.
Happy to move this to Ideas if Console-login support is out of scope.

Fix applied or workaround

Nothing was changed on the reporting install. Today, limits on main require a Go API key
in auth.json or OPENCODE_API_KEY; that is the only working path.

Filed by

deepseek-v4.1-flash (OpenCode) in T3 Code — in-thread machine investigation, not
npx t3 triage.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the careful write-up, @BunBnnuy. We confirmed this on main at 8ed276c246. With local OpenCode and a Console login, Usage → Limits shows no Go row and no notice. That's a gap in what the existing probe covers, not a V2 regression.

What the probe reads today: readOpenCodeGoUsageLimits in apps/server/src/provider/Layers/openCodeUsageLimits.ts only runs for an enabled instance with an empty Server URL. It looks for an opencode-go entry of the form { type: "api", key } in $XDG_DATA_HOME/opencode/auth.json (or ~/.local/share/opencode/auth.json, found through USERPROFILE on Windows), and falls back to OPENCODE_API_KEY. If there's no key, or https://opencode.ai/zen/go/v1/usage returns a 403, it reports unavailable: { reason: "unsupported" }. collectLimitNotices in packages/shared/src/usageLimits.ts and the account pool both skip unsupported accounts, so only providers that returned windows show up.

Why a Console login is missed: OpenCode 2 stores new credentials in the credential table of opencode.db and doesn't write them back to auth.json. A Console login is an OAuth token under integration_id = 'opencode', and a pasted Go API key is a separate opencode-go row. The probe reads neither. The API-key path shipped in #12115 (merged), and #14209 (merged) only changed how those snapshots get merged. The earlier PR #11783 was closed without merging because it touched the provider layer during the V2 rewrite, not because Console-login limits were deliberately deferred. The V2 migration (#14871) doesn't change this probe, and #11880 is a separate Limits bug about accounts being labeled by number.

Docs: docs/user/usage.md says local OpenCode reports the session, weekly, and monthly windows, and it doesn't mention needing an API key, so the docs promise more than the probe does.

Possible fixes: there are two separate changes here.

1. Read an opencode-go API key from the SQLite credential table and keep calling https://opencode.ai/zen/go/v1/usage. That's the feat(usage): show OpenCode Go, Cursor, and Grok subscription limits #12115 behavior, pointed at the store OpenCode 2 actually uses.
2. Support Console OAuth logins, which have no Go API key. The only route found is GET https://opencode.ai/console/api/go/status, which is an undocumented Console endpoint. Please hold off on a PR for this one until a maintainer decides whether it's in scope.

Workaround for now: set OPENCODE_API_KEY, or add { "opencode-go": { "type": "api", "key": "..." } } to the auth.json path above. Note that a Zen key without a Go subscription will still stay hidden.

We're leaving this open as a bug. It's still a maintainer decision whether Console logins are in scope, or whether only the SQLite key read is and the docs should say Limits needs a Go API key.

[0pilatos0]

Same on macOS arm64 (Darwin 27), T3 Code desktop 0.0.46-nightly.20261003.2610, OpenCode 2.0.22 running locally, Server URL empty. No auth.json; the provider status cache had usage limits unavailable: unsupported, and Limits showed no OpenCode row.

Workaround that works without a key file: add OPENCODE_API_KEY (a Go API key, marked sensitive) under Settings → Providers → OpenCode → Environment variables. The Go session, weekly and monthly windows appear after a refresh. Might be worth documenting until T3 can read OpenCode 2's credential store.

via t3 triage, Claude Opus 5.5 in Claude Code