DeepSeek Harness Hit 196K GitHub Stars in 13 Days — How to Self-Host It Without Sending Your Prompts to a Non-EU API

On August 13, 2026, DeepSeek open-sourced deepseek-harness, an MIT-licensed agent runtime that had been running its own coding-agent product internally. Thirteen days later, the repository sits at 196,371 stars and 22,270 forks (live GitHub API figures, checked while writing this). That's one of the fastest star trajectories any repository has posted in 2026 — for comparison, most viral AI-tooling launches take months to cross six figures, not two weeks.

The headline framing has mostly been "DeepSeek gave away the thing Anthropic and OpenAI keep behind a paid product": the actual runtime that turns a model into an agent — tool calling, session state, sandboxing, the loop that decides what to do next. That part is true and it's the reason the repo is trending. But the detail that matters more if you're an EU team is buried in the architecture docs, not the launch post: the model itself is just another plugin. You can run the entire harness — tool use, sandboxing, session management, the agent loop — while never sending a single prompt to DeepSeek's own API.

Here's how the plugin system actually works, and how to point it at an EU-hosted, OpenAI-compatible endpoint instead.

What you're actually installing

DeepSeek Harness (package name @deepseek-ai/dsh) is a Node.js agent runtime built on Cordis, an internal composition framework where — per the project's own architecture docs — "every component, including model adapters, tools, session logs, and the agent loop itself, functions as a replaceable plugin with no privileged core." Nothing is hardcoded to DeepSeek's own infrastructure at the framework level; the default DeepSeek adapter is just the plugin that ships enabled out of the box.

Quickest way to try it locally:

npx @deepseek-ai/dsh web

This starts a local Web UI at http://127.0.0.1:3080. For a from-source install (useful if you want to inspect or patch the adapter layer):

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Either way, at this point every request still goes to api.deepseek.com by default, authenticated via a DEEPSEEK_API_KEY environment variable. If your only goal is "run an agent locally," you're done. If your goal is "run this without a mainland-China-based vendor processing every prompt and file my agent reads," keep going — that's a config change, not a fork.

Why the model is "just a plugin" here

Model adapters register on a service key called ctx.llm. The harness ships two adapter packages: llm-deepseek (a direct adapter, hardcoded to DeepSeek's own API) and llm-pi-ai (@deepseek-ai/dsh-llm-pi-ai), described in its own README as a "generic multi-provider adapter" that normalizes OpenAI, Anthropic, DeepSeek, Azure OpenAI, Bedrock, Vertex, and — critically — hand-declared custom routes for providers that aren't in its built-in catalog at all. Per the package docs: "a route pi-ai does not ship is declared outright, so an OpenAI-compatible gateway, a self-hosted server, or a provider newer than the installed catalog is configuration rather than a code change."

That's the sovereignty hook: any inference endpoint that speaks the OpenAI-compatible chat completions protocol can become the harness's brain, with zero patching.

Pointing it at an EU-hosted endpoint

A concrete, verifiable example: IONOS's AI Model Hub runs an OpenAI-compatible inference API out of its Frankfurt (de-txl) datacenter, serving open-weight models including Qwen3 Coder, Llama 3.1, and Mistral variants, with IONOS stating explicitly that all inference processing stays within Germany. (Scaleway's Generative APIs, based in France, is a comparable option with the same OpenAI-compatible surface if you want a second EU provider to weigh against it.) Neither is affiliated with sota.io — they're just two real, checkable examples of "OpenAI-compatible + EU-hosted," which is the only requirement pi-ai's custom-route mechanism cares about.

Harness configuration is layered through Cordis profiles — named compositions stored in the harness home directory, applied as bundle patches → profile patches → home-level patches → CLI overlays. The llm-pi-ai provider block goes in your profile's cordis.patch.yml:

- id: llm
  name: '@deepseek-ai/dsh-llm-pi-ai'
  config:
    providers:
      eu-model-hub:
        displayName: IONOS AI Model Hub (Frankfurt)
        apiKeyEnv: IONOS_MODEL_HUB_API_KEY
        api: openai-completions
        baseURL: https://openai.inference.de-txl.ionos.com/v1
        compat:
          supportsDeveloperRole: false
          maxTokensField: max_tokens
        models:
          - id: meta-llama/Llama-3.3-70B-Instruct
            contextWindow: 128000
            maxTokens: 4096

Set the credential as an environment variable, never inline in the config — apiKeyEnv is a reference resolved per request, so the key itself never touches this file:

export IONOS_MODEL_HUB_API_KEY=sk-...

Then activate the profile and confirm the harness actually picked up the override before you trust it with real work:

dsh --profile web --dump-config

--dump-config prints the fully resolved Cordis tree after all patch layers apply — check that the llm row shows your eu-model-hub provider, not the default llm-deepseek adapter, before you start pointing real repositories at it.

The honest tradeoff

This is not a drop-in swap with identical output quality. DeepSeek's own hosted models (the ones llm-deepseek talks to) are what the harness was tuned against internally — routing through pi-ai to an open-weight model on IONOS or Scaleway means a different model, potentially different tool-calling reliability, and you'll want to check the compat block's thinkingFormat/supportsDeveloperRole/maxTokensField settings against whatever model you pick, since those flags exist specifically because different providers format reasoning traces and role fields differently. Treat the config above as a verified starting point, not a finished setup — test it against your actual agent workflows before relying on it.

What you get in exchange: every prompt, every file the agent reads, every tool-call payload stays inside an EU-hosted, GDPR-scoped inference boundary, using a runtime whose plugin architecture makes that a config file rather than a fork you now have to maintain against upstream. For a 13-day-old repo already past 196K stars, that's a meaningfully different adoption story for EU teams than "install DeepSeek's agent and hope no one asks where the data went."