DEV Community: Antonne Dillard

One Key for Claude Code, Codex, and dsh: The OpenAI-Compatible Pattern

Antonne Dillard — Tue, 01 Sep 2026 01:26:17 +0000

If you run Claude Code for hard problems, Codex for OpenAI-ecosystem work, and DeepSeek Harness (dsh) for cheap high-volume agents, you currently juggle three separate accounts, three API keys, and three billing pipelines. That is the problem the OpenAI-compatible endpoint pattern exists to remove: one base URL, one key, and each tool keeps speaking its own protocol.

This post shows the pattern concretely — the protocol map, the exact environment variables, and the code samples straight from an integration doc that already supports it. The pattern generalizes to any provider that exposes the same endpoints. I'll use the TeamoRouter endpoint (https://api.teamorouter.cn, keys sk-teamo-...) as the concrete example, because that is the documentation being quoted.

The pattern: one base URL, many protocols

The key fact is that modern coding agents are not locked to one wire format. Each is configured with a base URL and an API key, and each speaks its own protocol on top:

Claude Code speaks the Anthropic protocol (POST /v1/messages) — the same format the anthropic SDK uses.
Codex speaks the OpenAI protocol. That ecosystem exposes two endpoints: POST /v1/chat/completions (Chat Completions) and POST /v1/responses (Responses API). The doc notes /v1/responses works for GPT-series models only — Claude and Gemini get a 400 there.
dsh also speaks the OpenAI protocol via DEEPSEEK_BASE_URL, hitting /v1/chat/completions.
Gemini CLI speaks the Gemini native protocol (/v1beta/models/{model}:generateContent).

The same holds on the language-SDK side: the openai SDK points at the OpenAI-compatible base URL; the anthropic SDK points at the Anthropic base URL; both share the same key.

Protocol	Endpoint	Auth header	Typical tool
Anthropic	`/v1/messages`	`x-api-key` + `anthropic-version: 2023-06-01`	Claude Code, `anthropic` SDK
OpenAI Chat Completions	`/v1/chat/completions`	`Authorization: Bearer`	dsh, GLM, `openai` SDK
OpenAI Responses	`/v1/responses` (GPT only)	`Authorization: Bearer`	Codex-era apps
Gemini native	`/v1beta/models/{model}:generateContent`	`Authorization: Bearer`	Gemini CLI

One key, sk-teamo-<your-key>, is accepted by every row.

Pointing each tool at the same base URL

The integration doc gives the exact environment variables for each agent tool. These are the ones to export. Note the /v1 detail: OpenAI-style SDKs need the /v1 suffix on the base URL, while the Anthropic SDK does not.

Claude Code (Anthropic protocol):

export ANTHROPIC_BASE_URL="https://api.teamorouter.cn"
export ANTHROPIC_API_KEY="sk-teamo-<your-key>"

Codex / OpenAI-protocol tools (Chat Completions or Responses):

export OPENAI_BASE_URL="https://api.teamorouter.cn/v1"
export OPENAI_API_KEY="sk-teamo-<your-key>"

dsh (OpenAI protocol):

export DEEPSEEK_BASE_URL="https://api.teamorouter.cn/v1"
export DEEPSEEK_API_KEY="sk-teamo-<your-key>"

Gemini CLI (Gemini protocol):

export GOOGLE_GEMINI_BASE_URL="https://api.teamorouter.cn"
export GEMINI_API_KEY="sk-teamo-<your-key>"
export GEMINI_API_KEY_AUTH_MECHANISM="bearer"

Drop these into your shell profile (or prefix a command with them) and each tool routes to the same endpoint with the same key.

The same pattern in raw HTTP and SDKs

Calling the endpoints directly, the requests are standard. Anthropic protocol:

curl https://api.teamorouter.cn/v1/messages \
  -H "x-api-key: sk-teamo-<your-key>" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-fable-5","max_tokens":1024,"messages":[{"role":"user","content":"Introduce yourself in one sentence."}]}'

OpenAI protocol (Chat Completions):

curl https://api.teamorouter.cn/v1/chat/completions \
  -H "Authorization: Bearer sk-teamo-<your-key>" \
  -H "content-type: application/json" \
  -d '{"model":"glm-5.3","max_tokens":1024,"messages":[{"role":"user","content":"Hello"}]}'

OpenAI Responses API (GPT-series):

curl https://api.teamorouter.cn/v1/responses \
  -H "Authorization: Bearer sk-teamo-<your-key>" \
  -H "content-type: application/json" \
  -d '{"model":"gpt-5.6-sol","input":"Introduce TeamoRouter in one sentence."}'

