# Quando il prompt caching riduce davvero i costi di un coding agent? > Il prompt caching riduce i costi quando molte richieste riutilizzano un prefisso grande e stabile a livello di byte e il risparmio delle letture supera complessità e mancati hit. Misura l’input in cache dai dati reali invece di presumere uno sconto per ogni istruzione ripetuta. Il prompt caching è utile quando l’agente invia ripetutamente lo stesso grande inizio, non solo quando i prompt sembrano simili. Un timestamp, un elenco strumenti riordinato, un riepilogo variabile o un ID generato vicino all’inizio può eliminare il riuso di tutto ciò che segue. Prima di ridisegnare i prompt, esamina i metadati reali. Determina quanti token sono idonei, quanti vengono segnalati come letture, quanto spesso cambia il prefisso e se modello e protocollo offrono un vantaggio. ## Modella la base senza cache Parti dal costo dell’input, perché la cache non riduce output o esecuzione degli strumenti. ```text uncached_input_cost = requests * input_tokens_per_request * input_rate ``` Mantieni tariffe in unità coerenti, in genere per milione di token. Non usare uno sconto ricordato: consulta prezzo corrente e campi di utilizzo del modello esatto. | Componente | Stabile tra richieste? | Posizione probabile | |---|---|---| | Politica di sistema | Di solito | Prima | | Schemi degli strumenti | Di solito | All’inizio | | Convenzioni del repository | Spesso | All’inizio | | Checkpoint attività | A volte | Al centro | | Richiesta utente | Raramente | Verso la fine | | Output degli strumenti | No | Ultimo | ## Calcola il pareggio con simboli Sia `P` il numero di token del prefisso, `R` le richieste, `W` la tariffa di scrittura, `H` quella di lettura e `U` la tariffa normale: ```text uncached = R * P * U cached = P * W + (R - 1) * P * H savings = uncached - cached ``` Questo caso ideale presume hit dopo la prima richiesta. Per una frazione misurata `h`, sostituisci il termine successivo con una combinazione ponderata di `H` e `U`. Aggiungi i token fuori prefisso alla tariffa normale su entrambi i lati. La cache conviene solo se il risparmio resta positivo dopo mancati hit e lavoro tecnico. ## Metti prima il contenuto stabile Ordina dal più stabile al più volatile: * Istruzioni di sistema e sicurezza. * Definizioni in ordine deterministico. * Convenzioni e riferimenti duraturi. * Checkpoint compatto. * Richiesta corrente. * Ultimo output dello strumento. Serializza gli schemi in modo deterministico. Evita ordine casuale, modifiche di spazi, timestamp e commenti specifici. Versiona i blocchi stabili affinché un vero cambiamento generi un mancato hit spiegabile. ## Mantieni il prefisso utile, non solo grande Un prefisso gonfio può aumentare le letture, ma anche i token e la distrazione. Rimuovi strumenti obsoleti, politiche duplicate e riferimenti irrilevanti. Misura il costo per risultato accettato, non solo la percentuale di hit. Un prompt breve senza cache che risolve in meno turni può superare uno lungo e rumoroso. ## Strumenta richieste e risultati Registra modello, protocollo, versione del prefisso, token totali, token in cache se disponibili, output, latenza, chiamate, tentativi e risultato. Indica i campi assenti come non disponibili, non come zero. | Metrica | Perché conta | |---|---| | Quota in cache | Conferma il riuso reale | | Motivo del mancato hit | Individua cambiamenti accidentali | | Richieste per attività | Rivela loop che annullano il risparmio | | Costo per modifica accettata | Collega token e lavoro utile | | Tasso di tentativi | Mostra costi di affidabilità esterni | Una settimana di attività rappresentative vale più di cento ripetizioni di un prompt sintetico. ## Controlla routing e confini di sessione Il comportamento può dipendere da modello, provider, regione, finestra di conservazione e routing. Gateway o fallback possono inviare la richiesta a una rotta senza lo stesso prefisso caldo. Tratta le prestazioni come proprietà osservata della rotta scelta. Atlas Cloud offre più formati LLM tramite una API, ma la guida pubblica non promette uno sconto universale. Controlla modello e console prima di affermare risparmi. Usa i [protocolli LLM](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) per il formato e il [catalogo](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) per i modelli correnti. ## Evita falsi risparmi Un input più economico può nascondere turni extra, strumenti falliti o ricostruzioni ripetute. Distingui inoltre la lettura della cache dallo storage o retrieval applicativo: risolvono problemi diversi. Non includere segreti solo perché il contenuto può essere memorizzato. Segui i controlli sui dati e sulla conservazione; la cache non sostituisce il controllo accessi. ## Usa una porta pratica di adozione Adotta quando: * Il prefisso stabile è utile e riutilizzato spesso. * L’utilizzo reale segnala letture dalla cache. * Il risparmio sopravvive al tasso di mancati hit. * Il versionamento è semplice e deterministico. * Qualità e numero di turni non peggiorano. Altrimenti riduci il prompt, recupera solo file rilevanti e accorcia il loop. ## Conclusione Il prompt caching riduce i costi quando un prefisso grande, utile e stabile viene riutilizzato abbastanza su una rotta che addebita meno l’input memorizzato. Metti prima il contenuto stabile, calcola il pareggio con le tariffe attuali, misura attività reali e costo per modifica accettata. Un alto tasso di hit non aiuta se il prompt è troppo grande o richiede più turni. ## FAQ ### Quali contenuti sono più adatti al prompt caching? Istruzioni di sistema stabili, schemi degli strumenti, convenzioni del repository e riferimenti che cambiano raramente sono migliori di log live o dell’ultimo messaggio utente. ### Perché il contenuto variabile deve seguire il prefisso stabile? Le cache di prefisso richiedono in genere un inizio identico. Timestamp, ID o contesto variabile vicino all’inizio possono invalidare tutto il contenuto stabile successivo. ### Il prompt caching riduce sempre la latenza? No. L’effetto dipende da implementazione, stato della cache, routing, modello, dimensione e carico. Misura la latenza separatamente dal costo. ### Come calcolo il punto di pareggio? Confronta il costo dell’input normale con scrittura e lettura della cache per il riuso previsto, includendo costo tecnico e tasso di mancato hit. ### Le definizioni degli strumenti possono essere memorizzate? Possono far parte di un prefisso ripetuto se provider e protocollo le includono. Verifica i metadati di utilizzo invece di presumerlo. ### Devo mettere in cache l’intera conversazione di codice? Di solito no. Cambia a ogni turno. Metti prima istruzioni e schemi stabili, poi un checkpoint compatto e la richiesta corrente.