Both open source. Both running on your own machine. Both billing your own compute. But one is a pluggable harness kernel and the other a workspace that is already assembled — this page draws the line between the two roads, then tells you which to reach for and when.
Skip to the comparison matrix ↓
Staging these two as a head-to-head fight produces a distorted answer.
DeepSeek Harness (dsh on the command line) answers
"how should a harness be built?" It sits on the Cordis plugin system: the kernel handles
mounting, unmounting and dependencies and nothing else, while models, tools, skills,
sessions, sandboxes, storage, loops, scheduling and the UI are all plugins. What it ships
is a minimal kernel you are expected to compose.
Kiro Crew answers "how does a workspace stay alive?" A long-running Gateway keeps sessions, memory, schedules and task checkpoints across restarts; corrections settle into lessons, repeated workflows into skills; cron, webhooks, heartbeats and seven messaging channels sit on top. What it ships is a workspace that is already assembled and keeps getting better. Underneath it drives kiro-cli over ACP — which is to say Kiro Crew is itself an orchestration layer above a harness.
So the matrix below has no winning column and no total score. In most rows the two sides are not doing the same job better or worse; they are doing different jobs. The actual decision waits in the last section: do you want composability, or do you want to skip the assembly?
A pluggable harness kernel
Its thesis is Agent = Model + Harness. The Cordis kernel only mounts, unmounts and resolves plugin dependencies; models, tools, skills, sessions, sandboxes, storage, loops, scheduling and the UI are all plugins, so you can swap any layer in configuration alone.
A workspace that is already assembled
Built around a long-running Gateway, so sessions, memory, schedules and task checkpoints survive restarts. Corrections become durable lessons and repeated patterns get synthesized into named skills, which is what makes it self-learning and self-evolving.
Both commands are taken from official docs and re-checked in August 2026.
Install Node.js, run one command to serve the Web UI, then paste an API key under Settings → Models. No account, no sign-up.
npx @deepseek-ai/dsh web Served at http://127.0.0.1:3080 by default. You can also clone the repo and build from source with pnpm.
On Linux the docs point at a one-line install (a prebuilt, SHA-256-verified wheel from the release CDN). macOS has a universal DMG; Windows has no desktop build yet, so you run the Gateway from a source install and open the dashboard in a browser.
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh The dashboard then lives at http://localhost:5476; first launch walks you through device-code sign-in. Append -s -- --channel insider to track a faster release channel.
Seven dimension groups, stated in parallel. No highlighted winner column, no total score — the difference itself carries more information than a ranking would.
| Dimension | DeepSeek Harness | Kiro Crew |
|---|---|---|
| What they are | ||
| Nature | A pluggable agent harness — a runtime kernel | A persistent development workspace on hardware you control |
| Core thesis | Agent = Model + Harness; everything is a plugin, and every run is traceable | Sessions, memory, schedules and checkpoints survive restarts; it learns (lessons) and evolves (skills) |
| Category here | coding | productivity |
| Maturity | Developer preview; the only published artifact is the v0.1.0-rc.7 pre-release (2026-08-17), and DeepSeek states there WILL be compatibility-breaking changes | Stable v0.2.0 shipped (2026-08-10); every install path offers Stable / Insider / Nightly |
| Written in | TypeScript | Python (the desktop app is an Electron wrapper) |
| License | MIT | Apache-2.0 |
| Architecture and extension | ||
| Extension model | The Cordis kernel: mounting, unmounting and dependencies only — capabilities live in plugins that cooperate through Cordis services and events | MCP servers + markdown skills + hooks, with kirocrew-core / kirocrew-cron built in |
| How you change it | Compose in configuration — select, swap or extend any capability (including the UI and the agent loop) without touching the source | Add plugins, wire up MCP, write a skill, or build an App with the SDK; the kernel itself is not meant to be replaced |
| Runtime shape | Layered from profiles and bundles, with web and headless shipping as templates | A long-running Gateway plus many front ends; run it locally or deploy it remotely |
| Runtime modes | Four of them: Standard mode (the full toolset), Code mode (tools exposed through the Code Mode SDK so the model orchestrates multi-step calls in one TypeScript program), Minimal mode (persistent bash and str_replace_editor only), and Creator mode (runtime inspection, in-memory plugin experiments, preset authoring) | No equivalent notion of modes — behaviour is shaped by agents, skills and governance profiles instead |
| Ecosystem | The GitHub dsh-plugin topic indexes community plugins; a Python SDK and extra CLI modes are documented | Kiro Crew Apps bundle an interface with agents, skills, schedules, integrations and backend services; the App SDK works in TypeScript or Python |
| Memory and persistence | ||
| Session persistence | An append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection | Sessions, memory, active projects and task checkpoints survive restarts; long work resumes from a checkpoint |
| Long-term learning | No built-in mechanism for accumulating experience (skills and custom presets carry that weight) | Corrections and failures become lessons; repeated workflows are synthesized into named skills — both plain markdown you can inspect, edit or delete |
| Retrieval | Resume, fork, search and replay all operate on the same event stream | Architectural decisions and project context land in a knowledge graph backed by vector embeddings and full-text search, so it retrieves instead of re-reading |
| Observability | The Trajectory view: inspect by source exactly what the model saw, and replay a single run's event stream | Dashboard and Activity views stream tool calls, subagent progress, context usage, approvals, memory and logs live, backed by a signed audit log |
| Scheduled / proactive | No scheduler built in (a plugin could supply one) | Timezone-aware cron (per-job timeouts, jitter, skip dates), AutoNudge goal loops, authenticated webhooks, and heartbeat monitors |
| Models and cost | ||
| Where the model comes from | Your own API key: DeepSeek, another provider, or a custom OpenAI-compatible endpoint | Drives kiro-cli over the open Agent Client Protocol (ACP), sharing Kiro's model support and your .kiro configuration |
| Account required | None — paste a key and go | Yes — a one-time device-code sign-in with a Kiro account |
| Software price | MIT, free to self-host | Apache-2.0, free to self-host |
| Where the money goes | Entirely onto your own API key or subscription, billed per token, with no platform in between | Onto your Kiro plan; there is explicitly no separate metering for Kiro Crew, and scheduled jobs that run plain scripts without a model call consume no requests |
| Surfaces | ||
| How you reach it | A CLI and a Web UI | Desktop app, web dashboard (multi-session chat, memory explorer, cron manager, app store, 14 themes), CLI (chat / run / cron / spawn), and 7 messaging channels (Slack, Discord, Telegram, Teams, Webex, WeCom, WeChat) |
| Platforms | cli and web, on a local Node.js runtime | macOS (universal DMG), Linux (one-line install, deb, rpm, AppImage), Windows (no desktop build yet — source install plus a browser), and a multi-arch Docker image |
| Where it runs | A local process that starts and stops with your command | Your Mac, a Docker container, or a remote host; the desktop app can tunnel to a remote Gateway over SSH |
| Security and governance | ||
| Execution safety | Built-in approval and sandbox policy — operations that need authorization prompt you first | Officially 7 layers of defense: OS sandboxing, denied command patterns, bash blocking, input/output validation, sensitive path protection, credential redaction, and signed audit logs |
| Remote access | The Web UI binds to loopback by default | The dashboard binds to loopback and remote access requires token auth; URL exfiltration detection is part of the stack |
| Project governance | GitHub Discussions and Discord; core plugins and base APIs are still moving fast during the preview | A steering committee with proposals filed as pull requests and debated in public; maintainers listed openly |
| Cost of adoption | ||
| Zero to running | Install Node.js → one npx command → paste an API key. Minutes. | One-line install or the desktop app → sign in to Kiro → open the dashboard. Minutes. |
| Cost of deep customization | You have to learn the Cordis plugin model and how profiles and bundles compose — a higher floor, but also a much higher ceiling | Write a markdown skill or point it at an MCP server — a low floor; reach for the App SDK when you want a purpose-built interface |
| The real cost | It is a preview: an upgrade may break your config and your plugins | You need a Kiro plan with headroom, and your account lives inside Kiro |
Free software, and inference is entirely yours to control
Free software, but it needs a Kiro plan to run at all
No total score — four concrete situations and a recommendation for each.
You want to assemble your own harness and swap it layer by layer
The Cordis kernel turns models, tools, sessions, sandboxes, loops, scheduling and even the UI into plugins, so you replace any one of them in configuration without forking. Very few projects ship the harness itself as something you are meant to take apart.
You are benchmarking models in a minimal environment
Minimal mode keeps only a persistent bash and str_replace_editor, which strips the harness itself out of the measurement. The append-only session log then means every benchmark run stays replayable when you want to audit a result.
You want a workspace that stays up, remembers, works on a schedule, and answers wherever you are
The long-running Gateway keeps sessions and memory alive across restarts, cron and AutoNudge keep work moving while you are offline, and 7 messaging channels let you pick the same state back up from Slack or Telegram. That is the part a bare harness kernel expects you to build yourself.
You need to audit every run and reconstruct what the model actually saw
The Trajectory view in DeepSeek Harness is about replaying one run's event stream: every context injection, attributable to its source. The Kiro Crew dashboard and signed audit log are about continuous oversight of a workspace that never stops. Reproducing a single inference favours the former; watching a long-lived workspace favours the latter.
One more thing: this is not an either/or. DeepSeek Harness can serve as an orchestrated runtime, and Kiro Crew reaches outward through MCP. Both are explicit about open standards — one by making every capability a plugin, the other through ACP and MCP. The question was never which one wins, but whether you want to assemble a kernel or start from a workspace that is already assembled.
Not strictly. DeepSeek Harness is the agent harness itself — a runtime kernel. Kiro Crew is a persistent workspace built on top of kiro-cli. They overlap on being open source, self-hosted and bring-your-own-compute, which is why they get compared; but one sells a composable minimal kernel and the other sells a workspace you never have to assemble.
Both are free and open source (MIT and Apache-2.0), and in both cases you pay for inference — but through different doors. DeepSeek Harness uses your own API key against any OpenAI-compatible endpoint. Kiro Crew sends requests through kiro-cli, so usage counts against your Kiro plan and you need one to run it at all. You provide the hardware either way.
It depends on which layer you want to change. To replace the agent loop, session storage, the sandbox or even the UI, take DeepSeek Harness — all of those are plugins there. To add tools, skills or a purpose-built interface on top of capabilities that already work, take Kiro Crew: MCP, markdown skills and the App SDK exist for exactly that, at a far lower cost of entry.
Kiro Crew. Its long-running Gateway exists for this: sessions, memory, schedules and checkpoints survive restarts, and cron, webhooks and heartbeats start work while you are away. DeepSeek Harness has no scheduler built in and its process starts and stops with your command — though in principle a plugin could add one.
Yes, and they do not fight. DeepSeek Harness can act as an orchestrated runtime, and Kiro Crew reaches outward through MCP. Both bet on open standards — one by making every capability a plugin, the other via ACP and MCP. The real question was never which is better, but whether you want to assemble a kernel or start from a workspace that is already assembled.
How we compared. The body of facts comes from our two tool entries, with the fields that go stale fastest — preview status, billing model and account requirements, platform support and install paths — re-fetched from primary sources and checked on 2026-08-19. Sources: the DeepSeek Harness product page, the deepseek-harness repository, the Kiro Crew product page, and the KiroCrew repository. This space moves quickly — DeepSeek Harness especially, since it is still a preview — so re-check the details before you commit.
Keep reading: DeepSeek Harness · Kiro Crew · Best AI coding agents of 2026 · All tools →