Kimi K3 eguaglia GPT-5.6, ma richiede 4,6 volte il tempo

Artificial Analysis assegna a Kimi K3 lo stesso punteggio di GPT-5.6 medium nel Coding Agent Index, ma Kimi richiede 23,8 minuti contro 5,2, cioè 4,6 volte il tempo [1]. Per GLM-5.2 va peggio: 1,40 $ per l’input diventano 6,51 $ per task tentato [2]. Li considero entrambi capaci, ma nessuno offre l’affare suggerito dal prezzo per token.

Il confronto in una tabella: Kimi compete, GLM-5.2 resta indietro

Kimi K3 è competitivo, ma non dominante: pareggia GPT-5.6 Sol medium nell’indice complessivo, guida il test da terminale, resta indietro nella comprensione dei repository e impiega molto più tempo. Con queste impostazioni, GLM-5.2 è dietro tutti e tre i modelli di confronto e non guida nessuna misura [1] [2].

Misura	Kimi K3	GLM-5.2	Sol medium	Opus 5 medium
Coding Agent Index	61	43	61	62 (Valore migliore della riga)
DeepSWE, %	64	29	64	63
Terminal-Bench v2, %	84 (Valore migliore della riga)	72	78	79
SWE-Atlas Q&A, %	37	29	40	44 (Valore migliore della riga)
Costo per task, $	3,18	6,51	2,99 (Valore migliore della riga)	3,14
Tempo attivo, min	23,8	25,1	5,2 (Valore migliore della riga)	12,2

Il pareggio tra Kimi e Sol medium offre il confronto diretto più utile: entrambi ottengono 61 punti e i costi misurati sono vicini, rispettivamente 3,18 $ e 2,99 $ per task [1]. Cambia però il modo in cui arrivano al risultato. Kimi usa 23,8 minuti attivi e 10,6 milioni di token per task, contro 5,2 minuti e 5,8 milioni per Sol. Opus 5 medium racconta una storia simile: supera Kimi di un punto nell’indice, costa quattro centesimi in meno e termina in circa metà tempo [2].

I punteggi più alti dell’indice appartengono ancora ai modelli occidentali. Sol max e Opus 5 xhigh arrivano entrambi a 67, rispettivamente a 7,08 $ e 8,23 $ per task, mentre Opus guida anche la comprensione dei repository con il 55% su SWE-Atlas Q&A [1] [2]. Fable 5 max segue a 66, ma costa 11,71 $ per task [2]. Kimi resta competitivo dove riesce meglio: il suo 84% su Terminal-Bench v2 supera l’83% di Sol high e si avvicina ai modelli con effort massimo [1] [2].

La comprensione dei repository è la debolezza più evidente. Kimi ottiene il 37% nella prova con domande sul codice, meno del 40% di Sol medium e molto meno delle configurazioni Claude [1] [2]. Questo conta meno quando inizi un progetto da zero, ma in un codebase esistente da 300.000 righe capire ciò che c’è già rappresenta gran parte del lavoro.

Perché Kimi K3 sta ricevendo tanta attenzione? Per i risultati nel browser

Le posizioni di Kimi nelle arene hanno alimentato gran parte dell’interesse perché mostrano che le persone preferiscono il suo lavoro nel browser, anche quando test più ampi sugli agenti ne evidenziano i punti deboli. Kimi guida la classifica fullstack di Arena [3] ed è secondo nella WebDev Arena, davanti a Claude Fable 5 e GPT-5.6 [4]. I pesi aperti e i prezzi per token apparentemente bassi lo rendono ancora più interessante.

I risultati delle arene contano perché misurano ciò che le persone preferiscono, non il superamento di una suite di test. Nella classifica fullstack del 24 luglio 2026, Kimi K3 max era primo con 1.664 punti, davanti a GPT-5.6 Sol con 1.633 e Fable 5 con 1.623 [3]. Quattro giorni dopo, Opus 5 max guidava la WebDev Arena con 1.712 punti, mentre Kimi era secondo con 1.682 su 3.777 voti, davanti a Fable 5, Sol e GLM-5.2 [4]. Agli utenti piace chiaramente ciò che Kimi costruisce nel browser.

I materiali di lancio confermano che si tratta di modelli a pesi aperti. Moonshot presenta Kimi K3 come il primo modello a pesi aperti con 2.800 miliardi di parametri, insieme a una finestra di contesto da un milione di token, visione integrata e prezzi API di 3 $ per milione di token in input e 15 $ in output [5]. Z.ai pubblica GLM-5.2, più piccolo, con 753 miliardi di parametri e licenza MIT [6], a prezzi di listino pari a 1,40 $ per l’input e 4,40 $ per l’output [7]. Guardando solo il listino, entrambi sembrano molto meno costosi dei concorrenti occidentali.

