OpenCode-Anleitung: Modelle anbinden, Aufgaben lösen, Kosten prüfen

Für den Einstieg genügt ein bekannter Fehler und ein bereits vorhandenes Modellkonto. Ob sich ein weiteres Abonnement für die Programmierung lohnt, lässt sich nach einer echten Codeänderung beurteilen: sobald ihr Ergebnis geprüft wurde und die Kosten feststehen.

Mit KI programmieren: Was OpenCode übernimmt

OpenCode liest Projekte, bearbeitet Dateien und führt Befehle über eine Terminaloberfläche aus. Das Terminal ist die Werkbank, das angeschlossene Modell der Antrieb. Ein Modellwechsel verändert Denkvermögen, Geschwindigkeit und Preis. Das Repository bleibt dabei das Projekt, an dem gearbeitet wird. OpenCode im Überblick, Ollama-Integration

Ein Anbieter stellt den Modelldienst bereit. Ein API-Schlüssel ist ein Zugangsschlüssel, mit dem ein Programm diesen Dienst nutzen und dessen Abrechnungskonto belasten kann. Ein lokales Modell läuft über einen Inferenzserver auf dem eigenen Rechner. Diese Entscheidungen sind unabhängig davon, welche Oberfläche für den Agenten gewählt wird.

Auch die Kompatibilität eines Anbieters muss sich in der Praxis bewähren. Tool Calling bedeutet, dass das Modell eine Aktion anfordert, etwa das Lesen einer Datei oder das Ausführen eines Befehls. OpenCode weist darauf hin, dass relativ wenige Modelle sowohl Tool Calling als auch Codegenerierung gut beherrschen. Deshalb sollte sich ein Modell zunächst an einer kleinen Aufgabe bewähren, bevor es einen umfangreichen Umbau übernimmt. Hinweise zur Modellwahl

OpenCode installieren und im Projekt starten

OpenCode wird nach der offiziellen Anleitung installiert und anschließend in dem Repository gestartet, in dem es arbeiten soll. Wenn Node.js und npm bereits vorhanden sind, sieht der dokumentierte Installationsweg über das Paket so aus:

npm install -g opencode-ai
cd /path/to/project
opencode

Der Projektpfad wird durch den eigenen ersetzt. Die OpenCode-Dokumentation bietet außerdem curl -fsSL https://opencode.ai/install | bash an; der empfohlene Homebrew-Tap lautet brew install anomalyco/tap/opencode. Eine dieser Installationsmethoden reicht aus. Unter Windows empfiehlt die Dokumentation WSL, die Windows-Umgebung für Linux-Werkzeuge, und führt zusätzlich npm, Chocolatey und Scoop als Möglichkeiten auf. Offizielle Installation und erster Start

OpenCode öffnet eine TUI, also eine textbasierte Benutzeroberfläche im Terminal. Befehle mit / am Anfang, darunter /connect, werden in dieser Oberfläche eingegeben. Befehle, die mit opencode beginnen, etwa opencode stats, gehören in die Shell.

Als Ausgangspunkt empfiehlt sich ein Git-Repository mit einem neuen Branch. Git protokolliert die Änderungen. So lässt sich vor einem Commit der Diff prüfen: die genaue Gegenüberstellung hinzugefügter und entfernter Zeilen.

Bereits bezahlte Modellzugänge mit OpenCode verbinden

Mit /connect wird der Anbieter ausgewählt und dessen dokumentierter Anmeldeweg durchlaufen. Anschließend lässt sich über /models ein Modell wählen. Gängige Anbieter sind bereits vorkonfiguriert; eigene Endpunkte und lokale Server können zusätzliche Einstellungen erfordern. Modellauswahl

Die Tabelle beschreibt die Zugangswege auf der öffentlichen Anbieterseite von OpenCode. Welche Funktionen ein bestimmtes kostenpflichtiges Konto tatsächlich freigibt, wird damit nicht zugesichert. Anleitung zur Anbieteranbindung

