characterise the fork blocker: only free models run

Not sonnet, and not variant. Swept models through the new pipeline: every -free model runs,
every paid one silently does not — haiku, sonnet and codex-mini all never start.

Ruled out: variant (sonnet advertises low/medium/high/max and echoes back an invalid
"default", which looked like the answer and was not — setting high explicitly also never
ran); credentials (zen key in auth.json plus ANTHROPIC_API_KEY); and the sidecar environment,
since the same process runs sonnet fine through opencode run.

So the new pipeline does not resolve paid-model credentials and says nothing, while run and
the legacy path authenticate fine. Upstream bug in an in-progress pipeline, not our config.

The fork stays blocked, but precisely: steer and queue are proven, and the day a paid model
runs there the migration is worth doing immediately. Re-run the sweep after each upgrade.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/opencode-fork-decision.md

@@ -41,19 +41,41 @@ Steer and queue are exactly the two features we hand-built for Claude and that A
 changer. Having them as primitives, plus a resumable per-session cursor that mirrors officer's durable
 replay, is a strong argument for migrating.
 
-## The open question, which is now the only blocker
+## The blocker, now characterised: only free models run
 
-**Why does `claude-sonnet-4-6` run under `opencode run --model` and silently die under the new API?**
+It is not sonnet, and it is not `variant`. Swept four models through `POST /api/session/{id}/model`
+followed by a prompt:
 
-Until that is answered, the migration cannot be adopted: model choice is a user-facing control, and a
+| Model                | New pipeline |
-harness where picking the wrong model produces silence rather than an error is worse than one without
+| -------------------- | ------------ |
-streaming. Things to try, cheapest first:
+| `longcat-2.0-free`   | **ran**      |
+| `ling-3.0-tiny-free` | **ran**      |
+| `claude-haiku-4-5`   | never ran    |
+| `claude-sonnet-4-6`  | never ran    |
+| `gpt-5.1-codex-mini` | never ran    |
 
-1. `variant` on `ModelRef` — it is the one field of the three we never set.
+**Every `-free` model runs; every paid model silently does not.** Ruled out along the way:
-2. Compare `/config/providers` against what `run` resolves, to see whether the ids differ in form.
+
-3. Whether it is auth-scoped: alpha's default model failed `401 missing_api_key` on a *different*
+- **Not `variant`.** `claude-sonnet-4-6` advertises `["low","medium","high","max"]` and session create
-   provider (`nano-gpt`), which proves the new pipeline surfaces provider auth errors properly when it
+  echoes back `variant: "default"`, which is not among them — a promising theory that turned out to be
-   gets that far — so sonnet's silence is not a generic auth failure.
+  wrong: setting `variant: "high"` explicitly also never ran. Tested rather than assumed, which is the
+  whole lesson of this file.
+- **Not missing credentials.** `opencode auth list` shows an OpenCode Zen API key in
+  `~/.local/share/opencode/auth.json` plus `ANTHROPIC_API_KEY` in the environment.
+- **Not the sidecar's environment.** The *same* sidecar process runs `claude-sonnet-4-6` correctly
+  through `opencode run --model`, verified end to end. Same user, same home, same auth file.
+
+So the new pipeline does not resolve paid-model credentials, and fails **silently** rather than
+reporting it — while the legacy path and `run` both authenticate fine. Note it *can* surface provider
+auth errors when it reaches that far: alpha's default (`nano-gpt`) returned a clean
+`401 missing_api_key`. The silence is specific to opencode-zen paid models.
+
+This reads as an upstream bug in an in-progress pipeline, not something configurable on our side.
+
+**Consequence for the fork:** blocked, but precisely. Officer's users pick real models; a harness that
+works only on free tiers is not adoptable. Re-run the sweep above after each `opencode upgrade` — the
+day a paid model runs there, the migration is unblocked and worth doing immediately, because steer and
+queue are already proven.
 
 ## Revised recommendation