Il post di lancio di Moonshot è più prudente di quanto suggerisca quel confronto. Afferma che K3 è ancora dietro Fable 5 e GPT-5.6 Sol, con “un divario percepibile nell’esperienza d’uso” rispetto a entrambi [5]. Le misurazioni indipendenti rendono concreto quel divario, soprattutto per velocità e comprensione dei repository. La prudenza della stessa Moonshot vale la pena ricordarla ogni volta che un laboratorio cinese viene indicato come la causa di qualcosa, ed è la tesi che sostengo in il watermark nel testo di Claude risponde all’UE e non ai laboratori cinesi.

Cosa misura il Coding Agent Index? Sistemi completi di modello e agente

Il Coding Agent Index misura sistemi completi formati da modello e agente in tre ambiti: ingegneria software, lavoro da terminale e domande sui repository. Nella versione 1.3, Artificial Analysis combina con lo stesso peso 113 task DeepSWE, 84 task Terminal-Bench v2 e 124 domande SWE-Atlas Q&A [8].

La distinzione è importante perché Kimi è stato eseguito dentro Kimi Code CLI, GLM-5.2 dentro Claude Code, Sol dentro Codex e i modelli Claude dentro Claude Code [1] [2]. Ogni punteggio riflette quindi il modello, il suo agente e il livello di effort scelto. La tabella consente di confrontare queste configurazioni operative, ma non dice come si classificherebbero gli stessi pesi in un harness neutrale.

Kimi K3 e GLM-5.2 costano meno? Non per task completato

No. Il costo di un task completato dipende dal numero di token necessari all’agente e dalla frequenza con cui riesce, non solo dal prezzo di ogni token. GLM-5.2 è l’esempio più chiaro: ha il listino più basso del confronto, ma ogni task tentato costa più che con qualsiasi configurazione occidentale a effort medium [2] [7].

Anthropic ha reso definitivo il prezzo introduttivo di Claude Sonnet 5: 2 $ per l’input e 10 $ per l’output per milione di token [9]. Kimi K3 costa 3 $ e 15 $ [5], quindi entrambi i suoi prezzi sono più alti del 50% rispetto a Sonnet. Kimi non offre alcun vantaggio di listino contro quel modello.

Più in alto nel listino, Anthropic applica 5 $ per l’input di Opus 5 e 25 $ per l’output, mentre Fable 5 costa 10 $ e 50 $ [9]. OpenAI vende GPT-5.6 a 5 $ e 30 $, oppure a 10 $ e 45 $ nella fascia con contesto lungo [10]. Z.ai li batte tutti sul prezzo con GLM-5.2 a 1,40 $ e 4,40 $, più le letture dalla cache a 0,26 $ [7]. Tutte le cifre sono per milione di token.

Queste unità non sono perfettamente confrontabili. I produttori usano tokenizer diversi e Anthropic afferma che quello attuale produce circa il 30% di token in più rispetto al precedente per lo stesso testo [9]. La guida rapida di Moonshot precisa inoltre che Kimi K3 ragiona sempre, non permette di disattivare questa modalità e usa max come effort predefinito [11]. Anche i token del ragionamento nascosto finiscono in fattura.

listino, per milione di token in input

1,40 $

il modello più economico del confronto

misurato, per task tentato

6,51 $

dentro Claude Code, 25,1 minuti attivi

stimato, per task risolto

15,14 $

costo per tentativo diviso per il tasso di successo del 43%

Se confronto i task risolti invece di quelli tentati, Sol medium, Opus 5 medium e Kimi K3 restano vicini, rispettivamente a circa 4,90 $, 5,06 $ e 5,21 $. GLM-5.2 sale a 15,14 $, circa tre volte tanto. Il prezzo per token più basso del gruppo produce il costo stimato più alto per un risultato riuscito.

La stima resta ottimistica perché esclude il tempo dell’ingegnere. Dieci minuti spesi a esaminare un fallimento costano più di qualsiasi addebito nella figura, quindi il tasso di successo conta molto più del prezzo dei token quando una persona deve controllare l’output. Chiarito il costo, resta da capire per quali task Kimi sia abbastanza adatto da giustificare esecuzioni più lente.

In cosa riesce meglio Kimi K3? Terminale e sviluppo fullstack