Ein Chat-Abonnement enthält nicht automatisch ein API-Kontingent. Laut Anthropic schließt Claude Pro die API-Nutzung über Claude Console aus. Auch der Anthropic-Abschnitt der OpenCode-Dokumentation warnt vor Authentifizierungsplugins für Claude Pro/Max. Für diesen Zugang wird ein Anthropic-API-Schlüssel benötigt; alternativ lässt sich Claude Code mit dem Abonnement nutzen. Ebenso unterscheidet OpenAI zwischen API-Tokenpreisen und der Nutzung im Abonnement. Abrechnung von Claude Pro, OpenCodes Warnung zu Anthropic, OpenAI-Abonnements und API-Preise

Für Ollama werden zunächst Ollama und OpenCode installiert. Danach startet ollama launch opencode die Einrichtung, bei der ein lokales Modell ausgewählt wird. Mit ollama launch opencode --config lässt sich die Konfiguration auch ohne Sitzungsstart vornehmen. Der Launcher bietet sowohl lokale als auch Cloud-Modelle an; die Auswahl sollte entsprechend bewusst erfolgen. OpenCode mit Ollama einrichten

Für eine manuelle lokale Einrichtung verwendet das Anbieterbeispiel von OpenCode @ai-sdk/openai-compatible, die lokale Adresse http://localhost:11434/v1 und eine Modell-ID, die zum bereitgestellten Modell passt. Für LM Studio gibt es ein eigenes Anbieterbeispiel. Ein nicht aufgeführter OpenAI-kompatibler Dienst wird über /connect → Other angebunden; dazu kommen eine passende Anbieter-ID, Adresse und Modellkonfiguration in opencode.json. Lokale und eigene Anbieter

Die erste echte Aufgabe bearbeiten

Für den Einstieg eignet sich ein Fehler, dessen korrektes Verhalten schon vor dem Start des Agenten feststeht. Ein Registrierungsformular, das eine leere E-Mail-Adresse akzeptiert, ist dafür besser geeignet als der Auftrag, die gesamte Anwendung neu zu gestalten.

Zuerst das Projekt initialisieren. /init erstellt oder aktualisiert AGENTS.md, eine Markdown-Datei mit Anweisungen für künftige Agentensitzungen. Das Ergebnis sollte gelesen werden; falsche Befehle und Annahmen müssen vor dem nächsten Schritt korrigiert werden. Projektinitialisierung

Anschließend einen Plan anfordern. Mit der Tab-Taste wird Plan ausgewählt. Über @ lassen sich die tatsächlichen Implementierungs- und Testdateien im Repository referenzieren. Für den Fehler mit der leeren E-Mail-Adresse könnte der Auftrag lauten:

Das ist ein beispielhafter Arbeitsauftrag, kein Bericht über einen abgeschlossenen Test. Er wird durch einen echten Fehler und tatsächliche Dateien aus dem eigenen Projekt ersetzt. Plan schränkt Dateiänderungen und Shell-Befehle über Berechtigungen ein; eine isolierte Ausführungsumgebung bietet der Modus nicht. Agenten und Verhalten von Plan, Dateireferenzen

Danach den vereinbarten Umfang umsetzen. Mit Tab zu Build wechseln und den Agenten beauftragen, einen Regressionstest hinzuzufügen, der den Fehler nachweist, und die kleinstmögliche Korrektur vorzunehmen. Er soll zeigen, dass der Test beim ursprünglichen Verhalten fehlschlägt und nach der Änderung besteht. Anschließend führt er die relevanten vorhandenen Prüfungen aus. Build ist der Standardagent mit aktivierten Werkzeugen. Build-Agent

Zum Schluss das Ergebnis selbst prüfen. Dazu gehören der Diff, der Abgleich der Testaussage mit dem gewünschten Verhalten und die Kontrolle auf sachfremde Änderungen. Ein bestandener Test, der das falsche Verhalten prüft, sagt wenig aus. Der Agent sollte außerdem die tatsächlich ausgeführten Befehle und die von ihm nicht behobenen Fehler nennen.

