Prezzi API di Kimi K3: disattivare il reasoning «sempre attivo»

La documentazione di Kimi K3 afferma che il thinking non può essere disattivato e che reasoning_effort accetta solo "max". Nelle nostre misurazioni, però, l’API accetta anche "none" e l’impostazione funziona: la stessa domanda banale costa $0.00179 con il reasoning predefinito e $0.000285 senza, con una differenza di 6.3 volte. K3 è stato lanciato il 2026-07-16 a $3 per milione di token di input e $15 per milione di token di output. È il prezzo di listino più alto mai applicato da un laboratorio cinese, identico a quello di Claude Sonnet 5. Con questo prezzo per l’output, i token di reasoning consumati di default costituiscono gran parte del conto. Conviene quindi capire con precisione come funziona questa opzione di disattivazione non documentata.

TL;DR

• Con le impostazioni predefinite, Kimi K3 usa per il reasoning il 69-93% dei token di output; un paragrafo di 120 parole ha fatturato 2,289 token di output, pari a $0.0346.
• reasoning_effort: "none" viene accettato nonostante la documentazione dica il contrario e ha ridotto di 6.3 volte il costo delle nostre query semplici, ma nei calcoli a più passaggi l’accuratezza è scesa da 3/3 a 0/6.
• La prompt cache di Kimi K3 registra hit a partire da circa 256 token di prefisso, in blocchi da 256 token, con una tariffa di lettura di $0.30/M.
• Il cinese è la lingua CJK più economica per K3: 52 token netti ogni 100 caratteri, contro i 58 di GLM-5.2 e DeepSeek.

Tutti i dati riportati di seguito sono stati misurati il 2026-07-20 su kimi-k3, disponibile sul gateway Synthorai ai prezzi di listino Moonshot. Abbiamo aggiunto salt ai prompt ripetuti per evitare le response cache e verificato i comportamenti tramite un secondo percorso di richiesta indipendente. Ogni valore è supportato dai record grezzi di utilizzo.

Quanto costa per impostazione predefinita una risposta di Kimi K3?

Il reasoning domina il costo in ogni tipo di task testato, compresi quelli che non richiedono alcun ragionamento. Costo per risposta con le impostazioni predefinite:

Il grafico evidenzia il confronto tra modelli: GPT-5.6 adatta il reasoning al task, senza token di thinking per le domande banali e fattuali e con il 65-70% per matematica e scrittura. Claude Sonnet 5 viene fornito con il thinking disattivato, mentre GLM-5.2 dedica al thinking una quota ancora maggiore rispetto a K3. L’output di GLM costa però $4.40/M, contro i $15/M di K3. La stessa risposta a 17×23 ha quindi fatturato $0.00078 su GLM-5.2, $0.00027 su GPT-5.6, $0.0001 su Sonnet 5 e $0.0018 su K3. Il divario aumenta con la lunghezza dell’output: lo stesso paragrafo di 120 parole è costato $0.0346 su K3, $0.0186 su GLM-5.2, $0.0072 su GPT-5.6 e $0.0024 su Sonnet 5. Sul task più comune del gruppo, la differenza arriva a 15 volte. L’incidenza percentuale è simile a quella degli altri modelli cinesi di reasoning, ma l’importo finale no.

Per il budget vanno considerati altri due aspetti della modalità predefinita. Primo: la modalità thinking inserisce in ogni richiesta un preambolo nascosto di circa 67 token. Lo stesso messaggio di una parola ha fatturato 86 token di prompt con il reasoning attivo e 19 con il reasoning disattivato. È l’«hidden system prompt» rilevato dai primi tester e scompare insieme al reasoning. Secondo: al momento K3 è lento. Le richieste con domande banali hanno impiegato circa 19-24 secondi end-to-end con il reasoning attivo e 3-8 secondi senza, tenendo conto dell’infrastruttura della settimana di lancio. Nel budget va inclusa anche la latenza, non solo il costo.

È possibile disattivare il reasoning di Kimi K3?

Sì, nonostante la documentazione. Il riferimento ufficiale dell’API afferma che K3 «abilita sempre il thinking» e che reasoning_effort accetta solo "max". In pratica, l’endpoint ha accettato senza errori "none", "low", "medium" e "high" e ha rispettato i valori impostati. Abbiamo confermato lo stesso comportamento tramite un percorso di richiesta indipendente. Sul problema testuale a più passaggi, il selettore funziona, ma con differenze poco granulari:

