Go subscription: HTTP 429 outage on 2026-09-06 (multi-hour retry-after) — compensation requested

Summary

Paying OpenCode Go subscriber. On 2026-09-06 the Go endpoint
https://opencode.ai/zen/go/v1/messages returned HTTP 429 for an extended
period, making the paid Go service unusable. This report focuses on that
service outage and the compensation it warrants.

Environment

OpenCode version: 1.18.29
OS: CachyOS (Arch-based), Linux kernel 7.2.2-1-cachyos
Terminal: xfce4-terminal

Steps to Reproduce

Use the opencode-go provider (e.g. opencode run --model opencode-go/qwen3.8-flash "ok").
Observe the request to https://opencode.ai/zen/go/v1/messages returning HTTP 429.

Expected behavior

A paying subscriber should be able to use the Go service normally; the 429
should only occur after genuinely exceeding the sliding limits.

Actual behavior

39 HTTP 429 responses logged on the Go endpoint on 2026-09-06.
Each returned a retryAfterMs of ~37 626 000 → 48 533 000 ms (~10.5 h → 13.5 h), resetting on each attempt.
The free Zen models (e.g. Big Pickle) worked instantly during the same period → the fault is specific to the Go endpoint, not my network/auth/config.
On 09-06, 10 Go sessions were recorded at 0.00 $ (blocked attempts, no usable output).

Impact

The paid Go service was effectively unavailable for the duration of the 429
block on 2026-09-06. This is the basis of the compensation request below.

Request

Given the Go service was down for an extended period on 2026-09-06 (repeated
429s with multi-hour retry-after, while free Zen models worked), please grant
compensation for the lost paid service time (credit/extension on the Go
subscription).

Full log excerpts and the opencode.db aggregate are available on request;
happy to share details privately.

@laurentm28

This issue might be a duplicate of an existing issue from the same author. Please check:

Go : 429 quotidiens malgré une conso locale faible, sessions abortées — client ne révèle pas la vraie proximité du plafond #47598: Filed earlier today by the same author (@laurentm28) describing the same problem — Go subscription receiving HTTP 429 with multi-hour Retry-After values despite low reported usage.

If #47613 is a follow-up or refinement of #47598, please consider adding the additional details there rather than opening a separate issue, and closing this one.

Other potentially related issues:

FreeUsageLimitError persists 10+ days on deepseek-v4-flash-free even for minimal requests — while other free models work #42977: Persistent rate-limit errors on Go/free models despite low usage
Go subscription active but still "Free usage exceeded" — paid, no access #36265: Go subscription active but still hitting usage caps

Evidence: server-side usage counter does NOT match local usage

Additional info from the user's Go dashboard today (2026-09-06 15:37 CEST):

Window	Server dashboard	Local tracked (from `opencode.db`)
5 h	61.3 % (~$7.4 / $12)	$1.85 (~15 %)
Week	100 % — limit reached, reset in 10 h 24 min	$8.38 total over 30 days
Month	reset in 26 d 4 h	$8.38 (all sessions ever)

The dashboard's "5 hours" counter shows ~4× the total actually recorded locally.
Total cost of all sessions on this machine since install: $8.38 — far below the $30 weekly limit, yet weekly usage shows 100 %.
No background/headless process on this machine; only the interactive opencode session itself.
The user mostly uses the free Zen models (Big Pickle etc.) — free requests appear to be counted as paid Go usage on the dashboard. This seems like the root cause: free/zero-cost requests inflating the Go usage counters.

A weekly limit resetting after only 10 h is also not consistent with a 7-day rolling window.

Please investigate the counter. Happy to provide more details (logs, timestamps) on request. The compensation request for the blocked days still stands if this is confirmed as a billing/counter bug.

Concrete usage data (all sessions since subscription, mixed free+paid models)

Local tracked usage since install (all models together):

45 sessions, $8.38 total
1,696 LLM calls
cache-read: 111 M tokens (dominant), cache-write 2.3 M, input 4.1 M, output 0.9 M

Daily: 09-02: $0.73 (394 calls) | 09-03: $0.13 (66) | 09-04: $0.05 (47) | 09-05: $5.25 (863) | 09-06: $2.22 (326)

The dollar spend can NEVER reach the $30 weekly limit. The 111M cache-read tokens and 1,696 calls come overwhelmingly from the FREE Zen models (Big Pickle) I use for most of my work. If the Go usage counter counts free/Zen model traffic (esp. cache-read) against the paid Go limits, that fully explains the false "100% weekly" — and it's wrong: free model usage should not consume a paid subscription budget.

