DeepSeek partout : brancher un cerveau cloud pas cher sur Claude Code et une stack d'agents locale

DeepSeek fait désormais tourner trois choses différentes chez moi : le cerveau de ma stack d'agents, le CLI Claude Code, et l'échelon cloud d'une échelle de repli. L'effort de branchement total : un peu de JSON, quelques variables d'environnement, et un bug d'échappement systemd qui m'a coûté une soirée.

Ce que vous obtenez

Avant le mode d'emploi, la forme générale de la chose. Je fais tourner OpenClaw, une passerelle d'agents, avec huit agents nommés derrière une interface de chat, plus le CLI Claude Code que ces agents lancent pour le vrai travail de code. DeepSeek fait tourner les deux.

Schéma	Ce qu'il fait	Coût
1. Cerveau des agents	DeepSeek en tant que fournisseur dans la config de la passerelle ; n'importe quel agent peut le choisir comme principal ou comme repli	0,14 $–0,87 $ / million de tokens
2. Backend de Claude Code	Un drop-in systemd redirige le CLI vers l'endpoint compatible Anthropic de DeepSeek, sans réinstallation	même tarif au token
3. Échelle de repli	Une liste de décision pour savoir quand un travail va à DeepSeek plutôt qu'à un modèle local	0 $ quand ça reste en local

La ligne qui rend tout ça possible : DeepSeek fournit un endpoint compatible Anthropic à l'adresse https://api.deepseek.com/anthropic. Tout ce qui est conçu pour parler à Claude — le CLI Claude Code compris — peut y être pointé avec de simples variables d'environnement. Pas de script wrapper, pas de fork.

Schéma 1 : DeepSeek comme cerveau d'agent

Un bloc de fournisseur dans la config de la passerelle. Le vrai bloc, clé masquée :

"deepseek": {
  "baseUrl": "https://api.deepseek.com/v1",
  "api": "openai-completions",
  "apiKey": "CHANGE_ME",
  "timeoutSeconds": 450,
  "models": [
    {
      "id": "deepseek-v4-pro",
      "name": "deepseek-v4-pro",
      "reasoning": true,
      "input": ["text"],
      "cost": { "input": 0.435, "output": 0.87,
                "cacheRead": 0.003625, "cacheWrite": 0.435 },
      "contextWindow": 1000000,
      "maxTokens": 384000
    },
    {
      "id": "deepseek-v4-flash",
      "name": "deepseek-v4-flash",
      "reasoning": true,
      "input": ["text"],
      "cost": { "input": 0.14, "output": 0.28,
                "cacheRead": 0.0028, "cacheWrite": 0.14 },
      "contextWindow": 1000000,
      "maxTokens": 384000
    }
  ]
}

Chaque agent choisit ensuite un modèle principal et une chaîne de repli :

"model": {
  "primary": "deepseek/deepseek-v4-flash",
  "fallbacks": ["deepseek/deepseek-v4-pro", "vllm/google/gemma-4-31b"]
}

Voici ce qui se passe quand un message arrive sur ce routage :

Mon roster réel. La plupart des agents partent avec DeepSeek et se replient sur le local ; Doxy fait l'inverse, exprès :

Agent	Principal	Replis
Bits (chat principal)	DeepSeek flash	DeepSeek pro → gemma-4-31b local
Brains	DeepSeek pro	gemma-4-31b local
Flash	DeepSeek flash	DeepSeek pro → local
Hermes (agent de déploiement)	DeepSeek pro	DeepSeek flash → local
Alpha (sûr pour la famille)	DeepSeek flash	DeepSeek pro → local
Doxy (cheval de trait local)	120B local	DeepSeek flash (inverse — le local part en premier)
beta	local	DeepSeek flash → DeepSeek pro
Charley (vision)	gemma-31b local	DeepSeek pro → DeepSeek flash

Charley compte particulièrement ici : ces entrées DeepSeek sont uniquement textuelles ("input": ["text"]), donc le travail sur image reste local quoi que dise la chaîne. Des alias (ds-flash, ds-brain) me permettent de changer de modèle en pleine conversation sans toucher à la config.

