Uruchom Open Interpreter na niestandardowym endpoincie kompatybilnym z OpenAI.

Szybka odpowiedź: api_base plus prefiks modelu openai/.

Open Interpreter dokumentuje ścieżkę niestandardowego endpointu w obu interfejsach. W CLI podaj --api_base z endpointem i --model z prefiksem openai/ na identyfikatorze. W Pythonie ustaw interpreter.llm.api_base, interpreter.llm.api_key i interpreter.llm.model przed wywołaniem chat(). Prefiks to nie dekoracja. Open Interpreter działa na LiteLLM, a LiteLLM rozwiązuje, którego klienta providera użyć, ze stringa modelu. openai/claude-sonnet-4-6 oznacza "mów protokołem chat-completions OpenAI do tego, co mówi api_base, z claude-sonnet-4-6 jako polem modelu". Porzuć prefiks, a LiteLLM zamiast tego wywnioskuje providera z gołej nazwy, kierując identyfikator claude-* do klienta Anthropic i ignorując skonfigurowany przez Ciebie endpoint.

export OPENAI_API_KEY=sk-APIsRouter-...

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

Co Open Interpreter robi ze swoim modelem.

Open Interpreter (openinterpreter na GitHubie, około 66 tys. gwiazdek) daje modelowi językowemu interpreter kodu na Twojej maszynie: podajesz cel w naturalnym języku, model pisze Python albo shell, Open Interpreter wykonuje to lokalnie, a output wraca do rozmowy na potrzeby następnego kroku. Ta pętla czyni go jakościowo innym niż klient czatu. Model nie produkuje prozy; produkuje kod, który działa z uprawnieniami Twojego użytkownika, i iteruje na prawdziwych błędach z Twojego prawdziwego systemu. Z tego wynikają dwie konsekwencje dla routingu. Po pierwsze, jakość modelu jest bezpośrednio własnością bezpieczeństwa i poprawności: model, który halucynuje flagi albo błędnie czyta traceback, produkuje kolejny nieudany obieg, a w trybie auto-run produkuje taki, którego nie zrecenzowałeś. Po drugie, pętla jest głodna tokenów w specyficzny sposób: każda tura wysyła ponownie rosnącą rozmowę, kod i przechwycony output, więc długie sesje debugowania szybko kumulują kontekst. Ustawienie api_base przesuwa całą tę pętlę na jeden endpoint. Ponieważ pole modelu przechodzi jako zwykły string za prefiksem openai/, identyfikator Claude, identyfikator GPT i identyfikator DeepSeek to wymienne wybory jednej flagi, zamiast osobnych konfiguracji providerów.

Pełna konfiguracja: Python API i profil.

Ścieżka Python ustawia te same trzy wartości na interpreter.llm i dodaje dwa ustawienia, których LiteLLM nie może odkryć dla niestandardowego identyfikatora: context_window i max_tokens. Open Interpreter używa context_window, żeby zdecydować, ile historii rozmowy zachować przed przycięciem, więc pozostawienie tego nieustawionym albo domyślnym na modelu 200k przycina znacznie wcześniej, niż to konieczne; zadeklaruj to, co model faktycznie wspiera. Dla trwałej konfiguracji te same klucze żyją w profilu YAML pod blokiem llm: (otwórz katalog profili przez interpreter --profiles). Profil trzyma ustawienia endpointu, modelu i okna poza historią Twojej powłoki i czyni konfigurację współdzielną między maszynami, z kluczem wciąż dostarczanym przez środowisko.

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.")

Dobór modelu, który pisze Twój kod.

Porównanie modeli jest tu niezwykle konkretne: daj dwóm modelom to samo zadanie i licz obiegi do działającego wyniku. Widok użycia per klucz dodaje koszt tokenów per sesja, co razem z liczbą obiegów jest całym porównaniem. Za jednym endpointem każdy kandydat to jedna flaga.

• Główna pętla chce modelu, który pisze działający kod i dobrze czyta tracebacki za pierwszym razem; claude-sonnet-4-6 i gpt-5.5 to niezawodny środek, a każdy nieudany obieg, którego unika lepszy model, to zaoszczędzone tokeny i czas zegarowy.
• deepseek-v4-pro to mocny kandydat do sesji ciężkich na kod, gdzie liczy się wolumen; przez jeden endpoint, wypróbowanie go na własnych zadaniach to pojedyncza zmiana --model.
• Szybkie sesje narzędziowe (zmiany nazw plików, jednorazowe transformacje, konwersje formatów) nie potrzebują rozumowania z czołówki; claude-haiku-4-5-20251001 albo glm-5.2 utrzymują je szybkimi i tanimi.
• Tryb auto-run (-y) usuwa krok ludzkiej recenzji między generowaniem kodu a wykonaniem. Jeśli w ogóle go używasz, używaj go z najsilniejszym modelem, jaki uruchamiasz, w piaskownicy albo kontenerze, nigdy z modelem, który wciąż oceniasz.

