[Bug] Model resolution fails when the model ID itself contains "/" (NVIDIA NIM prefixed keys) — "Model not found" suggests the exact same ID

[justinwnewton]

Description

Model references do not resolve when the model ID itself contains a slash — notably all NVIDIA NIM models, whose API-facing IDs embed the vendor prefix (e.g. the model's real ID is literally nvidia/nemotron-3-ultra-550b-a55b, so under provider nvidia the registry key is nvidia/nemotron-3-ultra-550b-a55b).

A ref written in the natural bare form nvidia/nemotron-3-ultra-550b-a55b splits at the first slash → providerID=nvidia, modelID=nemotron-3-ultra-550b-a55b (bare) → the exact-match lookup misses the prefixed key → the fuzzy suggester then offers the real key, whose rendered form is byte-identical to the requested ref, producing this error:

ProviderModelNotFoundError: Model not found: nvidia/nemotron-3-ultra-550b-a55b. Did you mean: nvidia/nemotron-3-ultra-550b-a55b?

The identical-ID suggestion is this bug's structural signature — it is generated structurally whenever this class of miss occurs, not cosmetically. It also makes the error look absurd ("did you mean the thing I just asked for?").

This cannot be worked around client-side by renaming the model key: the key IS the API-facing model id that must be sent to the NIM endpoint, so it has to keep its prefix.

Related but distinct: #39926 reports the mirror-image failure of the same first-slash split, where a URL-based provider ID breaks. This report covers model IDs containing / under a normal named provider.

OpenCode version

1.18.20

Steps to reproduce

1. Authenticate the NVIDIA provider (opencode auth login nvidia). The registry then contains slash-prefixed keys such as nvidia/nemotron-3-ultra-550b-a55b (same shape as nvidia/moonshotai/kimi-k2.6 reported in NVIDIA provider missing moonshotai/kimi-k2.6 despite model being available via NVIDIA API #40911).
2. Pin the model in bare form (single provider prefix) somewhere that resolves at session start — e.g. an agent file frontmatter:

   ---
   model: nvidia/nemotron-3-ultra-550b-a55b
   ---

3. Spawn a fresh session with that agent.
4. Observe the immediate failure below (~32 ms after session start, zero inference attempts / zero tokens).

Contrast step: reference the same model via the doubled full-key form nvidia/nvidia/nemotron-3-ultra-550b-a55b (= providerID nvidia + modelID nvidia/nemotron-3-ultra-550b-a55b). It resolves fine — which is why the same route succeeds mid-session in already-running sessions yet fails deterministically on every fresh spawn of a bare-form pin.

Observed behavior

Fresh spawn on the bare-form pin fails before any API call:

Model not found: nvidia/nemotron-3-ultra-550b-a55b. Did you mean: nvidia/nemotron-3-ultra-550b-a55b?

The suggestion is byte-identical to the requested ID. The model was simultaneously confirmed live in NVIDIA's catalog (present in /v1/models throughout the observation window), so this is a resolution defect, not catalog absence.

Same model succeeds mid-session when referenced through the already-resolved doubled form.

Expected behavior

• A bare-form ref nvidia/nemotron-3-ultra-550b-a55b should resolve to the registry key nvidia/nemotron-3-ultra-550b-a55b under provider nvidia — i.e., resolution should tolerate model IDs that themselves contain slashes.
• At minimum, the suggester should never offer a candidate whose rendered <providerID>/<modelID> is identical to the requested ref.

Suggested fix direction

1. Resolution: after splitting <provider>/<rest> and missing on exact match, attempt to interpret <rest> as the full model ID (exact/suffix match against that provider's keys) before falling back to fuzzy suggestions — this makes the bare form resolve the prefixed key.
2. Suggester hygiene: filter out suggestions equal to the requested ref. "Did you mean X?" where X === requested is misleading and masks the actual failure mode.
3. Diagnostics (optional): when the would-be suggestion equals the request, emit a distinct message (e.g. "model ID may itself contain '/'; try doubling the provider segment") so scripts can recover.

Impact

Any agent/config pin or script that names a NIM model in the natural bare form fails deterministically at fresh-session spawn while the same model keeps working in sessions that were started interactively — intermittent-looking in aggregate, deterministic-by-form in reality. Easy to misdiagnose as provider outage/rate limiting.

Environment: opencode 1.18.20 standalone binary, macOS (darwin arm64), NVIDIA NIM endpoint https://integrate.api.nvidia.com/v1.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Model IDs with slashes truncated in provider-catalog.ts and bootstrap.ts #43662: Same root cause — model IDs containing slashes are truncated/misresolved at the first-slash split. That report covers OpenRouter models; this report covers NVIDIA NIM models, but the underlying parseModel split behavior and the fix direction are identical.

If there is meaningful overlap, consider consolidating or cross-referencing so the fix can be tracked in one place.

[rareboe]

I'd like to take this one if it isn't already being worked on.

I traced the bare-form failure to getModel in packages/opencode/src/provider/provider.ts. provider.models is keyed by the raw catalog id (fromModelsDevProvider copies Object.entries(provider.models) verbatim), so for NIM the key literally is nvidia/nemotron-3-ultra-550b-a55b. parseModel splits on the first slash, so the bare ref looks up provider.models["nemotron-3-ultra-550b-a55b"], misses, and modelSuggestions then returns the real key — which renders byte-identical to the request, exactly as reported.

Planned minimal fix:

1. On an exact-match miss in getModel, retry once with `${providerID}/${modelID}` before erroring. That resolves the bare form to the prefixed key, and the returned info.id stays the full API-facing id, so the correct id is still sent to the endpoint. The existing doubled form keeps working because it already hits on exact match.
2. Drop any suggestion whose rendered form equals the requested ref, so "did you mean " can't happen again.

I'm deliberately not touching parseModel (that's #39926 / #40071 territory, and changing the split would break the doubled form) and not adding suffix matching, since provider/<vendor>/<model> keys like moonshotai/kimi-k2.6 already resolve via exact match.

Will open a PR with regression tests shortly.