Fai girare Open Interpreter su un endpoint OpenAI-compatible personalizzato.

Risposta rapida: api_base più il prefisso di modello openai/.

Open Interpreter documenta un percorso per endpoint personalizzato in entrambe le interfacce. Sulla CLI, passa --api_base con l'endpoint e --model con un prefisso openai/ sull'id. In Python, imposta interpreter.llm.api_base, interpreter.llm.api_key, e interpreter.llm.model prima di chiamare chat(). Il prefisso non è decorazione. Open Interpreter gira su LiteLLM, e LiteLLM risolve quale client di provider usare dalla stringa del modello. openai/claude-sonnet-4-6 significa "parla il protocollo chat-completions di OpenAI verso qualunque cosa dica api_base, con claude-sonnet-4-6 come campo model". Togli il prefisso e LiteLLM deduce invece il provider dal nome nudo, instradando un id claude-* verso il client di Anthropic e ignorando l'endpoint che hai configurato.

export OPENAI_API_KEY=sk-APIsRouter-...

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

Cosa fa Open Interpreter con il suo modello.

Open Interpreter (openinterpreter su GitHub, circa 66K stelle) dà a un modello linguistico un interprete di codice sulla tua macchina: dichiari un obiettivo in linguaggio naturale, il modello scrive Python o shell, Open Interpreter lo esegue localmente, e l'output rientra nella conversazione per il passo successivo. Quel loop lo rende qualitativamente diverso da un client di chat. Il modello non produce prosa; produce codice che gira con i permessi del tuo utente, e itera contro errori reali dal tuo sistema reale. Due conseguenze seguono per il routing. Primo, la qualità del modello è direttamente una proprietà di sicurezza e correttezza: un modello che allucina flag o legge male un traceback produce un altro giro di andata e ritorno fallito, e in modalità auto-run ne produce uno che non hai revisionato. Secondo, il loop è affamato di token in un modo specifico: ogni turno reinvia la conversazione crescente, il codice, e l'output catturato, quindi le sessioni di debug lunghe accumulano contesto rapidamente. L'impostazione api_base sposta l'intero loop verso un endpoint. Poiché il campo model passa come stringa semplice dopo il prefisso openai/, un id Claude, un id GPT, e un id DeepSeek sono scelte intercambiabili a un flag invece di configurazioni fornitore separate.

Configurazione completa: API Python e un profilo.

Il percorso Python imposta gli stessi tre valori su interpreter.llm e aggiunge le due impostazioni che LiteLLM non può scoprire per un id personalizzato: context_window e max_tokens. Open Interpreter usa context_window per decidere quanta cronologia di conversazione mantenere prima di tagliare, quindi lasciarlo non impostato o al default su un modello da 200k taglia molto prima del necessario; dichiara ciò che il modello supporta davvero. Per una configurazione persistente, le stesse chiavi vivono in un profilo YAML sotto un blocco llm: (apri la directory dei profili con interpreter --profiles). Un profilo tiene endpoint, modello, e impostazioni di finestra fuori dalla cronologia della tua shell e rende la configurazione condivisibile tra macchine, con la chiave ancora fornita dall'ambiente.

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

Scegliere il modello che scrive il tuo codice.

Il confronto tra modelli qui è insolitamente concreto: dai a due modelli lo stesso task e conta i giri di andata e ritorno fino a un risultato funzionante. La vista di utilizzo per chiave aggiunge il costo in token per sessione, che insieme al conteggio dei giri è l'intero confronto. Dietro un endpoint ogni candidato è un flag.

• Il loop principale vuole un modello che scriva codice eseguibile e legga bene i traceback al primo passaggio; claude-sonnet-4-6 e gpt-5.5 sono il livello medio affidabile, e ogni giro di andata e ritorno fallito che un modello migliore evita sono token e tempo reale risparmiati.
• deepseek-v4-pro è un candidato forte per sessioni pesanti di codice dove il volume conta; tramite un endpoint, provarlo contro i tuoi task è un singolo cambio di --model.
• Le sessioni utility rapide (rinominare file, trasformazioni una tantum, conversioni di formato) non hanno bisogno di ragionamento di frontiera; claude-haiku-4-5-20251001 o glm-5.2 le mantengono veloci ed economiche.
• La modalità auto-run (-y) rimuove il passo di revisione umana tra generazione del codice ed esecuzione. Se la usi affatto, usala con il modello più forte che esegui, in un sandbox o container, mai con un modello che stai ancora valutando.