Kimi K3 è più convincente nei task intensivi da terminale, nello sviluppo web fullstack e nei run prolungati degli agenti, soprattutto quando un team ha bisogno di pesi aperti e vuole ospitare il modello in proprio. Le misurazioni indipendenti, i voti delle arene e i risultati di Moonshot indicano tutti questi usi [1] [3] [5]. Non giustificano invece Kimi come sostituto più economico per il lavoro su grandi repository esistenti.

Il risultato da terminale compare sia nei test indipendenti sia in quelli del produttore: Artificial Analysis ha misurato l’84% nella CLI di Kimi, mentre Moonshot ha ottenuto l’88,3% nella configurazione preferita [1] [12]. K3 guida anche la tabella SWE-Marathon di Moonshot con 42 punti, ma le note contano. Fable 5 ha usato modelli di riserva nel 35% dei task e alcune righe di Kimi sono state eseguite su un ramo preliminare calibrato per hardware H20 [12]. L’encoder visivo dedicato e la finestra di contesto da un milione di token danno inoltre un fondamento tecnico credibile al flusso di lavoro proposto da Moonshot tra codice e screenshot dell’applicazione [5] [12].

Questi punti di forza hanno limiti pratici. Il 37% nelle domande sul codebase rende Kimi una scelta discutibile quando il task dipende dalla comprensione del repository [1], mentre 23,8 minuti attivi per ogni esecuzione impongono di avviare più agenti in parallelo oppure aspettare. Anche ospitarlo in proprio non è cosa da poco: 2,8 mila miliardi di parametri richiedono circa 1,4 TB per i soli pesi con quantizzazione a 4 bit, prima della cache KV e delle risorse necessarie al servizio. Per un’installazione pratica serve quindi un cluster di server, non una workstation.

Prima di adottarlo vanno controllati anche i termini legali. Un’attività che offre il modello come servizio e supera 20 milioni di dollari di ricavi totali deve stipulare un accordo separato con Moonshot, mentre i prodotti con più di 100 milioni di utenti attivi mensili o 20 milioni di dollari di ricavi mensili devono mostrare “Kimi K3” in evidenza. L’uso interno è esente [13]. I termini standard dell’API di Moonshot consentono inoltre di usare i contenuti dei clienti per fornire, mantenere, sviluppare, supportare e migliorare i servizi; le limitazioni sull’uso per l’addestramento richiedono accordi enterprise separati [14]. Prima di inviare un repository proprietario all’API pubblica, chiederei queste restrizioni per iscritto.

Perché GLM-5.2 rende male in Claude Code? L’agente conta

Il calo di nove punti di GLM-5.2 su Terminal-Bench va letto soprattutto come un avvertimento sulla configurazione dell’agente, non come prova che i pesi siano deboli. Il modello ottiene l’81% nell’harness Terminus di Z.ai e il 72% dentro Claude Code [6] [2]. Nessuno al di fuori di Z.ai può indicare la causa esatta, ma la differenza potrebbe dipendere dall’uso degli strumenti, dal recupero dagli errori, dalla cache o dalle convenzioni dell’agente.

Qualunque sia la causa, quella configurazione rende male. GLM-5.2 ottiene 43 nell’indice e il 29% sia su DeepSWE sia nelle domande sul codebase; con 6,51 $ e 25,1 minuti attivi per tentativo, è anche la configurazione più lenta del confronto [2]. I prezzi di 1,40 $ per l’input e 4,40 $ per l’output non diventano mai un costo basso per task.

La scheda del modello di Z.ai mostra perché il sistema circostante è importante. Il risultato di 62,1 su SWE-Bench Pro usa OpenHands con un prompt di istruzioni su misura, DeepSWE viene eseguito in container isolati con timeout di due ore e Terminal-Bench usa Terminus con un budget di quattro ore [6]. Sono misurazioni valide di GLM-5.2 in una configurazione scelta per il modello, ma non prevedono come si comporterà in un altro agente.

GLM-5.2 resta una scelta plausibile quando vuoi ospitare il modello in proprio e verificare il lavoro automaticamente. I suoi 753 miliardi di parametri e la licenza MIT lo rendono il più facile da ospitare tra i due modelli [6], mentre il prezzo di 1,40 $ per l’input si presta a codemod in grandi volumi o migrazioni coperte da controlli deterministici. Quei controlli possono scartare il 57% dei tentativi falliti senza revisione manuale. Se deve esaminarli un ingegnere, lo sconto sui token non fa più risparmiare. Ospitarlo è un costo a parte, come ho visto con DeepSeek V4.1 Flash, che ha prezzi API bassi e pesi aperti enormi.