Full evidence bundle

1. Live HTTP 429 logs (today 2026-09-06) — `~/.local/share/opencode/log/opencode.log`

2026-09-06T12:08:26.652Z [sticky-retry] POST https://opencode.ai/zen/go/v1/messages status=429 retryAfterMs=42694000
2026-09-06T12:09:26.806Z [sticky-retry] POST https://opencode.ai/zen/go/v1/messages status=429 retryAfterMs=42634000
2026-09-06T12:20:47.191Z [sticky-retry] POST https://opencode.ai/zen/go/v1/messages status=429 retryAfterMs=41953000
2026-09-06T12:21:47.166Z [sticky-retry] POST https://opencode.ai/zen/go/v1/messages status=429 retryAfterMs=41893000
2026-09-06T13:32:54.809Z [sticky-retry] POST https://opencode.ai/zen/go/v1/messages status=429 retryAfterMs=37626000
2026-09-06T13:33:55.106Z [sticky-retry] gave up after 2 attempts status=429

retryAfterMs ~42.6 M → ~38 M ms = 11–12 h reset, shrinking slowly.
This repeats all day, every day → the "weekly limit" counter effectively never resets to usable.
The dashboard message is: "weekly usage limit reached. It will reset in 10 hours 27 minutes" — a <12 h reset is not a weekly (7-day) rolling window.

2. CLI proof that GO is down / free models work

$ opencode run --model opencode-go/qwen3.8-flash "reponds juste: OK"   → EXIT=124 (timeout 90 s, no response, 429 in log)
$ opencode run --model opencode/big-pickle  "reponds juste: OK"        → OK, EXIT=0 (instant)

Same key, same network, same moment → only the Go endpoint fails.

3. Dashboard (screenshot OCR, 2026-09-06 15:37)

Utilisation sur 5 heures      61.3%   (R): 22 minutes
Utilisation hebdomadaire      100%    (R): 10 heures 24 minutes
Utilisation mensuelle                 (R): 26 jours 4 heures

4. Local SQLite truth (`opencode.db`) — all 45 sessions since install

5h window   = 0.00 USD (at check time; ~1.85 USD earlier, far below 12 USD)
week window = 8.38 USD (limit 30 USD)
all time    = 8.38 USD  <-- EVERYTHING EVER, all models mixed
tokens      = 5,272,745 (in+out+reasoning)
cache_read  = 111,580,592 tokens

Daily: 09-02 $0.73 | 09-03 $0.13 | 09-04 $0.05 | 09-05 $5.25 | 09-06 $2.22

5. Conclusion (engineering)

Dollar spend can never hit the $30 weekly budget locally.
The enormous 111 M cache-read tokens / 1,696 calls come overwhelmingly from the free Zen models (Big Pickle).
If the Go counter charges free/Zen model traffic (especially cache-read) against the paid Go limits, that fully explains the false "100% weekly" and the 429 wall.
A weekly counter resetting in <12 h is itself a red flag.

Request: correct the counter so free-model traffic does not consume the paid Go budget, restore access, and honor the 3-day compensation.

Compensation request (final, honest)

Usage history since Go subscription started (sessions with successful output):

Date	Sessions (cost>0)	Cost	429 events on that day
09-02	6	$0.73	89
09-03	2	$0.13	—
09-04	4	$0.05	—
09-05	9	$5.25	14
09-06	5	$2.22	45

The first 429 appeared already on 2026-09-02 (89 that day) — the day usage started. Go has been throttled from essentially day 0.
Only 33 paid sessions ever succeeded (total $8.38) spread over ~5 days; the rest of the time the endpoint returned 429 with a 11-12 h retry-after.
Real usable time since subscribing ≈ 1 day max, and that alone explains why I mostly work on the free Zen models.

My request, transparently:

Preferred: grant the 3-day extension/credit on my Go subscription for the blocked days, AND fix the counter so free/Zen model traffic doesn't consume the paid Go budget.
If the blocked days aren't considered warrantable: since the paid service was effectively unusable for the large majority of my subscription period, provide a full refund of the Go subscription.

Either way, please acknowledge and fix the counter issue. Happy to provide anything else needed (exact invoice dates, full log excerpts).

Not alone: same bug reported by multiple users

Other open issues with the exact same symptom (Go quota shown 100% / limit reached while actual spend is far below):

