DeepSeek Harness
DeepSeek Harness is an open-source agent harness where every capability — models, tools, skills, sandboxes — is a swappable plugin. It speaks the openai-completions protocol natively, so QuickSilver Pro drops in as a custom provider with no plugin to install: one key and one balance across the whole catalogue.
Add the provider
Add a block to your settings.yaml. The provider ID is yours to choose but is permanent — it appears in requests and stored sessions, so pick it before you build sessions on top of it.
quicksilver-pro:
api: openai-completions
baseURL: https://api.quicksilverpro.io/v1
apiKeyEnv: QUICKSILVER_API_KEY
models:
- id: claude-sonnet-5
- id: deepseek-v4-pro
- id: kimi-k3
- id: gemini-3.5-flashThen export the key you created on the dashboard:
export QUICKSILVER_API_KEY=sk-...Prefer the UI? Settings → Models → Add a custom provider takes the same four values: the base URL above, openai-completions as the API protocol, your key as the credential, and at least one model ID. The route is usable immediately — no server restart.
Pick the protocol, not the vendor
This is the one place an otherwise-correct setup goes wrong. Every model here is reached over openai-completions — including the Claude and Gemini models. Selecting an anthropic or google provider type and pointing it at this base URL sends a different wire protocol to an endpoint that does not speak it, and you get a 404 rather than a clear error.
Model IDs are passed through verbatim, so a model that is not in your models list can still be sent directly by ID — the list only controls what appears in the selector.
Check it before you wire up an agent
One request settles whether the credential, the base URL and the model ID are all right, and it costs a fraction of a cent:
curl https://api.quicksilverpro.io/v1/chat/completions \
-H "Authorization: Bearer $QUICKSILVER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-pro",
"messages": [{"role": "user", "content": "Reply with the single word: ready"}]
}'This curl bypasses the harness entirely, so it isolates the account from the configuration. A 401 means the key or the header is wrong; a 404 means the model ID is not one we serve (see the model list); a 402means the balance is empty. If the curl succeeds but the harness still fails, the problem is the provider block above — almost always the protocol. The full list is in the error reference.
Choosing models for an agent loop
An agent harness is output-heavy and long-running, which makes the choice different from a chat UI. Some starting points from the full catalogue of 38 chat models:
- deepseek-v4-pro — strong tool-calling at a low per-token cost; a sensible default for the main loop.
- claude-sonnet-5 — when the loop needs to hold a long, messy codebase in context.
- kimi-k2.7-code — coding-tuned with a 256K context, for the steps that are mostly reading and editing code.
- kimi-k3 — a 2.8T multimodal reasoning flagship with 1M context, for the hard step in the middle of a run. Give any thinking model generous
max_tokensheadroom (≥1024) — a budget that only covers the answer gets spent on the reasoning instead, and the call comes back empty. - gemini-3.5-flash — cheap enough for the high-volume subagent work a harness fans out.
Every model bills against the same prepaid balance at the rate listed on the pricing page, so swapping the model in settings.yaml needs no new account, key or card.
Keeping a long run from stopping
Credit is prepaid, so when the balance reaches zero the API returns 402 and the harness stalls mid-run. For unattended agents, turn on auto-recharge under Credits: you set the trigger and the amount, and the amount chargeable per day is hard-capped, so an agent stuck in a retry loop cannot run up a bill.
Rate limits, streaming behaviour and the tool-calling schema are the same as for any other client — see rate limits, streaming and tool calling.