Dokumentation

Open Interpreter

Open Interpreter liest Anbieter aus einer TOML-Tabelle, wie sein Codex-Vorgänger. Es verwendet jedoch weiterhin einen Chat Completions-Transport, den das ursprüngliche Codex-Projekt entfernt hat. Mit einem einzigen Block [model_providers.kunavo] kann der Agent jedes Modell verwenden, auf das der Schlüssel Zugriff hat.

Eine [model_providers.kunavo]-Tabelle in ~/.openinterpreter/config.toml — base_url, env_key, wire_api = "chat" — und der Rust-Terminal-Agent läuft mit jedem Modell, das der Schlüssel erreicht.

~/.openinterpreter/config.toml

model_provider = "kunavo"
model = "claude-sonnet-5"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"     # the NAME of the variable, not the key
wire_api = "chat"

Die Basis-URL behält den Suffix /v1 auf dem chat-Wire bei. Die Dokumentation von Open Interpreter klärt dies anhand von Beispielen statt einer ausdrücklich formulierten Regel: Der Block für benutzerdefinierte Provider auf der Provider-Seite verwendet base_url = "https://api.example.com/v1", der auf der Konfigurationsseite "https://api.acme.example/v1", und das namentlich dokumentierte gehostete Gateway verwendet "https://app.nz/v1". Wird der Suffix weggelassen, führt das zu einem 404-Fehler, nicht zu einem Authentifizierungsfehler.

Kunavo hat diesen Client nicht mit seinem Endpunkt ausgeführt — weder diesen noch einen anderen Client auf diesen Seiten. Überprüft wurde die Konfigurationsoberfläche: Die unten aufgeführten Schlüssel sind diejenigen, die in der eigenen Dokumentation von Open Interpreter abgedruckt sind, wie sie am Ende dieser Seite datiert ist; Basis-URL und Modell-IDs stammen von Kunavo. Eine veröffentlichte Einrichtungsseite ist kein Testlauf. Mit der Verifizierungsanfrage stellen Sie fest, ob es funktioniert.

Zwei verschiedene Programme tragen den Namen „Open Interpreter“, und dieser Block ist für die Rust-Version. Das bei 0.4.3 eingefrorene Python-Paket wird über --api_base, --api_key und --model openai/<id> oder über interpreter.llm in Python konfiguriert. Nichts davon gibt es im aktuellen Terminal-Agenten, der ausschließlich die obige TOML-Tabelle einliest. Führen Sie interpreter --version aus, bevor Sie etwas bearbeiten — ein pip install open-interpreter aus einem alten Tutorial hinterlässt eine zweite Binärdatei, die um denselben Namen konkurriert.

Eine Claude-Modell-ID veranlasst Open Interpreter automatisch, das claude-code-Harness auszuwählen — laut dokumentierten Standardwerten wird es für „Anthropic, Claude-Modell-IDs, eine Anthropic-Basis-URL oder jeden messages-Provider“ ausgewählt. Diese Kombination ist hier zulässig: Die Routing-Tabelle führt claude-code als kompatibel mit wire_api = "chat" auf. Legen Sie harness explizit fest, wenn Sie ein anderes Harness möchten; ein expliziter Wert hat immer Vorrang, und bei einem nicht erkannten Wert wird ohne deutliche Fehlermeldung auf Chat ohne integrierten Anfrage-Builder zurückgegriffen.

Noch kein Schlüssel? Erstelle ein Kunavo-Konto, erstelle einen Schlüssel (er beginnt mit sk-kn-) und füge ab $10 Guthaben hinzu – Aufrufe werden aus diesem Guthaben bezahlt, fehlgeschlagene Aufrufe werden nicht berechnet. Das Dashboard öffnet anschließend die Open Interpreter-Einrichtung.

Schritt für Schritt

Erstellen Sie unter /app/keys einen Schlüssel und kopieren Sie ihn — er wird nur einmal angezeigt.
Exportieren Sie den Schlüssel unter dem Namen, den Sie in env_key eintragen möchten: export KUNAVO_API_KEY=sk-kn-.... Dieses Feld enthält den Variablennamen, nicht ihren Wert — in der Dokumentation wird env_key als Quelle aufgeführt, die „ein Bearer-Token aus einer Umgebungsvariablen einliest“.
Legen Sie den obigen Block in ~/.openinterpreter/config.toml oder in .openinterpreter/config.toml innerhalb eines vertrauenswürdigen Projekts ab, wenn er nur für ein Repository gelten soll. Die Projektkonfiguration hat Vorrang vor der Benutzerkonfiguration; eine -c key=value-Option hat bei diesem Lauf Vorrang vor beiden.
Starten Sie interpreter und führen Sie /model aus. Die Auswahl fragt zuerst die Modelle-Route des aktiven Providers ab, und Kunavo antwortet mit GET /v1/models, sodass die Liste automatisch gefüllt wird.
Führen Sie /debug-config aus, wenn die falschen Werte verwendet werden — der Befehl gibt die effektive Konfiguration und die Quelle jedes Werts aus. So lässt sich ein veraltetes Profil oder eine Projektdatei schneller erkennen, als die TOML-Datei erneut zu lesen.

Abgeglichen mit Die Seite „Model Providers“ von Open Interpreter am 21. September 2026. Einstellungen von Drittanbietern können sich ändern; wenn ein Feldname hier nicht mehr mit deiner Ansicht übereinstimmt, ist diese Seite maßgeblich, nicht diese hier.

Dies ist die Kurzfassung. Die vollständige Anleitung – Modellauswahl, Kosten einer tatsächlichen Sitzung und Fehlerszenarien – findest du in die Versionsunterschiede, Preise und Alternativen von Open Interpreter.

