Eine Claude Code Alternative ohne Cloud baue ich bei mir aus dem Terminal-Agenten Pi (pi.dev), der gegen ein lokales Qwen3.8-27B auf meinem Nvidia DGX Spark läuft. Die Modellinferenz läuft dabei vollständig auf dem eigenen Gerät, ohne Aufruf einer Anbieter-API. Was ein solcher Agent sonst noch anfasst, etwa eine Websuche, ein MCP-Adapter oder eine Update-Prüfung, kann sehr wohl ins Netz gehen, das musst du separat abschalten oder sperren. Für Kunden, die aus rechtlichen oder vertraglichen Gründen keine Cloud nutzen dürfen, ist das bei mir inzwischen mehr als ein Experiment, auch wenn es Claude Code nicht in jeder Hinsicht ersetzt.
Ich betreibe meine eigene KI-Belegschaft aus acht KI-Mitarbeitern auf Claude-Basis, kenne also die Cloud-Seite aus dem Produktivbetrieb. Der Pi-Aufbau daneben ist mein Testfeld für die Kunden, die genau diese Cloud-Seite nicht nutzen können. Alles, was ich zu lokaler KI und zu Claude schreibe, sammle ich auf der Seite KI.
Das ist mein Stand von heute, nicht das Ende der Geschichte: was Pi mit einem lokalen Modell kann, wo du bei diesem Aufbau aufpassen musst und für wen sich der Aufwand überhaupt lohnt.
Was eine Claude Code Alternative überhaupt leisten muss
Claude Code arbeitet als Agent im Terminal: Es liest Dateien in einem Projekt, schlägt Änderungen vor, führt Befehle aus und hält den Kontext über mehrere Schritte einer Aufgabe. Eine echte Alternative dazu muss also mindestens drei Dinge können, unabhängig davon, welches Modell dahinter läuft: mit dem Dateisystem eines Projekts arbeiten, Befehle ausführen und über mehrere Runden hinweg den Faden nicht verlieren.
Genau an diesen drei Punkten messe ich Pi mit einem lokalen Modell dahinter: nicht daran, ob es dieselbe Oberfläche hat, sondern ob dieselbe Art von Arbeit gelingt.
Lokale Kandidaten neben Pi
Pi ist bei mir die Wahl, aber nicht die einzige quelloffene Option für einen Terminal-Coding-Agenten ohne Cloud-Zwang. In Verzeichnissen für Claude-Code-Alternativen tauchen daneben regelmäßig Namen wie OpenCode, Aider, Cline und OpenHands auf, alle als eigenständige Terminal- oder Editor-Agenten, die sich grundsätzlich auch gegen ein lokal laufendes Modell schalten lassen. Zu Lizenzdetails und Funktionsumfang jedes einzelnen Tools liegt mir keine eigene Prüfung vor, deshalb nenne ich sie hier nur als Namen, die dir bei eigener Recherche begegnen werden, nicht als geprüfte Empfehlung.
Den Ausschlag zugunsten von Pi gab der schlanke Systemprompt. Eine englischsprachige Fachseite bezeichnet Pi als „Minimal Terminal Harness" mit einem Systemprompt von rund 200 Token, und von den Terminal-Agenten, die ich selbst ausprobiert habe, hat Pi tatsächlich den kleinsten. Für ein lokales Modell ist das ein Vorteil: Je weniger Anweisungen vorab im Kontext liegen, desto mehr Platz und Aufmerksamkeit bleiben für die eigentliche Aufgabe.
Mein Setup: Pi gegen Qwen3.8 auf dem DGX Spark
Konkret sieht mein Aufbau so aus: Auf dem DGX Spark mit GB10-Chip und 128 GB Unified Memory, von denen rund 119 GB nutzbar sind, läuft Qwen3.8-27B als NVFP4-Checkpoint unter SGLang, mit einer nach außen OpenAI- und Anthropic-kompatiblen API. Pi spricht gegen genau diese Schnittstelle, dadurch brauche ich keine Sonderanpassung im Agenten selbst, nur einen anderen Endpunkt als bei Claude Code.
Betrieben wird der Server als systemd-User-Unit mit aktiviertem Linger, weil ich auf dem Gerät kein passwortloses sudo habe. Die wichtigste Regel für den Betrieb: --mem-fraction-static bleibt bei maximal 0,50, sonst kann der ganze Host einfrieren. Die übrigen Stolperfallen, von der Startzeit über die Internetleitung bis zum Speicherlimit von Docker, habe ich in Qwen 3.8 lokal: Erfahrung mit DGX Spark gesammelt.
Was Pi kann, und wo du aufpassen musst
Das Handwerkszeug kann ich aus dem eigenen Betrieb bestätigen: Pi liest, schreibt und ändert Dateien, führt Befehle aus und sucht im Projekt, also genau die Bausteine, mit denen auch Claude Code arbeitet. Es liest AGENTS.md und CLAUDE.md aus dem Projekt, hat Skills, Sessions und Subagents, kennt einen Plan-Modus und eine Todo-Liste, lässt sich über MCP-Adapter an weitere Werkzeuge anbinden und kann im Web suchen. Das Modell wechselst du über einen eigenen Befehl, die Denkstufe lässt sich einstellen. „Minimal" heißt bei Pi also nicht, dass die Bausteine fehlen, die einen Coding-Agenten ausmachen.
Einen Unterschied solltest du kennen, bevor du Pi auf ein echtes Projekt loslässt: Es hat kein Permission-System. Pi fragt nicht nach, bevor es einen Befehl ausführt oder eine Datei überschreibt, es macht einfach. Claude Code fragt an diesen Stellen nach, und in einem Kundenprojekt will ich genau diese Rückfrage haben. Wer mit Pi arbeitet, sollte deshalb in einem Verzeichnis unter Versionskontrolle bleiben und dem Agenten kein Konto geben, das mehr darf als nötig. Das ist mein eigener Schluss aus dem fehlenden Permission-System, keine Vorgabe des Projekts; was Pi mitbringt und was nicht, steht in der Dokumentation zu Pi.
Was ich dagegen nicht liefern kann, sind Zahlen für den Vergleich mit Claude Code. Meine Einschätzung beruht bisher auf demselben Arbeitsalltag mit beiden Werkzeugen, nicht auf einem sauber aufgesetzten Benchmark, und so lange will ich sie auch nicht als Messergebnis verkaufen.
Wo die lokale Lösung an Grenzen stößt
Dieselbe englischsprachige Quelle, die Pi als minimalen Terminal-Agenten einordnet, schreibt auch offen, dass Claude Code bei Mehrdatei-Refactorings überlegen bleibe, unabhängig davon, welches lokale Modell dagegensteht. Das deckt sich mit meiner eigenen Erfahrung: Je mehr Dateien eine Änderung gleichzeitig betrifft und je länger ein Agentenlauf dauert, desto eher sehe ich bei Pi gegen Qwen3.8 Nacharbeit, während Claude Code den Überblick länger hält.
Bemerkenswert finde ich außerdem eine Randnotiz aus derselben Quelle: Anthropic habe am 4. April 2026 Third-Party-Harnesses den Zugriff über ein Claude-Pro-Abo gesperrt. Wer also einen alternativen Terminal-Agenten wie Pi betreibt, kann sich damit nicht einfach über ein bestehendes Claude-Abo behelfen, das lokale Modell muss selbst tragen, ohne Umweg über Claude im Hintergrund. Für mein Setup ändert das nichts, weil ich Pi ohnehin gegen mein eigenes lokales Modell laufen lasse, es zeigt aber, dass „Claude Code Alternative" hier wörtlich gemeint sein muss und nicht als Trick, um über die Hintertür an dasselbe Kontingent zu kommen.
Für wen sich das lohnt: Kunden ohne Cloud
Der Anwendungsfall, für den ich diesen Aufbau pflege, ist klar umrissen: Kunden, bei denen Code oder Daten das eigene Netz aus rechtlichen, vertraglichen oder schlicht aus Vertrauensgründen nicht verlassen dürfen, oder bei denen am Einsatzort keine verlässliche Internetverbindung vorhanden ist. In diesen Fällen ist eine Cloud-Lösung, egal wie gut sie ist, schlicht keine Option, und ein lokaler Aufbau wie Pi gegen Qwen3.8 wird zur einzigen realistischen Antwort.
Für alle anderen Fälle, in denen Cloud grundsätzlich erlaubt ist und es nur um Aufgabenqualität geht, würde ich aus heutiger Sicht nicht zu Pi als Ersatz raten, sondern zu Claude Code, mit dem meine eigene Belegschaft produktiv arbeitet. Den direkten Vergleich beider Wege an denselben Aufgabentypen habe ich in Qwen vs Claude: lokal gegen Cloud aufgeschrieben.
Häufige Fragen
Gibt es eine kostenlose Claude Code Alternative?
Pi selbst ist ein Terminal-Agent, den ich gegen ein selbst gehostetes Modell betreibe, dadurch entstehen bei mir keine laufenden Kosten pro Anfrage, dafür aber Kosten für die eigene Hardware und den Stromverbrauch. Eine pauschale Aussage, was das insgesamt günstiger oder teurer macht als ein Claude-Abo, kann ich ohne konkrete Nutzungszahlen nicht seriös treffen.
Kann ich Claude Code kostenlos nutzen, wenn ich stattdessen Pi mit einem lokalen Modell fahre?
Nein, das sind zwei getrennte Wege. Anthropic hat laut einer englischsprachigen Fachquelle am 4. April 2026 Third-Party-Harnesses den Zugriff über ein Claude-Pro-Abo gesperrt, ein alternativer Agent wie Pi kann sich also nicht über ein bestehendes Claude-Abo bedienen. Wer lokal arbeiten will, braucht ein eigenes lokales Modell dahinter.
Welches Modell passt zu Pi als Coding-Agent?
Bei mir läuft Qwen3.8-27B unter SGLang, mit Tool-Calling und einem großen Kontextfenster, das für Agentenaufgaben wichtig ist. Ob ein anderes Modell für dich besser passt, hängt von deiner Hardware und der Art der Aufgaben ab, dazu kann ich nur meine eigene Kombination als getesteten Ausgangspunkt nennen.
Wie richte ich einen KI-Agenten lokal ein?
In meinem Aufbau läuft zuerst ein lokaler Modell-Server, bei mir SGLang mit einer OpenAI- und Anthropic-kompatiblen API, danach zeigt der Terminal-Agent Pi auf genau diesen Endpunkt statt auf einen Cloud-Dienst. Die genauen Einzelschritte hängen stark von der eigenen Hardware ab, deshalb beschreibe ich hier nur den Aufbau, nicht eine Schritt-für-Schritt-Installation für jede Umgebung.
Reicht Pi mit Qwen 3.8 als vollwertiger Ersatz für Claude Code?
Für Aufgaben mit hartem Cloud-Verbot oder ohne Internetverbindung ja, weil es dort die einzige Option ist. Für alles andere sehe ich bei Mehrdatei-Refactorings und langen Agentenläufen weiterhin einen Vorteil für Claude Code, das ist auch der Grund, warum meine eigene Belegschaft dort läuft.
Wie du das für dich einordnest
Wenn Cloud für dich oder deine Kunden grundsätzlich möglich ist, würde ich zuerst Claude Code: Anleitung für Einsteiger lesen, bevor du dir den Aufwand für ein eigenes lokales Setup machst. Mein Setup mit Qwen3.8 auf dem DGX Spark beschreibe ich technisch im Detail in Qwen 3.8 lokal: Erfahrung mit DGX Spark, den direkten Vergleich der beiden Wege an denselben Aufgaben in Qwen vs Claude: lokal gegen Cloud.
Offizielle Hintergründe zu den Werkzeugen aus diesem Beitrag findest du direkt bei Pi, im SGLang-Projekt auf GitHub und bei Anthropic.
