Kimi K2.7 vs Opus 4.8: Duello di coding e costi

Ho inviato gli stessi task di coding a Kimi K2.7 Code e Claude Opus 4.8 tramite una sola API e ho misurato ciò che è tornato indietro. Quanto a correttezza erano alla pari: entrambi hanno risolto senza errori un caso insidioso di precedenza SemVer e un bug nascosto di merge degli intervalli. Ma Opus ha risposto da 3 a 9 volte più velocemente con un quarto dei token di output, mentre Kimi costava circa il 46% in meno per task al prezzo di listino. Quindi la scelta non riguarda quale modello sia "più intelligente". Se esegui lavoro di coding sensibile ai costi o in batch, Kimi K2.7 vince sul prezzo. Se ti serve bassa latenza, un contesto da 1M token o un modello di revisione finale di cui ti fidi, Opus 4.8 vale il sovrapprezzo, e molte team finiscono per instradare tra i due.

Pratico: ho eseguito gli stessi task di coding su entrambi

Come ho testato: ID modello kimi-k2.7-code e claude-opus-4-8, chiamati tramite un unico endpoint gateway compatibile con OpenAI il 2026-07-13, un solo tentativo per attività ai parametri predefiniti senza prompt caching. La latenza è misurata come tempo di clock reale lato client, quindi include il tempo di rete e di coda, non solo la generazione. Prima di assegnare il punteggio ho chiesto a ciascun modello di identificarsi come verifica di sanità mentale (Kimi ha risposto "made by Moonshot AI," Opus ha risposto Anthropic); si tratta di un controllo di routing, non di una prova della versione. Questo è un campione di due attività, non un benchmark. Mostra un comportamento che si percepisce; non può misurare le prestazioni agentiche multi-turno.

Attività 1 ha chiesto a ciascun modello di implementare una funzione compare_semver() seguendo le specifiche SemVer 2.0.0, inclusa la parte che la maggior parte delle implementazioni sbaglia: la precedenza delle pre-release, dove 1.0.0-alpha.1 < 1.0.0-alpha.beta, gli identificatori numerici hanno rango inferiore rispetto a quelli alfanumerici e beta.11 > beta.2 numericamente invece che in ordine di stringa. Ho valutato ciascuna risposta rispetto a una matrice di 72 confronti costruita a partire dall'ordinamento canonico delle specifiche. Attività 2 ha fornito una funzione merge_intervals() difettosa il cui vero bug era last[1] = cur[1] invece di max(...), una riga che assorbe silenziosamente un intervallo completamente contenuto come [1,10],[2,3]; ho valutato sulla base di 5 casi, incluso quell'intervallo contenuto.

Il costo è calcolato dai conteggi di token sopra riportati ai prezzi di listino nativi (Kimi $0.95/$4 per milione in/out, Opus $5/$25): Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078; Opus = 774×$5/M + 418×$25/M ≈ $0.0143. I conteggi dei token di input differiscono (172 vs 774) perché il tokenizer di ciascun modello e la contabilizzazione del gateway conteggiano in modo diverso lo stesso prompt, non perché i task fossero differenti. Entrambi i modelli hanno prodotto codice completamente corretto in entrambi i task. La differenza stava nel modo in cui ci sono arrivati. Opus è stato conciso e veloce, restituendo 418 token in 5.3 secondi nel Task 1. Kimi ha impiegato 49.1 secondi ed emesso 1,907 token, gran parte dei quali era una traccia di ragionamento passo dopo passo restituita insieme al codice. Tuttavia, poiché i token di Kimi costano circa 6× meno, l'esecuzione più verbose è comunque costata meno.

Ciò che il duello dimostra e non dimostra

Dimostra che, su problemi di coding limitati e ben specificati, Kimi K2.7 Code raggiunge la stessa risposta corretta di un modello di frontiera. Non dimostra che Kimi eguagli Opus in sessioni agentiche lunghe e multi-step, che due task in singolo colpo non possono mettere alla prova. La rivendicazione più forte di Kimi riguarda proprio quel territorio agentico, che i benchmark qui sotto affrontano direttamente.

Benchmark: cosa è di terze parti e cosa è il tabellone proprietario di Moonshot