Vor dem Debugging des Clients prüfen

Eine Anfrage klärt, ob der Fehler am Endpunkt, am Schlüssel oder an der Konfigurationsdatei liegt. Wenn diese Anfrage JSON zurückgibt, funktionieren dieselbe Basis-URL und derselbe Schlüssel in Open Interpreter.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Welche Modell-ID in das Feld gehört

Jedes Textmodell ist über eine Modell-ID erreichbar – die aktuelle Liste findest du unter GET /v1/models, den Katalog mit Preisen auf der Modellseite. Die Tarife sind USD pro 1 Mio. Token, Eingabe / Ausgabe.

Modell-ID	Kunavo: Ein- und Ausgabe	Wo es in Open Interpreter hineinpasst
`claude-sonnet-5`	$1.40 / $7.00	das Standardmodell für Bearbeiten-und-Ausführen-Schleifen
`claude-opus-5`	$3.50 / $17.50	Planung eines umfangreichen Refactorings, bei dem ein falscher Plan teuer zu stehen kommt
`claude-haiku-4-5`	$0.70 / $3.50	shellintensive Sitzungen, in denen die Anzahl der Runden ausschlaggebend ist
`gpt-5-6-sol`	$2.00 / $12.00	eine zweite Meinung aus einer anderen Modellfamilie mit demselben Schlüssel

Die Abrechnung erfolgt pro Token aus einem vorausbezahlten Guthaben ohne Monatsgebühr – siehe Abrechnung. Bei wiederholtem Kontext – dem Großteil dessen, was ein Editor oder Chat-Client sendet – verändert Prompt-Caching die Rechnung stärker als die Modellwahl.

Häufig gestellte Fragen

Wie richte ich Open Interpreter auf einen benutzerdefinierten API-Provider aus?

Fügen Sie der Tabelle [model_providers.<id>] in ~/.openinterpreter/config.toml die Felder name, base_url, env_key und wire_api hinzu. Wählen Sie den Provider anschließend mit dem Schlüssel model_provider auf oberster Ebene aus und geben Sie mit model ein Modell an. Verwenden Sie für einen OpenAI-kompatiblen Endpunkt wire_api = "chat" und eine Basis-URL mit dem Suffix /v1 — so sehen die Beispiele für einen benutzerdefinierten Provider und das namentlich dokumentierte gehostete Gateway auf der eigenen Provider-Seite von Open Interpreter aus. env_key enthält den Namen einer Umgebungsvariablen. Exportieren Sie daher den Schlüssel, anstatt ihn in die Datei einzufügen.

Muss Open Interpreters base_url mit /v1 enden?

Beim Chat-Wire: ja. Die Dokumentation formuliert keine Regel zur Pfadbildung, doch alle abgedruckten Beispiele für benutzerdefinierte Provider enthalten den Suffix: https://api.example.com/v1 auf der Provider-Seite, https://api.acme.example/v1 auf der Konfigurationsseite und https://app.nz/v1 für das dort namentlich aufgeführte Gateway. Das Messages-Wire verhält sich anders — die mit dem Client ausgelieferten Provider im Anthropic-Stil verwenden eine API-Basis ohne /v1. Daher gilt die Antwort mit /v1 speziell für wire_api = "chat" und wire_api = "responses".

Funktionieren die alten Optionen --api_base und --model openai/... noch?

Nein. Diese gehören zum bei 0.4.3 eingefrorenen Python-Paket, das über LiteLLM routete und deshalb das Präfix openai/ benötigte. Der aktuelle Terminal-Agent ist ein Rust-Fork von Codex, der weder diese Optionen noch die Präfixkonvention verwendet: Er liest eine TOML-Provider-Tabelle aus ~/.openinterpreter/config.toml oder einer .openinterpreter/config.toml auf Projektebene ein und wählt den Provider mit model_provider und das Modell mit model aus. Die Konfiguration wird von Grund auf neu geschrieben. docs.openinterpreter.com leitet auf die Rust-Dokumentation weiter, sodass Links aus einem alten Tutorial weiterhin funktionieren, obwohl sie ein Programm beschreiben, das bei Ihnen nicht installiert ist.

Warum zeigt die Modellauswahl unter /model für einen benutzerdefinierten Provider kein Kontextfenster an?

Diese Metadaten stammen aus dem im Client enthaltenen Katalog, der aus models.dev und einigen wenigen aktiven Provider-Endpunkten erstellt wird. Er wird nur dann mit Daten versehen, wenn ein Provider anhand der Anthropic-Identität, der Basis-URL, des Providernamens oder der Authentifizierungs-Umgebungsvariablen einem Eintrag zugeordnet wird. Kunavo ist nicht in diesem generierten Katalog enthalten — überprüft anhand der Datei im Repository am 21. September 2026. Daher erhält ein manuell eingetragener Provider die Modellliste aus der eigenen Modelle-Route des Endpunkts und sonst nichts. Die Modelle funktionieren weiterhin; neben ihnen zeigt die Auswahl nur weniger Informationen an.

Kann Open Interpreter ein Claude-Modell ohne Anthropic-Konto erreichen?

Ja, denn wire_api bezeichnet ein Transportprotokoll, keinen Anbieter. Bei wire_api = "chat" wird die Modell-ID unverändert an die konfigurierte base_url übergeben und dort aufgelöst. Sie verwenden also die Zugangsdaten des Endpunkts. Open Interpreter wählt anhand einer Claude-Modell-ID weiterhin automatisch sein claude-code-Harness aus, das als mit dem Chat-Wire kompatibel aufgeführt ist. Diese Kombination ist somit die dokumentierte Variante und keine Umgehungslösung.