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

1. Install or open T3 Code with OpenRouter configured.
2. Use T3 Code 0.0.42 on Windows (the bundled OpenCode runtime is 1.18.31).
3. Select the OpenRouter model openrouter/poolside/laguna-s-2.1:free.
4. Start a new prompt and submit any message.
5. 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-go prefixes 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:

• https://github.com/pingdotgg/t3code/issues/3571
• https://github.com/pingdotgg/t3code/pull/7247
• https://github.com/pingdotgg/t3code/issues/4239
• https://github.com/pingdotgg/t3code/pull/4242

Start in apps/desktop by tracing how the model picker serializes provider-qualified selections and how the prompt path resolves them against the provider catalog. Reproduce with openrouter/poolside/laguna-s-2.1:free, then add a regression test covering the separated providerID and nested modelID. Done means the request reaches OpenRouter without stripping the poolside/ namespace.