Reasonix: Ein Codierungs-Agent im Stil von Claude Code auf DeepSeek

Falls Ihnen die Arbeitsweise von Claude Code gefällt – also ein Coding-Agent, der in Ihrem Terminal lebt, Dateien liest, Befehle ausführt und seine eigenen Fehler korrigiert – Sie aber lieber nur Bruchteile eines Cents pro Aufgabe zahlen möchten statt einer monatlichen Abonnementgebühr, dann ist dies die Lösung: Reasonix, ein CLI-Agent im Stil von Claude Code, der auf die API von DeepSeek zugreift.

Was am Ende dabei herauskommt

Zuerst die Version, die heute ausgeliefert wird:

$ reasonix --version
1.18.0

Dann der Ablauf: Man öffnet ein Terminal im Projekt, gibt reasonix ein und beschreibt, was man möchte – zum Beispiel: „Füge diesem Skript ein --dry-run-Flag hinzu und aktualisiere die README-Datei.“ Der Agent liest die relevanten Dateien, bearbeitet sie, führt das Skript aus, um seine Arbeit zu überprüfen, und gibt anschließend einen Bericht ab – im Grunde derselbe Ablauf, den Claude Code-Nutzer kennen. Die Unterschiede liegen in der technischen Umsetzung:

• Das „Gehirn“ ist DeepSeek: Die Abrechnung erfolgt pro Token. Zwei Modellstufen decken alle Anforderungen ab: ein Flash-Modell für alltägliche Bearbeitungen sowie ein Pro-Modell für komplexe Refactorings und das Debugging. Mein ständig aktiver Agent-Stack nutzt ebenfalls diese beiden Modellstufen; er kostet 24,08 Dollar pro Monat (9,54 Dollar für das Flash-Modell + 14,54 Dollar für das Pro-Modell). Die gleiche Arbeitslast würde bei den führenden APIs etwa 475–915 Dollar kosten.
• Sie können den Zeitplan selbst festlegen. Da es keine Lizenzbeschränkungen gibt, können Sie DeepSeek dazu nutzen, langwierige Aufgaben zu erledigen – etwa Batch-Refactorings, Testschreiben oder das Erstellen von Dokumentationen – ohne sich um die Nutzungsstatistiken kümmern zu müssen.
• Der Zustand der Arbeit wird in Ihrem Home-Verzeichnis gespeichert. Reasonix legt dazu einen Ordner (~/.reasonix/) an, in dem sich die Konfigurationsdatei sowie der Verlauf und das „Gedächtnis“ pro Projekt befinden; so behält es den Kontext zu jedem Repository über mehrere Ausführungen hinweg bei.

Schritt 1: Installieren

Es handelt sich um ein globales npm-Paket:

npm install -g reasonix
reasonix --version

Das ist die gesamte Installation. Falls Sie Node unter einem nicht standardmäßigen Pfad installiert haben, notieren Sie sich bitte den vollständigen Pfad zu npm – Sie werden ihn später im Schritt 4 für den Updater benötigen.

Schritt 2: Richten Sie es auf DeepSeek aus

Erstellen Sie einen API-Schlüssel auf der Plattform-Website von DeepSeek (Zahlung nach Verbrauch; meine gesamte Agenten-Struktur kostete in den ersten elf Tagen im Juli insgesamt 2,23 Dollar). Beschreiben Sie anschließend den Anbieter in der Datei ~/.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

Die Feldbezeichnungen unterscheiden sich je nach Agent-CLI, doch letztendlich reduzieren sie sich alle auf dasselbe Trio: Basis-URL, Anmeldeinformationen sowie Modell-ID(s). Unabhängig vom Tool gelten zwei grundlegende Regeln:

• chmod 600: Verwenden Sie diesen Befehl für alle Dateien, die den Schlüssel enthalten – und geben Sie ihn niemals in der Kommandozeile ein. Sonst landet er im Shell-Verlauf sowie in der Ausgabe von ps. Die indirekte Verwendung über api_key_env dient gerade dazu, dass das Geheimnis und die Konfiguration getrennt behandelt werden können: Die Konfigurationsdatei ist eine Datei, die man z. B. in einem Chat zur Hilfe einfügen kann; die Datei .env hingegen nicht.
• Definieren Sie beide Stufen. „Flash“ als Standardoption und „Pro“ für anspruchsvollere Aufgaben – das ist die gesamte Kostenstruktur: Die meisten Ausführungen sind günstig; man wechselt erst auf die „Pro“-Stufe, wenn das Modell sichtbar Schwierigkeiten hat.

Schritt 3: Subagenten und Fähigkeiten

Subagenten sind spezialisierte Arbeitskräfte, die vom Hauptagenten gestartet werden – beispielsweise „durchsuche den Code nach allen Aufrufern dieser Funktion“. Bei der Abrechnung pro Token stellen sie außerdem das Mittel zur Kostensteuerung dar, da sie den „Flash-Tier“-Modus nutzen können, während der Orchestrator im „Pro-Tier“ arbeitet. „Fähigkeiten“ sind Anweisungsdateien, die der Agent bei Bedarf lädt; dadurch muss ein Deploy-Verfahren oder eine Konvention zum Schreiben von Tests nur einmal festgelegt werden, anstatt in jeder Sitzung erneut zu erklären.