Deux réglages vous mordront si vous les zappez :

• "reasoning": true est obligatoire pour les modèles de raisonnement. Ils diffusent reasoning_content avant la vraie réponse ; avec le flag désactivé, la passerelle n'entend que du silence, en déduit que le modèle a planté, et tue le tour aux alentours de 390 secondes. Ne me demandez pas comment je le sais.
• Augmentez timeoutSeconds. Le délai de requête par défaut était de 120 secondes ; les longs raisonnements le dépassent largement et « échouent » de façon aléatoire. 450 a réglé le problème chez moi, et les réglages de fournisseur se rechargent à chaud — pas besoin de redémarrer la passerelle.

Schéma 2 : le CLI Claude Code sur DeepSeek

Le CLI Claude Code lit ANTHROPIC_BASE_URL, ANTHROPIC_MODEL et ANTHROPIC_AUTH_TOKEN/ANTHROPIC_API_KEY dans son environnement, et l'endpoint /anthropic de DeepSeek parle exactement le même format que Claude. Rediriger le CLI revient donc simplement à changer l'environnement que la passerelle transmet à chaque sous-processus Claude Code qu'elle lance — le CLI reste une installation standard.

Le fichier est un drop-in utilisateur systemd. Le mien est généré par une petite appli GTK que j'ai construite, qui bascule entre quatre modes (Local LM Studio / DeepSeek / Anthropic Cloud / Off), mais il est assez court pour s'écrire à la main :

# ~/.config/systemd/user/openclaw-gateway.service.d/60-subagent-routing.conf
[Service]
# Routes Claude Code CLI sub-processes to DeepSeek's Anthropic-compatible
# endpoint. The key is NOT copied here: $$DEEPSEEK_API_KEY is systemd's escape
# for a literal $DEEPSEEK_API_KEY, which bash expands at runtime from the
# gateway EnvironmentFile -- the secret never enters the unit or the argv.
Environment="ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic"
Environment="ANTHROPIC_MODEL=deepseek-v4-pro"
ExecStart=
ExecStart=/usr/bin/bash -c 'export ANTHROPIC_AUTH_TOKEN="$$DEEPSEEK_API_KEY"; export ANTHROPIC_API_KEY="$$DEEPSEEK_API_KEY"; exec node /path/to/openclaw/dist/index.js gateway --port 18789'

La clé elle-même ne vit qu'à un seul endroit : l'EnvironmentFile du service (~/.openclaw/gateway.systemd.env, chmod 600), qui contient juste DEEPSEEK_API_KEY=CHANGE_ME.

