OpenCode vs Claude Code: warum ich beide parallel betreibe

Bevor ich zu Claude gekommen bin, habe ich mit Codex experimentiert. Damals lief Codex noch in der Cloud, eine Desktop-Anwendung gab es nicht. Irgendwann bin ich dann auf OpenCode gestoßen, dort war all das möglich. Ich habe angefangen, MCP-Server einzurichten, und mit meiner Codex-Subscription darüber gearbeitet.

Später bin ich mit OpenCode in eine eigene virtuelle Maschine auf meinem Server umgezogen. Seitdem kann ich ortsunabhängig damit arbeiten und vor allem unabhängig vom Endgerät.

Die Reihenfolge ist wichtig, weil sie erklärt, warum bei mir nichts abgelöst wurde: Jedes Werkzeug kam zu einem Zeitpunkt dazu, an dem es etwas konnte, was das vorhandene nicht konnte. Ersetzt hat deshalb keines das andere.

OpenCode ist für mich kein reiner Chat, sondern ein technischer Arbeitsmodus. Ich nutze den Assistenten, um Anforderungen schnell in konkrete Änderungen zu übersetzen, inklusive Dateianpassungen, Strukturarbeit und Verifikation.

• OpenCode arbeitet im Projektkontext und liest gezielt die Dateien, die für eine Aufgabe relevant sind.
• Änderungen entstehen auf Basis der vorhandenen Code-Struktur.
• Nach Anpassungen kann ich direkt prüfen, ob Seiten, Routen oder Inhalte korrekt geladen werden.

Ich starte meistens mit einem klaren Ziel, zum Beispiel mit einer neuen Unterseite, einer textlichen Anpassung, einer besseren mobilen Darstellung oder einem SEO-Update. Dann arbeite ich in kurzen Schleifen: Ziel formulieren, Umsetzung im Projekt durchführen lassen, Ergebnis prüfen, gezielt nachschärfen. So bleibt der Prozess schnell, aber kontrollierbar.

Der Hauptgrund ist banal: Ich will nicht zusätzlich meinen Rechner eingeschaltet lassen, nur um mit der KI zu arbeiten. Die Server laufen ohnehin rund um die Uhr und sind damit jederzeit erreichbar.

Dazu kommt, dass der Server mein digitaler Spielraum ist. Dort kann ich viel experimentieren und dabei mehr Verständnis für Infrastruktur entwickeln. Das ist kein Nebeneffekt, sondern einer der Gründe, warum das Konstrukt überhaupt so aussieht.

Und es hat sich etwas angesammelt: Sessions, eingerichtete Agenten, konfigurierte MCP-Server. Welche davon bei mir produktiv laufen, steht auf der Seite zu den MCP-Servern in Claude Code. Dieser gewachsene Zustand ist ein eigener Grund, dort zu bleiben.

Für den Zugriff unterwegs nutze ich Telegram. Möglich macht das opencode-telegram-bot, eine Erweiterung, die genau dafür gedacht ist: ein Telegram-Client für die OpenCode-CLI. Sie ist in TypeScript geschrieben, braucht Node 22.14 oder neuer und lässt sich per npx, global über npm, aus dem Quellcode oder als Docker-Compose-Setup betreiben. Konfiguriert wird sie über eine .env mit Bot-Token, der eigenen Telegram-User-ID und der OpenCode-API-URL.

Das Projekt beschreibt sich selbst als Client für eine OpenCode-Instanz auf der eigenen Maschine. Bei mir zeigt er stattdessen auf die VM auf meinem Server. Der Effekt ist derselbe, nur dass die Maschine eben immer läuft.

Im Alltag nutze ich das für schnelle Dinge. Eine neue Automation fürs Smart Home zum Beispiel gebe ich direkt in Telegram und lasse sie von dort aus vom Agenten umsetzen.

Zuletzt war das eine Meldung, wenn meine VELUX-Steuerung die Verbindung verliert, eingesprochen im Vorbeigehen, mit der Bitte, mir den Aufbau zu erklären, bevor gebaut wird. Zurück kam ein Vorschlag mit Entprellung, Priorität und Modus, dazu der Befund, seit wann der Sensor bereits offline war. Diesen Austausch habe ich im Wortlaut dokumentiert.

