[Bug] OpenCode Go: rolling 5-hour usage shows 100% / "Exhausted Weekly" when opencode.ai reports 1%

[makssiful]

[Bug] OpenCode Go: rolling 5-hour usage shows 100% / "Exhausted Weekly" when opencode.ai reports 1%

Repo: nesszer/Win-CodexBar
Version: v0.46.0 (built 2026-07-30, Windows)
Provider: OpenCode Go (opencodego)
Severity: Medium — false "quota exhausted" state; actual usage is fine

Summary

When the OpenCode Go rolling (5-hour) usage is at exactly 1%, the menu bar shows the 5-hour bar at 100%, labels the provider "Exhausted Weekly", and the Pace widget reports "Far ahead (+79.6%) / Runs out in 0m" — even though the opencode.ai dashboard and the provider's own API both report 1%.

Weekly (15%) and monthly (4%) rows display correctly and match the server exactly, so the web fetch and cookie path are fine. Only the rolling window is wrong.

Expected vs actual

Window	opencode.ai dashboard	CodexBar (Win fork)
Rolling (5h)	1%	100% ❌
Weekly	15%	15% ✅
Monthly	4%	4% ✅
Pace	—	"Far ahead (+79.6%)", "Runs out in 0m" ❌ (derived from bogus 100%)

Reproduction

1. Have an OpenCode Go subscription whose rolling 5-hour usage is exactly 1% (any value ≤ 1.0 in the API response).
2. Run CodexBar v0.46.0 with the OpenCode Go provider enabled (web/Auto mode with a valid opencode.ai cookie).
3. Observe the 5-hour bar at 100% red + "Exhausted Weekly" while opencode.ai shows 1%.

Evidence — live server payload

Authenticated fetch of https://opencode.ai/workspace/{wrk_id}/go (the exact URL the provider scrapes) returns:

rollingUsage:$R[34]={status:"ok",resetInSec:13631,usagePercent:1},
weeklyUsage:$R[35]={status:"ok",resetInSec:53863,usagePercent:15},
monthlyUsage:$R[36]={status:"ok",resetInSec:2334517,usagePercent:4}

usagePercent here is an integer percent (1 = 1%), matching the dashboard. The reset values also match the dashboard countdowns (3h47m / 14h58m / 27d0h at fetch time).

Root cause

rust/src/providers/opencodego/mod.rs, OpenCodeGoProvider::extract_window() (around lines 180–229):

let percent = super::extract_number(&percent_pattern, text);
if let Some(p) = percent {
    let reset = ...;
    // Regex path only matches direct percent field names — fraction
    // heuristic is safe here (upstream #2331). used/limit computed
    // percents must not use this path without a separate gate.
    let p = if (0.0..=1.0).contains(&p) {
        p * 100.0
    } else {
        p
    };
    return Some((p.clamp(0.0, 100.0), reset.max(0)));
}

The <= 1.0 → *100 "fraction heuristic" is applied to the direct usagePercent field on the regex path. The real server sends integer percent (usagePercent: 1 = 1%). The heuristic interprets 1 as the fraction 0.01 and multiplies by 100 → 100%.

• Weekly 15 and monthly 4 are > 1.0, so they pass through untouched — which is exactly why only the rolling bar is wrong.
• The Pace widget and "Exhausted Weekly" label are downstream artifacts of the fake 100% rolling value.

Upstream comparison (why this is a Win-fork regression)

In upstream steipete/CodexBar (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift):

• Regex path (parseSubscription, lines ~437–471): extracts usagePercent directly with no <= 1 scaling. Correctly shows 1%.
• JSON path (parseWindow, line ~779): applies if percentIsDirect, resolvedPercent <= 1.0 { resolvedPercent *= 100 } — where fractions genuinely occur in the JSON shape (upstream tests use usagePercent: 0.25 → 25%).

The Win fork ported the JSON-path heuristic onto the regex path, where the server's serialized $R[...] payload sends integer percent. That mismatch is the bug.

Suggested fix

In extract_window() (regex path), do not scale a direct usagePercent-style field by the <= 1.0 heuristic — mirror upstream's regex path, which treats the value as-is. Keep the heuristic only for fields where the server actually sends fractions, or drop it entirely on this path since the observed $R[...] serialization always uses integer percent (0–100).

Minimal change sketch:

let p = p; // remove: let p = if (0.0..=1.0).contains(&p) { p * 100.0 } else { p };

(Keep the existing clamp to 0..100.)

Related issues (different failure modes, do not close)

• steipete/CodexBar OpenCode Go in auto mode only shows local data; real web usage never gets applied steipete/CodexBar#2543 — "OpenCode Go in auto mode only shows local data" (local DB masks web usage → shows 0% forever; local-first path).
• steipete/CodexBar OpenCode Go Usage calculation incorrect steipete/CodexBar#2551 — "OpenCode Go Usage calculation incorrect" (remaining-quota mismatch from the local estimate).

This issue is distinct: the web path works, but a sub-1% integer rolling value is mis-scaled to 100%, producing a false "exhausted" state. PR #215 ("fix sub-1% usage units") fixed the computed used/limit branch but left the direct-field heuristic, so this survives in v0.46.0.

[github-actions]

Your GitHub account must be at least 30 days old to open issues or pull requests in this repository.

Closing this automatically.

[Finesssee]

Thanks for the issue, I will fix it ASAP. Sorry for the auto closing issue, will fix it as well

[github-actions]

Your GitHub account must be at least 30 days old to open issues or pull requests in this repository.

Closing this automatically.

[makssiful]

Follow-up: live CLI trace (value-dependent repro confirmed)

The bug is threshold-dependent, which makes it easy to miss. Same binary (v0.46.0), same cookie, same fetch path — the only variable is the rolling value crossing the <= 1.0 heuristic boundary.

When rolling usage was 1% (this morning, before filing):

5-hour:  [██████████████████████] 100% used   ← wrong (server said 1%)
Weekly:  [███░░░░░░░░░░░░░░░░░] 15% used     ← correct
Pace:    🚀 Far Ahead (+79.6%) / Runs out in 0m  ← artifact of the 100%

Server payload at that time: rollingUsage:$R[34]={status:"ok",resetInSec:13631,usagePercent:1}

Now that rolling usage is 2% (same session, ~35 min later):

$ codexbar-cli usage --provider opencodego --source web
OpenCode Go (web)
  5-hour:  [░░░░░░░░░░░░░░░░░░░░] 2% used (resets in 3h 34m)
  Weekly:  [███░░░░░░░░░░░░░░░░░] 15% used (resets in 14h 45m)
  Pace:    🐢 Far Behind - will last to reset

Live payload: rollingUsage:$R[34]={status:"ok",resetInSec:12820,usagePercent:2}

Same code path, same web fetch — 2 parses as 2%, 1 parsed as 100%. This is exactly the if (0.0..=1.0).contains(&p) { p * 100.0 } branch in extract_window() firing on an integer percent value. Any user whose rolling usage is at 1% (or below) will see a false "Exhausted" state; the moment it ticks to 2%, everything looks fine.

Repro recipe for maintainers: set up OpenCode Go with a fresh/just-reset 5-hour window so usagePercent is exactly 1, then codexbar-cli usage --provider opencodego --source web.

[github-actions]

Your GitHub account must be at least 30 days old to open issues or pull requests in this repository.

Closing this automatically.

[Finesssee]

yea u can just keep posing in here for follow ups, idk wat is wrong with this weird CI that I have.

[github-actions]

Your GitHub account must be at least 30 days old to open issues or pull requests in this repository.

Closing this automatically.