Emergono due elementi. Le impostazioni intermedie sono molto vicine: da low a max abbiamo ottenuto un numero simile di token e la stessa accuratezza su questo task. La scelta rilevante è quindi di fatto binaria. Con none, invece, il calo è netto. Obbligato a rispondere in modo conciso a un problema aritmetico a più passaggi, K3 ha sbagliato sei volte su sei, fornendo risultati errati diversi e non riconducibili a un unico errore sistematico. Quando non imponevamo una risposta concisa, il modello a volte ignorava la richiesta di brevità e svolgeva i passaggi nella risposta visibile. Il risultato era corretto, ma i token passavano dal campo del reasoning a quello del testo anziché scomparire.

La latenza varia meno di quanto suggerisca il numero di token. Eseguendo in streaming lo stesso problema a ogni livello di effort, il tempo al primo byte è stato compreso tra 6 e 24 secondi, con intervalli ampiamente sovrapposti. Anche none, pur non avendo reasoning da elaborare, ha atteso 12-13 secondi. Per un task di queste dimensioni, il tempo al primo token dipende quindi soprattutto dal serving. Il selettore modifica invece l’intervallo tra il primo byte e il primo token della risposta, cioè la fase di thinking che l’utente deve attendere.

In pratica, none è un vero strumento di riduzione dei costi per task di retrieval, formattazione o a passaggio singolo, ma diventa pericoloso quando servono passaggi intermedi. Non esiste alcuna garanzia documentata che il parametro continuerà a funzionare. Va considerato un comportamento misurato, da verificare nei propri campi usage, e potrebbe essere ufficializzato o rimosso quando la documentazione verrà aggiornata.

Quando conviene mantenere attivo il reasoning nei workload agentici?

Abbiamo eseguito K3 in cinque scenari tipici degli agenti, confrontando due volte le impostazioni predefinite con reasoning_effort: "none". I task erano semplici e identici, e sono stati completati correttamente da entrambe le configurazioni:

La prima riga è quella inattesa: nei loop di tool call K3 usa pochissimo thinking anche con le impostazioni predefinite, appena l’8%, quindi il margine di risparmio è ridotto. Il modello tratta la scelta del tool come un automatismo, non come una decisione da ponderare. Il risparmio si concentra nei task meccanici con un’alta quota di thinking, come le ricerche RAG e l’estrazione batch. Sono proprio i casi in cui una quota fissa sempre attiva ha meno senso. Per i piani agentici realmente articolati vale invece il crollo di accuratezza descritto nella sezione precedente: meglio lasciare attivo il reasoning e pagare i token.

Su larga scala, l’effetto sulla latenza è concreto anche se le singole chiamate sono variabili. Nei vari scenari, i primi token sono arrivati dopo 10-19 secondi con le impostazioni predefinite e dopo 8-13 secondi con none. Sugli output sostanziali, la velocità mediana di generazione è stata di 35 token al secondo. Considerando anche il serving della settimana di lancio, al momento questi valori si adattano meglio a workload asincroni e batch che a esperienze conversazionali.

Il reasoning reinviato viene fatturato di nuovo come input?

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

Rimuoverlo, però, non costa necessariamente meno. Senza la chain of thought precedente, K3 ha rifatto da zero il reasoning per la richiesta successiva: i token di reasoning del secondo turno sono aumentati del 31%, da 343 a 449. Con l’input a $3/M e l’output a $15/M, nel nostro test mantenere la CoT è risultato complessivamente più economico. L’indicazione della documentazione è quindi valida sia per i costi sia per la qualità. La leva davvero efficace in questo caso è la prompt cache descritta nella sezione successiva: la cronologia mantenuta costituisce un prefisso stabile, e i prefissi stabili smettono di essere fatturati a prezzo pieno.

Kimi K3 usa la prompt cache e da quanti token?

La prompt cache di K3 è automatica e ha una soglia bassa. Gli hit sono iniziati da circa 256 token di prefisso condiviso e sono aumentati in blocchi da 256 token: un prompt da 303 token ne ha messi in cache 256, mentre uno da 153 non ha mai prodotto hit nei tentativi ripetuti. L’input in cache viene fatturato a $0.30/M, con uno sconto fisso del 90% rispetto alla tariffa di $3/M per l’input nuovo. Nessuna delle chiamate effettuate ha comportato un sovrapprezzo per la scrittura in cache. Prima del primo hit sono servite da due a cinque chiamate identiche, quindi un singolo retry non dimostra né la presenza né l’assenza della cache: servono più misurazioni.

