Reasonix : un agent de codage façon Claude Code sur DeepSeek

Si vous aimez la façon de travailler de Claude Code — un agent de codage qui vit dans votre terminal, lit des fichiers, exécute des commandes, corrige ses propres erreurs — mais que vous préféreriez payer des fractions de centime par tâche plutôt qu'un abonnement mensuel, voici la recette : Reasonix, un agent CLI façon Claude Code, pointé vers l'API de DeepSeek.

Ce que vous obtenez

Vous ouvrez un terminal dans un projet, tapez reasonix, et décrivez ce que vous voulez : « ajoute un drapeau --dry-run à ce script et mets à jour le README ». L'agent lit les fichiers concernés, les modifie, exécute le script pour vérifier son travail, puis fait son rapport — la même boucle que connaissent les utilisateurs de Claude Code. Les différences se situent dans la plomberie :

• Le cerveau, c'est DeepSeek, facturé au jeton. Deux niveaux couvrent tout : un modèle flash pour les modifications quotidiennes et les tâches de liaison, et un modèle de raisonnement pro pour les refontes coriaces et le débogage. Ma pile d'agents toujours actifs tourne sur ces deux mêmes niveaux et est revenue à 24,08 $ pour un mois complet (9,54 $ flash + 14,54 $ pro) — la même charge de travail chiffrée à environ 475–915 $ sur les API haut de gamme.
• Vous le planifiez comme bon vous semble. Comme il n'y a pas de licence par poste, vous pouvez le laisser tourner sur de longues corvées — refontes en lot, rédaction de tests, passes de documentation — sans surveiller un compteur d'usage.
• L'état vit dans votre répertoire personnel. Reasonix garde un dossier caché (~/.reasonix/) avec son fichier de configuration, plus l'historique de session et la mémoire par projet, si bien qu'il se souvient du contexte de chaque dépôt d'une exécution à l'autre.

Étape 1 : installation

C'est un paquet npm global :

npm install -g reasonix
reasonix --version

C'est toute l'installation. Si vous gardez Node sous un préfixe non standard, notez le chemin complet vers npm — vous en aurez de nouveau besoin pour le programme de mise à jour à l'étape 4.

Étape 2 : le pointer vers DeepSeek

Créez une clé API sur le site de la plateforme DeepSeek (paiement à l'usage ; les onze premiers jours de juillet pour toute ma pile d'agents sont revenus à 2,23 $). Décrivez ensuite le fournisseur dans ~/.reasonix/config.toml :

# ~/.reasonix/config.toml — the shape, not a paste of mine
default_model = "deepseek-flash"

[[providers]]
name        = "deepseek"
base_url    = "https://api.deepseek.com"
models      = ["deepseek-v4-flash", "deepseek-v4-pro"]
api_key_env = "DEEPSEEK_API_KEY"    # NAME of the variable, not the key itself

Les noms de champs varient d'un CLI d'agent à l'autre, mais chacun se ramène au même triplet : URL de base, clé d'accès, identifiant(s) de modèle. Deux règles d'hygiène valables quel que soit l'outil :

• chmod 600 sur tout ce qui contient la clé, et ne jamais la passer sur une ligne de commande — elle finit dans l'historique du shell et la sortie de ps. L'indirection api_key_env existe précisément pour que le secret et la configuration puissent être traités différemment : la configuration est un fichier que vous pourriez coller dans un chat pour demander de l'aide, le .env ne l'est pas.
• Déclarez les deux niveaux. « Flash par défaut, pro pour le difficile » résume toute l'histoire des coûts : la plupart des échanges sont bon marché, et vous n'escaladez que lorsque le modèle peine visiblement.

Étape 3 : sous-agents et compétences

Les sous-agents sont des travailleurs à portée limitée que l'agent principal fait naître — « cherche dans le code tous les appelants de cette fonction » — et sur une facturation au jeton, ils sont aussi le levier de coût, puisque les travailleurs peuvent tourner sur le niveau flash pendant que l'orchestrateur réfléchit sur le niveau pro. Les compétences sont des fichiers d'instructions que l'agent charge à la demande, si bien qu'une procédure de déploiement ou une convention de rédaction de tests s'écrit une fois pour toutes au lieu d'être réexpliquée à chaque session.