Weekly usage limit reported as exhausted while rolling 5h limit never reached #38856, Weekly usage limit reported as exhausted while rolling 5h limit never reached #38855 (2026-07-25): "Weekly usage limit reported as exhausted while rolling 5h limit never reached"
Bug Report: 5‑hour rolling quota incorrectly hits 100% while actual USD spend is far below limit #42549 (2026-08-14): "5-hour rolling quota incorrectly hits 100% while actual USD spend is far below limit"
Go quota shows 100% exhausted but visible usage is only ~$20 #38936 (2026-07-26): "Go quota shows 100% exhausted but visible usage is only ~0"
Weekly usage quota stays maxed out (100%) even after the new monthly billing cycle starts, blocking usage despite ample monthly budget #47614 (2026-09-06): "Weekly usage quota stays maxed out (100%) even after the new monthly billing cycle starts"
weekly limit reached problem #47042, Go subscription usage issue #43206 (closed): same symptoms

This confirms a server-side counter/rate-limit bug affecting multiple subscribers, not an account-specific issue. Please treat the counter fix and the compensation request accordingly.

Revised compensation request — all blocked days, not just 3

Given the evidence (Go throttled from day 1: 429 already on 2026-09-02, and only ≈1 usable day out of the subscription period so far), I'm revising my request:

Primary: extend/credit my Go subscription for every day it was blocked/limited since the start of this issue — i.e. from 2026-09-02 until the counter is fixed and Go is usable again (days will keep accumulating until resolved). This replaces the earlier "3 days" figure.
Alternative: refund the subscription pro rata for all unusable time, or in full if the unusable share ends up being the majority of the period (which is currently the case: ~1 usable day out of 5).

I'll track the blocked period with the logs until a fix is confirmed. Thanks for handling this fairly.

Follow-up with hard evidence: the Go usage counter does not match real usage

Since opening this, the Go dashboard (opencode.ai/go) shows monthly usage at 50 % (~30 $ / 60 $), while 5 h and weekly both sit at 0 %. Given the state of my account during this window, this is impossible — and it's the clearest proof that the fault is server-side, not on my side.

