# OpenScale for DeepSeek Harness

Tested live with DeepSeek Harness 0.2.0-rc.2 (dsh): file edits, shell and streaming.

Protocol: Anthropic Messages, base URL https://api.openscale.so/anthropic

## Quick start

The fastest way to try it. Replace YOUR_OPENSCALE_API_KEY with your key and run it yourself; do not paste the key into an agent conversation.

```bash
mkdir -p ~/.dsh && echo '[{"id":"llm-pi-ai","config":{"providers":{"openscale":{"apiKeyEnv":"OPENSCALE_API_KEY","api":"anthropic-messages","baseURL":"https://api.openscale.so/anthropic","models":[{"id":"deepseek/deepseek-v4.1-flash","contextWindow":1048568,"maxTokens":32768,"input":["text","image"]},{"id":"z-ai/glm-5.3-flash","contextWindow":1048576,"maxTokens":32768,"input":["text","image"]}]}}}},{"id":"agent-default-model","config":{"provider":"openscale","model":"deepseek/deepseek-v4.1-flash"}}]' > ~/.dsh/openscale.patch.yml
export OPENSCALE_API_KEY='YOUR_OPENSCALE_API_KEY'
dsh web --patch ~/.dsh/openscale.patch.yml
```

## Version and configuration

Uses the custom model API (llm-pi-ai) of DeepSeek Harness 0.2, a developer preview whose configuration can change between releases. Check dsh --version first.

Default path: `~/.dsh/profiles/web/cordis.patch.yml`.

Pass the file to dsh with --patch, or merge its entries into the profile patch (~/.dsh/profiles/web/cordis.patch.yml for dsh web). An entry replaces the whole config of the plugin it names, so if you already have an llm-pi-ai entry, add providers.openscale to it instead of adding a second one. In the web UI the same values go in Settings, Models, Add model provider, Custom model API, with API protocol Anthropic Messages.

[Download the configuration fragment](https://openscale.so/setup/deepseek-harness.yaml). This is a merge fragment, not a replacement for an existing file. Model metadata is generated from OpenScale's catalog; prices are estimates in USD per million tokens, not an account balance or billing receipt.

## Authenticate locally

The provider reads OPENSCALE_API_KEY from the environment that launches dsh. In the web UI you can instead enter the key in the provider form; dsh stores it in ~/.dsh/.credentials.yaml.

## Select and verify

Model settings apply on the next request; restart dsh after changing its launch environment.

The agent-default-model entry makes openscale/deepseek/deepseek-v4.1-flash the default for new sessions. Pick it in the model picker to switch an existing session.

[Official DeepSeek Harness documentation](https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/user/guide/providers.md)

## Procedure for the setup agent

1. Confirm the requested agent and inspect its installed version and active configuration location. Read only the relevant settings; do not dump credential stores or unrelated environment variables. If the agent is not installed, link its official installation instructions and let the user choose installation.
2. Read the matching recipe and its linked configuration. If the installed schema differs, consult the linked official docs for that version. Do not guess, silently upgrade, or apply a different version's schema.
3. Back up any file you will edit with a unique timestamp and its existing permissions. Backups may contain secrets: keep them local and private. Merge only the OpenScale provider block with a format-aware editor. Preserve JSONC/JSON5/YAML/TOML comments, other providers, defaults, profiles, secrets and unrelated settings. Never overwrite the full file with a downloaded snippet. On reruns update the same provider, without duplicate keys. Preserve existing OpenScale customizations unless they conflict with the requested setup.
4. Ask the user to create an account at https://openscale.so/signup?utm_source=agent_setup&utm_medium=agent, create an API key at https://app.openscale.so/app/keys, and ensure credits are available. Let them enter the key in the agent's local credential flow or private environment configuration. Never request the key in chat, print it, put it in shell history, commit it, or send it to any endpoint except https://api.openscale.so. Reuse an existing working credential without displaying it.
5. Validate configuration syntax and use the agent's supported reload procedure. Select an OpenScale model for the test session; preserve the previous default unless the user explicitly requests changing it. Keep separate vision, audio and auxiliary provider settings unless the user asks to move them too.
6. Fetch https://api.openscale.so/v1/models without authentication to confirm the chosen model ID exists. That checks discovery, not credentials or inference. Through the configured agent, send one short prompt: “Reply with OK.” Confirm the response and selected provider/model. For coding agents, also ask it to use one harmless read-only tool (for example, report the current directory) and answer after the tool result. Do not claim tool support from a text-only test. This small test uses account credits; do not run repeated benchmarks.
7. Report the agent version, changed paths (no secrets), selected model, discovery result, inference result and tool result separately. If credentials or a restart are pending, say “configuration saved; connection not yet verified.” Do not report success from merely writing a file.

## Troubleshooting and undo

- Missing models: check active profile, provider filters, model allowlists and overrides before changing unrelated settings.
- 401: re-enter the key locally. 402: check account credits. 404: check the base URL for the recipe's protocol and the exact live model ID. 429: respect Retry-After and retry with backoff. Do not loop indefinitely.
- Streaming or tool errors: record the agent version and a redacted error, and check that the agent uses the protocol and base URL its recipe states. Do not switch protocols on your own; each recipe names the one that was tested.
- Undo: remove only the OpenScale provider entries added by this setup and restore any selection changed for testing. If restoring a backup, first ensure it will not discard subsequent edits. Remove only credentials created for this setup using the agent's supported local auth flow.
