DeepSeek Harness with an OpenAI-Compatible API

DeepSeek Harness can use an OpenAI-compatible model endpoint when its provider plugin is given four values: a base URL, API key, model id, and Chat Completions path. For reAPI, the base URL is https://api.reapi.ai/v1, and the current model ids are deepseek-v4-flash and deepseek-v4-pro.^[1][2]

The Harness project is still labeled a developer preview, so its command names and configuration file may move. The stable part is the provider contract. Configure that first, then verify a plain message and one tool call before installing extra plugins.

The four values to map

Do not paste the key into a repository file. The provider plugin should read it from an environment variable or the secret store supported by the current Harness release.

At the HTTP layer, the request should resolve to:

POST https://api.reapi.ai/v1/chat/completions
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

This minimum body is enough to test model access outside the Harness before debugging agent behavior:

{
  "model": "deepseek-v4-flash",
  "messages": [
    { "role": "user", "content": "Reply with exactly: provider ok" }
  ],
  "stream": false,
  "max_tokens": 64
}

If that direct request fails, the Harness is not the problem. Fix the URL, key, model id, balance, or network access first.

Start with Flash, promote difficult steps to Pro

Both current DeepSeek V4 variants expose a 1M-token context window, up to 384K output, tool use, thinking mode, vision input, and context caching on the reAPI route.^[2] Their price and intended workload differ sharply.

An agent loop repeats instructions, repository context, and tool schemas. That makes cache behavior unusually important. Flash cache-hit input is 50 times cheaper than its cache-miss input; Pro cache-hit input is 120 times cheaper than its miss rate.

Use Flash as the default while wiring the agent. Route a step to Pro only when its reasoning requirement justifies roughly 12.4 times the cache-miss input rate and output rate.

Keep the stable prefix stable

Context caching is most useful when the beginning of consecutive requests remains identical. In a coding agent, that prefix often contains:

• system instructions;
• repository policy;
• tool definitions and JSON schemas;
• an unchanged architecture document;
• the earlier conversation before the newest tool result.

Reordering tools, adding timestamps near the top, or regenerating the same instructions with small wording changes can prevent prefix reuse. Put volatile state after the stable block.

For example, a Pro loop with 200,000 stable input tokens, 10,000 new input tokens, and 8,000 output tokens costs approximately:

200,000 cached input × $0.0145 / 1,000,000 = $0.0029
 10,000 new input    × $1.74   / 1,000,000 = $0.0174
  8,000 output       × $3.48   / 1,000,000 = $0.02784
                                                -------
                                                $0.04814

Without a cache hit, the same 210,000 input tokens would cost $0.3654 before output. The agent's context layout can matter more than trimming a few hundred tokens from the latest message.

Verify tool calls before adding plugins

A successful chat response does not prove an agent can act. Run a harmless tool-call test next:

{
  "model": "deepseek-v4-flash",
  "messages": [
    { "role": "user", "content": "What files are in the current directory?" }
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "list_files",
        "description": "List files in the current working directory",
        "parameters": { "type": "object", "properties": {} }
      }
    }
  ],
  "tool_choice": "auto"
}

The model should return a structured tool call. The Harness executes the local function and supplies the result on the next turn. If the model prints “I would list the files” as prose, inspect whether the provider plugin forwarded tools and returned the assistant tool-call fields intact.

Five failure points that look like model problems

Thinking is on by default on the current DeepSeek V4 route. Reasoning tokens count toward output usage, so a small output cap can end a tool plan before its user-visible answer.^[2]

Test the full agent loop with a disposable repository

After the message and tool-call probes pass, give the Harness a small repository created for integration testing. It should contain a readable file, a failing test, one protected path, and a harmless command. Ask the agent to diagnose the test, propose a patch, run the narrow check, and stop before any commit or external action.

This reveals four integration failures that a JSON tool-call test cannot:

• relative paths resolve outside the intended working directory;
• command output is truncated before the model sees the error;
• a patch tool changes line endings or file encoding;
• the approval boundary is enforced in the UI but not the plugin.

Repeat the same task after restarting the Harness. Session recovery matters in a coding agent because long runs fail at ordinary boundaries: laptop sleep, process restart, provider timeout, or malformed tool output. A working first turn is not enough.

Log enough to separate runtime and model failures

At minimum, retain a request id, selected model, token usage, cache-hit tokens, finish reason, tool name, tool duration, and redacted error. Do not log API keys or unrestricted file contents.

When an agent stops, these fields answer different questions:

Without that separation, teams often switch models to fix a missing environment variable or rewrite prompts to fix a dropped tool result.

Do not forward hidden reasoning as conversation history

The DeepSeek V4 response can carry reasoning content separately from the final answer. The API documentation advises removing prior reasoning content before the next turn.^[2] Store what is necessary for billing and debugging under the product's policy, but do not append hidden reasoning to the next user/assistant history as if it were ordinary content.

The conversation should preserve the visible assistant response, structured tool calls, and tool results required by the protocol. This keeps the next request valid and prevents the context from growing with material the endpoint does not expect to receive back.

Plugin safety belongs in the setup, not after it

The Harness preview supports plugins, which also means third-party code may receive prompts, files, tool output, or network access. Before enabling one:

1. read the plugin source and permission surface;
2. run the Harness in a disposable repository or sandbox;
3. start with read-only filesystem tools;
4. block secret files and parent directories;
5. require confirmation for shell, package installation, git pushes, and external messages.

The model endpoint cannot correct an over-permissioned local plugin. That boundary belongs to the agent runtime.

The current model contract and SDK examples are in the DeepSeek V4 API documentation, with live prices on the DeepSeek V4 model page.

References

1. DeepSeek, “deepseek-harness” official repository, developer preview, accessed August 23, 2026.
2. reAPI DeepSeek V4 API documentation, accessed August 23, 2026.
3. DeepSeek Harness official product page, accessed August 23, 2026.