Caching del prompt di Kimi K3

È automatico, e a freddo è sempre freddo

Non c'è niente da attivare. La cache si aggancia al prefisso ripetuto — la parte iniziale della richiesta che torna identica — e lo vedi nel campo usage.prompt_tokens_details.cached_tokens.

Abbiamo generato prefissi mai inviati prima a Moonshot — contenuto randomizzato sul momento, così una chiamata a freddo è davvero fredda — e li abbiamo inviati due volte ciascuno:

// prima chiamata, prefisso nuovo da 12,504 token
"usage": {
  "prompt_tokens": 12504,
  "completion_tokens": 32
  // nessun campo cached_tokens
}

// seconda chiamata, prefisso identico byte per byte, ~2s dopo
"usage": {
  "prompt_tokens": 12504,
  "completion_tokens": 32,
  "prompt_tokens_details": {"cached_tokens": 12288}   // 96 blocchi da 256
}

Su tutti i prefissi testati, da 1.3k a 29k token, la chiamata a freddo ha messo in cache esattamente zero. Al primo contatto non esiste credito parziale. Lo sconto arriva solo dalla seconda richiesta in poi — quindi un carico che non ripete mai un prefisso non ne trae alcun beneficio, per quanto grandi siano i suoi prompt.

Il blocco è da 256 token

Gli hit della cache non vengono concessi token per token. In nove test cached_tokens è tornato ogni singola volta come multiplo esatto di 256, lasciando fuori dalla cache un resto fino a 255 token:

La coda fuori cache non arriva mai a un blocco intero

Token lasciati fuori dalla cache per ogni prefisso caldo · nove prefissi, 1.3k–29k · misurato 2026-07-16

Conseguenza pratica: la cache rende in proporzione alla dimensione del prefisso. Un prefisso da 300 token ha al massimo un blocco cacheabile e fino a 255 token di coda non cacheabile — quasi tutto il prompt, a prezzo pieno. Un prefisso da 50k ha quasi 200 blocchi e la coda diventa un errore di arrotondamento. Non vale la pena progettare per gli hit della cache sui prompt piccoli.

Un'avvertenza dai dati grezzi del 2026-07-16: due prompt minuscoli ripetuti sono finiti in cache per intero — prompt_tokens 90 ha restituito cached_tokens 90, e 86 ha restituito 86. Quindi un prompt da ~90 token ripetuto parola per parola può andare in cache tutto; il conteggio a blocchi da 256 descritto sopra è quello che abbiamo misurato su prefissi da 1k a 70k. Granularità a blocchi da 256 riconfermata il 2026-07-18 via EvoLink (hit da 1,024/4,352/17,408/70,400).

prompt_cache_key non ha fatto nulla di misurabile

La documentazione API di Moonshot (letta il 2026-07-20) elenca un parametro prompt_cache_key, descritto come caching legato alla sessione e «consigliato» per le conversazioni multi-turno. Sembra la leva da tirare. Non lo è — almeno non per il riuso del prefisso.

Abbiamo fatto un test pulito: un prefisso nuovo di zecca, prima chiamata già con un prompt_cache_key esplicito, poi una seconda chiamata identica. Il risultato è indistinguibile dal caso senza key:

Stesso miss sulla chiamata a freddo, stesso hit su quella a caldo. Il caching automatico del prefisso aveva già fatto il lavoro. Per i carichi con prefisso ripetuto questo parametro non serve — e se l'hai aggiunto aspettandoti uno sconto, lo sconto non è arrivato da lì.

Fa risparmiare soldi, non tempo

Questo ci ha sorpreso. L'intuizione è che un hit della cache salti del lavoro, quindi dovrebbe essere più veloce. Confrontando chiamate a freddo e a caldo sullo stesso prefisso, il tempo a cronometro non è migliorato in modo consistente:

A queste dimensioni la varianza tra un'esecuzione e l'altra copre qualsiasi effetto della cache — e ricorda che K3 passa comunque secondi a ragionare a ogni chiamata, ed è quello a dominare i tempi. Tratta il caching del prompt come un'ottimizzazione di costo, non di latenza. Se ti serve velocità, guarda cosa abbiamo misurato sulla latenza.

Tutto questo regge anche passando dai gateway

Tutta la meccanica descritta in questa pagina è stata misurata su api.moonshot.ai il 2026-07-16. Due giorni dopo abbiamo rieseguito il protocollo principale attraverso EvoLink (direct.evolink.ai) su quattro nuove dimensioni di prefisso — e attraverso OpenRouter su una — per verificare che nel passaggio non si perda nulla:

Ogni risultato ha retto: le chiamate a freddo hanno messo in cache zero, gli hit a caldo sono arrivati in blocchi esatti da 256 token con la coda fuori cache, e si è ripetuto anche l'esito «soldi sì, tempo no» (una dimensione più veloce, tre no). L'unico test su OpenRouter ha dato un hit identico — 4,352 token in cache su un prefisso da 4,501 — con le ricevute in usage.cost a confermare in dollari la differenza di fatturazione di 10×. Il confronto tra gateway riporta quei numeri. Una particolarità da conoscere in ogni caso: su un miss la risposta omette del tutto prompt_tokens_details — il codice che dà per scontata la presenza del campo si rompe alla prima chiamata.

Per quanto tempo un prefisso resta caldo

Un prefisso scaldato restituiva ancora gli stessi 12,032 token in cache dopo 210 secondi, senza degrado sulle sonde a 30s, 90s e 210s.

È un pavimento, non il TTL: lì abbiamo smesso di sondare. Moonshot non documenta né il TTL, né una lunghezza minima del prefisso, né se la scrittura in cache abbia un sovrapprezzo, quindi non inventiamo numeri. Quello che possiamo dire: un prefisso riusato nel giro di pochi minuti resta caldo, e questo copre il caso che conta di più, il ciclo di un agente.

Come restare nella riga economica

• Metti davanti i byte stabili. System prompt, definizioni dei tool e documenti lunghi all'inizio; il turno variabile dell'utente alla fine. La cache confronta un prefisso: una modifica all'inizio invalida tutto quello che viene dopo.
• Tieni le variazioni fuori dal prefisso. Un timestamp, un ID di richiesta, un JSON riserializzato con le chiavi in ordine diverso: ognuno di questi cambia i byte e ti riporta in silenzio a $3.00 per 1M. È il modo più comune in cui i team perdono lo sconto senza accorgersene.
• Raggruppa le richieste su un solo prefisso. Venti domande sullo stesso documento vogliono un prefisso caldo e venti code corte.
• Non progettare la cache per i prompt piccoli. Sotto i ~256 token non c'è niente da mettere in cache; sotto ~1k la coda è quasi tutta la bolletta.
• Accetta la chiamata a freddo. La prima richiesta di ogni periodo freddo si paga a prezzo pieno. Mettila a budget invece di provare a progettarla via.
• Tieni d'occhio cached_tokens in produzione. È l'unico modo per sapere se il tasso di hit è davvero quello che credi. Se il campo manca, era un miss.

Quanto vale la differenza

Un agente con un prefisso fisso da 50,000 token che serve 200 richieste al giorno — 10M di token di input ogni giorno:

Conti sulle tariffe ufficiali del 2026-07-20, solo input. La riga economica è idealizzata: le chiamate a freddo si pagano a prezzo pieno e la coda non va mai in cache. L'output si paga comunque $15.00/1M, e i token di ragionamento su questo carico possono superare l'intera bolletta di input. Sono un tetto e un pavimento, non un preventivo.

FAQ sul caching del prompt

Come funziona il caching del prompt su Kimi K3?

In automatico, su un prefisso ripetuto, senza bisogno di parametri. Invia di nuovo un prefisso identico byte per byte e la parte ripetuta viene fatturata a $0.30 per 1M invece di $3.00. Abbiamo misurato hit concessi in multipli esatti di 256 token, con la coda restante mai messa in cache.

Serve prompt_cache_key per ottenere il prezzo scontato di Kimi K3?

No. Abbiamo testato un prefisso nuovo con e senza un prompt_cache_key esplicito e i conteggi dei token in cache sono risultati identici: zero sulla chiamata a freddo, 9,984 su quella a caldo in entrambi i casi. Il caching automatico del prefisso fa già il lavoro.

Il caching del prompt rende Kimi K3 più veloce?

Non in modo misurabile. Confrontando chiamate a freddo e a caldo sullo stesso prefisso, il tempo a cronometro non è migliorato in modo consistente su cinque dimensioni di prefisso: alcune chiamate a caldo sono state più lente delle corrispondenti a freddo. Tratta il caching del prompt come un'ottimizzazione di costo, non di latenza.

Quanto dura la cache del prompt di Kimi K3?

Almeno 210 secondi. Un prefisso scaldato ha restituito gli stessi 12,032 token in cache senza degrado sulle sonde a 30, 90 e 210 secondi. Moonshot non documenta alcun TTL, quindi questo è un pavimento misurato, non il limite reale.