Les versions actuelles vous laissent régler ce routage explicitement plutôt que d'espérer que les valeurs par défaut soient sensées, et c'est ce bloc de configuration qui mérite d'être compris, parce que c'est lui qui détermine la facture :

[agent]
# planner_model  = "deepseek-pro"    # two-model collaboration: pro plans, flash executes
# subagent_model = "deepseek-pro"    # default tier for spawned workers
# subagent_models = { review = "deepseek-pro", security_review = "deepseek-pro" }
# recovery_model = "deepseek-pro"    # steps in when a turn fails

La carte par compétence sur la troisième ligne est celle qui est utile. La plupart du travail délégué — grep ceci, renomme cela, écris le test évident — relève du travail flash. Une revue de code ou une passe de sécurité, non ; ce sont exactement les tâches où un modèle bon marché produit un résultat sûr de lui, plausible, et faux. Nommer les quelques compétences qui méritent le niveau coûteux vous donne le bon jugement là où ça compte et laisse tout le reste bon marché, ce qui est un meilleur compromis que de choisir un seul niveau pour tous les sous-agents.

Étape 4 : le maintenir à jour selon un calendrier

Les CLI d'agents évoluent vite, et un CLI obsolète rate des corrections d'outils. Il existe désormais un utilitaire intégré pour ça, qui est la bonne première réponse :

reasonix upgrade

avec le canal choisi dans la configuration :

[cli]
update_channel = "stable"   # stable | preview

Si vous préférez que ça se passe sans vous, planifiez-le. Le mien tourne sans surveillance et le CLI est actuellement en v1.18.0 sans que j'y aie pensé. Le script ci-dessous encapsule npm directement, ce qui reste utile à lire même si vous utilisez l'utilitaire intégré, parce qu'un npm update -g naïf sur une planification a deux modes de défaillance qui méritent d'être parés :

#!/usr/bin/env bash
set -euo pipefail
LOG="$HOME/logs/update-reasonix.log"
NPM="$(command -v npm)"

# 1. Lock guard — two overlapping npm runs corrupt the install
exec 9>"${LOG%.log}.lock"
flock -n 9 || { echo "update already running"; exit 0; }

# 2. Log rotation — cron logs grow forever unless you trim them
[ -f "$LOG" ] && tail -n 5000 "$LOG" > "$LOG.tmp" && mv "$LOG.tmp" "$LOG"

echo "before: $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"
"$NPM" update -g reasonix >> "$LOG" 2>&1
echo "after:  $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"

Branchez-le sur cron ou sur un minuteur systemd — les deux fonctionnent. Consigner la version avant et après compte plus qu'il n'y paraît : quand le comportement de l'agent change du jour au lendemain, le journal vous dit si une mise à jour en est la cause.

L’utiliser sur un vrai projet

Tout ce qui précède est de la configuration globale. Ce qui rend un CLI d'agent réellement utile, c'est la couche par projet, et Reasonix résout la configuration dans un ordre précis qu'il vaut la peine de connaître :

flag  >  ./reasonix.toml  >  ~/.reasonix/config.toml  >  built-in defaults

Ainsi, un reasonix.toml validé à la racine d'un dépôt devient les instructions permanentes de ce projet, tandis que votre fichier global conserve l'identifiant et vos préférences personnelles. Certains champs sont délibérément globaux uniquement — le canal de mise à jour, les préférences du CLI — pour qu'un dépôt que vous avez cloné ne puisse pas changer discrètement la façon dont votre installation se met à jour. C'est une limite sensée, et c'est la raison pour laquelle un fichier par projet est sûr à accepter de quelqu'un d'autre.

L'état de session et la mémoire sont eux aussi cantonnés par projet, sous ~/.reasonix/projects/<project>/sessions/. Lancez-le depuis un répertoire de projet plutôt que depuis votre dossier personnel, et vous obtenez une continuité par dépôt — il se souvient de ce qu'il a appris sur ce code la dernière fois au lieu de repartir à froid. Le lancer depuis $HOME fonctionne, mais vous obtenez un seul tas de contexte indifférencié, ce qu'il vaut mieux éviter si vous travaillez sur plusieurs dépôts.