Ecco la ripartizione, con ogni numero etichettato per fonte. La tabella autosegnalata di Moonshot è il punto in cui Kimi sembra più forte; la valutazione indipendente è più limitata perché il modello è recente, e dove non esiste ancora un numero K2.7 di terze parti, la cifra pubblicata più vicina è quella di K2.6 (indicata sotto).

La singola cifra su cui si regge il confronto, MCPMark Verified 81.1 vs 76.4, proviene dalla tabella di Moonshot stessa, non da un laboratorio indipendente. Questo non è un motivo per liquidarla, dato che l'uso di strumenti in stile MCP è esattamente l'ambito su cui Kimi è stato ottimizzato. Ma leggi il titolo "Kimi batte Opus" come una dichiarazione del fornitore su un benchmark ottimizzato dal fornitore. Nel confronto diretto misurato da una terza parte, Artificial Analysis colloca Opus 4.8 nettamente avanti nel suo Intelligence Index (56 contro 35), anche se quella riga usa K2.6 come proxy perché K2.7 non era ancora stato valutato in modo indipendente al momento della stesura.

Il divario nella finestra di contesto che i benchmark nascondono

Opus 4.8 dispone di una finestra di contesto da 1M di token; Kimi K2.7 arriva al massimo a 256K. I punteggi dei benchmark raramente lo evidenziano, ma è ciò che decide il lavoro reale. Una finestra da 256K contiene comodamente un repository di medie dimensioni e una lunga traccia dell’agente, ed è sufficiente per la maggior parte delle sessioni di coding. Si raggiunge il limite quando si inserisce in un unico prompt un intero monorepo di grandi dimensioni, lunghi set di documenti o trascrizioni di agenti di più ore. In quel caso, la finestra 4× più ampia di Opus fa la differenza pratica, non un dato su un grafico.

Prezzi: il divario 5–6× e la leva della cache

Ai prezzi di listino dell'API nativa, Kimi K2.7 Code costa $0.95 per milione di token in input e $4.00 per milione di output; Claude Opus 4.8 costa $5 e $25. Questo è un divario di 5–6× sull'output, ed è la ragione principale per cui i team valutano Kimi in primo luogo.

La leva che la maggior parte delle tabelle dei prezzi trascura è la cache. Kimi addebita $0.19 per milione di token su un cache hit, uno sconto dell'80% sull'input che hai già inviato. In un ciclo agentico che rilegge la stessa codebase a ogni passaggio, l'input memorizzato in cache domina la bolletta, quindi il costo effettivo scende ben al di sotto della differenza di listino. Philip Kiely di Baseten ha riportato un risparmio di circa l'82% su un workload di esempio dopo il passaggio da Opus 4.8 a Kimi 2.7 Code, il tipo di lavoro intensivo in termini di cache e input in cui il pricing di Kimi si amplifica. Il tuo numero varierà in base al rapporto tra input e output, ma la direzione è coerente: più rileggi il contesto rispetto a quanto generi, più Kimi vince in termini di costo.

Opus ripaga il suo prezzo sul lato dell’output. Ha generato un quarto dei token prodotti da Kimi nel mio Task 1, quindi su lavori ad alta intensità di generazione come la scrittura di file di grandi dimensioni o refactoring prolissi, il divario per token si riduce nella spesa reale, e la velocità di Opus taglia il tempo di attesa che stai pagando a un ingegnere per restare fermo.

La promessa degli open-weights contro la realtà di 577 GB

Kimi K2.7 viene distribuito come open weights sotto una licenza MIT modificata, quindi puoi ospitarlo in self-hosting e fare fine-tuning. Opus 4.8 è solo API; il tuo codice e le tracce di ragionamento vanno ad Anthropic. Sulla carta, questo rappresenta un vantaggio decisivo in termini di privacy e lock-in per Kimi. In pratica, controlla prima il costo dell'hardware.

Kimi K2.7 è un modello Mixture-of-Experts da 1 trilione di parametri (32B attivi per token, 384 esperti). Revisioni indipendenti stimano una distribuzione INT4 completa a circa 577GB di VRAM, una volta conteggiati pesi, KV cache e overhead di runtime, il che porta la configurazione minima pratica a circa 8× H100 80GB o a un box di classe DGX Spark. Una singola RTX 4090 (24GB) non può eseguire il modello completo con impostazioni utilizzabili. Per tutti tranne una manciata di team ben finanziati, "open weights" significa la libertà di indirizzare le richieste a un provider di hosting o di fare fine-tuning su GPU a noleggio, non un modello che si mette in funzione in-house. Se il tuo motivo per scegliere Kimi è il controllo dei dati on-prem, valuta il costo del cluster prima di impegnarti; per la maggior parte dei team, l’auto-hosting resta teorico.

