A /models list with no modality field, and five entries that can't chat

If you build a model picker by reading GET /models and dropping every id into a chat completion, you will ship a picker where a third of the options are broken.

I tried it against Groq. The endpoint advertises 14 models. Sending each one the same minimal chat request:

answered a minimal request : 9/14
failed outright            : 5/14

The five failures are not outages. They are models that were never chat models:

whisper-large-v3              400
whisper-large-v3-turbo        400
canopylabs/orpheus-v1-english 400
canopylabs/orpheus-arabic-saudi 400
groq/compound                 429

Two speech-to-text, two text-to-speech, and one router that was rate limited at the time. They all sit in the same flat list as the chat models, with no field saying which modality they are. The only way to know is to recognise the names.

Two smaller things from the same sweep:

The guard models (llama-prompt-guard-2-22m, -86m) and allam-2-7b answer chat requests but reject max_tokens: 8192 with a different error — max_tokens must be less than or equal to 512 for the guards, 4096 for allam. So per-model output ceilings are real and undiscoverable from the list.

And groq/compound turns out to be a router. Its 429 named openai/gpt-oss-120b rather than itself, which is the only place the routing is visible from the outside.

None of this is documented in the list response. If you enumerate models programmatically, probe each one once and cache what actually answers, rather than trusting the catalogue.