Gemini native:

curl "https://api.teamorouter.cn/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "Authorization: Bearer sk-teamo-<your-key>" \
  -H "content-type: application/json" \
  -d '{"contents":[{"role":"user","parts":[{"text":"Introduce yourself."}]}]}'

And in the official SDKs, you only change the constructor. The anthropic SDK (base URL without /v1):

from anthropic import Anthropic

client = Anthropic(
    api_key="sk-teamo-<your-key>",
    base_url="https://api.teamorouter.cn",
)

resp = client.messages.create(
    model="claude-fable-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.content[0].text)

The openai SDK (note the /v1):

from openai import OpenAI

client = OpenAI(
    api_key="sk-teamo-<your-key>",
    base_url="https://api.teamorouter.cn/v1",
)

resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

If your app has already migrated to the Responses API, the openai SDK's client.responses.create(...) works against the same base URL.

Model discovery and the fast-mode option

Before wiring anything up, hit GET /v1/models for the live model list — it lets you confirm exact model IDs (all lowercase, mind the - vs . distinction) before a tool burns requests on a misspelled name:

curl https://api.teamorouter.cn/v1/models \
  -H "Authorization: Bearer sk-teamo-<your-key>"

On the OpenAI side, if your provider supports it, the doc also shows a per-request fast mode. Add "service_tier": "fast" to a Chat Completions or Responses request; the doc quotes it at up to 2.5x standard speed for gpt-5.6-sol, bills at 2x the standard rate, and still accepts the older "priority" value. That is a per-request speed/cost trade you can now make without switching keys.

Why this matters

The win is structural, not cosmetic:

One key, one billing. The source puts it directly: one integration, unified billing — you stop registering and topping up across four platforms. One key switches you between DeepSeek, Claude, GPT, and Gemini.
Route by task, not by tool. The comparison post's own workflow: hard problems to Claude Code (flagship Claude), daily high-frequency work to dsh (cheap DeepSeek). Both tools point at the same endpoint and the same key.
Protocol correctness is a cost lever. This is the subtle one, and the doc is explicit: calling Claude through the OpenAI-compatible format can lose prompt cache and thinking capabilities, which means higher cost and degraded capability — fine for simple chat, wrong for agent workloads. The pattern's discipline — Anthropic protocol for Claude, OpenAI protocol for OpenAI models — is what preserves the caching that keeps bills down.

Honest risks of third-party endpoints

The pattern concentrates your stack on a third-party gateway, and the docs themselves are candid about the edges:

Rate limits on free tiers. The free preview models are capped daily: deepseek-v4-pro-free at 50 requests per day, deepseek-v4-flash-free and glm-5.3-flash-free at 200 requests per day. When the quota is spent, you must switch to the paid equivalents.
Protocol narrowness. /v1/responses is GPT-series only — Claude and Gemini return a 400. Gemini has its own native endpoint; there is no shortcut around picking the right protocol per model.
Latency on big models. Opus/Fable-class models can take seconds to tens of seconds to emit a first token during the thinking phase; the doc says that is normal, not a failure, and recommends streaming ("stream": true) plus client read timeouts up to the server's 600-second cap.
You are adding a dependency. A third-party endpoint is another system that can rate-limit, degrade, or go down. The source's own FAQ is even-handed: connecting to the official API is the simplest path; a gateway like this makes sense when you want one key across many models, a free tier to start with, or better connectivity from your region.
Key hygiene. Keys prefixed sk-teamo- belong in environment variables or a secret manager — never hardcoded, never committed to Git, never shipped in a client. If a key leaks, revoke it and replace it.

Conclusion

The OpenAI-compatible endpoint pattern decouples your agent tools from your model provider: one base URL, one key, and each tool keeps its native protocol — Anthropic for Claude Code, OpenAI for Codex and dsh, Gemini for Gemini CLI. The cost is a new dependency on the gateway, so keep official keys handy for the cases where the third-party route adds more risk than it removes. The payoff is one billing pipeline, unified access to every major model family, and the freedom to route each task to the cheapest model that can actually do it.

DeepSeek V4: $0.14/$0.28 per Million Tokens, and Agent Economics

Antonne Dillard — Mon, 31 Aug 2026 00:39:57 +0000

Your agent loop is a token furnace, and the model you feed it decides whether the monthly bill looks like a coffee habit or a car payment. DeepSeek V4 — the model family that powers the DeepSeek Harness (dsh) agent framework by default — is priced at roughly $0.14 per million input tokens and $0.28 per million output tokens. On a single real task that burns half a million tokens, that works out to about a dime. The same task on a flagship-tier model is a different order of magnitude, and that gap changes how often you are willing to let an agent run at all.

This article walks through the numbers as the DeepSeek ecosystem’s own documentation presents them, does the arithmetic transparently with the assumptions labeled, and gives you a practical rule for when a cheap engine is the right call and when you should still reach for a flagship.

The price, as published
The figure appears in two of the source documents about the DeepSeek Harness:

The comparison post “DeepSeek Harness vs Claude Code / Codex / OpenCode” lists dsh’s cost as starting from $0.14/$0.28 per million tokens, attached to its default model, DeepSeek V4 Flash.
The post “DeepSeek Harness: What It Is” describes DeepSeek V4 pricing as about $0.14 / $0.28 per million tokens and calls it a fraction of flagship-model pricing.
So the working numbers you can rely on: ~$0.14 per M input, ~$0.28 per M output. Everything below is computed from those two rates.

V4 Flash vs V4 Pro
The DeepSeek V4 family in the ecosystem’s model list has two working tiers:

deepseek-v4-flash— the default engine for dsh, and the tier the $0.14/$0.28 rate is attached to.
deepseek-v4-pro— the higher tier, listed alongside Flash. The published docs do not give Pro’s per-token rate, so I won’t invent one; treat Flash as the cheap workhorse and Pro as the step-up option.
Both also ship as free preview models — deepseek-v4-flash-free and deepseek-v4-pro-free — which is where the rate limits come in (more in the limitations section).

Why cheap engines power agent stacks
The agent-loop pattern is what makes price per token the decisive variable. As the comparison post puts it, an agent loop is a token black hole — a real task consuming 500,000 tokens is common. The harness (the loop, tools, file system, shell) decides how many tokens a task spends; the model decides what each of those tokens costs. DeepSeek Harness is explicitly model-agnostic: it defaults to DeepSeek V4 but can be pointed at any OpenAI-compatible endpoint with one environment variable. Its sharpest selling point, though, is unit economics — running agents 30–100x cheaper. The same post states that the identical workload often comes to one-hundredth of the cost of a Claude Code flagship session or a Codex GPT-5.6 session.

Part of the discipline is architectural, not just about the model. dsh is built on the idea that Agent = Model + Harness: the model is the brain, and the harness is everything else — tools, file system, shell, sub-agent orchestration, context access, and knowing when to stop. Because the harness decides what the model actually sees, it also controls the token bill. Its spill storage, for example, writes oversized tool output to disk and hands the model only a locator, so context is no longer blown up by huge text blobs — the source describes this as the real origin of dsh’s “token-saving” reputation. The everything-is-a-plugin design also means you can trim a capability surface (give the agent terminal and file access, but not the network) or swap the provider with one environment variable, without patching a core.

The strategic bet, in the source’s own framing, is that agent frameworks have to be cheap enough to actually run at scale. The popularity numbers back that up: dsh crossed 20,000 GitHub stars in roughly an hour after open-sourcing, and the first day carried it into the 28,000–31,000 range.

The economics math
Let’s do the arithmetic on the source’s own “500K tokens per real task” figure. Agent loops are input-heavy: the bulk of tokens are context, file contents, and tool results, with a smaller share of model-generated output. I’ll show two splits so you can see the sensitivity, and the assumption is right there in the table:

Split (input / output) Input @ $0.14/M Output @ $0.28/M Total per task
80/20 → 400K in, 100K out $0.056 $0.028 ≈ $0.08
50/50 → 250K in, 250K out $0.035 $0.070 ≈ $0.11
At either split, one heavy task is roughly eight to eleven cents on DeepSeek V4 Flash. Run ten of those a day and you are under a dollar and a half. Run fifty and you are still in single-digit dollars per day.

Now compare against the flagship direction, using only the explicit numbers the sources give. A heavy Claude Code session on default flagship models runs to several to tens of dollars, and the same workload on DeepSeek V4 Flash is described as often one-hundredth of that. Eight cents against eight dollars is exactly that ratio, and the 30–100x unit-economics claim brackets the same range. On the Codex side the comparison post is blunter still: GPT-5.6 is a medium-cost default, and Fast mode bills at 2x the standard rate on top. The point isn’t that every task lands at exactly these cents — it’s that the order-of-magnitude gap is real, and it’s arithmetic, not marketing.

When cheap makes sense — and when it doesn’t
The same sources are refreshingly honest about the trade-off, and their selection rule is worth reproducing in substance:

Quality-first → Claude Code, whose reasoning depth and tool reliability remain the benchmark. When one correct answer saves you hours, the flagship premium pays for itself.
Ecosystem-first → Codex, if you are already inside OpenAI/ChatGPT and value Fast mode speed and OAuth login convenience.
Cost-first / high-frequency → dsh + DeepSeek V4 Flash or Pro. When agents run all day, per-token price is the whole game.
The practical pattern most people land on is routing by task: hard problems to a flagship Claude, high-volume daily work to cheap DeepSeek. One harness, two models, and the expensive model only appears when the cheap one’s ceiling is actually the bottleneck.

Honest limitations
dsh is a developer preview. Version 0.1.0-rc.5, explicitly labeled with breaking changes to come. Bet on the concept, not the API surface.
Cheap does not mean flagship quality. Reasoning depth and tool reliability on the flagship tier are still the benchmark; the V4 family trades those for price. If your agent’s correctness ceiling matters more than its burn rate, that is a real cost — just not a per-token one.
Free preview tiers are rate-limited. deepseek-v4-pro-free allows 50 requests per day and deepseek-v4-flash-free allows 200 per day. When the quota is exhausted, the docs tell you to switch to the paid deepseek-v4-pro / deepseek-v4-flash.
Latency is not free either. Large models in these stacks can take seconds to tens of seconds to emit a first token during the thinking phase — a fact the integration docs flag as normal rather than a failure.
Ignore the “Claude Code killer” framing. The sources explicitly call it media narrative — a 0.1.0-rc.5 preview “replacing” a mature product is premature. What is real is the architectural direction, not the headline.
Conclusion
DeepSeek V4’s ~$0.14/$0.28 per million tokens is not a marginal improvement; it moves an agent-heavy workload from “watch the bill” to “forget the bill exists.” The honest counterweight is equally clear in the sources: flagship models still own reasoning depth and tool reliability, so the winning setup is usually a mix — cheap engine for volume, flagship for the hard calls. Price per token decides how many agents you can afford to run; quality per token decides which tasks you should let them touch.

Why Is Token Collective Procurement Cheaper? A Breakdown of Cost Structure and Cache Hit Rate

Antonne Dillard — Tue, 25 Aug 2026 02:51:19 +0000

The One-Sentence Takeaway

Token collective procurement's price advantage is not an unverifiable low price but the result of four engineering layers: discount coefficients, cache-based billing, model tiering, and channel price comparison. When evaluating a procurement platform, you should compare its effective cost, not its nominal unit price.

First, the Real Price Structure: Discount Coefficient × Cache Pricing

Using official list prices and platform discount coefficients as an example (per million tokens):

Model tier	Official output price	Platform discount coefficient	Platform output price
Flagship (GPT-5.6 Sol-class)	$30	0.1 (10% of list)	$3
Value (GPT-5.6 Terra-class)	$12	0.1 (10% of list)	$1.2
Batch (DeepSeek V4 Flash-class)	$1.2	~Official price	≈$1.2

On the cache side, the portion that hits the cache is billed separately at the cached input price (cached_input), which can be as low as roughly 10% of the official full price. Nominal discounts solve the "unit price"; cache-based billing solves "repeated content" — the two are orthogonal cost-reduction dimensions, and combined, the effective cost is far lower than either dimension alone.

The Four Layers of Effective Cost

effective cost = nominal unit price × volume
                × discount coefficient (supplier negotiation + usage scale)
                − cache savings (cache hit rate × cache price gap)
                − tiering savings (right-sizing high-spec tasks to matched models)
                − price-comparison savings (real-time channel quality monitoring → dispatch to best channel)

Layer 1: Discount Coefficient (Supplier Negotiation + Usage Scale)

Platforms gain bargaining power through first-party supplier aggregation and quality distribution channels, then set discount coefficients per vendor (e.g., 10% of list for the OpenAI family, 20% for Anthropic, 20% for Google). Discounts float with cumulative usage — the larger the scale, the more room for negotiation.

Layer 2: Cache-Based Billing (The Most Underrated Cost Saver)

Coding agents' requests have a highly repetitive prefix structure (system prompt, persona settings, context scaffolding). Once they hit the prefix cache, they are billed at the cached_input rate. Quantitative example: official output $12/M, cache read price $1.2/M, monthly usage 80M tokens, 60% hit rate:

Without cache-based billing: 80M × $12 = $960
With cache-based billing (60% hit): 32M × $12 + 48M × $1.2 = $441.6
The cache layer alone cuts costs by roughly 54%.

Layer 3: Model Tiering (Match Specs to Task Complexity)

Flagship-model capability is reserved for difficult reasoning; routine and batch tasks are routed to models matched to the spec. Quantitative example: monthly usage 100M tokens, official output price flagship $30/M, mid-tier $12/M, batch $1.2/M:

All flagship: 100M × $30 = $3,000
Tiered (30% flagship + 40% mid-tier + 30% batch): 30×30 + 40×12 + 30×1.2 = $1,416
Model tiering alone cuts costs by roughly 53%, and the quality loss is negligible — because high-spec resources are only allocated to high-value tasks.

Layer 4: Channel Price Comparison (Real-Time Dispatch to the Best Channel)

The platform's routing engine monitors each channel's latency (TTFT), stability, and price in real time, dispatching requests to the channel with the best current price-performance ratio; when a single upstream provider raises prices or fails, it switches automatically. This layer addresses the cost and availability risk of vendor lock-in.

Which "Bargains" You Should Not Touch

A low price whose nominal unit price sits significantly below upstream cost and cannot be attributed to any of the engineering layers above usually corresponds to shared quota, abnormal channels, or missing cache capability:

Shared quota: abnormal concurrency patterns trigger upstream risk control and mass account bans;
Abnormal channels: quota of unknown origin, with no guarantee of availability;
Fake low prices that lack cache-based billing: the nominal unit price is low, but with no cached_input billing, repeated content is billed at full price — so the effective cost is actually higher.

The screening formula:

explainable low price = discount coefficient (≤50%) + cache billing (≥30–50% hit rate)
                      + model tiering (≥40–50%) + channel price comparison (bounded)
unexplainable low price = none of the above four factors can be attributed,
                          and the nominal unit price is more than 30% below official  →  exclude

Common Questions

Q: What determines the cache hit rate?
The stability of the request prefix. By keeping the system prompt, persona settings, and few-shot examples fixed as a stable prefix, you can raise the hit rate. The gateway side automatically recognizes and bills at the cached_input rate.

Q: How do discount coefficients relate to official pricing?
Discount coefficients are determined by supplier negotiation and usage scale (e.g., 10% of list for the OpenAI family) and float with cumulative usage; a healthy price structure is always explainable and auditable.

Q: Does model tiering affect output quality?
It depends on whether the tiering is sensible. Grade by task complexity and value rather than randomly downgrading; high-value tasks are still routed to flagship models.

Q: Can you get cache pricing with a direct official connection?
Yes, but you must precisely control the prefix structure and configure caching yourself, and you would lack tiered routing and channel price comparison. The value of a collective procurement platform is in automating cache-based billing, tiering, and price comparison.

Summary

Token collective procurement's price advantage = the four-layer engineering of discount coefficient + cache-based billing + model tiering + channel price comparison. The cache and tiering layers combined typically cut effective costs by more than 50%. Evaluate platforms by effective cost, and be wary of low prices that cannot be attributed. Sign up for TeamoRouter to verify your effective cost with GPT at 10% of list, Claude at 20% of list, and cached_input cache billing.

DeepSeek Harness Architecture: The Ultimate Guide to 'Everything Is a Plugin'

Antonne Dillard — Tue, 18 Aug 2026 02:09:58 +0000

"Everything is a plugin" is the kind of line that sounds like marketing. In DeepSeek Harness (dsh) it's literal — and it's the source of every useful capability the framework has.

What is DeepSeek Harness (dsh)?

DeepSeek Harness is DeepSeek AI's open-source agent harness — the framework that turns a language model into a worker that can edit code and run commands. It follows the formula Agent = Model + Harness: the model (usually DeepSeek V4) is the brain; the harness is everything else — tools, filesystem, shell, sub-agents. Released under MIT, powered by the Cordis runtime, and in developer preview.

The key architectural claim is this: the filesystem, the shell, the model adapter, the Web UI, and sub-agents are not hardcoded. They're swappable plugins, orchestrated by a runtime called Cordis.

The two ideas behind Cordis

Cordis is the MIT plugin runtime that drives dsh. Two ideas capture it:

Registrations are reversible effects — tools, providers, and listeners install via ctx.effect() / ctx.on(), so reload and teardown unwind them cleanly.
Spatiotemporal composability — plugins compose in one context by declaration order; capabilities stack and unstack.

You don't need to read the source. Just remember: dsh's capability = the combination of plugins you load. Add a plugin to gain ability, remove one to lose it.

Seams: the "three-role" swappable capability

One word recurs in dsh's docs — seam, a swappable capability. It's the mechanism behind "swap one provider and change the whole product." A seam has three roles:

Role	Responsibility	Example (shell)
Service Definition	Declares the interface	`dsh-shell`
Service Provider	Implements it	`dsh-bash-local` / `dsh-bash-sandbox`
Consumer	The model-facing tool	`dsh-tool-bash`

Because the three are decoupled, changing an implementation touches only the Provider. Move the shell from local to a remote sandbox and the bash tool's model-visible schema doesn't change — invisible to the agent.

Three practical payoffs

1. Trimmable capability surface. Not every agent needs network. Mount only bash + file ops, omit web search → a more controllable, cheaper agent.

2. Swappable providers. The model backend is itself a seam — this is exactly how dsh plugs into DeepSeek V4 Pro (1M context, flagship reasoning) or V4 Flash (fast + cheap). Point DEEPSEEK_BASE_URL from the official API to any endpoint — one env var, nothing else changes:

export DEEPSEEK_BASE_URL="https://api.teamorouter.com/v1"
export DEEPSEEK_API_KEY="sk-teamo-your-key"

3. Custom tools. Want a tool that queries your internal ticketing system? Write a Cordis plugin, register it on ctx.tools, done — faster than waiting for official support.

The mental model: a slot board

[ bash ] [ files ] [ subagent ] [ web-search ] [ model-adapter ] ...
        └────────── all mounted on the Cordis runtime ──────────┘
                              │
                   the agent's actual capability

You decide what's plugged in. That model explains most of dsh's design — why the default preset bundles bash + file ops, and why headless mode needs only env vars.

The direct value is two things: cheaper (plug a cheap DeepSeek V4 in and the same loop costs an order of magnitude less) and more control (you decide exactly what the agent can touch).

Try the architecture → Get a key on TeamoRouter

The Ultimate Guide to DeepSeek Harness (DSH): What It Is and How to Install

Antonne Dillard — Mon, 17 Aug 2026 02:40:04 +0000

DeepSeek just shipped an open-source agent harness — and you can run it with one command:

npx @deepseek-ai/dsh web

That pulls the package and starts a Web UI at http://127.0.0.1:3080. No clone, no build.

What is DeepSeek Harness (dsh)?

DeepSeek Harness (dsh) is DeepSeek AI's open-source agent harness — the framework that turns a language model into a worker that can actually edit code and run commands. Built on an "everything is a plugin" architecture, powered by the Cordis runtime, and released under the MIT license. It's in developer preview, so interfaces will still shift — but for solo devs and cheap agent experiments it's fully usable today.

The industry has converged on a clean formula:

Agent = Model + Harness

The model is the brain — the weights that predict tokens. The harness is everything else: the tools the agent can call, the filesystem and shell it can touch, how sub-agents pass context, and when execution stops. A bare model is bad at memory and tool use on its own; the harness turns a chat model into a worker.

What model does it run?

dsh is model-agnostic, but its natural fit is the DeepSeek V4 family:

DeepSeek V4 Pro — the flagship reasoning model, up to 1M context, multiple reasoning-effort levels.
DeepSeek V4 Flash — the fast, cheap sibling for high-frequency work.

To route dsh through a free tier, set two env vars:

export DEEPSEEK_API_KEY="sk-teamo-your-key"
export DEEPSEEK_BASE_URL="https://api.teamorouter.com/v1"

Then npx @deepseek-ai/dsh web again. That's the whole setup — dsh speaks the OpenAI protocol, so any OpenAI-compatible endpoint works.

What's in the Web UI

http://127.0.0.1:3080 is the front-end of an agent runtime:

Sessions — create, switch, rename, run several in parallel.
Model selection — swap deepseek-v4-pro vs deepseek-v4-flash per session.
Tool panel — the tools the agent can call: bash, file read/write, sub-agents, web search.
Goals — break long tasks into stateful goals, pause / resume.

Don't treat it as "another chat window" — you give a goal, the agent loops over tools until done, and the UI is your observation deck.

Prove it works

Give the agent this task:

List the current directory, find the README, summarize its first
paragraph in one sentence, and write it to /tmp/summary.txt

dsh calls bash and the file tools in sequence, then reports back. That's the whole idea — the harness turns a model into a worker.

Run your first agent loop → Get a free key on TeamoRouter

What Is Kimi K3? Complete 2026 Guide to Moonshot AI's Open Source Model

Antonne Dillard — Tue, 28 Jul 2026 04:11:30 +0000

Quick Answer

Kimi K3 is a frontier-class, open-source large language model built by Moonshot AI (月之暗面). Released in July 2026, it packs 2.8 trillion parameters, a 1-million-token context window, and a novel hybrid architecture combining linear and full attention mechanisms. It is the first open-source model to beat Claude and GPT in frontend coding benchmarks, and it costs significantly less per solved task. This guide covers everything you need to know: what K3 is, how it works under the hood, how it compares to the competition, and how to start using it today.

What Is Kimi K3?

Kimi K3 is the third generation of Moonshot AI's flagship model family, succeeding the well-regarded Kimi K2 and K2.5. Unlike many Chinese AI models that prioritize benchmark scores over real-world usability, K3 was designed from the ground up for long-horizon agentic tasks — the kind where an AI codes a full feature, navigates a large codebase, or maintains coherent reasoning across hundreds of thousands of tokens.

Moonshot AI announced K3 on July 16, 2026, and released the open weights on July 27, 2026 — a deliberate five-day gap that let the inference ecosystem (vLLM, NVIDIA, AMD) prepare day-zero support. The model is available through the Kimi web app, the Kimi API, the Kimi Code terminal agent, and third-party API gateways.

Key Specifications at a Glance

Spec	Detail
Parameters	2.8 trillion (Mixture-of-Experts)
Context window	1,048,576 tokens (1M)
Architecture	Hybrid: KDA linear attention + MLA full attention + sparse MoE
Experts	896 routed experts, 16 active per token, plus shared experts
Depth	93 layers
Quantization	MXFP4 weights in release configuration
Multimodality	Native vision support with dedicated vision tower
Activation	SiTU (in MoE path)
License	Open weights (specific license at release)

The Architecture That Makes K3 Different

K3 is not simply a scaled-up Kimi K2. It introduces several architectural innovations that change how the model handles long contexts and reduces serving costs.

KDA (Kimi Delta Attention): The Core Innovation

Traditional Transformer models use full attention — every token attends to every other token, storing per-token key-value pairs in a KV cache. This works well but scales poorly: a 1M-token context with a model this large would consume enormous GPU memory just for the cache.

KDA replaces most attention layers with a recurrent linear attention mechanism. Instead of storing per-token KV pairs, it maintains a fixed-size matrix state plus a short convolution state. The recurrent state updates incrementally as new tokens arrive — like an RNN, but with far better parallelization during training. This is how K3 achieves its 1M-token context without requiring a data center's worth of VRAM per request.

Attention Residuals (AttnRes): Cross-Layer Memory

In a standard Transformer, information flows through layers sequentially via a single residual stream. K3 adds Attention Residuals — shortcuts that let deeper layers retrieve representations from much earlier layer blocks. Think of it as the model being able to "look back" across dozens of layers instead of relying on whatever survived the journey through intermediate layers. The vLLM team describes this as "creating cross-layer memory traffic" that improves the model's ability to maintain context over extremely long sequences.

The Hybrid Design

K3 alternates between KDA layers (efficient, recurrent) and MLA layers (Multi-head Latent Attention, a compressed full-attention variant) every four layers. This gives the model the efficiency of linear attention for most of the sequence while periodically re-establishing global context with full attention. The 896 MoE experts (16 active per token) handle the feed-forward computation, with shared experts always active for common patterns.

How Kimi K3 Compares to GPT and Claude

K3's benchmark performance tells a clear story: it is broadly competitive with the best closed-source models, and in some domains it leads outright.

DeepSWE (Software Engineering)

On the DeepSWE benchmark, which tests real-world software engineering tasks:

Model	pass@1	pass@4	Cost/Rollout	Tasks Solved per $100
Kimi K3	68.5%	89.4%	$4.65	14.7
Claude Fable 5	69.9%	88.5%	$13.41	5.3
GPT-5.6 Sol	72.7%	85.8%	$8.37	8.2

K3 trails slightly on single-attempt accuracy but pulls ahead with multiple attempts — and solves roughly 2.8x more tasks per dollar than either competitor.

Frontend Code Arena

This is where K3 really shines. In anonymous blind tests on the Frontend Code Arena benchmark, K3 scored 1,679 points — ranking #1 overall, ahead of Claude Fable 5 (1,631) and GPT-5.6 Sol (1,618). It took first place in 6 of 7 domains: Brand & Marketing, Reference-Based Design, Data & Analytics, Consumer Product, Simulations, and Content Creation Tools. This was a 17-position leap from Kimi K2.6's #18 ranking.

SWE Marathon

For ultra-long software engineering tasks, K3 ranked #1 on the SWE Marathon benchmark. It also scored 91.2 on BrowseComp and came in #2 on Terminal Bench 2.1 and FrontierSWE.

Language-Specific Strengths

K3 shows particular strength in Go (79% vs Fable 5's 71%), while Fable 5 leads in Python (74% vs 68%), JavaScript (70% vs 65%), TypeScript (64% vs 60%), and Rust (75% vs 65%). If your stack is Go-heavy, K3 is arguably the best model available.

Why Kimi K3 Matters

K3 represents several converging trends in AI that make it significant beyond raw benchmark numbers:

Open-source catching up to closed-source. K3 matches or exceeds GPT-5.6 Sol and Claude Fable 5 in key coding benchmarks while being fully open-weight. This means you can self-host it, fine-tune it, and inspect its architecture — none of which you can do with GPT or Claude.
Cost efficiency as a competitive moat. K3's aggressive input caching (90% discount on cache hits, with observed hit rates above 90% in coding scenarios) means the effective per-task cost is dramatically lower than sticker prices suggest. Moonshot's Mooncake serving architecture is purpose-built for this.
The return of architectural innovation. Rather than scaling a standard Transformer, Moonshot invested in novel attention mechanisms (KDA, AttnRes) that genuinely change the compute/capability tradeoff curve.

How to Access Kimi K3

You have several options, each suited to different use cases:

Kimi Web App (kimi.com)

The easiest way to try K3. Sign up at kimi.com and start chatting. Note that free-tier users face context window and rate limitations. Paid subscriptions unlock the full 1M-token context.

Kimi API

For programmatic access, the Kimi API is OpenAI-compatible. Get an API key from platform.moonshot.ai (international) or platform.moonshot.cn (China), then use the model ID kimi-k3 with the base URL https://api.moonshot.ai/v1. API pricing is $3.00/M input tokens (cache miss), $0.30/M input tokens (cache hit), and $15.00/M output tokens. A typical single API call costs about $0.007.

API Gateways (Recommended for Production)

For production workloads, running directly against the Moonshot API introduces single-provider risk. What happens during an outage or when rate limits hit? This is where API gateways like TeamoRouter come in.

TeamoRouter acts as a stable API gateway that sits between your application and the Kimi K3 API. It provides automatic failover, intelligent routing, and unified billing across multiple providers — so if Moonshot's API experiences issues, your requests seamlessly fall back to alternative endpoints without any code changes. For teams building on K3, this eliminates the single biggest operational risk of depending on one API provider.

Kimi Code (Terminal Agent)

Moonshot's native coding agent, available via npm i @moonshot-ai/kimi-code. It requires a paid subscription and provides K3-powered code generation, debugging, and repository navigation directly in your terminal.

Self-Hosting

With open weights available, you can deploy K3 on your own infrastructure. Be aware that this requires substantial GPU resources — multi-node clusters with high-VRAM GPUs. The vLLM project provides day-zero inference support with validated NVIDIA and AMD launch recipes.

Limitations to Know

K3 is impressive but not without tradeoffs:

Inference speed: K3 generates ~33-35 tokens per second on the standard tier, notably slower than GPT-5.6 Sol (~80+ t/s) and Claude Fable 5 (~60+ t/s). The "Kimi K3 Fast" variant improves this to ~117 t/s.
Always-on reasoning: At launch, only reasoning_effort="max" was available. You cannot dial down thinking to save costs on simple queries. Lighter modes are promised for later releases.
Parameter lock: Temperature, top_p, and penalty parameters are fixed. Developers must omit these from API requests.
Image handling: Public image URLs are not supported through the API at launch. Use base64 encoding or uploaded files for vision inputs.
Reliability gap: While K3 casts a wide net (high pass@k), both Fable 5 and Sol solve more tasks consistently across all attempts. K3 is better for exploration and iteration than for one-shot perfection.

The Launch Day Story

K3's launch was dramatic. Within 48 hours of release, Moonshot AI paused new consumer subscriptions — the existing GPU cluster could not handle the exponential call volume. Elon Musk commented "Impressive" on independent benchmark results. Chinese tech media called it a potential "DeepSeek moment" — a reference to when DeepSeek-R1 stunned the world by matching frontier models at a fraction of the cost. Whether K3 achieves the same mindshare remains to be seen, but the technical foundation is there.

Getting Started with Kimi K3

The fastest way to start building with K3:

Try it free at kimi.com to understand its capabilities.
Get an API key from platform.moonshot.ai and make your first API call in under 5 minutes (it's OpenAI-compatible — just change the base URL and model name).
For production, consider routing through TeamoRouter for automatic failover, load balancing, and stable access across multiple providers. TeamoRouter gives you a single endpoint that handles provider selection, health monitoring, and failover — so you focus on building, not on API reliability.

Kimi K3 is a genuine milestone: the first open-source model that competes head-to-head with the best closed-source systems in the areas that matter most to developers. Its hybrid architecture points toward a future where long-context AI is not a premium feature but the default. And with open weights now available, the ecosystem around K3 is only going to grow.