Per confronto, questa soglia è un quarto del minimo documentato da OpenAI, pari a 1,024 token, mentre la dimensione dei blocchi è meno granulare dei 64 token misurati altrove. La durata è best effort e non segue un TTL fisso. Nei nostri test, alcune entry sono sopravvissute a intervalli di inattività di 4 e 15 minuti, mentre dopo un intervallo di 8 minuti si è verificato un miss. La scadenza va quindi considerata un’eviction dipendente dal carico, verificando in ogni chiamata la quota di token in cache. Un altro dato rilevante per i costi: la context window da 1M token ha una tariffa fissa, senza fasce per il long context nel listino. Una finestra completamente utilizzata costa $3.00 per chiamata con input nuovo e $0.30 dopo il warm-up del prefisso. Per i workload con contesti estesi, la cache incide quindi molto più del prezzo di listino. Se il traffico riutilizza anche solo un system prompt di poche centinaia di token, la cache di K3 entra in funzione prima ancora che quella della maggior parte dei provider raggiunga la propria soglia minima. La nostra guida alla prompt cache descrive il funzionamento e come verificare gli hit tramite usage; lo studio sulle soglie minime della cache misurate raccoglie i dati comparativi.

Il cinese costa davvero di più su Kimi K3?

No. Rispetto ai modelli concorrenti, il tokenizer di K3 è più efficiente proprio con il cinese, un tema ricorrente nelle discussioni della settimana di lancio. Di seguito sono riportati i token netti ogni 100 caratteri su testi semanticamente allineati, sottraendo l’overhead dell’envelope:

Per il cinese, K3 fattura 52 token ogni 100 caratteri: l’11% in meno rispetto a GLM-5.2 e DeepSeek e meno della metà rispetto a Sonnet 5. Il punto debole è il giapponese, per cui usa il 16-24% di token in più rispetto agli altri modelli open-weight. Abbiamo inoltre verificato che il tokenizer non è cambiato nella famiglia: K3, K2.7-code e K2.5 hanno prodotto conteggi identici su tutti i 23 campioni allineati. I budget per lingua calcolati per K2 restano quindi validi. Il nostro studio sul LLM più economico per lingua analizza come la densità del tokenizer si combini con il prezzo per token in nove lingue.

FAQ

Quando verranno rilasciati i pesi aperti di Kimi K3?

Moonshot ha promesso i pesi completi con licenza Modified MIT entro il 27 luglio 2026; alla data di pubblicazione, K3 è disponibile solo tramite API. La definizione di «più grande modello open-weight mai realizzato» è per ora un impegno, non ancora un link per il download. Il funzionamento della cache nell’ecosistema open-weight a cui si aggiungeranno i pesi è descritto nella guida alla prompt cache per gli LLM open-weight.

Quali sono le vere novità di K3 rispetto alla famiglia K2?

Dal punto di vista dei costi, ne abbiamo misurate tre: il prezzo, con $3/$15 per K3 contro $0.95/$4 per K2.7-code, cioè un aumento di 3.2-3.75 volte; il thinking sempre attivo, mentre K2.5 non usa alcun reasoning e K2.7-code dispone di un selettore; e nient’altro. Il tokenizer è byte-identical tra K3, K2.7-code e K2.5 su tutti i nostri 23 campioni allineati, quindi i budget di token dell’epoca K2 restano validi. Secondo le specifiche di Moonshot, l’architettura include un nuovo MoE da 2.8T parametri, con 896 esperti e 16 attivi per token, Kimi Delta Attention, una context window da 1M token rispetto ai 256K di K2.7-code e input di immagini nativo. Abbiamo misurato le affermazioni sulla fatturazione, non quelle sull’architettura.

Kimi K3 supporta l’output strutturato?

Sì. Nei nostri test, un response_format con json_schema ha restituito un oggetto valido e conforme allo schema. Il reasoning continua comunque a essere eseguito: in quella chiamata di estrazione, 66 dei 97 token di output erano token di reasoning. Anche le chiamate vincolate da uno schema pagano quindi il costo del thinking, a meno di impostare anche reasoning_effort: "none".

Disattivare il reasoning cambia ciò che è visibile?

Sì. Con le impostazioni predefinite, K3 restituisce l’intera chain of thought in reasoning_content, e la documentazione consiglia di reinviarla senza modifiche nella cronologia multi-turno. Con reasoning_effort: "none" il campo è del tutto assente e anche il preambolo di thinking da circa 67 token scompare dal costo del prompt.

Misurazioni effettuate il 2026-07-20 su kimi-k3 ai prezzi di listino della settimana di lancio ($3/M per l’input, $0.30/M per l’input in cache, $15/M per l’output). Abbiamo aggiunto salt ai prompt ripetuti per evitare le cache a livello di risposta; i conteggi di accuratezza usano task con un’unica risposta verificabile; i comportamenti sono stati riprodotti tramite un secondo percorso di richiesta indipendente. Prezzi e comportamento potrebbero cambiare con la maturazione del rilascio; prima di basarsi sui dati riportati, è necessario verificarli nei propri record usage.

← Torna al blog