Two usual failures when switching models: the config is ignored (still on the default) and it applies but the model ID does not exist (the error looks like a network fault). One minimal task separates them.
This page is a verification method, not a full gateway config sample. Config keys change between versions and copied snippets rot; the method does not.
Step one: see the effective model
dsh --dump-config | grep -i -A3 model
You are checking where the composed config points. --dump-config prints the composed result, so it shows what applies, not what you hoped would apply.
Step two: send a task that must call a tool
Read package.json in the current directory and tell me only the name field. Do not guess.
Why insist on a tool call: if the model is misconfigured the host may fall back to a default, and a plain chat task still answers, making you think it worked. Reading a file requires a tool, so failures surface.
Step three: tell three failures apart
| Symptom | Meaning | Next |
|---|---|---|
| model not found | Wrong ID, or the gateway does not offer it | Check the gateway's model list; mind case and version suffixes |
| 401 / 403 | Bad key, or no access to that model | Try a known-good key or model to isolate the key |
| Answers, but not with the file content | Tool call failed, or the instruction was ignored | Rephrase more directly and see whether it still refuses to read |
Step four: keep evidence
Save the model section from --dump-config and the verbatim error. Next time someone asks which model you ran, you paste config and text, not an impression.