OpenCode Go: support the public usage API with an API key

[akshayprabhu200]

Summary

Use OpenCode Go's public authenticated usage endpoint (GET https://opencode.ai/zen/go/v1/usage) when an OPENCODE_API_KEY is configured, while retaining the existing local-history and cookie-backed paths as fallbacks.

Current behavior

Current main has local and web strategies for OpenCode Go, but no API-key strategy and no reference to the public endpoint. Users with an API key therefore cannot obtain authoritative rolling, weekly, and monthly usage windows through the supported API.

This is distinct from #2982:

• OpenCode Go: auto mode presents local estimates as authoritative when the cookie cache is empty #2982 covered the no-cookie, no-key auto-mode path and was fixed by fix: disclose local OpenCode Go quota estimates #2987.
• This issue covers adding the explicit API-key source published by OpenCode Go.

Expected behavior

• Resolve OPENCODE_API_KEY from provider configuration or the environment.
• Send it only to the fixed OpenCode HTTPS usage endpoint as a Bearer credential.
• Parse rolling, weekly, and monthly percentages and reset times.
• Preserve local daily cost/model history when authoritative API windows are overlaid.
• Preserve the existing cookie-backed path as a compatibility fallback.
• Propagate cancellation and fail soft to established sources on ordinary API errors.
• Never log or include the credential in diagnostics or proof.

Proposed implementation and proof

PR #2879 contains a provider-scoped implementation, deterministic request-contract and fallback tests, documentation, and prior green cross-platform CI. Before merge it should be rebased onto current main and accompanied by redacted authenticated runtime proof from a real OpenCode Go account.

No credentials or personal usage data are included here.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 19, 2026, 12:45 AM ET / 04:45 UTC.

Summary
Keep open: current main still has only local-history and cookie-backed OpenCode Go strategies, while the linked open PR is the concrete candidate implementation. Adding an API-key credential path changes provider authentication behavior and needs sign-off plus real authenticated proof before it can land.

Reproducibility: not applicable. as a bug reproduction: source inspection confirms the requested API-key strategy and endpoint are absent from current main.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should CodexBar add an explicit OpenCode Go API-key usage strategy alongside its existing local-history and cookie-backed sources?	Sponsor the scoped API source: Approve the API-key strategy if the rebased PR proves that the key is sent only to the fixed HTTPS endpoint and preserves the existing fallbacks.

Why: VISION.md requires sign-off for provider-authentication and privacy behavior; the open PR supplies a candidate implementation but does not establish that product decision.

Next step
The open linked PR already owns the implementation; the remaining work is product sign-off, rebase, and contributor-provided real behavior proof.

Review details

Best possible solution:

Retain the local and cookie paths, then land a rebased API-key strategy only after sign-off and a redacted authenticated capture confirms the fixed HTTPS endpoint, fallback behavior, and preserved local history.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a bug reproduction: source inspection confirms the requested API-key strategy and endpoint are absent from current main.

Is this the best way to solve the issue?

Unclear: the linked implementation follows the existing provider strategy pattern, but its new authentication path requires maintainer approval and authenticated runtime proof before it is the confirmed best solution.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The candidate PR changes credential routing and is currently dirty; without a rebase and redacted authenticated runtime capture, its endpoint, fallback, and secret-handling behavior remain unverified on the current base.

Codex review notes: model internal, reasoning high; reviewed against a32989c750e6.

Label changes

Label changes:

• add P2: This is a bounded provider capability request with limited blast radius.
• add impact:auth-provider: The requested behavior adds API-key resolution and provider usage routing.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a bounded provider capability request with limited blast radius.
• impact:auth-provider: The requested behavior adds API-key resolution and provider usage routing.

Evidence reviewed

What I checked:

• Current source selection: The provider exposes only Auto and Web modes, resolving to local and cookie-backed web strategies; no API-key strategy is present. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift:97, a32989c750e6)
• Documented current data sources: Current documentation lists browser cookies, local OpenCode Go history, and the private server-function path, and describes only local/web ordering and overlays. (docs/opencode.md:10, a32989c750e6)
• Current strategy contract: Strategy tests explicitly expect unscoped Auto to use local then web, scoped Auto to use web then local, and explicit Web to contain only the web strategy. (Tests/CodexBarTests/OpenCodeGoProviderStrategyTests.swift:45, a32989c750e6)
• Existing related fix is distinct: The previously merged local-estimate disclosure fix is in v0.51.0; its merge commit concerns confidence labeling rather than this missing API-key source. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift:184, 5dc260879ee3)
• Vision fit: VISION.md supports provider coverage following existing provider patterns, while explicitly requiring sign-off for behavior that affects provider authentication or privacy. (VISION.md:5, a32989c750e6)
• Open implementation candidate: Add OpenCode Go usage API support #2879 is open for this exact API-key source, but its supplied context reports a dirty merge state and no redacted authenticated runtime proof. (2f42b83b74a7)

Likely related people:

• Peter Steinberger: Merged the authoritative OpenCode Go overlay and the later local-estimate disclosure fix; current routing history is concentrated in this area. (role: recent area contributor and merger; confidence: high; commits: b036579b4b05, 5dc260879ee3; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift, docs/opencode.md)
• Aaron: Authored the existing overlay that preserves local history while replacing quota windows with server values, the main compatibility seam for the proposed source. (role: author of authoritative overlay behavior; confidence: high; commits: cf7b74913366; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift, Tests/CodexBarTests/OpenCodeGoWebOverlayTests.swift)
• Ratul Sarna: Introduced the OpenCode Go provider, establishing the original descriptor and provider boundary. (role: introduced provider behavior; confidence: medium; commits: 31bd4812d227; files: Sources/CodexBarCore/Providers/OpenCodeGo)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[dannolan]

Would love to see this happen as I hit my usage limit because I was relying on codexbar's inference (my own stupid fault) and would have paid more attention if this API was supported

[steipete]

Triage: PR #2879 implements exactly this — the public GET /zen/go/v1/usage endpoint behind an OPENCODE_API_KEY, keeping local-history and cookie paths as fallbacks. I'll prioritize reviewing and landing that PR; tracking the request here until it merges.

[steipete]

Shipped: #2879 just merged — OpenCode Go now uses the public GET /zen/go/v1/usage endpoint when OPENCODE_API_KEY is configured (settings, provider config, or environment), with local history and cookie paths as fallbacks. Ships in 0.54.1.