Prezzi delle API di Kimi K3, misurati: come spegnere il reasoning 'sempre attivo'

La documentazione di Kimi K3 dice che il thinking non si può spegnere e che reasoning_effort accetta solo "max". Nelle nostre misurazioni l’API accetta comunque "none", e funziona: la stessa domanda banale che costa $0.00179 con il reasoning di default costa $0.000285 senza, una differenza di 6,3x. K3 è uscito il 16-07-2026 a $3 per milione di token di input e $15 per milione di output, il listino più caro mai proposto da un laboratorio cinese e lo stesso prezzo di Claude Sonnet 5. A quel prezzo di output, i token di reasoning che il modello spende di default sono la bolletta, il che rende utile capire con precisione l’interruttore non documentato.

TL;DR

• Kimi K3 spende il 69-93% dei suoi token di output in reasoning con le impostazioni di default; un paragrafo di 120 parole è stato fatturato come 2.289 token di output, $0.0346.
• reasoning_effort: "none" viene accettato nonostante la documentazione dica il contrario, e ha ridotto il costo delle nostre query semplici di 6,3x, ma l’aritmetica multi-step è passata da 3/3 corrette a 0/6.
• La prompt cache di Kimi K3 fa hit a partire da circa 256 token di prefisso, in blocchi da 256 token, a una tariffa di lettura di $0.30/M.
• Il cinese è la corsia CJK più economica di K3: 52 token netti ogni 100 caratteri, sotto GLM-5.2 e DeepSeek a 58.

Tutto quanto segue è stato misurato il 20-07-2026 su kimi-k3, attivo sul gateway Synthorai ai prezzi di listino di Moonshot, con prompt ripetuti “salati” per aggirare le cache di risposta e le affermazioni sul comportamento verificate in modo incrociato su un secondo percorso di richiesta indipendente. Ogni numero è supportato dai record d’uso grezzi.

Quanto costa una risposta di Kimi K3 con le impostazioni di default?

Su ogni tipo di task che abbiamo inviato è il reasoning a dominare il conto, anche quando non serve alcun ragionamento. Per singola risposta, con le impostazioni di default:

Il punto del grafico è il confronto tra i modelli: GPT-5.6 ragiona in modo adattivo (zero token di thinking sulle domande banali e fattuali, 65-70% su matematica e scrittura), Claude Sonnet 5 arriva con il thinking disattivato, e GLM-5.2 ragiona in termini relativi anche più di K3. Ma il prezzo di output di GLM è $4.40/M e quello di K3 è $15/M, quindi la stessa risposta a 17×23 è costata $0.00078 su GLM-5.2, $0.00027 su GPT-5.6, $0.0001 su Sonnet 5 e $0.0018 su K3. Il divario si allarga con la lunghezza dell’output: lo stesso identico paragrafo di 120 parole è costato $0.0346 su K3, contro $0.0186 su GLM-5.2, $0.0072 su GPT-5.6 e $0.0024 su Sonnet 5, uno scarto di 15x sul task più banale dell’intero set. L’aliquota è paragonabile a quella di altri modelli di reasoning cinesi; il conto finale no.

Altri due fatti in modalità default da mettere a budget. Primo, la modalità thinking inietta in ogni richiesta un preambolo nascosto di circa 67 token: un messaggio identico di una sola parola è stato fatturato 86 token di prompt con il reasoning attivo e 19 con quello disattivato. È il “system prompt nascosto” notato dai primi tester, e sparisce quando sparisce il reasoning. Secondo, al momento K3 è lento: le nostre chiamate sulle domande banali hanno richiesto circa 19-24 secondi end-to-end con il reasoning attivo e 3-8 secondi senza, tenendo conto anche del serving della settimana di lancio. Metti a budget la latenza, non solo i dollari.

Si può disattivare il reasoning di Kimi K3?

Sì, nonostante quel che dice la documentazione. L’API reference ufficiale afferma che K3 “abilita sempre il thinking” e che reasoning_effort accetta solo "max". Nella pratica l’endpoint ha accettato "none", "low", "medium" e "high" senza errori, rispettandoli, e abbiamo confermato lo stesso comportamento su un percorso di richiesta indipendente. Sul problema aritmetico a più passaggi la manopola funziona davvero, ma in modo grossolano:

Due cose saltano all’occhio. I livelli intermedi si assomigliano: da low fino a max il conteggio di token è simile e l’accuratezza identica su questo task, quindi l’unica distinzione che conta è binaria. E none ha un vero e proprio crollo: costretto a rispondere in modo conciso a un problema aritmetico a più passaggi, K3 ha sbagliato sei volte su sei, con risposte errate sparse invece di un unico errore sistematico. Quando non abbiamo imposto un formato conciso, il modello a volte ignorava la brevità e svolgeva i passaggi direttamente nella risposta visibile: corretto, ma i token si spostavano dal campo di reasoning al campo di testo invece di sparire.