Genau dafür ist der mobile Weg gedacht: Der Gedanke geht nicht verloren, bis ich wieder am Schreibtisch sitze. Für alles, was Credentials braucht, ist der Rechner trotzdem die bessere Wahl.

Privat zahle ich für die Subscription 20 Dollar im Monat. Dazu kommt Strom. Der Server läuft ohnehin auch für anderes, deshalb rechne ich ihn nicht auf dieses Setup um, er wäre auch ohne KI da.

Beruflich sieht die Rechnung anders aus, und das ist ein eigener Grund für die Trennung: Dort läuft eine Lizenz auf die Firma und nicht auf mich privat. Ich will privat und beruflich getrennt halten, und die Abrechnung ist der Punkt, an dem diese Trennung am deutlichsten wird.

In meinem Szenario hat OpenCode eine klare Schwäche: Es läuft auf einem Headless-System. Sobald es darum geht, einen PC zu bedienen oder eine Website im Browser zu öffnen, ist Schluss. Für solche Aufgaben greife ich auf die Codex-Anwendung direkt auf meinem Rechner zurück.

Dasselbe gilt für intensive Entwicklung. Da nehme ich lieber die Codex-App oder Claude Code, weil ich damit direkt auf meinem Rechner arbeiten kann, ohne dort zusätzlich OpenCode installieren zu müssen.

Das ist der Preis der Verfügbarkeit. Headless kauft mir Erreichbarkeit rund um die Uhr und Unabhängigkeit vom Endgerät. Es kostet mich Browser, Oberfläche und lokale Entwicklung.

Ehrlich gesagt kaum. Fachlich stößt Claude Code bei mir praktisch nirgends an. Das einzige Gegenargument ist im Moment, dass ich dafür meinen Rechner laufen lassen müsste.

Ich könnte auch dafür eine VM aufsetzen. Ich will die Lizenzen aber nicht vermischen, und damit ist die Frage für mich beantwortet. Es ist also keine Grenze des Werkzeugs, sondern eine des Betriebs und der Abrechnung.

Dazu kommt ein Punkt, der mir wichtig ist: Weil ich privat Codex und ChatGPT verwende, behalte ich einen Eindruck aus beiden Welten. Das ist Absicht.

Genau genommen sind es bei mir drei Positionen und nicht zwei: OpenCode in der VM auf dem Server, die Codex-App auf dem Rechner, Claude Code im Job. Jede davon deckt etwas ab, das die anderen in meinem Aufbau nicht abdecken: Verfügbarkeit, lokale Bedienung, berufliche Trennung.

Ich kann durchaus verstehen, warum Leute wechseln. OpenCode bietet mehr Flexibilität und erlaubt es auch, unterschiedliche Modelle anzubinden. Ich glaube deshalb, dass die Entscheidung stark von den eigenen Vorstellungen, Schwerpunkten und Wünschen abhängt.

Was ich nicht glaube, ist, dass es ein Entweder-oder sein muss. Die verbreitete Erzählung ist der Wechsel: weg von dem einen, hin zum anderen. Bei mir hat sich stattdessen eine Aufteilung ergeben, und die läuft seit einer Weile stabil. Ein zusätzlicher Nutzen davon ist, dass ich mehrere Werkzeuge im Griff behalte, statt mich auf eines zu verlassen.

Wenn ich noch einmal bei null anfangen würde, würde ich mich wahrscheinlich stärker auf Claude konzentrieren und gegebenenfalls eine Windows-VM nehmen. Damit hätte ich dann auch einen Browser und eine Oberfläche, also genau das, was mir im Headless-Betrieb fehlt.

An sich könnte ich mir aber auch dasselbe Konstrukt noch einmal vorstellen. Es funktioniert für mich gut so, wie es ist. Das ist ein weniger spektakuläres Fazit als ein Wechsel-Artikel, aber es ist das ehrliche.