config: near-duplicate model IDs with divergent modalities cause a silent modality downgrade with no pointer to the config key #62911

Description

Two model IDs in the same provider that differ only in casing (MiniMax-M3.1-Flash vs minimax-m3.1-flash) are registered as two independent models. Model lookup is an exact match (model.id === ref.id in packages/core/src/model-resolver.ts), so each entry keeps its own capabilities — and nothing warns when the two entries declare different modalities.

The result is a silent modality downgrade with no pointer to the config key that controls it. Selecting the entry whose modalities.input is ["text"] while the provider's own config declares ["text", "image", "video"] makes every image attachment arrive as:

ERROR: Cannot read image (this model does not support image input). Inform the user.

The screenshot was captured correctly — packages/core/src/session/model-request.ts replaces the media part with that text before the request is built, because capabilities.input does not contain image. The message names the model capability but never names the config path to fix, so the natural first reading is "this model has no vision" rather than "this config entry under-declares its modalities".

Two related gaps:

1. No validation for near-duplicate model IDs. MiniMax-M3.1-Flash and minimax-m3.1-flash are the same upstream model, but nothing compares model IDs case-insensitively within a provider to flag the pair, nor to compare their declared modalities for a mismatch.
2. The downgrade message does not identify the offending config entry. It reports the model capability, not provider.<id>.models.<id>.modalities.input, so there is no way to get from the error to the fix without manually auditing every model definition.

Plugins

None required; reproduced with a custom @ai-sdk/openai-compatible provider.

OpenCode version

2.2.5

Steps to reproduce

1. Configure one provider with two model entries for the same upstream model, differing only in case, with different declared modalities:

   {
     "provider": {
       "custom": {
         "npm": "@ai-sdk/openai-compatible",
         "models": {
           "SomeModel-Flash": {
             "name": "Some Model Flash",
             "modalities": { "input": ["text"], "output": ["text"] }
           },
           "somemodel-flash": {
             "name": "Some Model Flash",
             "modalities": { "input": ["text", "image", "video"], "output": ["text"] }
           }
         }
       }
     }
   }

2. Select the first entry and attach an image to a prompt.
3. The image is replaced with ERROR: Cannot read image (this model does not support image input). Inform the user., even though the upstream model accepts images (verified independently with a direct curl to the endpoint).

Screenshot and/or share link

Not attached; the failure is fully reproducible from the config above.

Operating System

Windows 11

Terminal

Windows Terminal

Two questions, since I am not sure which layer should own this:

• Would a config-time diagnostic be the right shape — warn on two model IDs in the same provider that differ only by case and declare different modalities? That would have surfaced the duplicate immediately.
• Or should the runtime downgrade message carry the offending config path (provider id + model id + the modality list that was actually applied), so the error points at the fix instead of at the model's abilities?