Wenn die Änderung in die falsche Richtung geht, kann /undo die letzte Nachricht samt Änderungen zurücknehmen; /redo stellt eine zurückgenommene Nachricht wieder her. Beide Funktionen setzen Git voraus. Rückgängig machen und wiederherstellen

AGENTS.md und Projektregeln sinnvoll nutzen

In diese Datei gehören die Informationen, die eine kompetente Entwicklerin oder ein kompetenter Entwickler für die Arbeit im Repository braucht. Die Anweisungen sollten so konkret sein, dass sie sich überprüfen lassen:

• Die tatsächlichen Befehle für Installation, Build, Linting und Tests, einschließlich ihrer Reihenfolge, wenn diese eine Rolle spielt.
• Die Ablageorte für Anwendungscode, gemeinsame Pakete und generierte Dateien.
• Die einzuhaltenden Konventionen und vorhandene Module, die als Beispiel dienen.
• Die Kriterien für eine abgeschlossene Aufgabe, einschließlich relevanter Prüfungen und einer Zusammenfassung des geänderten Verhaltens.

Die Projektdatei wird eingecheckt, damit das Team sie gemeinsam nutzt. Persönliche Regeln gehören in ~/.config/opencode/AGENTS.md. Fehlt die entsprechende OpenCode-Regeldatei, kann OpenCode ersatzweise CLAUDE.md verwenden. Regeln und Dateipfade

opencode.json ist die Konfigurationsdatei. Über das Array instructions lassen sich vorhandene Anweisungen laden, ohne beispielsweise einen Leitfaden für Beiträge nach AGENTS.md kopieren zu müssen. Das folgende Beispiel verlangt außerdem vor Dateiänderungen und Shell-Befehlen eine Bestätigung:

{
  "$schema": "https://opencode.ai/config.json",
  "instructions": ["CONTRIBUTING.md"],
  "permission": {
    "edit": "ask",
    "bash": "ask"
  }
}

Der angegebene Dateiname muss im eigenen Projekt existieren; bei einer vorhandenen Konfiguration werden die Einstellungen dort ergänzt. Ein bloßer Verweis auf eine andere Datei innerhalb von AGENTS.md wird nicht automatisch aufgelöst. Soll die Datei geladen werden, ist dafür instructions vorgesehen. Eigene Anweisungen

Regeln beschreiben das gewünschte Verhalten. Berechtigungen bestimmen, ob eine Werkzeugaktion ausgeführt werden darf. Die meisten Berechtigungen stehen zunächst auf allow. Wer Rückfragen wünscht, sollte die Einstellungen entsprechend bewusst wählen. Berechtigungen konfigurieren

Plugins für einen konkreten Bedarf ergänzen

Ein Plugin erweitert OpenCode mit JavaScript- oder TypeScript-Code, der auf Ereignisse reagiert, etwa wenn ein Werkzeug ausgeführt wird oder eine Sitzung in den Leerlauf wechselt. Damit lassen sich beispielsweise lokale Benachrichtigungen bei Abschluss einer Aufgabe oder ein projektspezifischer Arbeitsablauf umsetzen. Plugin-Ereignisse und Beispiele

Ein lokales Plugin liegt für ein einzelnes Projekt in .opencode/plugins/, für alle Projekte in ~/.config/opencode/plugins/. OpenCode lädt diese Dateien beim Start. Ein veröffentlichtes npm-Paket wird im Array plugin von opencode.json eingetragen; die Dokumentation nennt beispielsweise opencode-wakatime. Pakete und Abhängigkeiten werden beim Start automatisch mit Bun installiert. Bevor ausführbarer Code in die Entwicklungsumgebung aufgenommen wird, sollten Quellcode und Pflegezustand des Plugins geprüft werden. Plugins laden