Come leggere una classifica di coding: prima confronta l’harness

Parti dall’harness, dalla versione del benchmark e dal task misurato, perché il punteggio di una classifica appartiene a quella configurazione. La distanza tra il successo di Kimi nelle arene e i risultati di GLM, tanto dipendenti dall’harness, mostra perché il nome del modello e il numero finale non bastano.

Segnale	Cosa premia	Cosa non può dirti
DeepSWE, 113 task	completare task di ingegneria da capo a fondo	l’aderenza alle convenzioni del tuo codebase
Terminal-Bench v2, 84 task	portare una shell a uno stato finale verificato	la comprensione di un grande repository esistente
SWE-Atlas Q&A, 124 task	rispondere a domande tecniche sul codice	la capacità di applicare la modifica descritta
WebDev e Fullstack Arena	ciò che le persone preferiscono nei confronti	correttezza, test, sicurezza, manutenibilità
Schede modello dei produttori	il modello al meglio nella configurazione scelta	la confrontabilità tra le righe

L’infrastruttura è la prima fonte di incertezza. Il team di ingegneria di Anthropic ha modificato di sei punti percentuali un risultato su Terminal-Bench 2.0 cambiando soltanto i limiti delle risorse, mentre gli errori di infrastruttura sono scesi dal 5,8% allo 0,5% quando i limiti sono aumentati [15]. Il team ha concluso che differenze inferiori a circa tre punti meritano scetticismo finché le configurazioni non sono documentate e allineate. Kimi e Sol medium rientrano in quel margine, quindi il loro punteggio identico indica parità, non la vittoria di uno dei due.

Il secondo problema è l’incoerenza della configurazione di test. Moonshot esegue ogni concorrente in un harness diverso, usa modelli di riserva in alcune righe e include un proprio benchmark interno. Fable 5 ha usato modelli di riserva 13 volte e ha rifiutato uno degli 80 task di quella prova [12]. Moonshot dichiara questi dettagli, ma il confronto perde gran parte del suo valore quando le note spariscono dal riepilogo.

Infine, deve coincidere anche la versione del benchmark. Artificial Analysis pubblica versioni distinte del proprio indice perché la composizione dei task cambia, e qui la versione corrente è la v1.3 [8]. I punteggi di versioni diverse non sono direttamente confrontabili, anche quando il nome del benchmark resta uguale. Un confronto utile indica quindi harness, livello di effort, budget del task e versione. La nuova valutazione di Muse Spark 1.3 nell’indice di Artificial Analysis mostra quanto un cambio di versione possa spostare una posizione.

La mia mappa: Kimi per la UI, GLM dietro controlli automatici

Proverei Kimi K3 per primo sui progetti fullstack nuovi e sui lavori con molta UI, mentre terrei GLM-5.2 dietro controlli automatici nel suo harness nativo. Per il resto continuerei ad assegnare il lavoro a Claude o GPT-5.6 in base al task:

Il lavoro	La mia scelta oggi
Modifiche di routine con test solidi	Sonnet 5, al prezzo permanente di 2 $/10 $
Cicli rapidi con agenti e lavoro da terminale	GPT-5.6 a effort medium o high
Lavoro su un grande repository esistente	Opus 5 a effort medium o high
Progetti fullstack nuovi e build con molta UI	Kimi K3, sostenuto dai risultati delle arene
Lavoro in grandi volumi con verifica automatica	GLM-5.2 nel suo harness nativo, come progetto pilota
Ultimo tentativo quando tutto il resto fallisce	Fable 5, con moderazione

La tabella segue la stessa regola che ho usato durante la settimana di lancio di Opus 5: confronto il costo delle modifiche approvate, non soltanto il prezzo dei token. Questo colloca Kimi nei lavori in cui i risultati da terminale e nelle arene sono più forti, e tiene GLM dietro controlli automatici.

Due misurazioni cambierebbero le mie scelte. Kimi K3 dovrebbe mantenere il punteggio di 61 in un harness neutrale come Claude Code o Codex, così da separare la capacità del modello dal vantaggio di Kimi Code CLI. Per GLM-5.2 serve il test opposto: un’esecuzione indipendente nel suo agente nativo da parte di qualcuno che non lo vende. Fino ad allora, entrambi mostrano capacità utili in task specifici, ma nessuno offre l’ampio vantaggio economico suggerito dal prezzo per token.