Płatność za użycie · poniżej cen oficjalnych

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

Tryby awarii charakterystyczne dla Open Interpreter.

Goły identyfikator modelu omija Twój endpoint. Bez prefiksu openai/, LiteLLM rozwiązuje providera z nazwy: identyfikatory claude-* zmierzają do klienta Anthropic, a wynikiem jest błąd uwierzytelniania albo routingu na host, którego nigdy nie skonfigurowałeś. Jeśli błędy wspominają SDK dostawcy zamiast Twojej bramki, brakuje prefiksu. Domyślne założenia kontekstu przycinają Twoje sesje. Dla identyfikatora, którego LiteLLM nie rozpoznaje, nic nie wypełnia okna kontekstu; Open Interpreter wraca do zachowawczego zachowania i przycina historię wcześnie. Zadeklaruj context_window jawnie, ponieważ sesja debugowania kodu, która traci swoje wcześniejsze próby, powtarza te same błędy. Rosnące sesje, rosnące rachunki. Każda tura wysyła ponownie rozmowę plus kod plus przechwycony output. Sesja, która wkleja do pętli duży dataframe albo długi log, niesie go w każdym kolejnym żądaniu. Preferuj, żeby model pisał kod inspekcjonujący pliki, zamiast wklejać zawartość plików do czatu, i zaczynaj świeże sesje, gdy zadanie się zmienia. Niezgodność wywołań funkcji. Open Interpreter może używać ustrukturyzowanych wywołań funkcji tam, gdzie są wspierane; flaga supports_functions istnieje dla identyfikatorów, gdzie detekcja źle zgaduje. Jeśli bloki kodu przychodzą źle sformowane na modelu, o którym wiesz, że jest zdolny, ustaw ją jawnie na True; jeśli model faktycznie nie ma wsparcia narzędzi, ustaw False, żeby włączyła się ścieżka zapasowa. Strona wykonania jest Twoja. api_base przesuwa ruch modelu; kod nadal działa lokalnie z Twoimi uprawnieniami. Bramka niczego nie sandboksuje, więc trzymaj auto-run zamknięty w kontenerach i pozwól, żeby recenzja bezpieczeństwa zostawała w pętli wszędzie indziej.

Kto kieruje Open Interpreter przez bramkę.

• Deweloperzy używający Open Interpreter jako codziennego narzędzia automatyzacji, którzy chcą generowania kodu jakości Claude, różnorodności GPT i szybkich identyfikatorów narzędziowych za jednym kluczem.
• Ludzie od danych uruchamiający pętle analizy eksploracyjnej, gdzie sesja może przepalić zaskakujący kontekst, a użycie per klucz czyni widocznym koszt per odpowiednik notebooka.
• Inżynierowie porównujący modele piszące kod po obiegach-do-działania, najuczciwszym dostępnym benchmarku, jedna flaga --model per kandydat.
• Majsterkowicze uruchamiający zaplanowane albo skonteneryzowane zadania interpretera, gdzie endpoint w zmiennej środowiskowej i jeden sekret biją zestaw poświadczeń per dostawca.
• Deweloperzy bez dostępu do rozliczeń danego dostawcy. Dostęp oparty na doładowaniu, bez wymogu karty, usuwa zależność od rejestracji u każdego dostawcy z osobna.

Zweryfikuj endpoint i debuguj pierwszą sesję.

Wylistuj najpierw modele bramki; identyfikator po openai/ musi dokładnie zgadzać się z serwowanym identyfikatorem, łącznie z sufiksem wersji. Awarie pierwszej sesji podążają za wzorcem. Błędy wymieniające anthropic albo inne SDK dostawcy oznaczają, że brakuje prefiksu openai/, a LiteLLM skierował po nazwie. 401 oznacza, że klucz nie jest widoczny w powłoce, która uruchomiła interpreter, albo został ustawiony dla innej zmiennej niż ta w użyciu; z prefiksem na miejscu, działa zarówno OPENAI_API_KEY, jak i jawny api_key. Błąd model-not-found z bramki to literówka w identyfikatorze. Błąd połączenia zwykle oznacza, że api_base zgubiło swój sufiks /v1; klient dokleja /chat/completions do dowolnej bazy, którą podasz. Gdy pętla już działa, konsola APIsRouter pokazuje model per żądanie, liczbę tokenów i wydatki. Sesje interpretera to klasyczny przypadek obciążenia, które wydaje się małe, a rozlicza się średnio, a widok użycia to sposób, żeby zobaczyć, które sesje faktycznie niosły tokeny.

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

Częste pytania