Zum Hauptinhalt springen

OpenCode

Worum geht's?

Das ist ein praktischer Entwickler-Guide zu OpenCode von anomalyco/opencode. Er richtet sich an Entwickler, die verstehen wollen, worin OpenCode gut ist, wie man es einrichtet und wie man sein Agent-, Tool-, Skill- und Konfigurationsmodell in einem echten Projekt nutzt.

Gegen Primärquellen geprüft

Dieser Guide basiert auf der offiziellen OpenCode-Dokumentation und dem offiziellen GitHub-Repository, geprĂĽft am 24. Juni 2026.

1. Was OpenCode ist​

OpenCode ist ein quelloffener KI-Coding-Agent, der laufen kann als:

  • ein Terminal-UI
  • eine Desktop-App
  • eine web-verbundene Oberfläche
  • eine IDE-Erweiterung

Die offizielle Doku positioniert es als Coding-Agenten und nicht nur als Chat-Wrapper. Sein Design dreht sich um:

  • terminal-first Entwicklung
  • Modell- und Provider-Flexibilität
  • agent-basierte Workflows
  • tiefe Anpassung ĂĽber Config, Commands, Skills und Plugins

In der Praxis sitzt OpenCode in derselben Familie wie Tools wie Claude Code, Codex CLI und Aider, aber mit stärkerem Fokus darauf, offen, provider-agnostisch und an verschiedene lokale oder Team-Setups anpassbar zu sein.

2. Warum Entwickler es nutzen​

Laut offizieller Doku ist OpenCode am stärksten, wenn du eine Agent-Shell willst, die an deinen Workflow angepasst werden kann, statt dich in einen Provider oder eine UI zu zwingen.

FähigkeitWarum sie zählt
Quelloffene Agent-ShellLeichter zu inspizieren, zu erweitern und in internen Workflows zu ĂĽbernehmen.
Terminal- + Desktop- + Web- + IDE-OberflächenDu bist nicht an eine Oberfläche gebunden.
75+ Provider plus lokale ModelleGute Passung für Abwägungen zwischen Kosten, Datenschutz und Experimentieren.
Plan- und Build-AgentenSaubere Trennung zwischen Planen und Ă„nderungen vornehmen.
Eigene Agenten und SubagentenNĂĽtzlich fĂĽr Code-Review, Doku, Debugging oder interne Team-Workflows.
Skills, Commands, Plugins, MCPLässt dich wiederholbares Verhalten in wiederverwendbare Bausteine verwandeln.
Headless und skriptbare CLIFunktioniert fĂĽr Automatisierung, CI und backend-angebundene Workflows.
Teilbare SessionsNĂĽtzlich fĂĽr Code-Review, Debugging und Pair-Programming-Ăśbergabe.

Das macht OpenCode besonders attraktiv fĂĽr:

  • Teams, die eine Tooling-Schicht ĂĽber vielen Modell-Providern wollen
  • Entwickler, die einen terminal-nativen Workflow bevorzugen
  • Organisationen, denen lokale Kontrolle und Erweiterbarkeit wichtig sind
  • Nutzer, die etwas Konfigurierbareres als eine geschlossene Hersteller-CLI wollen

3. Installation und erster Lauf​

Die offizielle EinfĂĽhrungsseite empfiehlt das Install-Skript als einfachsten Weg:

curl -fsSL https://opencode.ai/install | bash

Es kann auch mit Paketmanagern installiert werden:

npm install -g opencode-ai
brew install anomalyco/tap/opencode

Die Doku listet auĂźerdem bun, pnpm, yarn, Chocolatey, Scoop, mise, Docker, Release-Binaries und Arch-Pakete auf.

Erste Session​

cd /path/to/project
opencode

Nach dem Verbinden eines Providers empfiehlt die offizielle Doku, Folgendes auszufĂĽhren:

/init

Das lässt OpenCode das Projekt analysieren und eine AGENTS.md-Datei im Projekt-Root generieren.

Warum AGENTS.md wichtig ist​

Die Doku empfiehlt ausdrĂĽcklich, AGENTS.md in git zu committen. Das ist wichtig, weil es lokales Agent-Verhalten in geteilten Projektkontext verwandelt:

  • Projektstruktur
  • Coding-Muster
  • erwartete Konventionen
  • Workflow-Anleitung fĂĽr zukĂĽnftige Sessions

Das ist eine der besten Gewohnheiten von OpenCode und eine gute Team-Praxis.

4. Zentraler Workflow in der täglichen Entwicklung​

Die Doku von OpenCode präsentiert einen Workflow, der strukturierter ist als „bitte das Modell einfach, zu coden".

Nutze den Plan-Modus vor dem Build-Modus​

