DeepSeek Harness vs Claude Code vs Codex vs Muse Code : le framework open source pour agents IA en 2026

En août 2026, DeepSeek a rendu disponible DeepSeek Harness (dsh) en developer preview. Le projet est open source sous licence MIT et ne se présente pas comme un simple agent de programmation en terminal. DeepSeek le décrit comme un agent harness, c’est-à-dire la couche qui relie le modèle aux outils, aux sessions, au sandbox, aux politiques d’approbation, aux sous-agents, au web, aux skills, aux workflows et à l’interface utilisateur.^[1][2]

Son principe central est :

Everything is a plugin.

Les modèles, tools, skills, sessions, sandboxes, storage, agent loop, scheduling, subagents et même l’UI sont composés comme plugins au-dessus de Cordis.^[1][3][11]

Cela ne signifie pas que DSH est aujourd’hui plus mature que Claude Code, Codex ou Muse Code. Le fichier officiel SAFETY.md précise qu’il s’agit d’un experimental developer-preview software, qui n’a pas fait l’objet d’un audit de sécurité et ne doit pas être considéré comme secure ou production-ready.^[6]

La version publique npm @deepseek-ai/dsh vérifiée le 31 août est 0.1.1-rc.2.^[10]

En bref : DeepSeek Harness est surtout intéressant comme infrastructure ouverte et remplaçable pour construire ses propres agents. Il peut aussi lancer le véritable Claude Code et Codex comme sous-agents, ce qui lui permet de devenir une couche d’orchestration au-dessus de ces produits.^[8][9]

État des informations : 31 août 2026.

TL;DR

Qu’est-ce qu’un agent harness ?

Un modèle de langage seul n’est pas un agent complet.

Il peut produire :

texte
code
plans
tool calls

mais une autre couche doit gérer les outils, l’exécution, les permissions, l’historique, la reprise, la délégation, les modèles externes et l’interface.

DeepSeek résume cela par :

Agent = Model + Harness

^[1]

Pourquoi pas simplement un nouveau CLI ?

DSH possède un CLI, une Web UI et un mode headless, mais vise plus large qu’un assistant de code unique.^[1][3][5]

L’idée est :

ne pas hardcoder les capacités dans la boucle,
mais les monter comme composants remplaçables

Cela concerne model adapters, tools, filesystem, shell, sandbox, skills, web access, persistence, compaction, subagents, jobs, scheduling, approvals et UI.^[1][3]

Même l’agent loop est un plugin

La documentation d’architecture indique que model adapter, tool registry, session log et agent loop sont eux-mêmes des plugins.^[3]

Dans de nombreux produits, on peut ajouter des tools mais la boucle :

prompt → model → tool → model → finish

reste fixe.

Dans DSH, elle peut être remplacée par composition. La documentation indique qu’il n’existe pas de privileged core à patcher.^[3]

Cordis comme fondation

DeepSeek Harness repose sur Cordis.^[1][3]

Le 26 août 2026, des auteurs liés à Peking University et DeepSeek-AI ont publié A Programming Paradigm for Spatiotemporal Composability.^[11]

Cordis distingue notamment :

• temporal composability : retirer un composant et annuler ses effets,
• spatial composability : déclarer les dépendances et réagir aux changements du contexte.

Le framework met en œuvre effect tracking, dependency resolution, declarative loading, configuration reconciliation et hot module replacement.^[11]

Profiles et bundles

Un dsh actif est un arbre de plugins composé au démarrage.^[3]

Les profiles sont des compositions nommées, notamment :

web
headless

Les bundles distribuent configuration Cordis et code.

dsh-base apporte model adapters, tools, persistence, sandbox, approval policy, settings, credentials et telemetry.^[3]

Configuration par couches

Les couches se superposent selon un ordre défini :^[3]

bundles
↓
profile cordis.patch.yml
↓
home cordis.patch.yml
↓
--patch overlay

La configuration effective est visible avec :

dsh --profile web --dump-config

Web UI

Le quick start :

npx @deepseek-ai/dsh web

^[1][2]

La Web UI est servie localement par défaut sur :

http://127.0.0.1:3080

^[2]

L’agent peut lire et modifier des fichiers, exécuter des commandes, déléguer du travail et maintenir un plan.^[5]

DeepSeek Harness n’est pas limité aux modèles DeepSeek

La page Models permet d’utiliser d’autres providers.^[4]

La documentation cite notamment :

• Anthropic,
• OpenAI,
• Amazon Bedrock,
• Google Vertex,
• Azure,
• Codex,

ainsi que des custom providers pour gateways internes, serveurs self-hosted et endpoints compatibles OpenAI.^[4]

Un modèle personnalisé via LLM adapter

ctx.llm est un registre d’adapters.^[3][4]

Exemple conceptuel :

class MyAdapter extends LlmAdapter {
  async *stream(options) {
    // provider implementation
  }
}

L’adapter convertit les requêtes Harness vers le protocole du provider.^[4]

Changer de modèle sans redémarrer

La configuration d’un provider devient utilisable dès la requête suivante sans restart du serveur.^[4]