What actually happened (from opencode.db, opencode's own session.cost):

Date	Go messages	Recorded Go cost
09-02	235	0.63 $
09-03	49	0.13 $
09-04	47	0.05 $
09-05	573	3.59 $ (the one productive day)
09-06	147	0.99 $
09-07	26	0.05 $

Total recorded Go spend: ~5.43 $ (≈ 9 % of the 60 $ monthly allowance) — not 30 $.
On 09-06 (the day the 429s started) there are 10 sessions with a recorded cost of 0.00 $ (empty, blocked attempts).
The log contains 319 HTTP 429 responses and 277 "rate limit exceeded" entries, all on https://opencode.ai/zen/go/v1/messages, each returning a retryAfterMs of ~42,000,000 ms (~12 h) that keeps resetting.

Conclusion: a counter reporting ~30 $ of consumption for a window in which I was receiving 429s most of the time — while the free Zen models worked instantly in parallel — can only be a server-side metering/billing error. The usage shown as billed but never actually delivered must not be charged to my account.

Updated request:

Correct the Go usage meter — the ~30 $ / 50 % shown is not attributable to real, delivered usage.
Compensate the ~3 days of unusable service (as originally requested) — an extension/credit, and reverse any usage recorded during the blocked window.

Logs/timestamps and the opencode.db aggregate available on request; happy to share the exact log excerpts privately (billing-related).

Correction — chiffres 429 précisés (endpoint Go uniquement)

Je corrige mon commentaire précédent pour être strictement exact (en contentieux, une valeur gonflée n'aide pas) :

Le chiffre « 319 HTTP 429 » que j'ai donné incluait aussi les 429 du endpoint Zen gratuit (opencode.ai/zen/v1/chat/completions) et du provider Mistral.

Comptage précis, endpoint Go uniquement (https://opencode.ai/zen/go/v1/messages) :

Mesure	Valeur
Réponses HTTP 429 sur le endpoint Go	39
Marqueurs `retryAfterMs` sur le endpoint Go	44
`retryAfterMs` observés	37 626 000 → 48 533 000 ms (~10,5 h → 13,5 h)

Le point clé reste inchangé et est même renforcé : les 429 sont bien spécifiques au endpoint Go (les modèles Zen gratuits répondaient instantanément en parallèle), et le compteur mensuel affiche 50 % (~30 $) alors que le coût enregistré localement (session.cost) n'est que de ~5,47 $ sur la même fenêtre.

Méthode de comptage (reproductible) :

grep -a "status=429" "$LOG" | grep -c "zen/go/v1/messages"   # 39
grep -a "retryAfterMs" "$LOG" | grep -c "zen/go"             # 44

Dossier complet de preuves disponible sur demande.

Full evidence bundle — for cross-checking against server-side data

Here is everything needed to compare with your own server-side records. All figures are reproducible from the files below.

Environment: opencode 1.18.29 · CachyOS (Arch) · xfce4-terminal · account laurentm28.

1. Recorded spend per day — from opencode.db, opencode's own session.cost field, provider opencode-go:

Date	Recorded cost ($)
2026-09-02	0.63
2026-09-03	0.13
2026-09-04	0.05
2026-09-05	3.59
2026-09-06	0.99
2026-09-07	0.14
Total	5.53

Query: SELECT date(time_created/1000,'unixepoch'), round(SUM(cost),4) FROM session WHERE json_extract(model,'$.providerID')='opencode-go' GROUP BY 1 ORDER BY 1;

2. HTTP 429 on the Go endpoint — https://opencode.ai/zen/go/v1/messages:

Date range of 429s on the Go endpoint: from 2026-09-05T20:24:11Z through 2026-09-06.
40 retryAfterMs markers on 2026-09-06, ranging 37 626 000 → 51 105 000 ms (~10.4 h → 14.2 h), re-arming each time.

Log line format:

timestamp=2026-09-06T13:32:54.809Z ... url=https://opencode.ai/zen/go/v1/messages method=POST status=429 attempt=1 ... retryAfterMs=37626000
timestamp=2026-09-06T13:33:55.106Z level=WARN ... url=https://opencode.ai/zen/go/v1/messages method=POST status=429

Counts: grep -a "status=429" "$LOG" | grep -c "zen/go/v1/messages" and grep -a "retryAfterMs" "$LOG" | grep "zen/go" | grep -c "2026-09-06".

3. Blocked (no-output) sessions on 2026-09-06 — 10 sessions with recorded cost 0.00 $:
SELECT count(*) FROM session WHERE json_extract(model,'$.providerID')='opencode-go' AND cost=0 AND date(time_created/1000,'unixepoch')='2026-09-06';

4. Token volumes (why the bill diverges) — GO assistant messages, all time:

cache read: 72.58 M tokens
cache write: 2.33 M
input: 1.55 M · output: 0.57 M

The cache-read volume is the dominant cost driver in these agentic sessions. If your server-side meter prices cache reads differently from the local session.cost estimate, that explains a large part of the gap between the dashboard figure and the recorded spend.

5. Dashboard reading (2026-09-07 06:42 CEST) — screenshot saved locally:

5 h: 0 % · Weekly: 0 % · Monthly: 50 % (~30 $ / 60 $), reset in 25 d 13 h.

Given the recorded spend above is 5.53 $ over the same window, a 50 % monthly reading (~30 $) does not match the locally recorded usage. Please compare this against your own metering records.

All source files are retained locally for verification. I'm happy to share the raw opencode.log excerpts and opencode.db aggregates privately (billing-related) if helpful.

Direct comparison — server dashboard vs local recorded spend (same windows, 2026-09-07 06:42)

Local recorded spend (provider opencode-go, from session.cost in opencode.db), computed over exactly the same sliding windows as the dashboard:

Window	Dashboard (server)	Local recorded	Difference
5 h	0 % (0 $ / 12 $)	0.005 $ (2 sessions)	consistent
Weekly	0 % (0 $ / 30 $)	5.39 $ (30 sessions)	server says 0, PC records 5.39 $
Monthly	50 % (~30 $ / 60 $)	5.39 $	server shows ~5.5× the recorded spend

Two contradictions on the same month window:

Weekly shows 0 % even though 5.39 $ of real usage is recorded in that window (all sessions are from this week).
Monthly shows ~30 $ / 50 % while the same local data records 5.39 $.

A server meter that reads too low on the weekly window and too high on the monthly window in the same snapshot is not attributable to client-side usage. Please reconcile against your own billing records.

TL;DR — your meter is counting ~5.5× more than the real consumption.

Real consumption recorded by opencode (session.cost, provider opencode-go, all sessions since subscription): 5.39 $.
Your dashboard monthly meter shows: ~30 $ / 50 %.
Ratio: 30 / 5.39 ≈ 5.56× over-counted.

Same windows, same account, same period. A 5.5× inflation of the paid-service meter is precisely what we'd expect to see if blocked/retried or non-delivered requests were being billed as if consumed. That would be wrong: HTTP 429 responses delivered no model output (10 sessions that day recorded 0.00 $), yet they appear to have been counted.

Please audit the Go metering pipeline against the actual completed (status=200) requests. Happy to provide the raw logs privately.

@fwang

@fwang — quick bump with fresh evidence from this morning (2026-09-07), same account, all figures reproducible from opencode.db on this machine:

Server dashboard (opencode.ai/go) today:

Window	Dashboard	Local recorded (`session.cost`, provider `opencode-go`)
5 h	0 % (0 $ / 12 $)	0.02 $
Weekly	0 % (0 $ / 30 $)	2.22 $
Monthly	51.4 % (~30.8 $ / 60 $)	2.22 $ over 30 d / 5.40 $ total since subscription

The monthly counter sits at ~30 $ while BOTH the 5h and weekly windows read 0 %. These three meters are supposed to be consistent — only a server-side overcount explains a 30 $/month figure when no sessions used Go this window. Ratio stays ≈ 5.5–5.7× vs. the real number opencode itself recorded (session.cost).

This matches the pattern already reported in linked issues: #47598, #47614 (weekly stuck at 100 %), #42977, #38855, #42549. Blocked/retried requests showing HTTP 429 deliver no model output and should not be billed — yet the meter keeps climbing.

Since subscription start (09-02), the Go endpoint has been throttled almost every day (39 Go-only 429 on 09-06 alone). This is affecting a paying subscription. An update on the counter fix and the compensation request (outstanding since 09-06) would be much appreciated.

FR — Je sais quil
est
très
tôt
chez
vous,
mais
pourriez-vous
regarder
mon
problème
?
Merci
davance. Bonne journée à vous.

EN — I know it is very early for you, but could you please take a look into my issue? Thanks in advance. Have a nice day.

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Navigation Menu

Repository navigation

Go subscription: HTTP 429 outage on 2026-09-06 (multi-hour retry-after) — compensation requested #47613

Summary

Environment

Steps to Reproduce

Expected behavior

Actual behavior

Impact

Request

Evidence: server-side usage counter does NOT match local usage

Concrete usage data (all sessions since subscription, mixed free+paid models)

Full evidence bundle

1. Live HTTP 429 logs (today 2026-09-06) — `~/.local/share/opencode/log/opencode.log`

2. CLI proof that GO is down / free models work

3. Dashboard (screenshot OCR, 2026-09-06 15:37)

4. Local SQLite truth (`opencode.db`) — all 45 sessions since install

5. Conclusion (engineering)

Compensation request (final, honest)

Not alone: same bug reported by multiple users

Revised compensation request — all blocked days, not just 3

Follow-up with hard evidence: the Go usage counter does not match real usage

Correction — chiffres 429 précisés (endpoint Go uniquement)

Full evidence bundle — for cross-checking against server-side data

Direct comparison — server dashboard vs local recorded spend (same windows, 2026-09-07 06:42)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Go subscription: HTTP 429 outage on 2026-09-06 (multi-hour retry-after) — compensation requested #47613

Description

Summary

Environment

Steps to Reproduce

Expected behavior

Actual behavior

Impact

Request

Activity

github-actions commented on Sep 6, 2026

laurentm28 commented on Sep 6, 2026

Evidence: server-side usage counter does NOT match local usage

laurentm28 commented on Sep 6, 2026

Concrete usage data (all sessions since subscription, mixed free+paid models)

laurentm28 commented on Sep 6, 2026

Full evidence bundle

1. Live HTTP 429 logs (today 2026-09-06) — ~/.local/share/opencode/log/opencode.log

2. CLI proof that GO is down / free models work

3. Dashboard (screenshot OCR, 2026-09-06 15:37)

4. Local SQLite truth (opencode.db) — all 45 sessions since install

5. Conclusion (engineering)

laurentm28 commented on Sep 6, 2026

Compensation request (final, honest)

laurentm28 commented on Sep 6, 2026

Not alone: same bug reported by multiple users

laurentm28 commented on Sep 6, 2026

Revised compensation request — all blocked days, not just 3

laurentm28 commented on Sep 7, 2026

Follow-up with hard evidence: the Go usage counter does not match real usage

laurentm28 commented on Sep 7, 2026

Correction — chiffres 429 précisés (endpoint Go uniquement)

laurentm28 commented on Sep 7, 2026

Full evidence bundle — for cross-checking against server-side data

laurentm28 commented on Sep 7, 2026

Direct comparison — server dashboard vs local recorded spend (same windows, 2026-09-07 06:42)

laurentm28 commented on Sep 7, 2026

laurentm28 commented on Sep 7, 2026

laurentm28 commented on Sep 7, 2026

thdxr commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. Live HTTP 429 logs (today 2026-09-06) — `~/.local/share/opencode/log/opencode.log`

4. Local SQLite truth (`opencode.db`) — all 45 sessions since install