OpenCode liefert zwei eingebaute primäre Agenten mit:

  • Build fĂĽr Umsetzungsarbeit
  • Plan fĂĽr Analyse, ohne Dateien zu verändern

Du wechselst zwischen ihnen mit der Tab-Taste.

Das ist eine bedeutsame Design-Entscheidung: Planung ist nicht nur ein Prompt-Stil, sondern ein separater Agent-Modus mit restriktiveren Berechtigungen.

Stelle Fragen direkt zu Dateien​

Die Doku empfiehlt, Datei-Kontext inline anzuhängen:

"@packages/functions/src/api/index.ts"
How is authentication handled in @packages/functions/src/api/index.ts

Das macht OpenCode nicht nur zum Schreiben von Code nĂĽtzlich, sondern auch fĂĽr das Onboarding in eine Codebasis und das Erkunden der Architektur.

Nutze den Plan-Modus für größere Arbeit​

Der offizielle Workflow fĂĽr Feature-Arbeit ist:

  1. wechsle zu Plan
  2. beschreibe das Feature im Detail
  3. iteriere am Plan
  4. wechsle zurĂĽck zu Build
  5. bitte OpenCode, es umzusetzen

Das ist eine starke Best Practice, besonders fĂĽr:

  • Multi-Datei-Ă„nderungen
  • unbekannte Codebasen
  • Ă„nderungen mit UI-, Daten- und API-Auswirkungen
  • Refactors, bei denen du den Ansatz zuerst auf Plausibilität prĂĽfen willst

Bild-bewusste Planung​

Die Einführungs-Doku unterstützt ausdrücklich das Ziehen von Bildern in das Terminal, damit OpenCode sie als visuelle Referenz nutzen kann. Das ist ungewöhnlich praktisch für:

  • UI-Aufgaben
  • Design-Abgleich
  • Reverse Engineering von Screenshots

Undo, Redo und Teilen​

OpenCode enthält eingebaute Befehle zur Session-Steuerung:

  • /undo
  • /redo
  • /share

Das gibt dir eine leichtgewichtige Wiederherstellungs- und Kollaborationsschleife, ohne den Agent-Workflow zu verlassen.

5. Konfigurationsmodell​

Eines der größten Alleinstellungsmerkmale von OpenCode ist, wie viel seines Verhaltens bewusst konfigurierbar ist.

JSON- und JSONC-Config​

Die offizielle Config-Doku unterstĂĽtzt beides:

  • opencode.json
  • opencode.jsonc

Das ist klein, aber es zählt. JSONC macht langlebige Team-Config viel leichter wartbar.

Config-Ebenen werden zusammengeführt​

Die Doku sagt, dass die Konfiguration ĂĽber mehrere Ebenen hinweg zusammengefĂĽhrt und nicht ersetzt wird, darunter:

  1. remote organisationsweite Defaults
  2. globale Nutzer-Config
  3. eigener Config-Pfad
  4. Projekt-Config
  5. .opencode-Verzeichnisse
  6. inline Umgebungs-Overrides
  7. verwaltete Config-Dateien
  8. macOS-verwaltete Präferenzen

Das macht OpenCode unternehmensfreundlicher als viele Terminal-Coding-Tools, weil es Folgendes unterstĂĽtzen kann:

  • persönliche Defaults
  • repository-lokales Verhalten
  • organisationsweite Policy
  • admin-durchgesetzte Beschränkungen

Projekt-lokale Struktur​

Die Doku behandelt .opencode/ als erstklassigen Erweiterungsbereich fĂĽr Dinge wie:

  • agents/
  • commands/
  • plugins/
  • skills/
  • tools/
  • themes/

Das ist ein starkes Design, weil es Agent-Verhalten zum Teil des Repositories macht, statt es im Home-Verzeichnis eines einzelnen Entwicklers zu verstecken.

6. Agenten, Subagenten und Skills​

OpenCode ist nicht nur „ein Bot mit einem Prompt". Es hat ein echtes Agent-Modell.

Eingebaute primäre Agenten​

  • Build: Standard-Umsetzungsagent mit breitem Tool-Zugriff
  • Plan: analyse-zuerst Agent mit eingeschränkten Ă„nderungsberechtigungen

Eingebaute Subagenten​

Die offizielle Agents-Doku beschreibt eingebaute Subagenten, darunter:

  • General fĂĽr breitere mehrstufige Arbeit
  • Explore fĂĽr schnelle, schreibgeschĂĽtzte Exploration der Codebasis
  • Scout fĂĽr externe Doku- und Abhängigkeits-Recherche

Das ist nĂĽtzlich, weil es OpenCode eine eingebaute Arbeitsteilung gibt, statt einen einzelnen riesigen Agenten zu zwingen, alles zu erledigen.

