Lernpfad
KI-Grundlagen für Unternehmen
12 Std.
OpenCode ist darauf ausgelegt, Aufgaben zu erledigen. Es ist ein Open-Source-Agent, der ein KI-Modell mit deinem Repository, Terminal und deinen Entwicklungstools verbindet. Bitte ihn, einen Bug zu beheben, und er findet die relevanten Dateien, entwirft einen Plan, bearbeitet den Code, führt Tests aus und reagiert auf Fehler. Autovervollständigung kann das nicht eigenständig.
Diese größere Rolle sorgt für Aufmerksamkeit. Zum Zeitpunkt des Schreibens hatte das aktive OpenCode-Repository rund 189.000 GitHub-Sterne. Sterne sind kein Beweis für Codequalität, zeigen aber, wie groß das Interesse am Projekt ist.
Die Realität ist weniger geradlinig. OpenCode lässt dich das Modell wählen und verlangt anschließend, diese Wahl zu verwalten. Eine Anbieter-Policy-Änderung im Januar 2026 zeigte, wie schnell sich diese Optionen verschieben können. Ich gehe darauf ein, zusammen mit der Funktionsweise von OpenCode und wo es sich einordnet.
Noch ein kurzer Hinweis zum Namen: Wenn du nach OpenCode suchst, findest du möglicherweise das archivierte, Go-basierte opencode-ai/opencode-Repository. Dieses Projekt wurde im September 2025 eingestellt. Wir konzentrieren uns auf das aktive Projekt unter github.com/anomalyco/opencode, entwickelt vom Team hinter dem Serverless Stack (SST) Framework.
Was ist OpenCode?
OpenCode ist ein Open-Source-KI-Coding-Agent unter der MIT-Lizenz. Es ist modellagnostisch, also nicht auf einen Modellanbieter beschränkt. Nutzer können den Quellcode lesen und anpassen. Sie können das Tool auch selbst hosten. Die Software ist kostenlos. Die Modellabrechnung erfolgt separat, wie ich unter den Funktionen erkläre.
OpenCode ist kein Large Language Model (LLM). Das gewählte Modell liest Prompts und erzeugt Antworten. OpenCode liefert die Dateitools, Shell-Zugriff, Sitzungsverlauf, Berechtigungsregeln und Oberfläche rund um dieses Modell. Diese Unterscheidung ist hilfreich, weil ein Modellwechsel nicht den Rest des Tools verändert.
Entwickelt wird es von Anomaly, ehemals SST, und es setzt vor allem auf TypeScript und Bun.
Archivierte und aktuelle OpenCode-Repositories im Vergleich. Bild: Autor.
OpenCode ist nicht an eine Modellfamilie gebunden. Über das Models.dev-Register verbindet es sich mit mehr als 75 Anbietern, darunter Anthropic, OpenAI, Google, DeepSeek, Groq und lokale Modelle über Ollama. Einige vorhandene Abo-Konten lassen sich ebenfalls verknüpfen, wie ich im Funktionsabschnitt erkläre.
OpenCode-Terminalsitzung mit Dateiänderungen. Bild: Autor.
OpenCode startete im Terminal, wird aber inzwischen als Terminaloberfläche (TUI), als Beta-Desktop-App für macOS, Windows und Linux sowie als Erweiterungen für Editoren wie VS Code ausgeliefert. Die zum Zeitpunkt des Schreibens jüngste stabile Version ist v1.18.8.
Warum OpenCode entstanden ist
Wie bereits erwähnt, unterstützt OpenCode Modelle vieler Anbieter. Es wurde so gebaut, weil sich Modellqualität und Preise ändern und ein an einen Anbieter gebundenes Tool Nutzern weniger Optionen lässt.
In der Doku steht, dass OpenCode nicht an einen Anbieter gekoppelt ist. Das oben erwähnte Models.dev-Register liefert die Modelldetails und Preise, die OpenCode nutzt.
Diese Entscheidung betrifft mehr als die Abrechnung. Modelle unterscheiden sich bei Kontextlimits, Toolaufrufen und Eingabetypen. OpenCode bietet eine einheitliche Schnittstelle über diese Unterschiede hinweg. Ein Entwickler kann im selben Projekt das Modell wechseln, ohne die Sitzung in ein anderes Coding-Tool zu verschieben.
Das Team bevorzugt zudem terminal-first Tools, die Nutzer inspizieren können. Projektanweisungen liegen in einer einfachen Datei namens AGENTS.md. Wie OpenCode diese Datei erzeugt und nutzt, erkläre ich später.
Das offizielle Projekt nennt drei Designentscheidungen. Erstens die oben beschriebene Anbieterunterstützung. Zweitens bleiben die Hauptsteuerungen im Terminal. Drittens sind Client und Server getrennt. Diese Trennung kommt als Nächstes.
Im Januar 2026 blockierte Anthropic Dritttools dabei, Consumer-Claude-Abos über inoffizielle Kanäle zu nutzen. OpenCode ergänzte daraufhin weitere Abo-Optionen und nutzte ein eigenes Gateway. Nutzer konnten sich weiterhin über andere Anbieter verbinden.
Dieses Ereignis erklärt, warum die Anbieterauswahl in OpenCode so viel Aufmerksamkeit bekommt. Um zu sehen, was Nutzer damit tun, schauen wir uns als Nächstes eine Sitzung an.
Wie OpenCode funktioniert
OpenCode läuft als Client und lokaler Server. Die TUI, Desktop-App, IDE-Erweiterungen und das SDK sprechen per HTTP mit diesem Server. Derselbe Server unterstützt auch Remote-Anbindung mit opencode attach <url> und Headless-Betrieb mit opencode serve.
In einer Sitzung liest der Agent relevante Dateien, entwirft ggf. einen Plan, bearbeitet Code und führt bei Bedarf Befehle aus. Die Integration mit dem Language Server Protocol (LSP) speist Compiler- und Linter-Diagnosen zurück ins Modell, damit es auf Typ- und Syntaxfehler reagieren kann.
Eine Aufgabe kann zum Beispiel mit glob oder grep beginnen, um Dateien zu finden. Der Agent kann mit read hineinsehen und mit edit ausgewählte Zeilen ändern. Anschließend kann er mit bash einen Test- oder Build-Befehl ausführen. Die Ausgabe fließt in die nächste Modellanfrage ein.
Die Trennung in Build und Plan ist am einfachsten als Berechtigungsschalter zu verstehen. Build ist der Standard und darf lesen, schreiben und Befehle ausführen. Plan fragt nach, bevor Dateien bearbeitet oder bash-Befehle ausgeführt werden. Mit Tab wechselst du dazwischen.
Berechtigungsprüfungen greifen, sobald ein Tool aufgerufen wird. Ein Projekt kann ein Tool erlauben, blockieren oder jedes Mal nachfragen. Regeln können auch nach Befehlsmustern variieren. Ein Team könnte Routinetests erlauben, aber vor anderen Shell-Befehlen nachfragen.
Sitzungen werden lokal auf der Festplatte im OpenCode-Datenverzeichnis gespeichert. OpenCode kürzt automatisch lange Gespräche. Mit /undo und /redo wechselst du durch Git-basierte Dateisnapshots.
Kernfunktionen von OpenCode
OpenCode bündelt seine Hauptfunktionen in Modellzugriff, Projektkontext, Aufgabenausführung und lokaler Nutzung. Die Abschnitte unten erklären, was jede Gruppe in einer Codingsitzung verändert.
Multimodell-Unterstützung
Wie erwähnt, bezieht OpenCode seine Anbieterliste über Models.dev. In der Praxis kannst du einen gehosteten Dienst, eine Cloud-Plattform oder ein OpenAI-kompatibles Endpoint verbinden. GitHub Copilot- und ChatGPT Plus/Pro-Logins sind Alternativen zum separaten API-Schlüssel.
Die Anbieterauswahl bedeutet nicht, dass sich alle Modelle gleich verhalten. Toolnutzung, Kontextlimits, Antwortzeit und Preis hängen weiterhin vom gewählten Modell und Anbieter ab. Aufrufe an gehostete Modelle senden den benötigten Codekontext außerdem an diesen Anbieter unter dessen eigenen Datenregeln.
OpenCode bietet auch zwei optionale Zugänge zu Modellen. OpenCode Zen ist ein nutzungsbasiertes Gateway mit ausgewählter Modellauswahl. OpenCode Go ist ein Abo für 5 $ im ersten Monat, danach 10 $ pro Monat, für ausgewählte Open-Weight-Modelle. Eigene API-Schlüssel können weiterhin genutzt werden. Preise können sich ändern.
Das ist der nervige Teil: Ein kostenloses Tool kann trotzdem eine Anbieterrechnung erzeugen.
Mit Repository-Kontext arbeiten
Führe /init aus, und OpenCode generiert eine AGENTS.md -Zusammenfassung der Projektstruktur und -konventionen. Teams können diese Datei committen, sodass Sitzungen mit gemeinsamen Anweisungen starten.
Die Datei kann Testbefehle, Ordnernamen, Namensregeln und Projekthinweise enthalten. Eine globale AGENTS.md kann vorgabenübergreifend genutzt werden. Die Projektdatei hält Regeln für ein Repository.
Die zuvor beschriebenen LSP-Prüfungen laufen nach Edits. Zum Repository-Kontext gehören auch Dateireferenzen: Das @ -Symbol zieht eine ausgewählte Datei in einen Prompt.
Coding-Aufgaben ausführen
Neben den oben beschriebenen Build- und Plan-Agenten enthält OpenCode Subagenten für mehrstufige Suchen, Codebase-Scans und externe Doku. Eigene Agenten können ihr eigenes Modell, ihren Prompt und Toolberechtigungen haben.
Jeder Subagent arbeitet in einer Kind-Sitzung, damit seine Nachrichten die Hauptsitzung nicht in gleicher Weise füllen. Ein Custom-Agent kann auf Lesezugriff beschränkt, mit einem günstigeren Modell versehen oder auf eine Aufgabengattung zugeschnitten werden.
Model Context Protocol (MCP)-Server fügen externe Dienste hinzu. Sie werden in opencode.json definiert, und die zuvor beschriebenen Berechtigungsprüfungen gelten auch für deren Tools.
Vom Plan zur Codeänderung. Video: Autor.
Local-first-Entwicklung (und ihre Grenzen)
Der Begriff „local-first“ braucht eine Einordnung. Ich würde ihn nicht als Zusage verstehen, dass nie etwas die Maschine verlässt. Wie im Anbieterabschnitt erwähnt, kann sich OpenCode mit Ollama verbinden. Damit bleiben Code und Prompts auf lokaler Infrastruktur. Gehostete Modelle, /share und OpenCode Zen senden Daten jedoch nach draußen.
Die lokale Nutzung hängt weiterhin vom Modell ab. Kleine Modelle können ungültige Toolaufrufe zurückgeben oder Querverbindungen zwischen Dateien übersehen. Ein lokaler Server braucht zudem genügend Speicher für das gewählte Modell und genug Kontextplatz für die pro Anfrage gesendeten Dateien.
Das Berechtigungssystem ist ein Workflow-Schutz, kein Security-Sandboxing. Im vernetzten Servermodus solltest du OPENCODE_SERVER_PASSWORD setzen und an localhost binden. Ein früheres Problem mit ungeschützter Exposition wurde gefixt, dennoch sollte der Servermodus ohne Authentifizierung nicht öffentlich erreichbar sein.
OpenCode-Architektur
Wie erwähnt, trennt OpenCode seine Clients von seinem lokalen Server. Diese Trennung beeinflusst Konfiguration und gespeicherten Zustand. Die API bietet einen weiteren Zugangsweg zum Server.
Wenn du nur die TUI nutzen willst, kannst du die API-Details überspringen. Der Konfigurationsabschnitt am Ende ist für dich relevant.
Der TypeScript- und Bun-Server spricht mit Modellanbietern und führt Tools aus. Er verwaltet auch den Zustand. Seine OpenAPI-3.1-Spezifikation erzeugt das offizielle @opencode-ai/sdk. Skripte und eigene Clients können diese dokumentierte API nutzen.
Die API umfasst Sitzungen, Nachrichten, Dateien, Anbieter, Tools, Agenten und Konfiguration. Es ist derselbe Server, den OpenCodes eigene Clients nutzen. Ein Skript kann eine Sitzung anlegen oder eine Nachricht senden, ohne die TUI zu steuern.
OpenCode-Clients verbinden sich mit einem Server. Bild: Autor.
Die genannten Oberflächen agieren als Clients: TUI, Desktop-App, IDE-Erweiterung und opencode web. Alle sprechen mit demselben Serverprozess. Ein separates Gerät kann sich über diesen Prozess an eine bestehende Sitzung anhängen.
Ein opencode serve startet den Server ohne die normale TUI. opencode web fügt einen Browser-Client hinzu. Beide Befehle brauchen Authentifizierung, wenn der Server von einem anderen Gerät erreichbar ist.
Die Konfiguration liegt projektweit in opencode.json oder opencode.jsonc mit einem globalen Fallback unter ~/.config/opencode/opencode.json. Sie steuert Modelle, Berechtigungen, MCP-Server und Custom-Agenten. Wie im Workflow-Abschnitt beschrieben, bleiben Sitzungsverlauf und Tool-Logs in lokalen Dateien, sofern der Nutzer sie nicht teilt.
Typische OpenCode-Workflows
Dieselben Bausteine von OpenCode lassen sich für gängige Softwareaufgaben nutzen. Die Beispiele unten zeigen, wo menschliches Review weiterhin wichtig ist.
Neue Features bauen
Mit dem oben beschriebenen Plan-zu-Build-Prozess kann ein Entwickler ein Feature anfragen und die vorgeschlagenen Schritte prüfen, bevor etwas bearbeitet wird. Mit Tab wechselt die Aufgabe dann in den Build-Modus für Codeänderungen und Tests.
Der Plan kann vor jeder Dateiänderung angepasst werden. Ich nutze dieses Review, um den Scope zu schärfen, unveränderliche Dateien zu benennen oder Testanforderungen zu ergänzen.
Bestehenden Code refaktorieren
Dasselbe Plan-zu-Build-Vorgehen funktioniert beim Refactoring. Der Plan-Modus kann Abhängigkeiten und Call Sites identifizieren, bevor der Build-Modus Edits anwendet. Wenn das Ergebnis nicht passt, stellt /undo den früheren Snapshot wieder her. Den Diff musst du trotzdem prüfen, denn grüne Tests garantieren nicht, dass jede öffentliche Schnittstelle unverändert blieb.
Anwendungen debuggen
Zum Debuggen kann OpenCode einen Stacktrace mit Typinformationen des Language Servers kombinieren. Es kann eine Änderung vorschlagen, die Schritte zur Fehlerreproduktion wiederholen und das Ergebnis prüfen. Ohne klare Reproduktionsschritte bestätigt es ggf. nur, dass der Build läuft oder bestehende Tests bestehen.
Tests schreiben
Wie oben beschrieben, kann der Build-Modus Dateien bearbeiten und Befehle ausführen. Beim Testschreiben heißt das: Er kann einen Test erstellen, das Ergebnis lesen und erneut anpassen. Eine vollständige Test-Suite liefert mehr Feedback, dauert aber länger.
Die Testqualität braucht weiterhin menschliches Review. Ein generierter Test kann die Implementierung wiederholen statt das für Nutzer relevante Verhalten zu prüfen.
Große Codebasen verstehen
Der Repository-Abschnitt hat erklärt, wie /init Projekthinweise erzeugt. Danach kann eine Frage wie „Wie funktioniert hier die Authentifizierung?“ die Suche leiten. Der @general -Subagent kann mehrere Bereiche des Repos durchsuchen.
Konkrete Fragen liefern in der Regel klarere Ergebnisse als die Bitte, das gesamte Repository zu erklären. Dateireferenzen mit @ können die Suche weiter eingrenzen.
OpenCode vs. andere KI-Coding-Agenten
Diese Tools unterscheiden sich bei Lizenz, Modellunterstützung, Oberfläche und Abrechnung. Ich vergleiche sie danach, anstatt ein Tool als Standard zu behandeln.
OpenCode vs. Claude Code
Wir haben einen eigenen Artikel zu OpenCode versus Claude Code mit mehr Details. Claude Code ist proprietär und nutzt das Modell- und Kontosystem von Anthropic. OpenCode steht unter der MIT-Lizenz und lässt den Nutzer den Anbieter wählen. Es gibt zudem Einblick in Quellcode und Konfiguration. Wie im Verlauf erwähnt, funktionieren Consumer-Claude-Abos nicht mehr über OpenCode, daher benötigt Claude-Nutzung einen metered Anthropic-API-Schlüssel.
Beide Tools können Dateien lesen, Änderungen vornehmen, Befehle ausführen und MCP-Server nutzen. Der Hauptunterschied ist der Modellzugang: Claude Code bleibt beim beschriebenen Anthropic-Setup, während OpenCode andere Anbieter oder ein lokales Endpoint anbinden kann.
OpenCode vs. Cursor
Cursor ist eine VS-Code-basierte IDE und bietet auch CLI- und Cloud-Agenten. Der Hauptworkflow hält Vorschläge, Dateiänderungen und Agentaktionen im Editor. OpenCode nutzt die oben genannten Terminal-, Desktop- und Editoroberflächen. Cursor setzt auf kostenpflichtige Abos. OpenCode ist als Software kostenlos, aber Nutzer zahlen ggf. Tokens beim Modellanbieter. Die Hauptunterschiede sind Oberfläche, Modellauswahl und Abrechnungsmethode.
Cursor bietet auch Inline-Vervollständigung während des Tippens. OpenCode fokussiert Aufgaben, die an einen Agenten delegiert werden, und ersetzt diese Form der Vervollständigung nicht. Manche Entwickler nutzen beide Tooltypen für unterschiedliche Arbeiten.
OpenCode vs. Cline
Cline ist im Kern ein Open-Source-, BYOK-Agent mit VS-Code- und CLI-Oberflächen. Es gibt auch einen JetBrains-Client, der zum Zeitpunkt des Schreibens nicht Open Source ist. Sowohl Cline als auch OpenCode unterstützen MCP und erlauben Freigaberegeln. Cline platziert seine Editorsteuerung in einer Seitenleiste. OpenCode nutzt Terminalsitzungen, die getrennt vom Editor laufen können. Die Wahl hängt primär davon ab, wo ein Entwickler Änderungen prüfen und freigeben will.
Cline steht unter der Apache-2.0-Lizenz. OpenCode nutzt, wie erwähnt, die MIT-Lizenz. Beide erlauben Quellcodeprüfung und Änderungen, unterscheiden sich aber bei Oberfläche und Projektdateien.
Aider und Codex CLI sind ebenfalls terminalbasierte Coding-Agenten. OpenCode deckt Terminal-, Desktop- und IDE-Nutzung im selben Projekt ab und unterstützt Modelle verschiedener Anbieter.
OpenCode installieren und loslegen
Das offizielle Installationsskript funktioniert auf den meisten Unix-ähnlichen Systemen. Es bietet einen Weg, das Kommandozeilentool zu installieren:
Der Befehl lädt die OpenCode-Binary herunter und fügt sie der Umgebung des Nutzers hinzu. Ein Paketmanager kann besser passen, wenn Updates mit dem restlichen System verwaltet werden.
curl -fsSL https://opencode.ai/install | bashPaketmanager-Optionen sind unter anderem npm i -g opencode-ai@latest, brew install anomalyco/tap/opencode auf macOS und Linux sowie scoop install opencode oder choco install opencode unter Windows. Eine Desktop-App gibt es für macOS, Windows und Linux. Unter Windows empfiehlt die OpenCode-Doku WSL, weil einige Dateisystem- und Shell-Funktionen dort besser funktionieren.
Die Installation beinhaltet keinen Modellzugang. Für die erste Sitzung brauchst du eine der im Multimodell-Abschnitt beschriebenen Zugangsmethoden.
OpenCode installieren und anschließend Projektanweisungen erstellen. Video: Autor.
Ist OpenCode wirklich kostenlos nutzbar?
Kann ich Claude-Modelle in OpenCode nutzen?
Funktioniert OpenCode ohne Internetverbindung?
Ist das archivierte opencode-ai/opencode-Repository dasselbe Projekt?
Wie schützt OpenCode die Privatsphäre meines Quellcodes?
Themen