How to Fix "the supported api model names are deepseek-v4-pro or deepseek-v4-flash, but you passed gpt-5.6-sol"

Nothing is wrong with your key or your endpoint — the request was rejected only because the model name you sent is not on this endpoint's allowlist. The message itself has three parts, and each one is useful:

The first half is the endpoint telling you its allowlist. The second half is the endpoint echoing back the `model` field it received from you. Your request authenticated successfully, reached a working DeepSeek V4-compatible gateway, and was rejected at model validation — before any tokens were generated or billed.

OpenAI-compatible gateways that front DeepSeek V4 models return this wording or something close to it: coding-plan providers, aggregator endpoints, and self-hosted LiteLLM-style proxies. The phrasing varies per gateway — this site's own gateway, for example, words the same rejection differently — but the diagnosis and the fix are identical.

A bad key produces a 401-style error; this is a 400-class invalid-model rejection. It usually happens for one of four reasons: you copied a config written for OpenAI or ChatGPT and changed the base URL and key but not the model name; your tool defaults to its built-in OpenAI model list and you never overrode the `model` field; you switched providers or relays but a saved profile or cached model list still carries the old name; or an environment variable exported in an old shell session is overriding your new config.

Change the `model` field to one of the names the error itself lists — `deepseek-v4-pro` or `deepseek-v4-flash` — then restart your tool so the new configuration is picked up. In each major tool it is exactly one line:

If that already solves it, skip to section 9 to pick between Pro and Flash. If you want to confirm the diagnosis first, the next section has a one-request test.

You can verify key, URL, and model name together with one curl call before touching any tool config. Replace `<base-url>` with the endpoint your key belongs to:

If that returns a completion, your key, URL, and model name are all correct, and the remaining work is only making your tool send the same name. The per-tool sections below show exactly where the old name hides.

Codex reads its model from `~/.codex/config.toml`. Set the top-level `model` to a DeepSeek name and make sure the provider block points at your DeepSeek-compatible endpoint:

Three Codex-specific places the old name can survive. Profiles: a `[profiles.<name>]` section can pin its own `model`, so if you launch with `codex --profile <name>`, check that profile too. Model catalogs: if your setup uses `model_catalog_json` or a cached catalog file, delete the stale catalog so it regenerates. Old terminals: start a fresh terminal after editing so nothing is inherited from the previous session.

Claude Code picks models from environment variables. Set the main model and clear every default slot of leftover OpenAI-style names — Claude Code routes background calls through the default slots, so a GPT name left in one of them keeps triggering the error even after you fix the main variable:

Then restart the terminal (or re-source your shell profile) and confirm inside Claude Code with `/model`. If the error persists, grep your `.zshrc` or `.bashrc` for the old model name — a forgotten export there silently wins over your new settings.

In SDK code the model is just the `model` argument. It is commonly hardcoded, read from a `.env` file, or defaulted in a shared helper — search your project for the old name:

In Node the same change is `model: "deepseek-v4-pro"` in the `chat.completions.create` options. If the model name comes from an environment variable such as `OPENAI_MODEL`, update the variable's value — the code may be correct while the environment is stale.

In apps such as Cherry Studio, LobeChat, or Cursor with a custom OpenAI-compatible provider, the model dropdown usually lists only the app's built-in providers. Add the DeepSeek model manually: open the provider or model settings for your custom endpoint, add a custom model, and type the name exactly — `deepseek-v4-pro` or `deepseek-v4-flash`. Model names are case-sensitive and must match character for character: no capitals, no trailing spaces.

Then delete or disable the stale `gpt-5.6-sol` entry so it stops being selected by default, start a new conversation, and select the DeepSeek model before sending.

`...but you passed gpt-5.6-terra` and `...but you passed gpt-6.1-sol` are the same failure with a different OpenAI model name in the `model` field. A newer release does not change the diagnosis — the endpoint still serves DeepSeek models only, and the name it lists in the error is the name to send. The fix is identical in every tool above.

Use one rule for every variant, including future ones and non-GPT names such as `claude-*` or `gemini-*`: the names in the first half of the error message are the valid model names for that endpoint; the name after "you passed" is only what you sent. Put a name from the first half into your `model` field and the error goes away.

Both names fix the error, so pick by workload:

A practical default: start with `deepseek-v4-flash` for interactive loops where speed matters, and reach for `deepseek-v4-pro` when a task needs deeper reasoning or long-context coding work. For the full comparison, continue with `/guides/deepseek-v4-pro-vs-flash`, and check your provider's pricing page before committing to high volume. Whichever you choose, type the name exactly as the error lists it.

If the same request now fails differently, you have moved past the model-name problem and hit the next one. Debug in this order — each row eliminates one cause:

And the classic silent killer: environment variables exported in another shell, a Docker image built before the fix, or a tmux session older than your edit. When in doubt, restart everything once and retest.