Open Interpreter auf einem custom OpenAI-kompatiblen Endpoint betreiben.

Kurzantwort: api_base plus das openai/-Modellpräfix.

Open Interpreter dokumentiert einen custom-Endpoint-Pfad in beiden Interfaces. Auf der CLI übergib --api_base mit dem Endpoint und --model mit einem openai/-Präfix auf der ID. In Python setz interpreter.llm.api_base, interpreter.llm.api_key und interpreter.llm.model, bevor du chat() aufrufst. Das Präfix ist keine Dekoration. Open Interpreter läuft auf LiteLLM, und LiteLLM entscheidet aus dem Modell-String, welchen Provider-Client es nutzt. openai/claude-sonnet-4-6 bedeutet "sprich das OpenAI-Chat-Completions-Protokoll gegen das, was api_base sagt, mit claude-sonnet-4-6 als model-Feld." Lässt du das Präfix weg, inferiert LiteLLM den Provider stattdessen aus dem nackten Namen und routet eine claude-*-ID Richtung Anthropics Client, dein konfigurierter Endpoint wird ignoriert.

export OPENAI_API_KEY=sk-APIsRouter-...

interpreter \
  --api_base https://api.apisrouter.com/v1 \
  --model openai/claude-sonnet-4-6

Was Open Interpreter mit seinem Modell macht.

Open Interpreter (openinterpreter auf GitHub, rund 66.000 Stars) gibt einem Sprachmodell einen Code-Interpreter auf deinem Rechner: du formulierst ein Ziel in natürlicher Sprache, das Modell schreibt Python oder Shell, Open Interpreter führt es lokal aus, und der Output fließt zurück in die Konversation für den nächsten Schritt. Dieser Loop macht es qualitativ anders als einen Chat-Client. Das Modell produziert keine Prosa; es produziert Code, der mit den Rechten deines Nutzers läuft, und es iteriert gegen echte Fehler von deinem echten System. Zwei Konsequenzen folgen fürs Routing. Erstens ist Modellqualität direkt eine Sicherheits- und Korrektheitseigenschaft: ein Modell, das Flags halluziniert oder einen Traceback missliest, produziert eine weitere fehlschlagende Runde, und im Auto-Run-Modus produziert es eine, die du nicht überprüft hast. Zweitens ist der Loop auf spezifische Weise tokenhungrig: jeder Zug schickt die wachsende Konversation, den Code und den erfassten Output erneut, lange Debugging-Sessions summieren also Kontext schnell auf. Die api_base-Einstellung bewegt diesen ganzen Loop auf einen Endpoint. Weil das model-Feld nach dem openai/-Präfix als reiner String durchgereicht wird, sind eine Claude-ID, eine GPT-ID und eine DeepSeek-ID austauschbare Ein-Flag-Entscheidungen statt separater Provider-Setups.

Vollständiges Setup: Python-API und ein Profil.

Der Python-Pfad setzt dieselben drei Werte auf interpreter.llm und fügt die zwei Einstellungen hinzu, die LiteLLM für eine custom ID nicht selbst herausfinden kann: context_window und max_tokens. Open Interpreter nutzt context_window, um zu entscheiden, wie viel Konversationshistorie es vor dem Kürzen behält, ungesetzt oder auf Default bei einem 200k-Modell kürzt es also weit früher als nötig; deklarier, was das Modell tatsächlich unterstützt. Für ein dauerhaftes Setup leben dieselben Keys in einer Profil-YAML unter einem llm:-Block (öffne das Profile-Verzeichnis mit interpreter --profiles). Ein Profil hält Endpoint, Modell und Fenster-Einstellungen aus deiner Shell-History und macht die Konfiguration über Rechner hinweg teilbar, wobei der Key weiterhin aus der Umgebung kommt.

import os
from interpreter import interpreter

interpreter.llm.api_base = "https://api.apisrouter.com/v1"
interpreter.llm.api_key = os.environ["APISROUTER_API_KEY"]
interpreter.llm.model = "openai/claude-sonnet-4-6"

# LiteLLM cannot infer these for a custom id; declare them:
interpreter.llm.context_window = 200000
interpreter.llm.max_tokens = 8192
interpreter.llm.supports_functions = True

interpreter.chat("Profile data.csv and plot the top 10 rows by revenue.")

Das Modell wählen, das deinen Code schreibt.

Modellvergleich ist hier ungewöhnlich konkret: gib zwei Modellen dieselbe Aufgabe und zähl Runden bis zu einem funktionierenden Ergebnis. Die Nutzungsansicht pro Key fügt die Token-Kosten pro Session hinzu, was zusammen mit der Rundenzahl der ganze Vergleich ist. Hinter einem Endpoint ist jeder Kandidat ein Flag.