Eigene Agenten​

Du kannst Agenten in der Config oder in Markdown-Dateien definieren und Folgendes feinjustieren:

  • Prompt
  • Modell
  • Modus
  • Berechtigungen
  • Temperatur
  • Schritt-Limits

Das macht es leicht, gezielte Agenten zu erstellen, etwa:

  • Code-Reviewer
  • Doku-Autor
  • Security-Auditor
  • Debug-Ermittler

Skills​

OpenCode unterstützt SKILL.md-basierte wiederverwendbare Anweisungen und lädt sie bei Bedarf über sein skill-Tool.

Ein besonders wichtiges Detail aus der offiziellen Doku: OpenCode kann Skills aus folgenden Quellen entdecken:

  • .opencode/skills/
  • .claude/skills/
  • .agents/skills/
  • passende globale Verzeichnisse im Home-Ordner des Nutzers

Das bedeutet, dass OpenCode sehr gut in Teams passt, die bereits in Claude-artige oder agent-kompatible Skill-Bibliotheken investiert haben. In der Praxis senkt das die Migrationsreibung und lässt dich prozedurales Wissen über Tools hinweg wiederverwenden.

7. Commands, Tools, Plugins und MCP​

Hier wird OpenCode zu mehr als einem Terminal-Chatbot.

Eigene Commands​

OpenCode lässt dich Slash-Commands entweder in der Config oder in Markdown-Dateien erstellen, zum Beispiel:

  • /test
  • /component Button
  • /review-changes

Das Command-System unterstĂĽtzt:

  • Prompt-Templates
  • Argumente wie $ARGUMENTS, $1, $2
  • inline Dateireferenzen mit @file
  • Injektion von Shell-Ausgabe
  • Modell- und Agent-Overrides pro Command

Das ist äußerst nützlich für wiederholbare Workflows. In vielen Teams ist das der schnellste Weg von „das machen wir oft manuell" zu „wir haben es in einen wiederverwendbaren KI-Command verwandelt".

Tools und Berechtigungen​

Die offizielle Tools-Doku listet eingebaute Tools auf, etwa:

  • bash
  • read
  • edit
  • write
  • grep
  • glob
  • apply_patch
  • skill
  • todowrite
  • webfetch
  • websearch

Das Berechtigungsmodell von OpenCode kann pro Tool oder pro Muster erlauben, verweigern oder eine Genehmigung verlangen.

Das ist mächtig, aber es gibt einen wichtigen Vorbehalt:

Standardverhalten ist freizĂĽgig

Die offizielle Config-Doku sagt, dass OpenCode standardmäßig alle Operationen ohne explizite Genehmigung erlaubt. Für echte Projektarbeit solltest du das normalerweise mit permission-Regeln verschärfen, besonders für edit, bash, task und externen Zugriff.

MCP-Server​

OpenCode enthält explizite MCP-Verwaltungsbefehle, etwa:

  • opencode mcp add
  • opencode mcp list
  • opencode mcp auth

Das macht es zu einer guten Passung fĂĽr Teams, die interne Tool-Ă–kosysteme rund um MCP bauen, statt sich nur auf eingebauten Datei- und Shell-Zugriff zu verlassen.

Plugins​

OpenCode unterstĂĽtzt auĂźerdem Plugins und kann sie installieren ĂĽber:

opencode plugin <module>

Das bedeutet, du kannst dein Kern-Setup schlank halten und Integrationen nur dort hinzufĂĽgen, wo sie Wert schaffen.

8. Provider und Modell-Flexibilität​

Die offizielle Provider-Doku sagt, dass OpenCode das AI SDK plus Models.dev nutzt und 75+ LLM-Provider unterstützt, zusätzlich zu lokalen Modellen.

Was das in der Praxis bedeutet​

OpenCode ist eine starke Wahl, wenn du Folgendes willst:

  • zwischen Anthropic, OpenAI, OpenRouter, xAI, Bedrock, Azure und anderen wechseln
  • ĂĽber ein Gateway oder einen Proxy routen
  • lokale Modelle hinter einem OpenAI-kompatiblen Endpoint betreiben
  • einen Agent-Workflow standardisieren und dabei nur das Backend-Modell ändern

Hilfreiche Befehle​

Die offizielle CLI unterstĂĽtzt:

opencode auth login
opencode auth list
opencode models

Und fĂĽr schnelle, nicht-interaktive Arbeit:

opencode run "Explain how this module works"

Lokale und remote Betriebsmodi​