La latenza cambia meno di quanto suggerisca il conteggio di token. Facendo lo streaming dello stesso problema a ogni livello di effort, i tempi al primo byte andavano da 6 a 24 secondi, con intervalli che si sovrapponevano ampiamente tra i vari livelli; persino none, che non aveva nulla su cui ragionare, aspettava 12-13 secondi. Il tempo al primo token, per un task di questa dimensione, è quindi dominato dal serving. Quel che la manopola cambia davvero è l’intervallo tra il primo byte e il primo token della risposta, cioè la fase di thinking che l’utente si trova ad aspettare.

In pratica: none è una leva di costo reale per task di retrieval, formattazione o a singolo passaggio, e un’arma a doppio taglio per qualsiasi cosa richieda passaggi intermedi. Non c’è alcuna garanzia documentata che questo parametro continui a funzionare; trattalo come comportamento misurato, verificalo nei tuoi campi usage e aspettati che venga formalizzato o rimosso quando la documentazione si allineerà.

Quando conviene lasciare il reasoning attivo nei workload agentici?

Abbiamo eseguito K3 su cinque scenari in stile agentico, due volte ciascuno, con impostazioni di default rispetto a reasoning_effort: "none", usando task semplici e identici che entrambe le configurazioni hanno superato interamente:

La sorpresa è la prima riga: nei loop di tool-call K3 ragiona pochissimo anche con le impostazioni di default (quota dell’8%), quindi c’è ben poco da risparmiare; il modello tratta la selezione degli strumenti come un riflesso, non come una deliberazione. I risparmi si concentrano dove la quota di thinking è alta e il task è meccanico (lookup RAG ed estrazione batch), cioè proprio dove una tassa fissa sempre attiva ha meno senso. Per i piani agentici davvero a più passaggi vale il crollo di accuratezza della sezione precedente: lascia il reasoning attivo e spendi i token.

Su larga scala l’effetto sulla latenza è reale, anche se le singole chiamate sono rumorose: in questi scenari i primi token arrivavano in 10-19 secondi con le impostazioni di default e in 8-13 secondi con none, e la generazione girava a una mediana di 35 token al secondo su output sostanziosi. Questi numeri, con il serving della settimana di lancio incluso, si adattano meglio a forme asincrone e batch che a qualsiasi caso conversazionale attuale.

Il reasoning che restituisci viene rifatturato come input?

Sì, token per token. La documentazione di Kimi indica di mantenere il reasoning_content di ogni turno dell’assistant nella cronologia dei messaggi, senza modificarlo. Abbiamo misurato quanto costa: un secondo turno inviato con la chain of thought del primo turno ha fatturato 599 prompt token; la stessa identica richiesta senza chain of thought ne ha fatturati 198. La differenza di 401 token corrisponde quasi esattamente ai 402 reasoning token del primo turno, quindi il thinking conservato rientra in ogni richiesta successiva alla tariffa piena di input di $3/M, e una conversazione lunga ripaga il reasoning accumulato a ogni turno.

Toglierlo però non è automaticamente più economico. Senza la chain of thought precedente, K3 ha rifatto il reasoning del follow-up da zero: i reasoning token del secondo turno sono saliti del 31% (da 343 a 449). A $3/M di input contro $15/M di output, nella nostra prova mantenere la CoT è risultata l’opzione complessivamente più economica: il consiglio della documentazione regge quindi sia sui costi che sulla qualità. La leva che qui paga davvero è il prompt cache descritto nella sezione successiva: la cronologia conservata è un prefisso stabile, e i prefissi stabili smettono di essere fatturati a prezzo pieno.

Kimi K3 mette in cache i prompt, e a partire da quanti token?

Il prompt cache di K3 è automatico e la soglia è bassa: gli hit sono iniziati intorno ai 256 token di prefisso condiviso, avanzando a blocchi da 256 token (un prompt da 303 token ne ha messi in cache 256; un prompt da 153 token non è mai andato in cache tra i vari tentativi). L’input in cache viene fatturato a $0,30/M, uno sconto netto del 90% rispetto alla tariffa fresh di $3/M, senza sovrapprezzo di cache-write su nessuna chiamata che abbiamo effettuato. Il warm-up ha richiesto da due a cinque chiamate identiche prima del primo hit, quindi un singolo retry non dimostra nulla in un senso o nell’altro; misura su più chiamate.