• Der Haupt-Loop will ein Modell, das lauffähigen Code schreibt und Tracebacks im ersten Durchgang gut liest; claude-sonnet-4-6 und gpt-5.5 sind die verlässliche Mitte, und jede fehlschlagende Runde, die ein besseres Modell vermeidet, sind gesparte Token und Wall-Clock-Zeit.
• deepseek-v4-pro ist ein starker Kandidat für code-lastige Sessions, wo Volumen zählt; über einen Endpoint ist es an deinen eigenen Aufgaben zu testen eine einzelne --model-Änderung.
• Schnelle Utility-Sessions (Datei-Umbenennungen, einmalige Transformationen, Format-Konvertierungen) brauchen kein Frontier-Reasoning; claude-haiku-4-5-20251001 oder glm-5.2 halten sie schnell und günstig.
• Der Auto-Run-Modus (-y) entfernt den menschlichen Review-Schritt zwischen Code-Generierung und Ausführung. Nutzt du ihn überhaupt, nutz ihn mit dem stärksten Modell, das du laufen lässt, in einer Sandbox oder einem Container, nie mit einem Modell, das du noch evaluierst.

Nutzungsbasiert · unter offiziellem Preis

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Die Fehlerbilder speziell für Open Interpreter.

Eine nackte Modell-ID routet um deinen Endpoint herum. Ohne das openai/-Präfix löst LiteLLM den Provider aus dem Namen auf: claude-*-IDs gehen Richtung Anthropics Client, und das Ergebnis ist ein Auth- oder Routing-Fehler gegen einen Host, den du nie konfiguriert hast. Erwähnen Fehler ein Vendor-SDK statt dein Gateway, fehlt das Präfix. Default-Kontext-Annahmen kürzen deine Sessions. Für eine ID, die LiteLLM nicht erkennt, füllt nichts das Kontextfenster; Open Interpreter fällt auf konservatives Verhalten zurück und kürzt Historie früh. Deklarier context_window explizit, weil eine Code-Debugging-Session, die ihre früheren Versuche verliert, dieselben Fehler wiederholt. Wachsende Sessions, wachsende Rechnungen. Jeder Zug schickt Konversation plus Code plus erfassten Output erneut. Eine Session, die einen großen Dataframe oder ein langes Log in den Loop einfügt, trägt es in jeden folgenden Request. Bevorzug, das Modell Code schreiben zu lassen, der Dateien inspiziert, statt Dateiinhalt in den Chat zu pasten, und starte frische Sessions, wenn sich eine Aufgabe ändert. Function-Calling-Mismatch. Open Interpreter kann strukturierte Function-Calls nutzen, wo unterstützt; das supports_functions-Flag existiert für IDs, bei denen die Erkennung falsch rät. Kommen Code-Blöcke bei einem Modell, das du als fähig kennst, fehlgeformt an, setz es explizit auf True; fehlt einem Modell tatsächlich Tool-Support, setz False, damit der Fallback-Pfad greift. Die Ausführungsseite ist deine. api_base bewegt den Modell-Traffic; der Code läuft weiterhin lokal mit deinen Rechten. Ein Gateway sandboxt nichts, halt Auto-Run also auf Container beschränkt und lass den Sicherheits-Review überall sonst im Loop.

Wer Open Interpreter über ein Gateway routet.

• Entwickler, die Open Interpreter als tägliches Automatisierungstool nutzen und Claude-Qualitäts-Codegenerierung, GPT-Vielfalt und schnelle Utility-IDs hinter einem Key wollen.
• Data-Leute, die explorative Analyse-Loops laufen lassen, wo eine Session überraschend viel Kontext verbrennen kann und Nutzung pro Key die Kosten pro Notebook-Äquivalent sichtbar macht.
• Ingenieure, die code-schreibende Modelle an Runden-bis-lauffähig vergleichen, dem ehrlichsten verfügbaren Benchmark, ein --model-Flag pro Kandidat.
• Bastler, die geplante oder containerisierte Interpreter-Jobs laufen lassen, wo ein Env-Var-Endpoint und ein Secret einen Credential-Satz pro Vendor schlagen.
• Entwickler ohne Zugang zum Billing eines bestimmten Vendors. Guthabenbasierter Zugang ohne Kartenpflicht entfernt die Sign-up-Abhängigkeit pro Provider.

Endpoint verifizieren und die erste Session debuggen.

Liste zuerst die Modelle des Gateways; die ID nach openai/ muss exakt zu einer bedienten ID passen, Versions-Suffix eingeschlossen. First-Session-Fehler folgen einem Muster. Fehler, die anthropic oder ein anderes Vendor-SDK nennen, bedeuten, das openai/-Präfix fehlt und LiteLLM hat nach Namen geroutet. Ein 401 bedeutet, der Key ist in der Shell, die den Interpreter gestartet hat, nicht sichtbar, oder wurde für eine andere Variable gesetzt als die genutzte; mit dem Präfix an Ort und Stelle funktionieren OPENAI_API_KEY oder ein explizites api_key beide. Ein Model-not-found-Fehler vom Gateway ist ein ID-Tippfehler. Ein Connection-Fehler bedeutet meist, api_base hat sein /v1-Suffix verloren; der Client hängt /chat/completions an das an, was du als Base gibst. Sobald der Loop läuft, zeigt die APIsRouter-Konsole Modell, Token-Zahlen und Ausgaben pro Anfrage. Interpreter-Sessions sind der klassische Fall einer Workload, die sich klein anfühlt und mittel abrechnet, und die Nutzungsansicht ist, wie du siehst, welche Sessions die Token tatsächlich getragen haben.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Häufige Fragen