Die aktuellen Versionen ermöglichen es Ihnen, die Routing-Einstellungen explizit zu konfigurieren – anstatt darauf zu hoffen, dass die Standardeinstellungen sinnvoll sind. Dieser Konfigurationsblock ist es wert, verstanden zu werden, denn er ist die eigentliche Konfiguration:

[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

Die Auflistung der Fähigkeiten in der dritten Zeile ist die nützliche Variante. Die meisten zu delegierenden Aufgaben – wie z. B. nach bestimmten Mustern suchen, Dateien umbenennen oder offensichtliche Tests schreiben – sind einfache, schnell erledigbare Arbeiten. Eine Code-Review oder eine Sicherheitsprüfung hingegen nicht; genau bei solchen Aufgaben liefert ein billiges Modell zuversichtlich klingende, aber falsche Ergebnisse. Wenn man nur jene wenigen Fähigkeiten auswählt, die den Einsatz des teureren Modells rechtfertigen, erhält man eine gute Entscheidungsgrundlage an den entscheidenden Stellen – während alles andere weiterhin mit dem günstigeren Modell abgewickelt werden kann. Das ist ein besserer Kompromiss, als für alle Subagenten einheitlich nur ein Modell zu wählen.

Schritt 4: regelmäßig aktualisieren

Agent-CLIs entwickeln sich schnell weiter – ein veraltetes CLI verpasst daher wichtige Verbesserungen. Mittlerweile gibt es dafür eine integrierte Lösung; das ist die richtige Antwort auf dieses Problem:

reasonix upgrade

mit dem im Konfigurationsmenü ausgewählten Track:

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

Falls Sie möchten, dass die Ausführung ohne Ihr Zutun stattfindet, legen Sie einfach einen Zeitplan fest. Bei mir läuft das Ganze automatisch – die CLI befindet sich derzeit auf Version 1.18.0, ohne dass ich mir darüber Gedanken gemacht hätte. Das untenstehende Skript ruft direkt npm auf; es lohnt sich also, es zu lesen – auch wenn Sie die integrierte Funktion nutzen. Denn ein einfaches npm update -g im Automatikmodus birgt zwei Fehlerquellen, vor denen man sich schützen sollte:

#!/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"

Verbinden Sie es entweder mit cron oder einem systemd-Timer – beides funktioniert. Das Protokollieren der Version vor und nach einer Änderung ist wichtiger, als es zunächst scheint: Wenn sich das Verhalten des Agents über Nacht ändert, zeigt das Log an, ob eine Aktualisierung dafür verantwortlich war.

Verwendung in einem echten Projekt

Alles oben Genannte betrifft die globale Einrichtung. Was einen Agent-CLI tatsächlich nützlich macht, ist die projektspezifische Konfigurationsebene – und Reasonix wendet dabei eine bestimmte Reihenfolge bei der Konfigurationsauflösung an, die man kennen sollte:

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

Damit wird eine unter dem Namen reasonix.toml im Root-Verzeichnis eines Repos gespeicherte Datei zu den festen Anweisungen für dieses Projekt. Gleichzeitig enthält Ihre globale Konfigurationsdatei Ihre Anmeldeinformationen sowie persönliche Einstellungen. Einige Felder sind absichtlich nur global verwendbar – beispielsweise der Update-Kanal oder die CLI-Einstellungen –, sodass ein geklontes Repo nicht heimlich ändern kann, wie Ihre Installation sich selbst aktualisiert. Das ist eine sinnvolle Grenze – und genau deswegen ist es sicher, eine projektbezogene Konfigurationsdatei von jemand anderem zu akzeptieren.

Auch der Sitzungszustand sowie der Speicher sind pro Projekt begrenzt – und zwar unter ~/.reasonix/projects/<project>/sessions/. Starten Sie das Programm aus einem Projektverzeichnis statt aus Ihrem Home-Verzeichnis, bleibt der Kontext pro Repository erhalten: Es merkt sich, was es beim letzten Mal über diesen Code gelernt hat, anstatt wieder bei Null anzufangen. Der Start aus $HOME funktioniert zwar auch, doch in diesem Fall erhalten Sie ein ungeordnetes Sammelsurium an Kontextinformationen – was man vermeiden sollte, wenn man mit mehreren Repositories arbeitet.

Was ich in eine Projektdatei schreiben würde – ungefähr nach dem Nutzen geordnet:

• Die Befehle zum Bauen und Testen. Die wichtigste Zeile überhaupt. Ein Agent, der weiß, wie er seine eigene Arbeit überprüft, muss nicht mehr raten.
• Die Eskalationsregeln – der oben genannte subagent_models-Block, der pro Repository angepasst wird. Ein Projekt mit Sicherheitsanforderungen benötigt andere Standardeinstellungen als eine statische Website.
• Was der Agent auf keinen Fall tun darf. Einschränkungen beim Deployment, Dateien, die er niemals berühren darf – sowie Regeln wie „Dies darf niemals in der Produktivumgebung ausgeführt werden“. All das sollte einmal schriftlich festgehalten werden.
• Fähigkeiten für alle prozeduralen Abläufe – etwa Deploy-Runbooks oder Checklisten für Releases. So bleibt die Prozedur im Repository gespeichert und muss nicht aus dem Gedächtnis abgerufen werden.

Für konkrete Beispiele zu der Art von Projekten, für die dieses Vorgehen geeignet ist: Die selbstgehostete Chat-App, die Backup-Oberfläche sowie der Umwandlungsprozess von WordPress in eine statische Version weisen alle dieselbe Struktur auf: einen klar definierten Codebase, einen echten Verifizierungsbefehl sowie eine Kontrollinstanz, bevor etwas ausgeliefert wird.

Bonus: Fügen Sie es zu Ihrer Chat-App hinzu

Ein Terminal-Agent muss nicht unbedingt in einem Terminal verbleiben. Da Reasonix im Grunde nur eine CLI auf einem PTY ist, kann man dessen Ausgabe mithilfe von xterm.js in eine Web-Oberfläche streamen und es somit von jedem Gerät in Ihrem Netzwerk aus nutzen. Meine selbstgehostete Chat-App macht genau das – Reasonix erscheint dort als „Terminal-Bot“ neben den regulären Chat-Agenten; außerdem gibt es Kontrollmöglichkeiten zum Starten, Neustarten und Beenden. Die gesamte Einrichtung wird in DisPatch: Eine selbstgehostete KI-Chat-Anwendung beschrieben.

Fallstricke

• Bei Reasoning-Modellen scheint die Verarbeitung vor der Antwort ins Stocken zu geraten. Das Pro-Tier streamt seine Überlegungen bereits vor der eigentlichen Antwort; falls ein Wrapper oder Gateway um den Agenten herum eine kurze Idle-Timeout-Zeit hat, werden lange Denkprozesse abgebrochen. Erhöhen Sie das Timeout – geben Sie dem Modell keine Schuld.
• Setzen Sie den API-Schlüssel niemals in argv ein. Verwenden Sie ausschließlich eine Konfigurationsdatei (mit chmod 600) oder eine Umgebungsdatei. Kommandozeilen-Parameter können über Verlauf und Prozesslisten preisgegeben werden.
• Legen Sie den Pfad zu npm im Updater fest. Cron läuft mit einem minimalen PATH; npm kann in einer interaktiven Shell und in Cron unterschiedlich aufgelöst werden. Geben Sie den Pfad daher explizit im Skript an.
• Sichern Sie Ihren Update-Prozess ab. Ohne flock führt ein langsames npm-Registry sowie ein zu häufiger Update-Zeitplan dazu, dass zwei globale Installationen gleichzeitig laufen – mit dem Ergebnis einer fehlerhaften CLI.
• Achten Sie auf das „Escalation-Verhalten“. Das Pay-per-Token-Modell bleibt günstig nur, wenn „Flash“ der Standardmodus ist. Falls alle Aufgaben aus Vorsicht im Pro-Modus ausgeführt werden, entstehen unnötige Kosten – überwachen Sie die Ausgaben in der ersten Woche.
• Die Sitzungsordner werden immer größer. Die Projekt-Historie ist praktisch – bis ein gesprächiger Agent Monate an Daten ansammelt. Löschen Sie gelegentlich die alten Sitzungsdaten im entsprechenden Ordner.
• Die Struktur der Konfiguration ändert sich mit den Updates. Dieses Tool verwendet ein config_version-Feld, weil sich die Konfigurationsstruktur zwischen Versionen ändern kann. Beispielsweise wurde der API-Schlüssel aus config.toml in api_key_env verschoben. Falls der Agent nach einem Update nicht mehr authentifizieren kann, vergleichen Sie die Konfiguration mit der aktuellen Dokumentation – bevor Sie einen neuen Schlüssel generieren.
• Das Fortsetzen einer alten Sitzung ist nicht kostenlos. Wird ein Gespräch nach Ablauf des Prompt-Cache-Fensters erneut gestartet, werden alle Kontextdaten erneut übertragen – zu vollen Kosten. Es gibt eine Einstellung zum Entfernen veralteter Daten beim Neustart; aktivieren Sie diese. Eine neue Sitzung ist meist günstiger als die Wiederbelebung einer alten.

Weiterführende Lektüre: Der umfassende DeepSeek-Einführungsleitfaden erklärt, wie die Claude Code CLI auf DeepSeeks Anthropic-kompatiblen Endpunkt verweist – also dasselbe Prinzip aus der entgegengesetzten Richtung.