Pagamento a consumo · sotto i prezzi ufficiali

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

Le modalità di errore specifiche di Open Interpreter.

Un id di modello nudo aggira il tuo endpoint. Senza il prefisso openai/, LiteLLM risolve il provider dal nome: gli id claude-* si dirigono verso il client di Anthropic, e il risultato è un errore di autenticazione o routing contro un host che non hai mai configurato. Se gli errori menzionano un SDK fornitore piuttosto che il tuo gateway, manca il prefisso. Le assunzioni di contesto predefinite tagliano le tue sessioni. Per un id che LiteLLM non riconosce, nulla riempie la finestra di contesto; Open Interpreter ricade su comportamento prudente e taglia la cronologia presto. Dichiara context_window esplicitamente, perché una sessione di debug del codice che perde i suoi tentativi precedenti rifà gli stessi errori. Sessioni crescenti, conti crescenti. Ogni turno reinvia conversazione più codice più output catturato. Una sessione che incolla un grande dataframe o un log lungo nel loop lo porta in ogni richiesta successiva. Preferisci far scrivere al modello codice che ispeziona i file piuttosto che incollare contenuti di file in chat, e inizia sessioni nuove quando un task cambia. Disallineamento di function-calling. Open Interpreter può usare chiamate a funzione strutturate dove supportate; il flag supports_functions esiste per id dove il rilevamento indovina male. Se i blocchi di codice arrivano malformati su un modello che sai capace, impostalo esplicitamente su True; se un modello manca davvero di supporto ai tool, imposta False così il percorso di fallback si attiva. Il lato dell'esecuzione è tuo. api_base sposta il traffico del modello; il codice gira ancora localmente con i tuoi permessi. Un gateway non fa sandboxing di nulla, quindi mantieni l'auto-run confinato ai container e lascia che la revisione di sicurezza resti nel loop ovunque altro.

Chi instrada Open Interpreter tramite un gateway.

• Sviluppatori che usano Open Interpreter come strumento di automazione quotidiano e vogliono generazione di codice di qualità Claude, varietà GPT, e id utility veloci dietro una chiave.
• Persone che lavorano con dati eseguendo loop di analisi esplorativa, dove una sessione può bruciare contesto sorprendente e l'utilizzo per chiave rende visibile il costo per equivalente-notebook.
• Ingegneri che confrontano modelli di scrittura di codice su giri-di-andata-e-ritorno-al-funzionante, il benchmark più onesto disponibile, un flag --model per candidato.
• Smanettoni che eseguono job interpreter programmati o containerizzati, dove un endpoint via variabile d'ambiente e un segreto battono un set di credenziali per fornitore.
• Sviluppatori senza accesso alla fatturazione di un dato fornitore. L'accesso basato su ricarica senza obbligo di carta rimuove la dipendenza dalla registrazione per provider.

Verifica l'endpoint e fai debug della prima sessione.

Elenca prima i modelli del gateway; l'id dopo openai/ deve corrispondere esattamente a un id servito, suffisso di versione incluso. I fallimenti della prima sessione seguono un pattern. Gli errori che nominano anthropic o un altro SDK fornitore significano che manca il prefisso openai/ e LiteLLM ha instradato per nome. Un 401 significa che la chiave non è visibile nella shell che ha lanciato l'interprete, o è stata impostata per una variabile diversa da quella in uso; con il prefisso in posizione, sia OPENAI_API_KEY sia un api_key esplicito funzionano. Un errore modello-non-trovato dal gateway è un errore di battitura nell'id. Un errore di connessione di solito significa che api_base ha perso il suffisso /v1; il client aggiunge /chat/completions a qualunque base tu fornisca. Una volta che il loop gira, la console di APIsRouter mostra il modello per richiesta, i conteggi dei token e la spesa. Le sessioni dell'interprete sono il caso classico di un carico che sembra piccolo ma fattura in modo medio, e la vista di utilizzo è come vedi quali sessioni hanno effettivamente portato i token.

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

Domande frequenti