OpenCode Provider: 7 Checks für Modelle, Keys und Konfiguration

Die Suche OpenCode Provider kann einen Dienstvergleich, einen Drittanbieter, einen OpenAI-kompatiblen Endpoint oder ein fehlendes Modell meinen. Eine feste Markenliste veraltet bei Preisen, IDs und Authentifizierung schnell. Eine saubere Entscheidungsreihenfolge bleibt dagegen nachvollziehbar.

Die offizielle OpenCode-Dokumentation bündelt Credentials, Config, OpenCode Zen, OpenCode Go und ein Provider-Verzeichnis. Dieser Artikel ergänzt die Reihenfolge: Ebene bestimmen, minimale Verbindung wählen, Modell-ID prüfen und Belege sichern, bevor Schreibaktionen gestartet werden.

Der Provider ist der Weg zu einem Modelldienst. Das Modell ist die konkrete Fähigkeit dieses Dienstes; Zugangsdaten beweisen die Berechtigung. Wer alles als eine Einstellung behandelt, erhält irreführende Symptome: Ein gültiger Key repariert keine falsche Modell-ID, und ein sichtbares Modell beweist keine gültige Anmeldung.

Der Konfigurations-Scope ist ein viertes Thema. Ein Provider kann in der Projektdatei funktionieren, aber global fehlen; verwaltete Einstellungen können deine Änderung überschreiben. Notiere Datei, Scope, Providername, Modell-ID und Prüfdatum, statt eine vollständige Datei mit lokalen Pfaden zu teilen.

Vier Wege sind praktisch. OpenCode Go und OpenCode Zen sind First-Party-Dienste mit eigenen Plänen. Ein gehosteter Drittanbieter passt, wenn Team-Abrechnung, Region oder ein bestimmtes Modell zählen. Ein OpenAI-kompatibler oder lokaler Endpoint ist flexibel, bringt aber mehr Verantwortung für URL, Discovery, Runtime und Diagnose.

Wähle nicht nur nach einem Verzeichnisnamen. Entscheide zuerst, ob monatliche Planbarkeit, Verbrauchskontrolle, Datenstandort, Offline-Betrieb, Qualität, Latenz oder ein bereits betriebener Dienst wichtig ist. Ein günstiger Provider hilft nicht, wenn die Modellliste instabil ist oder die Umgebung den Endpoint nicht prüfen kann.

Die offizielle Form legt eigene Provider unter provider ab. Der npm-Adapter, Optionen, Auth-Variable und Modellkarte hängen vom Dienst ab. Lies die Anleitung des Anbieters, übernimm nur verstandene Felder und dokumentiere die Wahl von Endpoint und Adapter.

Halte das Secret außerhalb des Repositories: OAuth, Umgebungsvariable oder Credential Store. Eine aktive API-Key gehört nicht in opencode.json, Screenshots, Shell-History oder geteilte Sessions. Wenn ein Key in einem Log auftauchte, rotiere ihn vor der weiteren Diagnose.

Füge beim Testen nur einen Provider hinzu. Eine kleine Änderung trennt Schema, Dienstfehler und Rollback; entferne den Block, stelle das bekannte Modell wieder her und wiederhole den bekannten Request.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my-provider": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "provider-demo",
      "options": { "baseURL": "https://api.provider.test/v1" },
      "models": { "model-id": { "name": "Model name" } }
    }
  }
}

Ein Eintrag ist erst fertig, wenn OpenCode ein echtes Modell findet und einen kleinen Request abschließt. Prüfe ID und Authentifizierung in der aktuellen Provider-Dokumentation und nutze /models. Bei mehreren Varianten sollte zuerst eine zu Kontext, Tools, Latenz und Kosten passende ID geöffnet werden.

Der erste Request sollte lesbar und vergleichbar sein: eine kleine lokale Datei erklären lassen oder nur den nächsten Prüf-Befehl nennen lassen. Prüfe Vollständigkeit, Tools, Dauer und tatsächlich verwendetes Modell. Schreibaktionen kommen erst nach diesem Beleg.

1. Scope prüfenGlobal, Projekt, eigener Pfad oder verwaltet unterscheiden.
2. Key schützenOAuth, Umgebungsvariable oder Credential Store verwenden.
3. Provider bestätigenID, Adapter, Endpoint und offizielle Anleitung abgleichen.
4. Modell bestätigenExakte ID statt nur Anzeigename verwenden.
5. Modelle listenSelector öffnen oder den dokumentierten `/models`-Weg nutzen.
6. Nur lesenKleinen Prompt senden und mit einer Erwartung vergleichen.
7. Rollback notierenGültige Config, Ergebnis und kleinste Rücknahme festhalten.

Fehler lassen sich trennen, wenn Authentifizierung, Discovery, Modell und Transport nicht vermischt werden. 401 oder OAuth-Schleife deuten auf Zugangsdaten oder Scopes. Ein fehlender Provider deutet auf Scope, Schema oder Ladefolge. Ein fehlendes Modell deutet auf Katalog oder ID. Ein Timeout nach erfolgreicher Discovery deutet auf Netzwerk, Proxy, Region oder Dienststatus.

Ändere pro Test nur eine Variable. Prüfe den Endpoint nach der offiziellen Anleitung, danach die von OpenCode gelesene Datei, dann die Modellliste und zuletzt den Prompt. Mehr Provider als Diagnosehilfe zu ergänzen macht Katalog und Logs unleserlicher.

OpenCode Go passt zu vorhersehbarer Subscription-Nutzung; Zen zu ausgewähltem Katalog und Pay-as-you-go. Ein gehosteter Drittanbieter passt bei Abrechnung, Compliance, Region oder einem bestimmten Modell. Ein lokaler oder OpenAI-kompatibler Endpoint passt, wenn du Runtime und Dienst selbst verantwortest. Das sind Fit-Entscheidungen, keine dauerhaften Rankings.

Der Provider verändert auch die Datenschutzannahme. Das CLI kann lokal laufen, während Anfragen an den ausgewählten Modelldienst gehen. Lies die Richtlinie, sende keine Secrets oder unnötigen Kundendaten und teste in einem nicht produktiven Repository. Models-, JSONC-, Ollama- und Go-vs-Zen-Leitfäden decken die Nachbarthemen ab; diese Seite verknüpft sie ohne Wiederholung.

Bei OpenCode Provider ist eine reproduzierbare Verbindung wertvoller als eine eingefrorene Gewinnerliste. Verzeichnis, Modelle, Preise, Quoten und Login ändern sich; prüfe die offizielle Quelle am Konfigurationstag und notiere das Datum.