How to use SiliconFlow models in DeepSeek Harness
SiliconFlow is the practical choice when you want several Chinese model families behind one key. It is not in DSH's built-in provider catalog, so you add it as a Custom model API.
Before you start
You need a partially funded SiliconFlow account, an API key, and Node.js installed. If DSH itself is not running yet, do the install guide first.
Step 1 — create an API key
Sign in to SiliconFlow and create a key in its console. Copy it once — most providers never show it again.
Step 2 — start the harness
npx @deepseek-ai/dsh web
Web UI comes up at http://127.0.0.1:3080.
Step 3 — Add model provider → Custom model API
In Settings → Models, choose Add model provider, then switch the card to Custom model API — that is the route for a relay, a company gateway, or any provider absent from the installed catalog. Fill in:
| Field | Value |
|---|---|
| Provider ID | siliconflow |
| Base URL | https://api.siliconflow.cn/v1 |
| API protocol | OpenAI Chat Completions |
| API key | your key |
The Provider ID is permanent — requests, saved sessions, model defaults and credential references all use it. To rename a provider you add a new one and delete the old one; everything except the ID stays editable.
A provider speaks exactly one protocol. A gateway that serves both OpenAI and Anthropic formats needs two separate provider entries.
Step 4 — add at least one model
Use Fetch available models to ask the endpoint what it serves — the request uses the base URL, protocol and key currently in the form. It reads the listing formats common gateways publish, but not every endpoint answers in one of them, so when it fails or lists nothing, add the ids by hand and they work the same.
Known-good ids:
deepseek-ai/DeepSeek-V3Qwen/Qwen2.5-72B-Instructmoonshotai/Kimi-K2-Instruct
Step 5 — verify
Save, then select the model in the composer. Model changes apply on the next request; no restart.
Or: configure it in YAML
The Web UI writes the same document you can edit directly. The profile for a
standard dsh web launch is web, so the file is
$DSH_HOME/profiles/web/cordis.patch.yml. Adapters re-read it on the next
request — no restart needed.
# $DSH_HOME/profiles/web/cordis.patch.yml
- id: llm-pi-ai
config:
providers:
siliconflow:
apiKeyEnv: DSH_API_KEY
api: openai-completions
baseURL: https://api.siliconflow.cn/v1
models:
- id: deepseek-ai/DeepSeek-V3
A Cordis config override replaces the complete entry config — when editing an existing override, preserve your other providers and fields or they vanish.
Export the variable referenced above in the shell that starts DSH:
export DSH_API_KEY="sk-..."
Troubleshooting
- 404 on every request — the base URL is wrong. It must end at the
version segment (
/v1), never at/chat/completions. - 401 Unauthorized — key revoked, or pasted with trailing whitespace. Note that DSH's env-var detection does not validate the key.
- CLIENT_UPGRADE_REQUIRED — the model needs a newer harness. The error names the version to install.
- Model missing from the picker — a saved default pointing at a deleted provider makes the composer show Select model and block input until you pick another.
- Empty or truncated reply — usually the model id resolved to a different model than you expected. Add the id explicitly rather than relying on Fetch available models.
Cost and caveats
Per token, generally at or below the official provider price. Some small models have a rate-limited free tier.
- The
/v1suffix is part of the base URL — drop it and every request 404s. - Model IDs are namespaced with the vendor, e.g.
deepseek-ai/DeepSeek-V3. - A Chinese phone number is required to register.
Plugins that pair well with this provider
There is no dedicated plugin for this provider yet — which is expected: an OpenAI-compatible endpoint does not need one. Browse Models & Routing for routers and key managers that work with any provider.
Other providers
Source for every field above: the official DSH provider docs. If DSH changes a field name, that document wins over this page.