Le modèle choisi devient le défaut pour les nouvelles sessions, tandis qu’une session déjà utilisée conserve le modèle enregistré dans son log.^[4]

Quatre runtime modes

DeepSeek documente quatre modes.^[1]

Standard

Agent complet avec fichiers, shell, search, skills, planning, goals, subagents et workflows.

Code

Même base, avec Code Mode SDK permettant au modèle de regrouper plusieurs opérations dans un programme TypeScript.^[1]

Minimal

persistent bash
str_replace_editor

Pensé notamment pour des évaluations à tool surface réduit.^[1]

Creator

Pour inspecter le runtime, expérimenter avec des plugins et construire des presets.^[1]

Append-only session log

DeepSeek indique que tout ce que le modèle voit est enregistré dans un append-only session log.^[1]

Cela comprend system prompts, reasoning, tool calls/results, subagent scheduling et context injections.^[1][3]

Resume, fork, search et replay reposent sur ce même event stream.

« Model-visible means logged »

La documentation formule explicitement :

Model-visible means logged.

^[3]

Tout contenu envoyé au modèle doit pouvoir être reconstruit depuis le session log.

C’est utile pour l’audit et le debugging.

Sous-agents comme capability

ctx.subagents est un registre de providers.^[8]

La documentation liste :

spawn-in-process
fork
ACP
Codex
Claude Code
dsh-sdk

^[8]

Le parent délègue donc à une interface commune.

DeepSeek Harness peut lancer le vrai Codex

Le package documenté est :

@deepseek-ai/dsh-subagent-codex

^[9]

Il lance le véritable produit Codex, pas seulement une requête HTTP vers un modèle.

La note d’implémentation cite :

@openai/[email protected]

et app-server --stdio.^[9]

Chaque appel crée un processus frais, un thread ephemeral et une tâche one-shot.

Il peut aussi déléguer à Claude Code

Un provider frère intègre le véritable Claude Code.^[8][9]

Le schéma est :

task
→ subagent provider
→ Claude Code
→ résultat final

Le child reçoit une tâche autonome et le workspace, sans récupérer automatiquement toute la conversation parent.^[9]

La comparaison directe est donc incomplète

Le modèle mental plus juste est :

DeepSeek Harness
├── runtime propre
├── providers de modèles
├── Claude Code comme child
└── Codex comme child

DSH peut être concurrent et orchestrateur.

Cela augmente aussi la complexité et la surface d’attaque.

Agent Teams est expérimental

Le repo contient un mécanisme Agent Teams avec durable roster, task board, mailbox et child sessions.^[3]

Mais la documentation le classe comme experimental private opt-in coordination seam.^[3]

Il ne faut pas le présenter comme une API stable.

DeepSeek Harness vs Claude Code

Claude Code est un produit de coding agent orienté software engineering. Il peut explorer un codebase, modifier des fichiers, lancer commandes et tests, utiliser Git et MCP.^[12]

Différence principale :

Claude Code = produit fini
DSH = framework/runtime composable

Le repo Claude Code indique que l’usage relève des Anthropic Commercial Terms.^[12]

DSH est sous MIT.^[1][2]

DeepSeek Harness vs OpenAI Codex

Correction importante : Codex CLI est lui aussi open source.

Le repo openai/codex est sous :

Apache-2.0

^[13]

Il est donc faux de présenter DSH comme une alternative open source à un Codex fermé.

Codex est surtout une plateforme coding agent avec CLI, IDE, desktop, cloud, sandbox, approvals et politiques réseau.^[13]

DSH est davantage une couche de composition et peut lancer Codex comme child.^[9]

DeepSeek Harness vs Muse Code

Meta a lancé Muse Code le 5 août 2026 en beta avec Muse Spark 1.2.^[14]

Muse Code et son modèle ont été co-entraînés pour planning, tool use, compaction, subagents et tâches longues.^[14]

Différence :

Muse = optimisation conjointe model + harness
DSH = interchangeabilité model + capabilities

Tableau comparatif

Pourquoi pas de benchmark en pourcentage ?

Nous n’avons trouvé aucun benchmark public maintenant constants :

même modèle
même prompt
même repo
mêmes tools
même sandbox
même budget
même temps
même grading

Comparer Opus + Claude Code à un modèle DeepSeek + DSH mesure plusieurs variables à la fois.

Comment benchmarker correctement ?

Test A : même modèle

même modèle + DSH
vs
même modèle + harness minimal

Test B : produit complet

Claude + Claude Code
OpenAI + Codex
Muse Spark + Muse Code
modèle choisi + DSH

Mesurer completion rate, tests, coût, temps, tool calls, interventions humaines, régressions, changements hors scope et restart recovery.

Sécurité : le point le plus important

SAFETY.md indique que DSH peut exécuter du code généré, des commandes, charger des plugins tiers et accéder au réseau, aux processus, aux credentials et aux fichiers.^[6]

Des erreurs du modèle, bugs, mauvaises configurations, entrées malveillantes ou plugins non fiables peuvent modifier/supprimer des fichiers ou divulguer des données.^[6]

Le sandbox ne garantit pas l’isolation

