Consolidated. This note's findings now live in ../MIN-STUDIES.md §4, 5. The original is kept for its measurements; do not re-derive from it.

GO's allowance: soft, with a documented fallback — and the model list

Young, 2026-10-10: "GO's $60 hard or soft? — Check the allowance list for GO" plus the full model table, the free lists for both endpoints, and the enabled ZEN models.

Answer first: GO is SOFT. It does not block — it falls back to the ZEN balance once a limit is reached. And the docs say it in one sentence.

1. ✅ Hard or soft — SOFT, and it is a per-model allowance

"If you also have credits on your Zen balance, you can enable the Use balance option in the console. When enabled, Go will fall back to your Zen balance after you've reached your usage limits instead of blocking requests." — opencode.ai/docs/go § Usage beyond limits

"Instead of blocking requests" is the whole answer. The guard is soft, so it escalates, not blocks — which is the behaviour Mira's Stage 6 gate needs.

🔴 And the $60 is NOT a single number — it is PER MODEL

This is the correction that matters. Young's table and the live docs both show each model has its own monthly limit:

So "the $60" is the GLM/MiMo/Muse allowance — and a model's allowance is consumed at that model's own token prices. Two models at $60 with different prices give different amounts of work. (Why some are lower: "for some models, we haven't had the opportunity to negotiate a discount" — it is a bulk-discount pass-through, not a tier difference.)

The window rule applies per model

"Each model has the following usage limits: 5-hour — 20% of the monthly limit; weekly — 50%; and monthly — 100%."

So per model: 5-hour = 20% of that model's limit, weekly = 50%, monthly = 100%. The 5-hour window still binds first.

2. Token efficiency — which of the chosen models gives the most work

Young's criterion: "models that give us more tokens or help our agents complete tasks better." Computed from the published prices:

If the whole allowance went to one side of the bill (M tokens):

On a realistic agent mix (85% cached read, 10% fresh input, 5% output — a coding agent re-reads its context constantly):

The ranking, and the surprising result

The finding worth acting on: Muse Spark 1.2 Contributor is ~3× more work per allowance than GLM-5.3-Flash — at $0.10/$0.20 vs $0.15/$0.50 — and it is not in our current config. Its caveat is in the docs: "(limited regions)".

And the limit dominates the price. Qwen3.8 Flash is cheaper per token than GLM-5.3-Flash on input but its $30 limit means less total work. So the selection rule is not "cheapest token" — it is "limit ÷ price".

3. ⚠️ A correction to Young's free-model list — verified live

The live ZEN model list differs from the list given. Measured at GET https://opencode.ai/zen/v1/models:

ZEN live: 14 models — 8 free, 3 paid, 3 unclear (big-pickle, jev-1.13, test).

GO live: 38 models — including both free ones (longcat-2.5-preview-free, step-5-preview-free) and space-bunny (paid) alongside space-bunny-free.

So the free lists are real but they move. "The list of models may change as we test and add new ones." — read /models, never a saved list.

4. 🔴 The finding that constrains the whole free-first strategy

The free tier is not callable from an arbitrary API client.

Measured — POST https://opencode.ai/zen/v1/chat/completions with a free model:

{"type":"error","error":{"type":"FreeTierError",
 "message":"OpenCode's free tier can only be used from within OpenCode"}}

HTTP 403 FreeTierError. The free models are client-restricted to OpenCode itself.

Why this matters to V3: our Arms is OpenCode, so this works for us — but it means a free model cannot be reached by a generic HTTP client, a custom router, or any tool that is not OpenCode. And it is consistent with the other requirement we measured earlier: x-opencode-session is mandatory — the provider is verifying that the caller is a real OpenCode client.

So "optimise the free models first" is available to us, but only through Arms. Any V3 component that calls a model outside OpenCode cannot use the free tier.

5. The two endpoints, and what each is for

Both /zen/v1/models and /zen/go/v1/models answer HTTP 200./zen/v1/usage returns 404 — consistent with §3 of the earlier finding: the ZEN credit balance has no API, only GO's windows do.

So the ledger's asymmetry is now fully explained:

• GO — windows readable, per-model limits published, fallback documented
• ZEN — balance console-only, no usage endpoint, cost_state: unknown

6. What this changes in the plan

Stage 6.5's proof is now writable: exhaust a model's window, and the ledger must record window_state: blocked for that model while another model's window is still ok — because the allowance is per model, not per workspace.

7. Not established

• No window has been exhausted. All three windows read percent: 0 — the rate-limited status and the ZEN fallback have not been observed, only read from the docs.
• Muse Spark 1.2 Contributor was not called. Its price and limit are from the published table; "(limited regions)" is unverified for our workspace.
• The per-model allowance was not exercised — I confirmed the endpoint is workspace-level (a ?model= param is ignored), and the per-model split is from the docs' table, not from a measurement.
• big-pickle, jev-1.13 and test are unidentified — present on ZEN, pricing unknown.
• The free-tier restriction was measured on /zen/v1 — the same rule is assumed for /zen/go/v1's free models, not tested there.