Skip to content

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

Open
Open
[Bug]: Usage → Limits never reports OpenCode Go for OpenCode 2 Console logins#14983
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@BunBnnuy
BunBnnuy
opened on Oct 3, 2026

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.
Image

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

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.

Image Image

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.

Activity

  1. juliusmarminge commented on Oct 3, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 3, 2026
    Member

    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.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 3, 2026

  3. 0pilatos0 commented on Oct 3, 2026

    @0pilatos0
    0pilatos0
    on Oct 3, 2026

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions