Repository navigation
OpenCode adapter requires provider/model, but OpenCode Go runtime rejects opencode-go/<model> and expects bare model id #3571
Description
Summary
There appears to be a mismatch in the opencode provider adapter used by T3 Code.
The adapter validates OpenCode model selections in provider/model format, but when using OpenCode Go models the runtime rejects values like opencode-go/deepseek-v4-pro and suggests the bare model id instead (deepseek-v4-pro).
This makes OpenCode Go models fail even when the local OpenCode installation itself is healthy.
Version
- T3 Code (Alpha)
1.17.11 - OpenCode CLI
1.17.11 - macOS
Affected provider / model
- Provider:
OpenCode - Subprovider:
OpenCode Go - Example model:
DeepSeek V4 Pro
I also saw the same shape of failure with other opencode-go/* models.
Actual behavior
When selecting OpenCode Go / DeepSeek V4 Pro in T3 Code and sending a message, the turn fails.
Observed runtime error:
ProviderModelNotFoundError: Model not found: opencode-go/deepseek-v4-pro. Did you mean: deepseek-v4-pro?
I also previously saw the doubly-prefixed variant before cleaning local state:
ProviderModelNotFoundError: Model not found: opencode-go/opencode-go/deepseek-v4-pro. Did you mean: deepseek-v4-pro, deepseek-v4-flash, mimo-v2.5-pro?
Expected behavior
Selecting OpenCode Go / DeepSeek V4 Pro should work normally.
T3 Code should serialize model selection in the format that the OpenCode runtime actually accepts for OpenCode Go.
Evidence
1. T3 Code adapter validation requires provider/model
In the desktop app bundle, the OpenCode adapter validates model selection with:
OpenCode model selection must use the 'provider/model' format.
The relevant flow calls parseOpenCodeModelSlug(...) and then passes the parsed value into session.promptAsync(...).
2. OpenCode runtime rejects opencode-go/<model>
The local OpenCode runtime logs repeatedly fail with:
Model not found: opencode-go/deepseek-v4-pro. Did you mean: deepseek-v4-pro?
3. OpenCode itself reports the model as provider + bare model id
From the local OpenCode logs, successful model metadata looked like:
model.providerID=opencode-go
model.id=deepseek-v4-pro
That suggests the runtime expects providerID=opencode-go plus modelID=deepseek-v4-pro, not modelID=opencode-go/deepseek-v4-pro.
4. opencode models exposes mixed namespaces
On this machine, opencode models includes entries like:
opencode-go/deepseek-v4-pro
opencode-go/glm-5.2
opencode-go/kimi-k2.7-code
But when those are selected through T3 Code, the runtime still responds that the accepted id is the bare model id.
Reproduction
- Install and authenticate OpenCode normally.
- Open T3 Code.
- Choose provider
OpenCode. - Choose model
OpenCode Go / DeepSeek V4 Pro. - Send any simple prompt.
- Observe the model resolution failure.
Notes
This no longer looks like a user configuration problem.
I was able to clear cached state and still reproduce the core failure mode. The remaining issue appears to be the contract between:
- T3 Code's
opencodeadapter validation / serialization - the OpenCode SDK call shape
- the OpenCode Go runtime's expected model id format
A likely fix area is the OpenCode adapter path that currently enforces provider/model and passes that shape into the runtime for OpenCode Go models.
Activity
joshua-lehmann commentedon Jul 29, 2026
I’m seeing the same problem with T3 Code + OpenCode Go.
Affected models in my recent T3 sessions:
opencode-go/deepseek-v4-proopencode-go/kimi-k2.7-codeAll four affected sessions either ended as T3 runtime errors or were left stuck running without a final assistant response. The short failures occurred after roughly 21–26 seconds; another pair ran for about 25–27 minutes before erroring. T3 recorded completed tool calls and no tool-call errors, but could not correlate the sessions with native OpenCode telemetry, so the UI did not provide a usable provider error/final response.
This lines up with the reported
ProviderModelNotFoundError/ provider-and-model-ID serialization mismatch. I only have an OpenCode Go subscription (no Codex or other provider), so this currently makes T3 Code unusable for me. Please let me know if there is a workaround or a build/version that fixes OpenCode Go model selection.joshua-lehmann commentedon Jul 29, 2026
@t3dotgg @juliusmarminge Could one of you please triage this? This is a blocking OpenCode Go provider failure, not a minor model-picker issue: my only available subscription is OpenCode Go, and the affected T3 sessions either fail with runtime errors or stay running without a final response.
I re-checked the tracker and found multiple distinct OpenCode /
opencode-goreports, including hangs and missing replies. The exact model-ID serialization issue here is still open and appears to affect bothopencode-go/deepseek-v4-proandopencode-go/kimi-k2.7-code. Is there a known workaround or a fix planned for an upcoming release?maria-rcks commentedon Oct 9, 2026
Note
This is an automated response from a bot acting on maria's behalf.
This issue has had no activity since 2026-07-29.
Is it still relevant on the current version? If so, your version and OS would help.
juliusmarminge commentedon Oct 27, 2026
I couldn't reproduce this on current
main(71ba6b3) on Linux with OpenCode CLI 1.18.18:providerID=opencode-go modelID=deepseek-v4-pro, and OpenCode resolved the model (llm.provider=opencode-go llm.model=deepseek-v4-pro). There was noProviderModelNotFoundError.providerID=opencode-go modelID=kimi-k2.7-code./providerresponse lists theopencode-gomodels with matching keys and ids (for exampledeepseek-v4-pro). T3 Code buildsopencode-go/deepseek-v4-profrom those and splits it back into the same provider and model ids.So T3 Code sends the provider and the bare model id separately, which is the shape you describe as the one OpenCode expects. To narrow it down, could you share:
opencode --version, and whether it still happens there.opencode run -m opencode-go/deepseek-v4-pro "hi"run outside T3 Code, on the same machine.provider/opencode-go/modelentries in youropencode.json(global~/.config/opencode/and the project's), with keys redacted. A model defined there under a prefixed key would explain theopencode-go/opencode-go/...variant.~/.local/share/opencode/log/).shivamhwp commentedon Nov 11, 2026
Closing this as not planned for now. It did not reproduce on main at
71ba6b374con 2026-10-27 with OpenCode CLI 1.18.18. OpenCode Go models were sent asproviderID=opencode-gowith a bare model id, and OpenCode resolved them.If it still happens on a current build, please reply here with the details asked for above and we'll reopen it.