OpenRouter nested model ID poolside/laguna-s-2.1:free is rejected by T3 Code/OpenCode
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- Install or open T3 Code with OpenRouter configured.
- Use T3 Code 0.0.42 on Windows (the bundled OpenCode runtime is 1.18.31).
- Select the OpenRouter model
openrouter/poolside/laguna-s-2.1:free. - Start a new prompt and submit any message.
- The request fails before a response is generated.
Expected behavior
T3 Code/OpenCode should resolve the provider-qualified selection as:
- providerID:
openrouter - modelID:
poolside/laguna-s-2.1:free
The request should then be sent to OpenRouter using the valid raw model ID poolside/laguna-s-2.1:free. The nested poolside/ namespace is part of the model ID and must be preserved; it should not be treated as an accidental provider prefix.
Actual behavior
The request fails with ProviderModelNotFoundError:
Model not found: openrouter/poolside/laguna-s-2.1:free. Did you mean: poolside/laguna-s-2.1:free, poolside/laguna-xs-2.1:free?
The important detail is that OpenRouter uses poolside/laguna-s-2.1:free as the API model ID, while T3/OpenCode uses openrouter/... as the provider-qualified application selection. The provider catalog exposed by OpenCode contains the model with providerID openrouter and modelID poolside/laguna-s-2.1:free, but the prompt path still fails to resolve the selected value.
I also verified that a direct OpenCode request using the separated providerID/modelID succeeds, so this does not look like an unavailable OpenRouter model or an invalid API model ID.
Related work:
- T3 issue #3571 reports a similar provider/model serialization boundary for OpenCode Go, but this report concerns OpenRouter.
- PR #7247 addresses duplicated
opencode/opencode-goprefixes only and intentionally leaves other providers unchanged; it does not cover this valid nested OpenRouter model ID. - T3 issue #4239 was about OpenCode configuration being overwritten with
{}and was fixed by PR #4242. That is related to model discovery, but it does not explain this remaining prompt-time lookup failure.
Impact
Major degradation or frequent failure
Version or commit
T3 Code 0.0.42; OpenCode 1.18.31
Environment
Windows desktop app; provider: OpenRouter; model: poolside/laguna-s-2.1:free; T3 Code is using its bundled OpenCode runtime.
Logs or stack traces
ProviderModelNotFoundError: Model not found: openrouter/poolside/laguna-s-2.1:free. Did you mean: poolside/laguna-s-2.1:free, poolside/laguna-xs-2.1:free?Screenshots, recordings, or supporting files
No response
Workaround
A temporary workaround is to explicitly declare the OpenRouter models in ~/.config/opencode/opencode.jsonc:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"openrouter": {
"models": {
"poolside/laguna-s-2.1:free": {
"name": "Laguna S 2.1 (free)"
},
"poolside/laguna-xs-2.1:free": {
"name": "Laguna XS 2.1 (free)"
}
}
}
}
}After restarting T3 Code, the provider catalog exposes the models correctly and the direct OpenCode request works. This looks like a workaround rather than the underlying fix.
Suggested fix: make the T3 model picker and prompt path consistently normalize a provider-qualified selection (openrouter/poolside/...) into separate providerID and modelID values, refresh/revalidate the provider catalog when models or configuration change, and add a regression test for a valid nested OpenRouter model ID such as poolside/laguna-s-2.1:free. Any prefix cleanup must remain provider-specific: it must not strip the legitimate poolside/ namespace from OpenRouter model IDs.
Related references:
Source: pingdotgg/t3code