Triage

Thanks for tracking this down, @alhammadialihameed. Including the OpenCode log lines and the stored session records made the cause easy to confirm.

What I found

This bug is on main. It comes from how OpenCode reasoning defaults are chosen, not from OpenCode Go auth or the model list.

• inferDefaultVariant in apps/server/src/provider/Layers/OpenCodeProvider.ts has special cases for anthropic / google* (high) and for openai / opencode (medium, otherwise high). Nothing matches opencode-go. On the OpenCode 2 path (openCode2ModelCapabilities), the Reasoning options are exactly the variants OpenCode advertises. For opencode-go/deepseek-v4.1-flash and opencode-go/glm-5.3-flash that's low / high / max, so the descriptor ends up with no default and no current value.
• OpenCode 2.0.20 doesn't add medium on its own when no variant is sent. VariantUnavailableError is only thrown when the session model carries an explicit variant that isn't in the model's list (withVariant in OpenCode's model-resolver.ts). So the "variant":"medium" or "xhigh" in your session records was on the model ref T3 sent.
• T3 gets that value from the thread's saved model selection. The fallback OpenCode capability set is low / medium / high / xhigh, with medium as the current value. The web composer drops a variant the loaded model doesn't list, but if the model isn't in the catalog yet it forwards the saved options unchanged. Orchestrator workers copy the parent's selection when they don't pass their own options, which would explain why workers fail immediately.
• One open question: models.dev currently lists muse-spark-1.3-contributor with minimal / low / medium / high / xhigh, which is a different set from the DeepSeek and GLM Flash models. It's worth checking what OpenCode actually advertises for that one.

Workaround for now: set Reasoning to High or Max before sending, including on the thread that spawns workers.

Likely fix area

• inferDefaultVariant for opencode-go. One thing to watch: adding it to the openai / opencode branch and preferring max would also change the default for OpenAI and opencode/* models that advertise max. A narrower option is to choose a variant these models actually list, such as high.
• Model selection on send, in the web composer and when workers inherit options. One option is to drop or remap a saved variant that isn't in the model's advertised list instead of forwarding it.

A maintainer will decide on the fix direction.

Thanks Julius — one more data point for the muse-spark-1.3-contributor question, and a confirmation of the mechanism.

What OpenCode actually advertises for opencode-go/muse-spark-1.3-contributor

It is not the same set as the DeepSeek/GLM Flash models. From the OpenCode models cache (~/.cache/opencode/models.json, refreshed by OpenCode 2.0.20 on this machine):

The same values show up in T3 Code's own capability descriptors (~/.t3/caches/opencode.json) for those three slugs — for all three the variant descriptor has currentValue absent and no isDefault option, i.e. exactly the "no default, no current value" state you described for the OpenCode 2 path.

So medium is valid for muse-spark-1.3-contributor, but the two Flash models only take low/high/max. A single opencode-go branch that guesses one fixed effort won't be correct for all three; the default has to come from the model's advertised list.

On the "where does medium come from" question

Your read matches what I see here: the failing sessions weren't sent a variant by a successful fallback resolver, they carried a stale one on the model ref. The three failed worker sessions that produced the VariantUnavailableError: medium lines were stored as {"id":"glm-5.3-flash","providerID":"opencode-go","variant":"medium"} and {"id":"deepseek-v4.1-flash",...,"variant":"medium"}. The parent thread's saved selection was the source; workers inherited it unchanged, which is why they failed at 0s before the first turn.

(Those records now work after I removed the stale medium locally, so the fail-fast is the only effect — nothing was corrupted.)

Narrower fix, for the record

Rather than adding opencode-go to the openai/opencode branch, the safe shape is: for opencode-go (and any provider with a known variant list), pick a variant from the model's advertised list, and on send drop/remap a saved variant that is not in that list. That keeps opencode/* and OpenAI defaults untouched and handles the muse-spark case, where medium is legitimate but xhigh may not be what the user wants when the thread was created under the fallback capability set.

Happy to test any patch against T3 Code (Nightly) + OpenCode 2.0.20 on macOS arm64 if useful.

Any timeline on when this bug will be fixed? My main provider is OpenCode without a subscription and this bug cuts me off all my primary models, making T3 Code unusable.