Per dare un riferimento, quella soglia è un quarto del minimo documentato da OpenAI di 1.024 token, e la dimensione dei blocchi è più grossolana della granularità da 64 token che abbiamo misurato altrove. La durata è best-effort e non un TTL fisso: nella nostra prova le voci in cache sono sopravvissute a intervalli di inattività di 4 e 15 minuti, mentre un intervallo di 8 minuti è andato a vuoto. Trattala quindi come un’eviction dipendente dal carico e verifica la quota in cache a ogni chiamata. Un altro dato di prezzo su cui vale la pena fare due conti: il context window da 1M token ha un prezzo piatto, senza fascia long-context nel listino. Una finestra riempita al massimo costa $3,00 di input fresh a chiamata, e $0,30 una volta che il prefisso è caldo, quindi i workload a contesto ampio dipendono dalla cache molto più che dal prezzo di listino. Se il tuo traffico riutilizza un system prompt anche solo di qualche centinaio di token, la cache di K3 si attiva dove quella della maggior parte dei provider non sarebbe ancora partita; il funzionamento e come verificare gli hit da usage sono spiegati nella nostra guida al prompt caching e nello studio sui minimi di cache misurati.

Il cinese costa davvero di più su Kimi K3?

No. Il cinese è proprio la lingua in cui il tokenizer di K3 rende meglio rispetto ai concorrenti, e questo risponde a una domanda emersa più volte nelle discussioni della settimana di lancio. Token netti ogni 100 caratteri su passaggi allineati semanticamente, sottratto l’overhead di envelope:

K3 fattura il cinese a 52 token ogni 100 caratteri: l’11% in meno rispetto a GLM-5.2 e DeepSeek, e meno della metà di Sonnet 5. Il suo punto debole è il giapponese, dove paga il 16-24% in più degli altri modelli open-weight. Abbiamo anche verificato che il tokenizer è identico in tutta la famiglia: K3, K2.7-code e K2.5 hanno prodotto conteggi identici su tutti e 23 i campioni allineati, quindi i budget per lingua costruiti per K2 restano validi. Come la densità del tokenizer si combina con il prezzo per token su nove lingue è l’argomento del nostro studio LLM più economico per lingua.

FAQ

Quando saranno rilasciati i pesi open di Kimi K3?

Moonshot ha promesso i pesi completi sotto una licenza Modified MIT entro il 27 luglio 2026; al momento di questo post K3 è disponibile solo tramite API. La definizione di “il più grande modello open-weight di sempre” è un impegno, non ancora un link per il download. Il comportamento del caching nell’ecosistema open-weight a cui i pesi si uniranno è illustrato in prompt caching for open-weight LLMs.

Cosa c’è davvero di nuovo in K3 rispetto alla famiglia K2?

Sul conto, tre cose che abbiamo misurato: il prezzo (i $3/$15 di K3 contro i $0.95/$4 di K2.7-code, un aumento di 3.2-3.75x), il thinking sempre attivo (K2.5 non ragiona affatto, K2.7-code ha un toggle) e nient’altro: il tokenizer è identico byte per byte tra K3, K2.7-code e K2.5 su tutti e 23 i nostri campioni allineati, quindi i budget di token dell’era K2 restano validi. Sulla scheda tecnica, secondo Moonshot: un nuovo MoE da 2.8T parametri (896 esperti, 16 attivi per token) con Kimi Delta Attention, un context window da 1M token contro i 256K di K2.7-code, e input immagine nativo. Noi abbiamo misurato le affermazioni sulla fatturazione, non quelle sull’architettura.

Kimi K3 supporta l’output strutturato?

Sì. Un response_format con json_schema ha restituito un oggetto valido e conforme allo schema nel nostro test. Va detto che il reasoning gira comunque sotto: 66 dei 97 token di output di quella chiamata di estrazione erano reasoning, quindi le chiamate vincolate a uno schema pagano la thinking tax come tutto il resto, a meno che non si imposti anche reasoning_effort: "none".

Disattivare il reasoning cambia ciò che si può vedere?

Sì. Con le impostazioni di default K3 restituisce l’intera catena di ragionamento in reasoning_content, e la documentazione consiglia di rimandarla indietro senza modifiche nella cronologia multi-turn. Con reasoning_effort: "none" il campo scompare del tutto, e con esso sparisce dal conto del prompt il preambolo di thinking da ~67 token.

Misurato il 2026-07-20 su kimi-k3 ai prezzi di listino della settimana di lancio ($3/M input, $0.30/M cached, $15/M output). I prompt ripetuti sono stati salati per evitare le cache a livello di risposta; i conteggi di accuratezza usano task con una singola risposta verificabile; le affermazioni comportamentali sono state riprodotte su un secondo percorso di richiesta indipendente. Prezzi e comportamento possono cambiare man mano che il rilascio matura; verifica sui tuoi record di usage prima di fare affidamento su qualsiasi numero riportato qui.

← Torna al blog