Documentazione

Open Interpreter

Open Interpreter legge i provider da una tabella TOML, come faceva il suo predecessore Codex, ma conserva un trasporto Chat Completions che Codex upstream ha rimosso. Basta un blocco [model_providers.kunavo] e l’agente può usare qualsiasi modello raggiungibile con la chiave.

Un'unica tabella [model_providers.kunavo] in ~/.openinterpreter/config.toml — base_url, env_key, wire_api = "chat" — e l'agente da terminale Rust funziona con qualsiasi modello raggiungibile dalla chiave.

~/.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"

L’URL di base mantiene il suffisso /v1 sul protocollo chat. La documentazione di Open Interpreter chiarisce questo aspetto tramite esempi, non con una regola esplicita: il blocco del provider personalizzato nella pagina dei provider usa base_url = "https://api.example.com/v1", quello nella pagina di configurazione usa "https://api.acme.example/v1" e il gateway ospitato che documentano per nome usa "https://app.nz/v1". Se elimini il suffisso, l’errore è un 404, non un errore di autenticazione.

Kunavo non ha eseguito questo client sul proprio endpoint: né questo né alcun altro client di queste pagine. È stata verificata la configurazione: le chiavi riportate di seguito sono quelle presenti nella documentazione di Open Interpreter, consultata alla data in fondo a questa pagina; l’URL di base e gli ID dei modelli sono di Kunavo. Una guida di configurazione pubblicata non equivale a un’esecuzione di prova. La richiesta di verifica è ciò che ti dice se funziona.

Esistono due programmi diversi chiamati «Open Interpreter» e questo blocco è per quello scritto in Rust. Il pacchetto Python, fermo a 0.4.3, si configura tramite --api_base, --api_key e --model openai/<id>, oppure tramite interpreter.llm in Python. Nessuno di questi elementi esiste nell’attuale agente da terminale, che legge solo la tabella TOML qui sopra. Esegui interpreter --version prima di modificare qualsiasi cosa: un pip install open-interpreter proveniente da un vecchio tutorial lascia in esecuzione un secondo binario che compete per lo stesso nome.

Con un ID modello Claude, Open Interpreter seleziona automaticamente l’claude-code: le impostazioni predefinite documentate lo scelgono per «Anthropic, ID di modelli Claude, URL di base Anthropic o qualsiasi provider messages». È un abbinamento valido in questo caso: la tabella di instradamento indica che claude-code è compatibile con wire_api = "chat". Imposta esplicitamente harness se ne vuoi uno diverso; un valore esplicito ha sempre la precedenza e un valore non riconosciuto ricade su chat, senza un generatore di richieste integrato, anziché generare un errore esplicito.

Non hai ancora una chiave? Crea un account Kunavo, genera una chiave (inizia con sk-kn-) e aggiungi credito da $10: le chiamate vengono pagate con quel saldo e le chiamate non riuscite non vengono addebitate. La dashboard si apre quindi sulla configurazione Open Interpreter.

Passo dopo passo

Crea una chiave su /app/keys e copiala: viene mostrata una sola volta.
Esportala con il nome che stai per inserire in env_key: export KUNAVO_API_KEY=sk-kn-.... Questo campo contiene il nome della variabile, non il suo valore: la documentazione indica env_key come origine che «legge un token bearer da una variabile d’ambiente».
Inserisci il blocco qui sopra in ~/.openinterpreter/config.toml, oppure in .openinterpreter/config.toml all’interno di un progetto attendibile, se vuoi applicarlo a un solo repository. La configurazione del progetto ha la precedenza su quella dell’utente; il flag -c key=value ha la precedenza su entrambe per quell’esecuzione.
Avvia interpreter ed esegui /model. Il selettore interroga prima la route dei modelli del provider attivo e Kunavo risponde con GET /v1/models, quindi l’elenco si popola automaticamente.
Esegui /debug-config se sono attivi i valori sbagliati: stampa la configurazione effettiva e l’origine di ciascun valore, così puoi individuare un profilo obsoleto o un file di progetto più rapidamente che rileggendo il TOML.

Verificato rispetto a Pagina dei provider di modelli di Open Interpreter il 21 settembre 2026. Le impostazioni di terze parti cambiano; se il nome di un campo qui non corrisponde più a quello visualizzato, fa fede quella pagina, non questa.

Questa è la versione breve. La guida completa, con scelta del modello, costo di una sessione reale e modalità di errore, è in la distinzione tra versioni di Open Interpreter, i prezzi e le alternative.

