Le tabelle comparative dei modelli di intelligenza artificiale descrivono capacità, velocità, contesto massimo e prezzo per milione di token. Questi dati sono utili, ma non mostrano sempre quanti passaggi servano a un agente per completare un'attività reale.
Il 25 luglio 2026 abbiamo esaminato i registri locali prodotti da Kimi Code CLI 0.29.1. I dati mostrano un rapido accumulo di token registrati e permettono di distinguere input normale, input recuperato dalla cache e output.
Dossier in breve
- Il caso reale: Monitoraggio dei log locali di Kimi Code CLI durante lo sviluppo reale del 25 luglio 2026.
- I dati registrati: 1.449.154 token e 30 chiamate interne in circa 9 minuti.
- La distinzione necessaria: Token registrati, costo fatturato e quota sottratta non sono la stessa cosa. La cache e il tipo di servizio cambiano il calcolo.
- La lezione chiave: Il prezzo nominale per milione di token non basta a descrivere il costo di un agente che esegue più chiamate per completare un'attività.
L'esplosione dei token negli agenti autonomi
Il primo divario tra teoria e pratica risiede nel modo in cui gli agenti di programmazione dialogano con il server. In un test standard, il modello risponde a una domanda isolata. Nel lavoro di sviluppo:
- L'agente legge i file dal computer locale per analizzare il contesto.
- Le chiamate successive includono istruzioni, cronologia, risultati degli strumenti e parti dei file già letti.
- Il contesto già elaborato può essere recuperato dalla cache: costa meno dell'input nuovo, ma compare comunque nel consumo registrato.
Dettaglio dei token registrati
Tra le 22:38 e le 22:47 del 25 luglio, una singola sessione con Kimi K3 ha registrato: 64.311 token di input normale, 1.372.416 recuperati dalla cache e 12.427 di output.
La sessione conteneva 11 richieste dell'utente: in media 2,7 chiamate interne per ogni richiesta visibile. Nell'insieme delle sessioni locali esaminate risultano 3.516.457 token registrati.
Questi valori provengono dai registri locali. Non corrispondono automaticamente al costo fatturato o alla quota sottratta, che dipendono dal servizio e dal trattamento della cache.
Il peso del ragionamento obbligatorio
Kimi K3 permette di scegliere lo sforzo di ragionamento tra basso, alto e massimo. Per usare Kimi K2.7 Code è invece necessario mantenere attiva la modalità Thinking. Nelle prove locali, una richiesta con un'impostazione non compatibile è stata rifiutata dall'API con l'errore:
invalid thinking: only type=enabled is allowed for this model
La scelta del modello, del livello di ragionamento e della finestra di contesto può cambiare il consumo. La documentazione di Kimi indica che K3 con contesto da un milione di token usa circa il doppio della quota rispetto alla versione K3 da 256.000 token. Il calcolo varia tra provider e servizi, quindi va misurato sullo stesso compito.
Saturazione e blocchi: il paradosso del pagamento
Kimi Code e Kimi Platform non usano lo stesso sistema commerciale. Kimi Code applica quote su finestre di cinque ore, settimanali e mensili legate all'abbonamento. Kimi Platform fattura invece le API in base all'uso e applica limiti separati.
L'abbonamento mantiene le proprie quote periodiche. Kimi Code offre anche Extra Usage: se viene attivato, al termine della quota disponibile le richieste possono continuare usando un saldo separato, con un limite di spesa configurabile. La convenienza non può quindi essere valutata soltanto confrontando il prezzo nominale per milione di token.
Il problema osservato non è la sola tariffa del modello, ma la difficoltà di prevedere quante chiamate e quanti token serviranno per completare un'attività con un agente. Per confrontare strumenti diversi servono quindi sessioni reali, contatori distinti e lo stesso incarico di partenza.
Cosa fare con questa informazione
- Misurare sessioni reali: contare separatamente input, output, cache e chiamate per uno stesso tipo di attività.
- Ridurre il contesto: inviare soltanto i file e le parti di codice necessari.
- Scegliere il modello in base al compito: un livello di ragionamento inferiore può ridurre il consumo, ma va verificato mantenendo invariato l'incarico.
- Controllare il ragionamento: dove il modello lo consente, usare il livello minimo che produce un risultato corretto.
- Confrontare condizioni uguali: usare gli stessi file, lo stesso obiettivo e gli stessi criteri di verifica.