Skip to content
Tutorial / Step 3

Configuring Models and Compatible Endpoints

Understand the boundaries of Providers, API Keys, and custom OpenAI-compatible Endpoints.

Answer in brief

Understand the boundaries of Providers, API Keys, and custom OpenAI-compatible Endpoints.

The model Provider determines where requests are sent, which model is used, and how authentication works. DeepSeek Harness treats model adaptation as a replaceable capability, so don’t conflate the “Harness” with the “DeepSeek API.”

Minimal Configuration

Add a Provider under Settings → Models in the Web UI, enter the required API Key, and save. After configuring, verify the connection first with a low-risk, low-cost request.

Provider and model changes apply to the next request without a restart. DeepSeek credentials are stored in $DSH_HOME/.credentials.yaml; settings keep a reference and do not reveal a saved key again.

Verify three layers in order: a short text request, a longer stream that ends cleanly, and one harmless tool call. If plain text fails, do not tune prompts or tools.

Custom Compatible Endpoints

If you use an OpenAI-compatible service, you usually need to confirm:

  • Whether the Base URL includes the correct version path;
  • Whether the model ID matches the server side;
  • Whether streaming responses and tool calls are truly compatible;
  • Whether the proxy preserves the extension fields the model needs;
  • Whether error messages leak request bodies or Keys.

“API-format compatible” does not mean identical behavior. In multi-turn tool calling especially, the server may require extra reasoning fields to be preserved.

A custom Provider needs a permanent lowercase ID, Base URL, API protocol, credential, and at least one model. Vision inputs must be declared explicitly; that declaration is a routing assertion, not an automatic capability test.

Credential Policy

Recommended practices:

  1. Use a separate Key for each environment.
  2. Grant the minimum necessary quota and permissions.
  3. Rotate regularly and monitor for abnormal calls.
  4. Store keys only in the Harness credential settings or in protected environment variables.
  5. If a Key ever appears in Git history, revoke it immediately — deleting the file is not enough.

Verification Checklist

  • A plain text request completes.
  • A tool call completes and the flow continues to the next step.
  • Errors produce diagnosable information without exposing the full Key.
  • Configuration behaves as expected after switching sessions or restarting.
  • Billing and rate limits are within an acceptable range.

Signals such as MISSING_CREDENTIAL, UNKNOWN_MODEL, GET /models 401, and image modality mismatch each point to a different layer. Share the model ID, status, and timestamp—not full authorization headers.

Once configured, continue with Workspaces, Sessions, and Permissions.

Primary sources