Für den Anfang reicht der integrierte Arbeitsablauf. Ein Plugin lohnt sich, wenn klar ist, welche wiederkehrende Arbeit es abnimmt. Eine größere Pluginsammlung kann zusätzlichen Konfigurations- und Fehlersuchaufwand verursachen, bevor ein Nutzen entsteht.

Was kosten OpenCode und Zen?

Der Arbeitsablauf des Agenten und die Modellkosten sollten getrennt betrachtet werden. Bei einem vorhandenen unterstützten Abonnement wird der Zugang dieses Kontos genutzt. Mit einem API-Schlüssel rechnet der Anbieter nach Verbrauch ab. Bei lokaler Modellausführung zählen die Kapazität des Rechners und seine Betriebskosten. Zen ist ein separater, optionaler Zugang zu Modellen. Anbieterwahl

OpenCode Zen ist ein Modelldienst mit verbrauchsabhängiger Abrechnung. Die öffentliche Seite wirbt mit $20 Guthaben zuzüglich $1.23 Kartenbearbeitungsgebühr. Dieser angebotene Kauf kostet damit $21.23, wobei $20 für die Nutzung zur Verfügung stehen. Laut Seite werden Anfragen ohne Aufschlag abgerechnet, monatliche Ausgabenlimits sind möglich, und beim Erreichen eines Guthabens von $5 erfolgt eine automatische Aufladung um $20. Das sind Guthaben- und Zahlungsbedingungen, kein monatlicher Abonnementpreis. Vor dem Einzahlen sollten die aktuellen Bedingungen geprüft werden. Öffentliche Preisseite von Zen

Für die Verbindung wird /connect aufgerufen und OpenCode Zen ausgewählt. Nach der Konto- und Zahlungseinrichtung erhält man einen API-Schlüssel, fügt ihn in OpenCode ein und wählt über /models ein Modell. Wenn ein anderer Anbieter die Anforderungen bereits erfüllt, bleibt Zen optional. Zen verbinden

Beispielrechnung für eine Sitzung über Anthropic

Eine beispielhafte Sitzung mit Claude Sonnet 4.6 über die direkte API von Anthropic lässt sich anhand der veröffentlichten Standardpreise berechnen: $3 pro Million Eingabetokens und $15 pro Million Ausgabetokens. Ein Token ist eine kleine Texteinheit, die das Modell verarbeitet oder erzeugt. Für das Beispiel wird angenommen, dass die gesamte Sitzung über alle Anfragen hinweg 200,000 Eingabetokens ohne Caching und 20,000 Ausgabetokens umfasst. Anthropic-Preise für Modelle und Werkzeuge

Das ist eine Rechnung, keine gemessene OpenCode-Sitzung und kein zugesicherter Preis für eine Fehlerkorrektur. Vorausgesetzt werden die Standardpreise der direkten API, kein Caching und keine zusätzlichen Dienstgebühren. Zu berücksichtigen ist der gesamte Inhalt der Anfragen, einschließlich Anweisungen, wiederholt übermitteltem Gesprächskontext und Werkzeugergebnissen. Für Cache-Lese- und Schreibvorgänge gelten andere Preise; auch andere Dienste und Modelle verändern die Rechnung. Zen wird mit dieser Schätzung nicht bepreist.

Zwanzig Sitzungen mit der angenommenen Nutzung würden insgesamt $18 kosten, dreißig Sitzungen $27. Zum Vergleich: Claude Pro wird in den USA öffentlich für $20 pro Monat angeboten und enthält Claude Code mit Nutzungslimits. Das zeigt, wo ein variables API-Budget einen festen Preis pro Nutzer übersteigen kann. Es belegt weder gleichwertige Ergebnisse noch identische Kontingente oder welche Variante für die eigene Arbeit günstiger ist. Preis von Claude Pro und Abgrenzung zur API

