OpenCode adapter requires `provider/model`, but OpenCode Go runtime rejects `opencode-go/<model>` and expects bare model id

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

1. Install and authenticate OpenCode normally.
2. Open T3 Code.
3. Choose provider OpenCode.
4. Choose model OpenCode Go / DeepSeek V4 Pro.
5. Send any simple prompt.
6. 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 opencode adapter 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.

Start in the OpenCode adapter path around parseOpenCodeModelSlug(...) and the session.promptAsync(...) call, then compare the adapter's model serialization with the OpenCode runtime logs showing providerID=opencode-go and a bare model id. Done means OpenCode Go selections such as deepseek-v4-pro no longer fail model resolution while other provider/model selections retain their expected behavior.