Verifica prima di eseguire il debug del client

Una sola richiesta stabilisce se il problema riguarda l'endpoint, la chiave o il file di configurazione. Se restituisce JSON, lo stesso base URL e la stessa chiave funzionano 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-..."

Quale model id inserire nel campo

Ogni modello di testo è raggiungibile come model id: l'elenco aggiornato è GET /v1/models e il catalogo con i prezzi è nella pagina dei modelli. Le tariffe sono in USD per 1M di token, input / output.

ID del modello	Kunavo ingresso / uscita	Dove si inserisce in Open Interpreter
`claude-sonnet-5`	$1.40 / $7.00	il modello di lavoro predefinito per i cicli di modifica ed esecuzione
`claude-opus-5`	$3.50 / $17.50	pianificare un refactoring di grandi dimensioni, in cui un piano sbagliato costa caro
`claude-haiku-4-5`	$0.70 / $3.50	sessioni incentrate sulla shell, in cui il numero di turni è determinante
`gpt-5-6-sol`	$2.00 / $12.00	un secondo parere da una famiglia diversa, con la stessa chiave

La fatturazione è per token, usando un saldo prepagato senza canone mensile: vedi billing. In presenza di contesto ripetuto, che costituisce la maggior parte di ciò che invia un editor o un client di chat, prompt caching incide sulla spesa più della scelta del modello.

Domande frequenti

Come si configura un provider API personalizzato in Open Interpreter?

Aggiungi una tabella [model_providers.<id>] a ~/.openinterpreter/config.toml con name, base_url, env_key e wire_api; quindi selezionala con la chiave di primo livello model_provider e specifica un modello con model. Per un endpoint compatibile con OpenAI, usa wire_api = "chat" e un URL di base che termina con /v1: è la struttura mostrata nella pagina dei provider di Open Interpreter sia per un provider personalizzato sia per il gateway ospitato che documenta per nome. env_key contiene il nome di una variabile d’ambiente, quindi esporta la chiave invece di incollarla nel file.

L’URL base di Open Interpreter deve terminare con /v1?

Per il protocollo chat, sì. La documentazione non formula in prosa una regola per costruire il percorso, ma tutti gli esempi di provider personalizzati riportati includono il suffisso: https://api.example.com/v1 nella pagina dei provider, https://api.acme.example/v1 nella pagina di configurazione e https://app.nz/v1 per il gateway menzionato. Il protocollo messages funziona diversamente: i provider in stile Anthropic inclusi nel client usano una radice API senza /v1; quindi la risposta /v1 riguarda specificamente wire_api = "chat" e wire_api = "responses".

I vecchi flag --api_base e --model openai/... funzionano ancora?

No. Appartengono al pacchetto Python fermo alla versione 0.4.3, che passava da LiteLLM e perciò richiedeva il prefisso openai/. L’attuale agente da terminale è un fork Rust di Codex e non supporta né quei flag né quella convenzione del prefisso: legge una tabella di provider TOML da ~/.openinterpreter/config.toml o da un file .openinterpreter/config.toml a livello di progetto e seleziona il provider con model_provider e model. La configurazione viene scritta da zero e docs.openinterpreter.com reindirizza alla documentazione Rust; perciò i link dei vecchi tutorial continuano a funzionare, anche se descrivono un programma che non hai installato.

Perché il selettore /model non mostra la finestra di contesto per un provider personalizzato?

Perché questi metadati provengono dal catalogo incluso nel client, generato da models.dev e da una manciata di endpoint di provider attivi; vengono inizializzati solo quando un provider corrisponde a una voce tramite identità Anthropic, URL di base, nome del provider o variabile d’ambiente di autenticazione. Kunavo non è incluso in questo catalogo generato — verifica effettuata sul file nel repository il 21 settembre 2026 — quindi un provider scritto manualmente ottiene l’elenco dei modelli dalla route dei modelli dell’endpoint e nient’altro. I modelli funzionano comunque; semplicemente il selettore mostra meno informazioni accanto a ciascuno.

Open Interpreter può usare un modello Claude senza un account Anthropic?

Sì, perché wire_api indica un protocollo di trasporto, non un fornitore. Con wire_api = "chat", l’ID del modello viene passato all’URL di base configurato e risolto lì, quindi le credenziali che usi sono quelle dell’endpoint. Open Interpreter continuerà a selezionare automaticamente il proprio harness claude-code a partire da un ID modello Claude, e tale harness è indicato come compatibile con il protocollo chat: è quindi l’abbinamento documentato, non una soluzione alternativa.