Die CLI-Doku zeigt auĂźerdem, dass OpenCode laufen kann als:

  • ein interaktives TUI
  • ein nicht-interaktiver CLI-Runner
  • ein Headless-HTTP-Server mit opencode serve
  • eine web-gestĂĽtzte Oberfläche mit opencode web
  • ein remote-angebundenes TUI mit opencode attach

Das macht es flexibler als Tools, die nur einen lokalen interaktiven Modus unterstĂĽtzen.

9. Best Practices​

Wenn du OpenCode ernsthaft einsetzt, sind dies die von der offiziellen Doku am stärksten gestützten Best Practices.

1. Committe AGENTS.md​

Behandle AGENTS.md als geteiltes Projektgedächtnis, nicht als wegwerfbare lokale Ausgabe.

2. Nutze Plan zuerst bei nicht-trivialen Aufgaben​

Der Build-Modus ist mächtig, aber der Plan-Modus ist der sicherere Default für:

  • unbekannten Code
  • groĂźe Refactors
  • riskante Migrationen
  • Ă„nderungen mit unklarem Scope

3. Füge explizite Berechtigungen hinzu​

Lass echte Repositories nicht auf dem voll freizĂĽgigen Default, wenn deinem Team Leitplanken wichtig sind.

Gute Ausgangsidee:

  • edit: ask
  • bash: ask
  • task: ask
  • externe oder Web-Tools: nach Bedarf eingeschränkt

4. Lege wiederverwendbares Verhalten in .opencode/ ab​

Wenn sich ein Workflow wiederholt, verschiebe ihn aus dem Chat-Verlauf hinein in:

  • einen eigenen Command
  • einen eigenen Agenten
  • ein Skill
  • eine Projekt-Config-Datei

So skaliert OpenCode von „interessantes Tool" zu „wiederholbarer Team-Workflow".

5. Trenne Belange nach Agent​

Verwende unterschiedliche Agenten fĂĽr:

  • Planung
  • Umsetzung
  • Review
  • Doku
  • Debugging

Das ist sauberer, als zu versuchen, einen universellen Prompt zu zwingen, alles gut zu erledigen.

6. Nutze Projekt-Config, um die Team-Erfahrung zu stabilisieren​

Lege die wichtigen Defaults in opencode.json ab, damit jeder Entwickler dasselbe bekommt:

  • Modell-Defaults
  • Berechtigungen
  • Commands
  • aktivierte Provider
  • MCP-Setup

10. Wo OpenCode am besten passt​

OpenCode ist besonders stark, wenn du Folgendes willst:

  • einen quelloffenen Terminal-Agenten
  • Provider-Unabhängigkeit
  • UnterstĂĽtzung lokaler Modelle
  • geteilte Anpassung auf Repo-Ebene
  • ein reicheres Erweiterungsmodell als eine minimale Coding-CLI

Es ist oft eine bessere Passung als ein einfacheres Tool, wenn dein Team investieren will in:

  • eigene Agent-Rollen
  • wiederverwendbare Slash-Commands
  • Skills und interne Anweisungen
  • MCP-lastige Workflows
  • Policy- und Berechtigungskontrolle

Im Vergleich zu Aider​

OpenCode ist generell attraktiver, wenn du Folgendes willst:

  • ein breiteres Agent-Modell
  • mehr Anpassungsoberflächen
  • Web-/Server-/Desktop-Optionen
  • Skill- und Plugin-Schichtung

Aider ist oft einfacher, wenn deine Priorität ist:

  • eine sehr git-zentrierte Schleife
  • eng abgegrenzte Datei-Bearbeitung
  • minimaler konzeptioneller Overhead

Im Vergleich zu Hersteller-CLIs​

Im Vergleich zu Claude Code oder Codex CLI gibt OpenCode etwas „Einzelhersteller-Feinschliff" auf, im Austausch für:

  • mehr Backend-Freiheit
  • mehr Erweiterbarkeit
  • mehr lokale Kontrolle
  • leichtere Wiederverwendung tool-ĂĽbergreifender Anweisungs-Assets

11. Empfehlung​

OpenCode ergibt am meisten Sinn, wenn du eine ernstzunehmende offene Coding-Agent-Plattform willst, nicht nur eine Prompt-Shell.

Nutze es, wenn du standardisieren willst auf:

  • einen terminal-nativen Workflow
  • viele mögliche Modell-Backends
  • projekt-lokale Agent-Anpassung
  • wiederverwendbare interne Commands, Skills und Policy

Wenn du nur schnelle KI-Edits in einem git-Repo brauchst, reicht vielleicht ein engeres Tool. Aber wenn du einen Coding-Agenten willst, der zu einer Team-Betriebsschicht heranwachsen kann, ist OpenCode eine der ĂĽberzeugenderen quelloffenen Optionen.

Quellen​