Alternative a Open Interpreter: agente attuale, Python legacy e migrazione

Prima di cercare alternative a Open Interpreter, stabilisci quale Open Interpreter stai abbandonando: il nome ora appartiene a un agente di coding da terminale in Rust che è un fork di Codex di OpenAI, mentre lo strumento Python che eseguiva codice generato sulla tua macchina è fermo alla versione 0.4.3 di ottobre 2024 e non è più mantenuto dal progetto. Ogni generazione è gratuita e open source, quindi non si tratta mai di una decisione sul prezzo della licenza: è una decisione su quale programma vuoi usare e l'unico costo ricorrente è quello dell'API del modello a cui lo indirizzi.

Due reindirizzamenti nascondono la separazione. La richiesta del vecchio percorso del repository OpenInterpreter/open-interpreter tramite l'API GitHub restituisce openinterpreter/openinterpreter, linguaggio Rust, e docs.openinterpreter.com risponde con HTTP 308 verso la documentazione del terminale Rust. I link di un tutorial del 2023 o del 2024 continuano a risolversi; semplicemente forniscono la documentazione di un programma diverso, descrivendo comandi che il binario installato non possiede. Entrambi verificati il 18 settembre 2026.

Un nome, tre programmi e un pacchetto morto

Il redirect dal vecchio percorso del repository è il motivo per cui la separazione è facile da non notare. L'attuale README lo dichiara in una sola riga verso la fine — "Questa è la nuova versione Rust di Open Interpreter, basata su Codex. Cerchi il progetto Python originale? Continua a vivere come fork mantenuto dalla community all'indirizzo endolith/open-interpreter." Si noti che anche la licenza è cambiata con la riscrittura, da AGPL-3.0 ad Apache-2.0, cosa importante se avevate integrato il vecchio codice. L'organizzazione detiene inoltre il progetto vocale inattivo 01, con ultimo push a novembre 2024, oltre a 01-app e aifs, nessuno dei quali aggiornato dal 2024. Nessuno dei tre è archiviato, ma nessuno è nemmeno attuale.

Prezzi di Open Interpreter: non ce ne sono, e quei tre numeri non lo sono

Non esistono piani, postazioni, quote o account. openinterpreter.com/pricing ha restituito HTTP 404 il 18 settembre 2026; le pagine di installazione da terminale, quickstart e configurazione non contengono alcun testo relativo a prezzi, abbonamenti o fatturazione; e il README del prodotto desktop dichiara che "non richiede un account Interpreter". Questa è una conclusione basata sull'assenza di prove — non è stata trovata alcuna pagina dei prezzi, non una promessa del progetto che non ne apparirà mai una — ma è la risposta onesta a "prezzi di Open Interpreter": l'unico costo ricorrente sono i token del modello.

I prezzi che dominano questa ricerca appartengono ad altri prodotti. Teneteli fuori dal budget:

Entrambi i prezzi degli strumenti verificati il 18 settembre 2026.

Quale alternativa è adatta a quale utente

Cosa migra e cosa no

Nulla viene trasferito dalla generazione Python. I flag, la superficie API Python, i file di profilo YAML e Python e la convenzione per i nomi dei modelli LiteLLM sono tutti scomparsi. Ciò che rimane è una configurazione modellata su Codex e sugli standard, documentata deliberatamente dal progetto nella sua pagina sulla migrazione:

Controllate la collisione dei nomi binari prima di installare. Il wheel legacy 0.4.3 dichiara quattro script console — interpreter, i, interpreter-classic e wtf — mentre l'installer attuale colloca interpreter, i e codex-code-mode-host in ~/.local/bin, secondo la pagina di installazione. Se avete mai eseguito pip install open-interpreter, ora due programmi diversi competono per due di quei nomi, interpreter e i, e quale prevale dipende dalla precedenza della shell. Eseguite prima which -a interpreter, which -a i e interpreter --version, e ripeteteli dopo l'installazione.

Rollback. Eseguite il backup di ~/.openinterpreter/ prima di cambiare provider — il ciclo di disinstallazione documentato rimuove l'installazione standalone gestita ma conserva deliberatamente quella directory, inclusi configurazione, sessioni, log e credenziali archiviate nei file, così la reinstallazione ripristina la configurazione. Se fate il percorso inverso, mantenete intatto il virtualenv legacy invece di eliminarlo: 0.4.3 è ancora su PyPI, ma non è garantito che in seguito sia possibile risolvere nuovamente un vecchio insieme di dipendenze fissato.

Collegare l'agente attuale a un endpoint compatibile con OpenAI

Questa è la frase più importante se arrivate dalla nostra configurazione di Codex CLI, che vi dice che wire_api ha un unico valore valido. Quella regola vale per Codex upstream e non vale per Open Interpreter. Il riferimento alla configurazione dell'upstream dice, a proposito di wire_api, che "responses è l'unico valore supportato ed è quello predefinito quando viene omesso". La delta mantenuta di Open Interpreter elenca invece come aggiunte deliberate un "trasporto OpenAI-compatibile Chat Completions di prima classe" e un "trasporto compatibile con Anthropic Messages per i provider che espongono quell'API". Il fork raggiunge quindi endpoint che Codex upstream non può raggiungere, e tutte e tre le superfici di Kunavo — /v1/responses, /v1/chat/completions e /v1/messages — hanno un valore di protocollo corrispondente.

La struttura documentata per un provider personalizzato, tratta dalla pagina dei provider, è un blocco chat-completions con un URL di base che termina in /v1; la stessa pagina mostra un gateway ospitato configurato esattamente in questo modo. Applicata a Kunavo:

# Top-level keys come FIRST. Anything written after a [table] header
# belongs to that table, so model_provider placed below would be ignored.
model_provider = "kunavo"
model = "gpt-5-6-terra"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"
wire_api = "chat"

Tre limiti che vale la pena conoscere prima di dedicarci una serata, tutti ricavati dalla documentazione del progetto e non testati qui:

• Kunavo non è nel catalogo incluso, quindi impostate model manualmente. Il catalogo dei provider generato viene costruito da models.dev più alcuni endpoint di provider attivi e conteneva 116 provider al momento del controllo; Kunavo non è presente né in quello né in models.dev. Non aspettatevi che il selettore /model precompili i metadati relativi alla finestra di contesto o alle capacità per un provider scritto manualmente.
• Il routing dell'harness è rigido. Secondo la pagina dell'harness, chat accetta chat nativa oltre a claude-code, claude-code-bare, deepseek-tui, kimi-code, kimi-cli, qwen-code, swe-agent e minimal; responses accetta native, claude-code e claude-code-bare; e per messages, "la modalità nativa viene rifiutata perché Messages richiede un trasporto nativo dell'harness". Qualsiasi stringa di harness non riconosciuta ricade sulla chat senza un request builder integrato, quindi un errore di battitura degrada silenziosamente l'esecuzione. Quale harness offra le prestazioni migliori con un determinato modello non è documentato, e questa pagina non fa supposizioni.
• L'URL di base Messages è un'inferenza, non un esempio Kunavo documentato. I provider Messages inclusi nel catalogo — Anthropic e Z.AI's ZCode — usano entrambi una radice API senza /v1, e la pagina di Z.AI dichiara che la richiesta ZCode Messages viene inviata a /v1/messages — quindi il client aggiunge il percorso. In base a questa regola, un blocco basato sul protocollo Anthropic userebbe la radice API anziché l'URL /v1 sopra, ma nei documenti ufficiali non esiste alcun esempio Messages per un provider personalizzato e questo non è stato eseguito. Iniziate dal protocollo chat, che è la struttura documentata.

Altri due dettagli documentati: env_key indica il nome della variabile d'ambiente, non la chiave in sé, e per le esecuzioni una tantum interpreter --chat-completions sovrascrive la struttura della richiesta per quella chiamata senza modificare URL di base, credenziali o modello del provider. L'accesso ChatGPT è indicato come autenticazione del provider integrato openai, non come opzione per un provider personalizzato; le fonti di autenticazione che la pagina dei provider documenta per una tabella di provider sono env_key, experimental_bearer_token e un blocco auth basato su comando, oltre a un blocco aws solo per Amazon Bedrock.

Una stima dei costi per una sessione

Si tratta di aritmetica illustrativa dei token, non di costi misurati delle attività né di un limite massimo di fatturazione. Supponete una sessione dell'agente che invii 300.000 token di input non memorizzati nella cache e riceva 20.000 token di output — una configurazione scelta a scopo illustrativo, perché un harness in stile Codex reinvia il contesto accumulato a ogni turno. Il vostro repository e il numero di turni saranno diversi. Le tariffe sono i prezzi live del catalogo Kunavo per milione di token.

Il divario è il punto, non una singola riga: in queste condizioni i modelli Claude Haiku 4.5 calcolano la stessa sessione a $0,280 rispetto a $0,840 per Claude Sonnet 4.6. Questo non è un invito a scegliere la tariffa più economica. Il prezzo più basso nell'elenco e il costo più basso per completare l'attività sono affermazioni diverse, e un modello che richiede tre tentativi per un refactoring può costare più di uno che ne richiede uno solo — misurate entrambi sul vostro repository prima di decidere. L'importo del catalogo Kunavo è un minimo di fatturazione, non un tetto massimo: quando l'upstream comunica il proprio addebito, la fattura è il maggiore tra il costo del catalogo e il costo upstream moltiplicato per il markup applicabile. Gli addebiti della cache e gli strumenti esterni sono esclusi da questo esempio. Il ricarico minimo è di $10 di credito prepagato, che è un minimo di finanziamento e non una tariffa per attività o un abbonamento — consultate i dettagli di fatturazione.

Configurarlo, con onestà

Open Interpreter non è stato testato a runtime con Kunavo: nulla in questa pagina è stato eseguito e ogni affermazione sulla configurazione è stata ricavata dal repository e dalla documentazione del progetto il 18 settembre 2026. Il riferimento pubblicato più vicino è l'integrazione di Codex CLI, il cui blocco TOML ha la stessa struttura — copiatelo, cambiate la directory di configurazione in ~/.openinterpreter/config.toml e ignorate la regola del singolo wire_api, che appartiene a Codex upstream. Mantenete disponibile un percorso funzionante, eseguite un'attività circoscritta, poi leggete l'addebito registrato dal vostro account. Create un account Kunavo quando sarete pronti a finanziare una chiave.

State ancora confrontando i percorsi anziché i client? API compatibile con OpenAI illustra cosa il protocollo chat garantisce e cosa non garantisce, mentre gateway LLM tratta in generale il compromesso tra una chiave e un unico saldo.

Domande frequenti

Stato del repository, release, registri dei pacchetti, documentazione e catalogo dei provider generato verificati il 18 settembre 2026; i prezzi degli strumenti OpenAI e Anthropic sono stati letti dalle rispettive pagine dei prezzi lo stesso giorno. Nessun prezzo di abbonamento ChatGPT è citato perché quella pagina ha rifiutato il recupero. Nulla di quanto riportato è stato testato a runtime con un endpoint. Le tariffe dei token Kunavo provengono dal catalogo live e ogni esempio in dollari in questa pagina è aritmetica illustrativa dei token, non un costo misurato dell'attività.