Quale dovresti scegliere

Abbina il modello al carico di lavoro invece di incoronare un vincitore:

• Scegli Kimi K2.7 Code per lavori sensibili ai costi, ad alto volume o di coding agentico in cui rileggi ripetutamente una codebase, la latenza non è critica e un contesto da 256K è sufficiente. Lo sconto sul caching si accumula a tuo favore.

• Scegli Claude Opus 4.8 quando hai bisogno di bassa latenza, di un contesto da 1M token per repository di grandi dimensioni o sessioni lunghe, di un output più conciso o di un modello di revisione finale di cui fidarti per modifiche ad alto rischio, dove il suo vantaggio nei punteggi di ragionamento indipendente conta di più.

Il gioco ibrido: il modello economico prepara le bozze, il modello frontier rifinisce

Il modello più comune tra i team che usano entrambi non è sceglierne uno, ma instradare. Lascia che Kimi K2.7 gestisca la generazione e le iterazioni di massa a basso costo, poi passa il risultato a Opus 4.8 per la revisione finale o per le parti che richiedono un giudizio all’avanguardia. Kimi parla nativamente il formato OpenAI mentre Opus usa l’API proprietaria di Anthropic, quindi il modo pratico per instradarli tra loro è un gateway che espone entrambi dietro un unico endpoint compatibile con OpenAI; su una piattaforma come AIReiter, per esempio, entrambi stanno sotto una singola chiave, rendendo il passaggio da Kimi a Opus una semplice modifica della stringa del modello anziché una nuova integrazione. Il risparmio dell’82% sopra riportato è derivato בדיוק da questo tipo di instradamento, non dall’eliminare del tutto Opus.

FAQ

Kimi K2.7 è migliore di Claude Opus 4.8 per programmare?

Su compiti limitati e ben specificati sono equivalenti; nel mio test entrambi hanno restituito codice completamente corretto. Il vantaggio di Kimi è l’uso agentico degli strumenti (MCPMark 81,1 contro 76,4, secondo quanto riportato da Moonshot); Opus è in vantaggio nel ragionamento generale, nella velocità e nelle attività su contesti lunghi.

Quanto è più economico Kimi K2.7 rispetto a Opus 4.8?

Circa 5–6× più economico sul prezzo di listino ($0.95/$4 per milione vs $5/$25). Con cache hit ($0.19/M input) su carichi di lavoro ripetitivi, i risparmi nel mondo reale possono arrivare all’80% o più.

Qual è la finestra di contesto di Kimi K2.7 rispetto a Opus 4.8?

Kimi K2.7 gestisce 256K token; Opus 4.8 gestisce 1M, quattro volte di più.

Posso eseguire Kimi K2.7 localmente?

Solo con hardware serio. Si segnala che una distribuzione INT4 completa richiede circa 577GB di VRAM (all'incirca 8× H100 o un DGX Spark). Una singola GPU consumer come una RTX 4090 non può eseguire il modello completo.

Kimi K2.7 è open source?

Viene distribuito con pesi aperti sotto una licenza MIT modificata, quindi puoi ospitarlo autonomamente e perfezionarlo. Opus 4.8 è chiuso e disponibile solo tramite API.

In sintesi

Se il tuo collo di bottiglia è il budget, scegli Kimi K2.7 Code come impostazione predefinita e lascia che il caching faccia il resto. Se è la latenza, la lunghezza del contesto o una modifica che non puoi permetterti di sbagliare, paga per Opus 4.8. Considera la licenza open-weights come un bonus che incasserai solo se possiedi le GPU. E se non sei sicuro, integra entrambi e instrada in base al task invece di puntare il workflow su una sola scommessa che dovrai poi annullare in seguito.

Letture correlate

• Grok 4.5 vs Claude Opus 4.8

• Claude Sonnet 5 vs Opus 4.8

• GLM 5.2 vs Claude Opus 4.6