# Claude Code e Codex via API: costi e confronto tra 3 opzioni > Canonical: https://vxi.me/it/posts/claude-code-codex-api-gateway-comparison/ > Locale: it-it > Published: 2026-10-14 > Updated: 2026-10-14 > Markdown: https://vxi.me/it/posts/claude-code-codex-api-gateway-comparison.md Ogni mese, quando rinnovi l’abbonamento a Claude Code o Codex, probabilmente ti è capitato di fare due conti: il piano Plus costa 20 dollari al mese; se lo usi poco ti sembra uno spreco, se lo usi molto non basta. Passare alle API ufficiali con tariffazione a consumo lascia il dubbio di quanto sarà la fattura. Vorresti aggregare gli abbonamenti con un gateway self-hosted, ma ti aspettano VPS e configurazione OAuth. Un intermediario commerciale costa meno, ma affidargli la tua key significa dover sperare che il modello restituito sia davvero quello richiesto. Ho messo a confronto le tre opzioni concretamente percorribili: usare CLIProxyAPI per convertire gli abbonamenti CLI che hai già in API compatibili, gestendole in proprio; inoltrare le richieste a consumo tramite un intermediario commerciale come OpenRouter; oppure usare direttamente le API ufficiali dei fornitori dei modelli. La conclusione, in breve: non esiste il gateway migliore in assoluto, ma il modello di costo che si adatta ai tuoi consumi. Se usi molto gli agent e resti entro i limiti dell’abbonamento, aggregare gli abbonamenti in self-hosting è spesso la soluzione più conveniente. Se usi poco, la tariffazione a consumo è la più semplice. Nel mezzo, conta quanto sei disposto a gestire una VPS. Chiariamo prima l’ambito: questo articolo riguarda le opzioni per fornire API ad agent di programmazione AI come Claude Code e Codex; non è un confronto generale tra gateway per modelli linguistici. CLIProxyAPI aggrega le credenziali degli abbonamenti ai diversi strumenti CLI. Secondo la documentazione del progetto, tra gli upstream supportati ci sono Codex, Claude Code, Gemini CLI e Grok, con API compatibili con OpenAI, Gemini, Claude e Codex. Non ha senso confrontarlo con i gateway generici. ## Allineiamo i criteri di costo All’inizio pensavo di partire da una tabella delle funzionalità, ma il numero di funzioni non spiega dove finiscono i soldi. Ho quindi impostato il confronto su struttura dei costi, difficoltà di integrazione e flusso dei dati: sono questi gli aspetti che possono creare problemi nella scelta. Anche la versione incide sulle conclusioni: CLIProxyAPI viene aggiornato spesso. Pensavo bastasse controllare il numero di versione nelle GitHub releases, ma ho scoperto che va confrontato anche con il tag dell’immagine su Docker Hub. Solo se entrambi indicano v8.0.27 (rilasciata il 2026-10-12) si può essere certi: controllando una sola fonte si rischia di vedere una pagina non aggiornata dalla cache. I numeri di versione citati qui sono aggiornati al 2026-10-14; prima di metterti al lavoro, controlla anche i tag su Docker Hub. ## Self-hosting: abbonamento e VPS, costi relativamente fissi È più utile valutare il self-hosting come una soluzione a costo fisso che chiamarlo «API gratuita». Prendendo come esempio un abbonamento da 20 dollari al mese e una VPS da circa 5–10 dollari, la spesa mensile è relativamente stabile e il costo si ammortizza meglio quanto più usi il servizio. Per chi usa intensamente gli agent ogni giorno, questa opzione è spesso la più economica. In cambio, dovrai gestire tre aspetti: la procedura di accesso tramite codice dispositivo OAuth, la manutenzione continuativa della VPS e i rischi legati ai controlli sull’abbonamento upstream. Quando ho fatto il deploy su una VPS a inizio ottobre, durante la fase OAuth ho incontrato un errore 403 di Cloudflare e timeout dovuti alla regione. Alla fine ho verificato che il problema riguardava l’abbonamento o l’ambiente di rete, non il gateway. Ho descritto l’intera procedura di quel deploy in un altro articolo; puoi riutilizzare direttamente le sezioni su Docker e sulla configurazione del client, che non riguardano OAuth: [Come usare CLIProxyAPI come reverse proxy per Codex](/posts/cliproxyapi-codex-docker-proxy/). Ma il self-hosting funziona così: se si rompe un anello della catena, a svegliarsi nel cuore della notte per sistemarlo sarai tu. ### Una stima del punto di pareggio Quanto devi usarlo perché il self-hosting convenga rispetto alla tariffazione a consumo? Facciamo un conto approssimativo, dichiarando le ipotesi: non è un preventivo preciso. - **Costi fissi del self-hosting**: abbonamento da $20/mese + VPS entry-level da $5/mese ≈ **$25/mese al massimo**, a prescindere dall’utilizzo. - **Tariffazione a consumo delle API ufficiali**: prendendo come esempio un modello di livello Sonnet 5.5 (input $2 / output $10 per milione di token, prezzi raccolti da terze parti), 1 milione di token in input + 200.000 in output al giorno costano circa $4 al giorno, cioè quasi **$120 al mese**. Il punto di pareggio è abbastanza intuitivo: per chi usa spesso gli agent e arriva a circa un milione di token al giorno, il self-hosting trasforma una spesa potenzialmente illimitata in un costo mensile fisso. Al contrario, se apri il terminale solo qualche volta a settimana, la tariffazione a consumo può costarti pochi dollari al mese: con il self-hosting pagheresti invece una VPS che resta inutilizzata. Scegli in base al tuo caso. ### Test di installazione: v8.0.27, tutto al primo tentativo Ho ripetuto da zero l’intera installazione su una macchina di test isolata (Ubuntu 26.04, 1 core / 1,9 GB di RAM), fissando la versione a v8.0.27 invece di usare latest: ```bash docker pull eceasy/cli-proxy-api:v8.0.27 # 292MB，发布页显示 2026-10-12 发布 ``` Per la configurazione minima bastano tre righe; il servizio si avvia anche senza upstream configurati: ```yaml # config.yaml config-version: 8 server: port: 8317 ``` ```bash docker run -d --name cpa-test --restart unless-stopped \ -p 8317:8317 \ -v ./config.yaml:/CLIProxyAPI/config.yaml \ -v ./auths:/root/.cli-proxy-api \ eceasy/cli-proxy-api:v8.0.27 ``` I log di avvio confermano versione, commit e data di build (v8.0.27 / bf93416 / 2026-10-12), corrispondenti a GitHub main. `/` restituisce 200 ed elenca tre endpoint compatibili; `/v1/models` restituisce una lista vuota se non hai configurato upstream: è normale, non è un errore. Durante i due test ho notato alcuni dettagli che vale la pena chiarire nelle guide: 1. **La configurazione minima non prevede autenticazione**. Se non configuri `access.api-keys`, chiunque può usare il tuo gateway. Per fare prove in una rete interna non è un problema, ma se esponi la porta su Internet, la prima cosa da fare è aggiungere una key. 2. **Dal container non usare 127.0.0.1 per raggiungere l’host**. All’inizio avevo configurato il mock upstream come `http://127.0.0.1:18888` e il gateway ha restituito subito connection refused: il localhost del container è il container stesso. Usa l’indirizzo del bridge Docker sull’host (di solito 172.17.0.1) oppure `--network host`. Il messaggio d’errore del gateway è chiaro: nel 500 indica direttamente la causa del fallimento di dial, rendendo semplice la diagnosi. Inoltre, nella configurazione di test non esisteva l’endpoint `/health` (404). Quando scrivi uno script di health check, non copiare alla cieca un modello generico. ### Quanto rallenta il gateway? Test: circa 4 ms «Il self-hosting sarà lento?» è una delle domande più comuni quando si valuta questa soluzione, quindi ho fatto una misurazione. Metodo: sulla stessa macchina ho avviato un mock upstream OpenAI con un ritardo fisso di 50 ms prima del primo chunk, poi ho confrontato il collegamento diretto al mock con il passaggio attraverso il gateway. Ho eseguito 20 chiamate per percorso, in streaming. | Percorso | Successi | Mediana della latenza al primo token | p95 della latenza al primo token | Mediana della durata totale | |---|---|---|---|---| | Collegamento diretto al mock upstream | 20/20 | 52.4ms | 52.9ms | 104.2ms | | Passaggio dal gateway CLIProxyAPI | 20/20 | 56.5ms | 57.3ms | 108.7ms | Il gateway aggiunge solo circa 4 ms. Il fatto che p95 e mediana siano molto vicini indica un overhead stabile. La conclusione vale esclusivamente nelle condizioni di questo test: **stessa macchina, carico ridotto e upstream mock; il gateway self-hosted non è il collo di bottiglia**. La lentezza percepita dipende di solito dall’inferenza del modello e dalla rete verso l’upstream, non da questo passaggio aggiuntivo. Non ho però testato le prestazioni con concorrenza elevata o in ambienti di rete complessi. ![Confronto dell’overhead del gateway: collegamento diretto al mock upstream vs passaggio dal gateway CLIProxyAPI, mediana della latenza al primo token/TTFT p95/mediana della durata totale (N=20, test sulla stessa macchina), overhead del gateway di circa 4 ms](/images/posts/claude-code-codex-api-gateway-comparison/gateway-overhead-chart.png) Per confronto, ho eseguito 10 chiamate a un modello reale tramite un intermediario commerciale che offre compatibilità con OpenAI: gpt-6-luna (identificativo del modello sul lato dell’intermediario, fingerprint del modello non verificato). Successi: 10/10; mediana della latenza al primo token: 1240ms; p95: 1996ms; mediana della durata totale: 1745ms. La latenza al primo token dipende soprattutto dall’inferenza del modello. Questo conferma anche la conclusione precedente: in un’esperienza end-to-end, i 4 ms del gateway sono trascurabili. Il deploy non è complicato: avvia il container e l’agent può raggiungere il servizio tramite un endpoint compatibile con OpenAI. Per endpoint e autenticazione, fai riferimento alla documentazione della versione che usi. Di seguito trovi la forma di configurazione più comune lato client; ricordati di sostituire l’indirizzo di esempio con quello del tuo servizio: ```python from openai import OpenAI client = OpenAI( base_url="https://your-api.example/v1", api_key="YOUR_API_KEY", ) ``` Se non vuoi partire da zero, ho raccolto gli script di deploy che avevo verificato in un repository per l’installazione in un solo passaggio. `setup.sh` e, dopo aver configurato la key, il servizio è pronto: una soluzione pratica se vuoi risparmiare tempo. kuangyongjie/cliproxyapi-codex-deploy ## OpenRouter: meno manutenzione, pagamento a consumo La logica dei costi di OpenRouter è opposta: il costo dei token dei modelli viene addebitato secondo le tariffe dei fornitori, senza maggiorazioni; la piattaforma guadagna sulle ricariche. Le ricariche con carta di credito hanno una commissione del 5,5% (minimo 0,80 dollari), quelle in criptovaluta del 5%. Ho confrontato queste tariffe con tre fonti indipendenti aggiornate a 2026-10 (betterclaw.io, leanroute.dev, calculatorai.app) e i dati coincidono. Per le tariffe aggiornate fa fede la [pagina ufficiale dei prezzi](https://openrouter.ai/pricing), verificata il 2026-10-14. È disponibile anche la modalità BYOK: colleghi la tua key ufficiale e non paghi commissioni della piattaforma sui primi 25.000 dollari mensili di spesa ai prezzi di listino; oltre questa soglia si applica una commissione del 5% (come indicato nella pagina ufficiale). È l’opzione più semplice da integrare: ti registri, ricarichi il credito, imposti `base_url` nell’OpenAI SDK e scegli un modello. La documentazione ufficiale conferma la disponibilità di endpoint compatibili con OpenAI e la sostituzione drop-in, senza quasi dover modificare il codice esistente: ```python from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="YOUR_OPENROUTER_API_KEY", ) response = client.chat.completions.create( model="YOUR_MODEL", messages=[{"role": "user", "content": "Hello"}], ) ``` La minore manutenzione ha un prezzo: le richieste passano prima da OpenRouter e poi dal fornitore upstream. Per impostazione predefinita la piattaforma non conserva prompt e completion, ma solo metadati; è possibile attivare i log tramite opt-in. Questa è la politica di logging predefinita della piattaforma, ma le richieste raggiungono comunque il fornitore upstream e sono soggette alle sue politiche sui dati. Per i team che trattano dati sensibili, la domanda importante non è tanto «vengono conservati o no?», quanto «da quali soggetti passeranno le richieste?». È una considerazione valida per qualsiasi intermediario commerciale. I rischi degli intermediari commerciali vanno descritti in modo concreto, distinguendo le prove dalle valutazioni. Uno studio segnala casi di rivendita tramite intermediari in cui il fingerprint del modello non corrispondeva, ma non sono riuscito a verificare autonomamente la fonte originale; per questo non citerò intermediari cinesi specifici. Un approccio più prudente è iniziare con una spesa contenuta, verificare il fingerprint del modello restituito e il comportamento del servizio, e cambiare fornitore se non corrispondono. Diffida delle raccomandazioni che parlano solo di prezzo e non spiegano come verificare il servizio. ## API ufficiali: il riferimento per il collegamento diretto Le API ufficiali si pagano a consumo e collegano direttamente al fornitore del modello: il percorso dei dati è il più breve. Sono il riferimento per confrontare le altre due opzioni: tutte le promesse di «X% di risparmio» usano questi prezzi come base. Per i prezzi specifici di OpenAI e Anthropic ho usato una raccolta di dati di terze parti aggiornata al 2026-10, utile per un confronto iniziale. Le pagine dei prezzi, però, cambiano spesso: prima di procedere verifica sempre la [pagina ufficiale dei prezzi di OpenAI](https://openai.com/api/pricing/) e la [pagina dei prezzi di Anthropic](https://www.anthropic.com/pricing). Non usare prezzi soggetti a variazioni come valori permanenti nel tuo modello dei costi. Per valutare la stabilità si può partire dall’architettura, senza aspettare misurazioni reali: con il self-hosting c’è il singolo punto di failure della VPS, che dovrai riparare tu; una piattaforma commerciale può fornire routing e fallback (l’efficacia dipende dal modello e dal tipo di guasto); le API ufficiali sono gestite direttamente dal fornitore. In pratica, la scelta si riassume così: se usi molto il servizio, sai gestire una VPS e accetti i rischi legati ai controlli sull’abbonamento, valuta il self-hosting; se usi poco o non vuoi occuparti della manutenzione, OpenRouter è più immediato; se hai requisiti stringenti sul percorso dei dati e vuoi il collegamento diretto, scegli le API ufficiali. Questo articolo non confronta la disponibilità effettiva dei tre servizi: non confondere l’analisi architetturale con una garanzia di uptime. ## Ambito e limiti In questo test ho misurato due aspetti: l’overhead del gateway (mock upstream sulla stessa macchina, N=20, +4ms) e l’esperienza reale di collegamento diretto tramite un intermediario commerciale (il servizio che avevo a disposizione, gpt-6-luna, N=10). **Non ho misurato** la latenza online di OpenRouter e delle API ufficiali (non avevo le key necessarie), il comportamento end-to-end di un upstream con abbonamento OAuth (serve completare l’accesso device dal browser) né la stabilità per periodi superiori a 24 ore. La conclusione sull’overhead del gateway si basa su un upstream mock: dimostra che «il gateway in sé non è lento», non che «il tuo upstream non è lento». La versione di CLIProxyAPI, le tariffe di OpenRouter e i prezzi ufficiali possono cambiare. I dati riportati sono stati verificati al 2026-10-14; prima di procedere, ricontrolla la pagina delle release del progetto, i tag su Docker Hub e le pagine ufficiali dei prezzi. ## In breve: scegli in base al tuo caso - **Scegli l’aggregazione self-hosted** se usi intensamente gli agent ogni giorno per scrivere codice, hai già abbonamenti CLI, possiedi competenze di base nella gestione Linux e vuoi rendere prevedibili i costi. - **Scegli OpenRouter** se i consumi sono bassi, medi o variabili, non vuoi gestire server e passi spesso da un modello all’altro per confrontarne i risultati. - **Scegli le API ufficiali** se hai requisiti di conformità sul percorso dei dati, hai un budget adeguato e non ti preoccupano le variazioni dei consumi. **Link utili:** [Progetto CLIProxyAPI](https://github.com/router-for-me/CLIProxyAPI) · [Repository per il deploy in un passaggio](https://github.com/kuangyongjie/cliproxyapi-codex-deploy) · [Guida rapida di OpenRouter](https://openrouter.ai/docs/quickstart) · [Prezzi di OpenRouter](https://openrouter.ai/pricing) ## Verification context - Level: first-party - Verified: 2026-10-14T00:00:00.000Z - Environment: Ubuntu 26.04 - Environment: Docker 29.9.0 - Environment: CLIProxyAPI v8.0.27 - Evidence mode: mixed - Evidence receipt: https://vxi.me/evidence/claude-code-codex-api-gateway-comparison.json