In der Shell zeigt opencode stats Nutzungs- und Kostenstatistiken an; opencode stats --days 1 beschränkt sie auf den letzten Tag. Für eine einzelne Sitzung kann mit opencode export eine Sitzung ausgewählt und als JSON exportiert werden. Die Nutzung sollte mit der Abrechnung des jeweiligen Dienstes abgeglichen werden. Eine Schätzung anhand von Tokens ist nicht der Preis einer im Abonnement enthaltenen Aufgabe. Befehle zur Nutzungsübersicht

Sechs Aufgaben, geordnet nach ihrem praktischen Nutzen

Der Einstieg gelingt mit wiederkehrender Arbeit, deren Ergebnis sich beurteilen lässt. Die folgenden Abläufe sind Vorschläge, keine Aussagen über gemessene Zeitersparnis.

Der nichtinteraktive Befehl opencode run nimmt einen Prompt für skriptgesteuerte Aufgaben entgegen, sobald Anbieter und Arbeitsablauf eingerichtet sind. Wiederholbare Automatisierung lohnt sich, wenn für die Aufgabe bereits eine verlässliche Prüfmethode existiert. CLI-Befehl run

Wann passen OpenCode, Claude Code oder Pi?

OpenCode passt, wenn die Modellwahl für den Arbeitsablauf entscheidend ist und integrierte Plan- und Build-Agenten, Projektregeln sowie Plugin-Unterstützung gefragt sind. Die Anbieterauswahl ermöglicht eine gemeinsame Arbeitsoberfläche für mehrere Dienste und lokale Konfigurationen. Das ist eine Empfehlung für den Arbeitsablauf, keine Aussage darüber, dass OpenCode besseren Code erzeugt. OpenCode-Modelle, Agenten

Claude Code passt, wenn bereits überwiegend mit Claude gearbeitet wird und das Claude-Pro- oder Max-Abonnement über die dokumentierte Terminal- oder IDE-Integration genutzt werden soll. Claude und Claude Code teilen sich die Nutzungslimits des Tarifs. Die Abrechnungsoptionen lassen sich im Artikel Claude Code: Preise 2026 vergleichen. Claude-Integration für Abonnements

Pi passt, wenn ein kleinerer Kern gesucht wird, dessen Arbeitsweise sich mit Erweiterungen, Prompt-Vorlagen, Skills und Themes gestalten lässt. Auch Pi unterstützt mehrere Anbieter; Modellflexibilität allein begründet daher keine Entscheidung für OpenCode gegenüber Pi. Laut öffentlicher Pi-Übersicht lässt sich ein Planungsmodus durch Erweiterungen hinzufügen, statt bereits zum Kern zu gehören. Meine Empfehlung: OpenCode für den mitgelieferten Arbeitsablauf, Pi für Entwickler, die mehr davon selbst gestalten möchten. Öffentliche Pi-Übersicht

Für einen breiteren Vergleich von Terminal-Agenten eignet sich Gemini CLI vs. Claude Code. Modellzugang, bevorzugter Arbeitsablauf und Abrechnungsweg sollten dabei jeweils als eigene Vergleichsfragen betrachtet werden.

Zwei Geschäftsideen rund um OpenCode

Die stärkste Idee: Code-Reviews nach Repository-Regeln

Ein kleines Entwicklungsteam könnte für einen Review-Ablauf bezahlen, der seine wiederkehrenden Fehler prüft und Bedenken mit reproduzierbaren Belegen meldet. Als Interessenssignal dienen rund 1,300 monatliche US-Suchanfragen nach „ai code review“, laut der am 4. Oktober 2026 geprüften Keyword-Schätzung von DataForSEO. CodeRabbit nennt für Essentials öffentlich $24 pro Entwickler und Monat bei jährlicher Abrechnung oder $30 bei monatlicher Abrechnung. Das ist ein konkreter Preisbezug für diese kostenpflichtige Produktkategorie. Keyword-Daten von DataForSEO, CodeRabbit-Preise