Le piège du $$ (toute la raison d'être de cet article)

Ma première tentative utilisait un seul $. Ça ne s'est pas bien passé. Dans un fichier unit, $VAR est développé par systemd lui-même au moment du lancement, ce qui grave la clé directement dans la ligne de commande — visible dans ps, dans /proc/<pid>/cmdline, et dans systemctl show. Pas vraiment l'endroit où on veut voir traîner un secret.

$$VAR est l'échappement systemd pour un littéral $VAR : systemd laisse passer la chaîne telle quelle, et c'est bash qui la développe au moment de l'exécution, à partir de l'environnement déjà rempli par l'EnvironmentFile. Effet net : le secret n'existe que dans un seul fichier en chmod 600, nulle part ailleurs — il n'apparaît jamais dans le fichier unit, dans systemctl show, ni dans aucun argv. Un gestionnaire de secrets du pauvre, bricolé avec systemd et bash — et ça marche.

D'autres pièges rencontrés en le faisant vraiment tourner :

• Définissez les deux variables d'authentification. Selon la version du CLI, c'est ANTHROPIC_AUTH_TOKEN ou ANTHROPIC_API_KEY qui est lue ; n'en définir qu'une, c'est jouer à pile ou face.
• Fixez ANTHROPIC_MODEL, sinon les alias habituels sonnet/opus du CLI sont envoyés à l'endpoint DeepSeek et provoquent un 404.
• Le drop-in masque toute vraie clé Anthropic. Un seul environnement possède tout le CLI — je l'ai découvert quand il a silencieusement cassé mes alias « router vers le vrai Claude ».
• Videz d'abord ExecStart= — la ligne vide avant la surcharge — sinon systemd ajoute votre commande au lieu de remplacer l'originale.
• Les mises à jour de paquet peuvent orphaner le wrapper. Il fige la commande de lancement en dur, donc une mise à jour qui change le vrai ExecStart oblige à régénérer le drop-in. Mon générateur lit la commande canonique dans le FragmentPath de l'unit, et refuse d'envelopper quoi que ce soit qui contient déjà $$DEEPSEEK_API_KEY.
• Puis rechargez : systemctl --user daemon-reload && systemctl --user restart <service>.

Pour vérifier tout le chemin de bout en bout, laissez tomber le CLI et testez avec curl :

curl https://api.deepseek.com/anthropic/v1/messages \
  -H "x-api-key: $DEEPSEEK_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"deepseek-v4-pro","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'

Une réponse "type":"message" en retour signifie que tout le chemin de compatibilité Anthropic fonctionne vraiment.

Schéma 3 : quand utiliser DeepSeek plutôt que le local, en pratique

Avoir les deux ne veut pas dire que tout part au cloud. Par million de tokens, avec les prix catalogue de Claude pour l'échelle (Opus 5 $/25 $, Sonnet 3 $/15 $, Haiku 1 $/5 $) :

Option	Entrée	Sortie	Remarques
DeepSeek flash	0,14 $	0,28 $	lecture cache 0,0028 $ — le service d'agent de chat coûte des centimes par jour
DeepSeek pro	0,435 $	0,87 $	le palier « qui réfléchit », encore 7 à 17 fois moins cher que Sonnet
Local (même machine)	0 $	0 $	juste l'électricité

La vitesse a été la plus grosse surprise. Les modèles locaux de classe 100 milliards de paramètres m'ont forcé à monter les délais de tour à 20-30 minutes, et deux agents qui partagent une même machine GPU se bloquent mutuellement. DeepSeek répond en quelques secondes ; le plafond de 450 secondes n'a compté que pour les pires cas de raisonnement. Le contexte est l'autre écart — une fenêtre d'1 million de tokens contre environ 128k pour les modèles locaux — donc les longues sessions d'agent et les gros travaux de code sur de grandes bases partent par défaut chez DeepSeek. La vision va dans l'autre sens : mes entrées DeepSeek sont uniquement textuelles, donc « regarde cette image » reste sur un modèle de vision local.

La règle de confidentialité que j'applique vraiment : n'envoyez au cloud rien que vous ne mettriez pas dans un e-mail.

Les chaînes de repli fonctionnent dans les deux sens, c'est ma partie préférée. Les agents à cloud prioritaire retombent sur un modèle local quand internet ou l'API meurt ; le cheval de trait à local prioritaire se replie sur DeepSeek flash quand le serveur local est occupé ou hors service. Personne ne reste complètement dans le noir.

Pièges, en version courte

Le flag reasoning: true, le délai de 120 secondes, l'échappement $$, et le drop-in qui masque votre vraie clé Anthropic sont tous couverts en détail dans les schémas 1 et 2. Deux de plus :

• Une allowlist de plugins non vide est stricte. Dans OpenClaw, une entrée de fournisseur activée mais absente de plugins.allow ne se charge jamais. Pas d'erreur, pas d'avertissement, juste le silence.
• DeepSeek, ici, est uniquement textuel. Vérifiez "input" dans l'entrée du modèle avant de lui envoyer des travaux de vision.

Vous préférez plutôt du 100% local — pas de clé API, pas de facture cloud ? Je l'ai écrit aussi : DeepSeek : le faire tourner en local — un guide en 4 étapes, les distillations de DeepSeek sur votre propre GPU avec Ollama, Docker, et Open WebUI. Ça, c'est le chemin du débutant ; celui-ci est pour quand les gros travaux dépassent votre GPU, mais que les trucs privés restent quand même à la maison.