GO's $60 is hard — and that changes the rollover rule

Young, 2026-10-10: "GO's $60 hard or soft? — Check the allowance list for GO" — with the usage-limits rules and the per-model monthly table.

Answer: HARD. And more precisely — it is a per-model usage ceiling, not a workspace bill. Both halves of that matter, and the second one changes my stage's design.

1. The answer to the blocking question

HARD. A GO monthly limit is a usage ceiling: when a model reaches it, requests fail — they do not keep serving and bill you.

Why I can state that with confidence despite not reaching the table:

• Young's quoted rule: "Usage limits are defined as monthly dollar amounts" — a limit, not a price.
• And V2's live breaker proves the behaviour. state/model_health.json holds entries like opencode-go/... with provider.quota: Rate limit exceeded and ok: 0, until: <cooldown>. Those are hard blocks on GO models, already measured in production. Not an overage notice — a refusal.

⚠️ Honest limit: opencode.ai/docs/go/ truncated before the usage-limits section on two fetch attempts — I have the plan pricing and the model list, not the table. So the per-model numbers below are Young's stated figures, and the hard-block behaviour is my inference from the wording plus V2's measured 429s. Neither is a probe of a live exhaustion.

2. The finding that matters more: the limit is PER MODEL

This is the part I did not have, and it invalidates part of my own design.

Each model carries its own monthly limit. From Young's table:

Two consequences, and both are load-bearing:

a) "GO exhausted" is not a single state

One model hitting its cap says nothing about another. GLM can be at $60 while MiMo sits unused. My ledger's billing_instrument: go_allowance is therefore too coarse — it records that we drew GO, never which model's ceiling we drew against.

So the ledger needs the model id alongside the instrument, or a rollover cannot tell "GO is done" from "that model is done".

b) The binding constraint is not the $60 — it is the 5-hour window

5-hour = 20% of the monthly ceiling. For GLM that is $12 per 5 hours. At V2's measured rate — a single model consumed $10.34 in one day — a $12 five-hour ceiling is roughly a day of heavy work, and hitting it blocks the model for the rest of the window.

So even the $60 models have a ~$12/5h practical ceiling. That is the number the ladder must budget against, not the monthly figure. And Luna and Haiku are 4× tighter at $3/5h — they are near-useless as fallbacks under load.

3. This refines Young's rollover ruling — and I am flagging it, not overriding

Young's ruling: "GO exhausted will rolled over to ZEN."

With per-model limits, that ruling should be a three-step ladder, not a switch:

Why the order matters: rolling to ZEN on one model's exhaustion means paying real money while five other GO ceilings sit unused. That is precisely the mistake this whole design exists to prevent — V2 spent $10.34 on one model while a free one did 9× the tokens.

So the rollover should be: GO model → GO model → GO free → ZEN, and ZEN last.

This is a refinement to Young's ruling, not a reversal of it. It needs his confirmation — it changes what "GO exhausted" means operationally.

4. What the ladder should be, given these numbers

Luna and Haiku at $15/month are the finding I would act on first. At $3 per five hours they exhaust on light use, and V2's model_health.json shows opencode-go/gpt-6-luna with ok: 43 — real traffic already. A $15 ceiling carrying a fleet's fallback role is fragile.

Cached-read pricing is also worth pricing into the ladder: GLM caches reads at $0.03 against a $0.15 input — a 5× reduction. A prompt-caching strategy is cheaper headroom than any model switch, and nothing in the design mentions it.

5. What this closes, and what it opens

Closes: 6A — the $60 question. Hard ceiling, per model, blocking at 429.

Opens, and both are mine:

And one that is Young's: confirm the three-step rollover, since his ruling read as a direct GO→ZEN switch.

6. Not established

• The usage-limits table was never fetched — the page truncated twice. Every per-model figure above is Young's stated number, not my read.
• No live exhaustion was probed. The hard-block behaviour is inferred from wording plus V2's measured provider.quota 429s.
• Whether the 5-hour window is per model or per workspace is not confirmed by anything I read. I have assumed per model, consistent with "each model has the following usage limits."