Die kleinste verkaufbare Version würde die Review-Checkliste und die Projektanweisungen eines Teams laden, einen bereitgestellten Diff untersuchen und einen kurzen Bericht mit Dateipfaden, Prüfschritten und protokollierter Modellnutzung liefern. Als Anfang genügt ein wiederholbarer lokaler Befehl. Plugin-Ereignisse kommen dort hinzu, wo sie manuelle Arbeit verringern.

Die Hürden sind Wettbewerb und Vertrauen. Eine allgemeine Hülle für Code-Reviews bietet gegenüber vorhandenen Tools wenig Vorteil. Eine vielversprechende Nische braucht wiederkehrende fachliche Regeln und Belege dafür, dass die Vorschläge den Prüfaufwand reduzieren. Das Suchvolumen zeigt Interesse an der Kategorie, keine Nachfrage nach einem OpenCode-Produkt. Von den hier genannten Möglichkeiten ist diese die stärkste, weil Reviews regelmäßig anfallen und ihr Nutzen an tatsächlichen Diffs beurteilt werden kann.

Ein geprüftes OpenCode-Einrichtungspaket für Agenturen

Eine Agentur könnte einen Einrichtungsservice kaufen, der für jedes Kunden-Repository eine funktionierende Anbieteranbindung, eine korrekte AGENTS.md, eine minimale Konfiguration und eine geprüfte erste Aufgabe liefert. Rund 1,600 monatliche US-Suchanfragen nach „open source ai coding assistant“ zeigen Interesse an dieser Kategorie, basierend auf derselben DataForSEO-Prüfung. Keyword-Daten von DataForSEO

Das MVP wäre eine Einrichtungscheckliste samt repositoriespezifischer Konfiguration. Zum Lieferumfang gehören ein erfolgreich ausgeführter Prüfbefehl und ein klarer Abrechnungsweg. Eine weitere breit angelegte Oberfläche für Coding-Agenten wäre dafür unnötig. Die Hürde: Kostenlose Dokumentation deckt die Installation bereits ab, und Suchinteresse belegt keine Zahlungsbereitschaft. Ein kundenspezifisches Setup und eine gepflegte Übergabe lassen sich nur dann verkaufen, wenn Agenturen dieser Arbeit einen Wert beimessen.

Welche Verantwortung bleibt beim Menschen?

OpenCode beantwortet nicht, ob das Modell die fachlichen Anforderungen verstanden hat. Tests, Code-Review und die Entscheidung über ein Deployment bleiben in eigener Verantwortung. Bei einem Anbieterwechsel müssen außerdem Ergebnisqualität und tatsächliche Kosten erneut geprüft werden.

Lokale Modellausführung ersetzt die Rechnung eines gehosteten Dienstes durch Anforderungen an Hardwarekapazität und Einrichtung. Eine lokale Agentenoberfläche, die mit einem Cloud-Anbieter verbunden ist, sendet ihre Modellanfragen weiterhin an diesen Anbieter. Wo die Modellausführung stattfindet, muss unabhängig davon entschieden werden, wo der Prompt eingegeben wird.

Bei einer winzigen Änderung, deren Umsetzung bereits bekannt ist, können Einrichtung und Prüfung mehr Aufmerksamkeit kosten als die Änderung selbst. Bei einem unklaren Projekt sollten die Abnahmekriterien feststehen, bevor der Agent mit der Umsetzung beauftragt wird. Der eigentliche Wert liegt in einer korrekten, geprüften Änderung.

Der nächste Schritt am Montag: einen reproduzierbaren Fehler auswählen, einen neuen Branch anlegen, einen Anbieter verbinden und den Ablauf aus Lesen, Planen, Bearbeiten, Testen und Prüfen abschließen. Festhalten, welches Modell verwendet wurde, welche Prüfungen bestanden wurden und wie die Sitzung abgerechnet wurde. Diese Ergebnisse bilden die Grundlage für die nächste Entscheidung über Entwicklungswerkzeuge.

Für einen auf das Repository zugeschnittenen Coding- oder Review-Ablauf im eigenen Team ist KI-Agentenentwicklung der passende nächste Schritt.