Ce que je mettrais dans un fichier de projet, à peu près par ordre de rentabilité :

• Les commandes de construction et de test. La ligne la plus rentable, de loin. Un agent qui sait comment vérifier son propre travail arrête de deviner.
• La carte d'escalade — le bloc subagent_models vu plus haut, ajusté par dépôt. Un projet avec une surface de sécurité veut un réglage par défaut différent d'un site statique.
• Ce qu'il ne doit jamais faire. Les verrous de déploiement, les fichiers qu'il ne doit jamais toucher, « ne jamais exécuter ceci contre la production ». Écrivez-le une fois pour toutes.
• Des compétences pour tout ce qui est procédural — le guide de déploiement, la check-list de release — pour que la procédure vive dans le dépôt plutôt que dans votre mémoire.

Pour des exemples concrets du genre de projet auquel ça convient, l'application de chat auto-hébergée, l'interface graphique de sauvegarde, et la reconstruction de WordPress vers statique ont toutes la même forme : une base de code définie, une vraie commande de vérification, et un verrou avant toute mise en ligne.

Bonus : l’intégrer à votre application de chat

Un agent de terminal n'est pas obligé de rester dans un terminal. Comme Reasonix n'est qu'un CLI sur un PTY, vous pouvez le diffuser dans une interface web avec xterm.js et l'utiliser depuis n'importe quel appareil de votre réseau. Mon application de chat auto-hébergée fait exactement ça — Reasonix apparaît comme un « bot terminal » aux côtés des agents de chat habituels, avec des contrôles start/restart/stop. L'ensemble de la mise en place est décrit dans DisPatch : un chat IA auto-hébergé.

Pièges à éviter

• Les modèles de raisonnement ont l'air bloqués avant de répondre. Le niveau pro diffuse sa réflexion avant la réponse ; si un wrapper ou une passerelle autour de l'agent a un délai d'inactivité court, les longues réflexions se font tuer en plein milieu. Augmentez le délai, n'accusez pas le modèle.
• Ne mettez jamais la clé dans argv. Uniquement le fichier de configuration (chmod 600) ou un fichier d'environnement. Les drapeaux en ligne de commande fuient via l'historique et les listes de processus.
• Figez le chemin de npm dans le programme de mise à jour. Cron tourne avec un PATH minimal ; npm peut se résoudre différemment dans un shell interactif et dans cron. Codez-le en dur ou résolvez-le explicitement dans le script.
• Verrouillez votre tâche de mise à jour. Sans flock, un registre npm lent combiné à un calendrier trop zélé finit par produire deux installations globales concurrentes et un CLI cassé.
• Surveillez l'habitude d'escalade. Le paiement au jeton ne reste bon marché que si flash est le niveau par défaut. Si chaque tâche tourne sur pro « au cas où », vous avez réinventé l'abonnement — suivez les dépenses pendant la première semaine.
• Les dossiers de session grossissent. L'historique par projet est formidable jusqu'à ce qu'un agent bavard en accumule des mois ; élaguez de temps en temps les données de session du dossier caché.
• Les schémas de configuration bougent sous vos pieds. Cet outil porte un marqueur config_version précisément parce que la forme change d'une version à l'autre — le déplacement de l'identifiant hors de config.toml vers api_key_env en est un exemple. Si l'agent ne parvient soudain plus à s'authentifier après une mise à jour, vérifiez la forme de la configuration face à la documentation actuelle avant de régénérer votre clé.
• Reprendre une vieille session n'est pas gratuit. Rouvrir une conversation après l'expiration de la fenêtre de cache de prompt du fournisseur signifie que le contexte est renvoyé au prix plein. Il existe un réglage pour élaguer la sortie d'outils périmée à la reprise à froid ; laissez-le activé. Une session neuve est souvent moins chère que de ressusciter une session périmée.

Lecture complémentaire : le guide plus général DeepSeek partout explique comment pointer le vrai CLI Claude Code vers l'endpoint compatible Anthropic de DeepSeek — la même idée dans l'autre sens.