DeepSeek écrit que sandboxing, approval prompts et permission controls réduisent le risque mais ne garantissent pas l’isolation.^[6]

Le projet recommande least privilege, VM/container jetable, backups, limitation des secrets et review des plugins/commandes.

Local-first ne veut pas dire local-only

La Data Processing Statement décrit DSH comme local-first.^[7]

Inputs, outputs, contexte, tool calls, pièces jointes, chemins et logs sont stockés localement par défaut.

Mais modèles externes, web tools, MCP et plugins peuvent envoyer des données à leurs providers.^[7]

local-first ≠ local-only

Telemetry : situation nuancée

Le comportement telemetry a changé en août.^[16]

FULL nécessite une configuration explicite et les profils frais n’envoient pas automatiquement le session log complet. Le feedback peut activer un chemin plus limité selon le mode.^[16]

La Data Processing Statement mentionne aussi des informations de configuration anonymisées et project lists pouvant être rapportées avec possibilité de désactivation.^[7]

Il faut donc vérifier la version et la configuration réellement déployées.

Developer preview = breaking changes réels

Le README avertit :

THERE WILL BE COMPATIBILITY-BREAKING CHANGES.

^[2]

Plusieurs RC ont été publiées rapidement en août jusqu’à 0.1.1-rc.2.^[10]

Des discussions GitHub contiennent également des rapports communautaires sur des dist-tags npm incohérents pour certains plugins autour de rc.2.^[15]

Ce ne sont pas des confirmations officielles universelles, mais cela renforce l’avertissement upstream.

Faut-il déjà développer des plugins ?

Oui pour la R&D, si l’on accepte le churn.

Les extension points officiels couvrent tools, LLM adapters, settings cards, storage, filesystem, sandbox, subagent providers et d’autres capabilities.^[3][4]

Pour une API stable sur plusieurs années, le projet est encore trop jeune.

Pour qui DSH est-il pertinent ?

Agent platform teams

Pour créer une plateforme interne indépendante d’un seul modèle.

AI infrastructure R&D

Pour expérimenter avec loops, context policies, routing, subagents et sandboxes.

Environnements multi-model

Pour un control plane commun sur DeepSeek, Anthropic, OpenAI, gateways internes et modèles self-hosted.

Benchmarking

Minimal mode permet de réduire la tool surface.^[1]

Quand choisir plutôt Claude Code, Codex ou Muse Code ?

Claude Code si l’on veut un coding agent mature centré sur l’écosystème Claude.

Codex si l’on veut CLI, IDE, desktop et cloud dans l’écosystème OpenAI avec des contrôles de sandbox et governance développés.^[13]

Muse Code si l’on recherche une paire model+harness co-optimisée avec Muse Spark 1.2.^[14]

DeepSeek Harness si l’objectif est d’abord :

construire son propre harness
plutôt qu'utiliser simplement un agent prêt

Checklist avant production

Versions et supply chain

• Pinner @deepseek-ai/dsh.
• Vérifier le scope @deepseek-ai.
• Vérifier le repo upstream.
• Ne pas remplacer upstream par un wrapper inconnu.
• Pinner les plugins.
• Vérifier la compatibilité CLI/plugins.

Runtime

• Compte utilisateur dédié.
• Workspace minimal.
• Secrets hors workspace.
• Backups.
• Approval pour commandes destructives.
• Réseau limité.
• Tests négatifs du sandbox.
• Ne pas considérer le sandbox comme une frontière parfaite.

Modèles

• Savoir quel provider reçoit le code.
• Vérifier la retention policy.
• TLS/auth pour gateway interne.
• API keys minimales.
• Router les modèles avec logs.
• Tester plusieurs modèles.

Plugins

• Review des plugins tiers.
• Capabilities minimales.
• MCP servers de confiance.
• Skills traités comme du code.
• Pas d’auto-update sans review.

Qualité

• Acceptance tests.
• Tests lancés par l’agent.
• Review du diff final.
• Mesure des régressions.
• Coût par tâche réussie.
• Test de reprise après restart.
• Limites claires pour les subagents.

Verdict POLPROG

DeepSeek Harness est l’un des projets agents les plus intéressants d’août 2026, non parce que DeepSeek aurait simplement créé un « clone de Claude Code ».

Le point clé est :

model = plugin
tools = plugins
sandbox = plugin
session log = plugin
subagent provider = plugin
agent loop = plugin
UI = plugin

Et le parent peut déléguer au véritable Codex et au véritable Claude Code.^[8][9]

La bonne question est donc :

Les entreprises vont-elles séparer modèle et harness pour bâtir leur propre control plane multi-agent ?

Les modèles frontier changent vite. Un harness peut survivre à plusieurs générations de modèles.

C’est une idée architecturale puissante.

Mais au 31 août 2026 DSH reste en developer preview, sans security audit selon l’upstream et explicitement non production-ready.^[6]

R&D et POC contrôlé

À évaluer sérieusement.

Base immédiate pour production critique

Pas encore sans hardening, sandboxing, version pinning, plugin review et POC complet.

La force principale de DSH n’est pas un « meilleur modèle », mais l’idée de faire en sorte que le modèle ne soit plus le centre architectural de tout l’agent.