OpenCode Go: local estimate wins with an API key present, off by 76 points and rendered as "Lasts until reset"

Reproduce the report with codexbar usage --provider opencodego --format json, using the opencode-go entry in ~/.local/share/opencode/auth.json. Trace provider selection and the local/API usage paths to determine why the API path is not used or why it falls back. Done means the selected source and reported windows match the provider usage data, without misleading pace advice.

TL;DR: OpenCode Go reports source: "local" with dataConfidence: "estimated" even though an API key for that provider sits in ~/.local/share/opencode/auth.json. The estimates are off by up to 76 percentage points, and the pace line turns them into advice: the menu bar says "70% in reserve, Lasts until reset" while the account's own usage page shows 81% of the monthly window already spent.

Environment

• CodexBar 0.56.1 (132)
• macOS 26.6.2 (25G83), arm64
• Provider: OpenCode Go, subscribed plan
• ~/.local/share/opencode/auth.json contains an opencode-go entry with "type": "api" and a key present

Observed

codexbar usage --provider opencodego --format json, read at 2026-08-30T15:30:32Z:

{"source":"local","usage":{"dataConfidence":"estimated",
  "primary":  {"usedPercent":0,   "windowMinutes":300},
  "secondary":{"usedPercent":3.9, "windowMinutes":10080},
  "tertiary": {"usedPercent":5,   "windowMinutes":43200}},
 "pace":{
  "secondary":{"stage":"farBehind","deltaPercent":-91,"expectedUsedPercent":95,
               "summary":"91% in reserve | Expected 95% used | Lasts until reset"},
  "tertiary": {"stage":"farBehind","deltaPercent":-70,"expectedUsedPercent":75,
               "summary":"70% in reserve | Expected 75% used | Lasts until reset"}}}

The OpenCode Go usage page, read in the browser minutes apart:

The menu bar popover renders these as "5-hour 100% left", "Weekly 96% left", "Monthly 95% left", under the caption "Quota estimated from local usage history". Refreshing with ⌘R does not change them.

Why the pace line makes this worse

farBehind and "Lasts until reset" are derived from the local estimate, so a window that is 81% spent is presented as 70% in reserve with a reassurance that it will last. A wrong number is visible as a wrong number; a wrong number wearing a verdict is not.

Relation to earlier reports

• #3216, fixed by #3218 and merged 2026-08-26, covered the fraction heuristic misreading whole-percent API values. This install is 0.56.1 and carries that fix, and the shape here is different: the API path is not being taken at all.
• #2982 and #2993 covered auto mode presenting local estimates as authoritative when the cookie cache is empty. The failure mode looks the same, but #3065 since added public usage API support with an API key, and a usable key is present in auth.json. The question is why the local strategy still wins.

What I did not check

I did not call GET /zen/go/v1/usage myself, so I cannot say whether the API returns correct figures for this account or whether CodexBar tried it and fell back. The comparison above is CodexBar's own CLI output against the account's usage page, read minutes apart with no activity in between.