Ho bruciato circa 400€ di crediti Claude in tre settimane prima di accorgermi di una cosa stupida. Il system prompt che riusavo su 90 chiamate al giorno non era cacheable. Una virgola fuori posto rompeva l'impronta della cache, e ogni chiamata pagava il prezzo pieno dei token.
Quella sola correzione ha tagliato del 78% il costo di quel workload. Nessuno dei tool a pagamento che avevo provato lo avrebbe trovato. Non PromptPerfect. Non AI Test Kitchen. Non l'optimizer di Vellum. Riscrivono tutti il testo del prompt. La cosa che mi svuotava il portafoglio era l'architettura intorno al prompt.
Questo articolo è il playbook consolidato: 5 trucchi gratis che ora applico a ogni nuovo prompt che metto in produzione, in ordine di effort. Combinati, su un workload tipico da solo dev, tagliano dal 60 al 75% della spesa. Testati su 47 dei miei prompt nelle ultime due settimane, scorati prima e dopo su Keep My Prompts (KMP), con il delta reale per ogni trucco.
Se sei un indie hacker o lavori in un team da 1 a 5 persone, questo è calibrato per te. Se sei un CTO con 50 ingegneri e un contratto procurement, non è il tuo articolo.
Perché il problema dei costi è peggiorato nel 2026
Tre cose sono successe nel Q2 2026 che rendono questo il momento giusto per ottimizzare in modo aggressivo.
Primo, Anthropic ha tagliato in silenzio il TTL della cache di Claude da 60 minuti a 5 minuti di default a marzo. Se contavi su finestre di cache lunghe senza aver fatto audit della frequenza delle chiamate, la spesa è salita del 17-30% senza che tu abbia toccato nulla.
Terzo, il mercato dei SaaS di prompt optimization continua a gonfiare i prezzi degli abbonamenti mentre il gap di valore reale si chiude. Un tool da 30€ al mese che promette di "riscriverti i prompt" era già debole nel 2024. Nel 2026, con KMP scoring disponibile gratis a 5 esecuzioni al giorno, per uso indie il valore è sparito.
L'opportunità è reale, ma non sta dove i tool a pagamento vogliono farti guardare. Lo spreco è strutturale. Cache miss, esempi few-shot ridondanti, parse failure che generano retry, modelli premium che girano su task banali. Le riscritture lessicali non risolvono nessuna di queste cose.
Per dare la misura del problema: su KMP, sui 39 prompt che i primi utenti hanno scorato, il punteggio overall medio è 3.60 su 5. La mediana è 3.50. Anche il 75° percentile sta a 4.40. Il prompt "top quartile" nel campo ha comunque problemi strutturali documentabili. Lo spreco non è un'eccezione rara. È il default.
Trucco 1: Scora il prompt, non riscriverlo
L'errore comune, e quello che gli optimizer a pagamento incoraggiano, è chiedere a un LLM "riscrivi il mio prompt meglio". Spendi 10 token di input, ti torna indietro 1500 token di output, ripeti tre o quattro volte finché qualcosa "suona meglio", e spedisci. Costo totale per ciclo di ottimizzazione: 4500-6000 token di output. Informazione utile ottenuta: di solito niente di strutturale.
La mossa cheap e corretta è scorare il prompt prima. Uno scorer ti dice perché il prompt è debole: contesto debole, formato di output mancante, ruolo ambiguo, niente few-shot, niente scaffolding di chain-of-thought. Con quella diagnostica, fai una sola modifica mirata e spedisci. Costo totale in token: circa 600 token per la chiamata di scoring, zero per la modifica (la fai tu nel tuo editor).
Vuoi sapere quanto sono efficaci i tuoi prompt? Prompt Score li analizza su 6 criteri.
Sui 47 prompt che ho scorato la scorsa settimana, la modifica mirata dopo lo scoring ha pareggiato o battuto la riscrittura blind in 39 casi, cioè l'83%. Gli 8 casi in cui la riscrittura blind era equivalente erano tutti prompt che strutturalmente erano già a posto e avevano solo bisogno di un aggiustamento di tono. Per qualsiasi cosa con un vero problema strutturale, lo scoring vince.
Il piano Free di KMP ti dà 5 Quick Optimize al giorno, e basta per una sessione di refactoring focalizzata. Lo scoring è il diagnostico, non l'ottimizzazione. Trattalo come un profiler: leggi l'output, sistemi una cosa, vai avanti.
Trucco 2: Ri-estrai il tuo system prompt
Questo è il trucco che mi ha restituito i 400€ del primo paragrafo.
L'anatomia dello spreco: avevo un preambolo da 200 token che iniziava con "You are a helpful assistant that responds in JSON…" e veniva preposto al messaggio user a ogni singola chiamata. 90 chiamate al giorno. Il role boundary diceva user, non system. L'impronta della cache non corrispondeva mai. Stavo pagando 200 token di costo in input fuori cache a ogni chiamata, 18.000 token al giorno, quando avrei dovuto pagarli una volta all'ora al massimo.
Il fix è meccanico. Sposta il preambolo nel ruolo system. Aggiungi cache_control: {"type": "ephemeral"} al blocco system su Anthropic, o usa la primitiva di caching equivalente su OpenAI (il prompt prefix caching scatta in automatico sopra i 1024 token). Il cache hit rate al primo deploy è passato dallo 0% al 92%. Quel 92% stabile ha portato il costo del workload da 130€ a settimana a 28€ a settimana.
Un avvertimento, e si lega al cambio di TTL della cache: il nuovo default di 5 minuti significa che devi anche pensare alla frequenza delle chiamate. Se il tuo traffico è a burst, con buchi tra una raffica e l'altra, la cache scade prima del burst successivo e non vedi alcun beneficio. La soluzione è aggiungere una chiamata heartbeat ogni 4 minuti durante i periodi attivi, oppure attivare il flag TTL a 1 ora dove disponibile. L'articolo sul cache TTL descrive il pattern heartbeat nel dettaglio.
Questo trucco da solo sposta il 60-80% della spesa su qualunque workload con un system prompt stabile e oltre 30 chiamate l'ora. Non c'è tool a pagamento che te lo individui. Guardano il testo del prompt, non il role boundary.
Trucco 3: Few-shot pruning A/B
Ecco un fatto che dovrebbe sorprenderti. Su KMP, il criterio col punteggio più basso sui 39 prompt scorati è few-shot, con una media di 1.63 su 5. Di gran lunga il criterio peggiore. Il secondo peggiore è chain-of-thought a 2.83. Few-shot sta in un'altra categoria.
Scatter plot di 12 prompt few-shot scorati a N=3 vs N=1: 7 su 12 cadono nella banda di rumore, 4 mantengono un calo significativo, 1 ha scorato più alto con meno esempi
Il fenomeno si rompe in due direzioni, e tutte e due costano soldi.
Direzione uno: la maggior parte dei prompt non ha esempi few-shot quando ne trarrebbe beneficio. Due o tre esempi concreti possono sostituire un paragrafo di istruzioni astratte, e il costo in token di solito è più basso. Se il tuo prompt fallisce sulla coerenza, qui c'è la tua correzione.
Direzione due, ed è lo spreco di costo: quando gli sviluppatori usano few-shot, spesso ne accumulano cinque, sei, otto esempi. Il valore marginale dell'esempio dal numero 4 in poi è vicino a zero per la maggior parte dei task non di classificazione. Stai pagando il prezzo pieno in token a ogni chiamata per esempi che non cambiano l'output.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
Il test ti prende dieci minuti. Prendi un prompt con N=3 o più esempi few-shot. Scoralo su KMP. Scendi a N=1 (solo l'esempio più forte). Scora di nuovo. Se il delta sul punteggio overall è sotto il 5%, puoi spedire la versione a N=1 e risparmiare il 30-50% di token di input per chiamata.
L'ho fatto su 12 dei miei prompt few-shot. Il delta medio di punteggio da N=3 a N=1 è stato 0,18 punti su una scala da 5. Su 7 dei 12, il delta era sotto 0,10 e statisticamente irrilevante. Quei 7 prompt ora girano con un'impronta di token più piccola, senza una perdita di qualità osservabile.
Quando non pruning: task di classificazione strict dove gli esempi stabiliscono il confine delle label, e task di structured output dove gli esempi mostrano lo schema. Per tutto il resto, pruning aggressivo.
Trucco 4: I contratti di output uccidono i retry loop
Se il tuo prompt restituisce testo free-form e il tuo codice a valle prova a fare parse, sei in un retry loop che forse non stai nemmeno misurando.
Sul mio classificatore di customer support, prima dei contratti di output, il retry rate era 22%. Due chiamate su dieci tornavano con JSON malformato, il parse falliva, il codice ritentava, e il retry a volte funzionava. Quel 22% era spreco puro: ogni retry era una seconda chiamata piena al prezzo pieno dei token.
La correzione è lo structured output. OpenAI espone response_format: {type: "json_schema", json_schema: ...} da GPT-5.4. Anthropic lo fa attraverso il tool use con una forced tool choice. Mistral ha una JSON mode. Scegli la primitiva nativa del tuo provider e definisci lo schema esatto che vuoi.
Dopo aver messo in produzione lo structured output sullo stesso workload, il retry rate è sceso al 3%, e quel 3% era causato da ambiguità genuine nell'input (non dal modello che falliva lo schema). Risparmio netto di token sul workload: 38%, perché ogni retry era una chiamata intera.
Una nota di attenzione. Lo structured output aggiunge un 5-10% di overhead di latenza sulla chiamata vincolata. Se sei su un prompt one-shot interattivo dove la latenza conta e il parse failure è benigno, non vale. Se sei in un loop, si ripaga nella prima ora.
Trucco 5: Triage dei modelli cheap
Il principio: grosso modo il 70% delle tue chiamate è extraction, classification, summarization, o paraphrase semplice. Niente di tutto questo ha bisogno di Opus o GPT-5.4. Haiku 4.5 e Mistral Small 4 fanno il lavoro a un quindicesimo del costo. DeepSeek V4-Pro lo fa a un quarantesimo.
Decision matrix che mappa 8 tipi di task comuni al tier di modello consigliato, con moltiplicatore di costo rispetto al baseline Opus che va da 1x a 20x più cheap
Il pattern che paga in modo consistente è il triage a due livelli. Primo passaggio con un modello cheap. Cattura il segnale di confidenza (un punteggio emesso dal modello, una soglia sulla logprob dell'output, o un validatore a valle). Se la confidenza è alta, spedisci la risposta cheap. Se la confidenza è bassa, fai escalation a un modello premium solo per quel caso.
L'ho fatto sul classificatore di customer support citato prima. Prima del triage, ogni chiamata andava a Opus. Costo per 1000 messaggi: 4,80€. Dopo il triage, Haiku gestiva il 91% dei messaggi, Opus il 9%. Costo per 1000 messaggi: 0,61€. La qualità del classificatore, misurata sullo stesso test set etichettato, è scesa di 0,4 punti percentuali. Trade accettabile per un taglio costi dell'87%.
Il pattern a due livelli funziona solo se riesci a rilevare la confidenza bassa. Il modo più cheap è chiedere al modello cheap di emettere anche un punteggio di confidenza nello structured output (il trucco 4 si abbina in modo naturale qui). I modelli non sono perfetti nell'auto-valutarsi, ma sono abbastanza affidabili da rendere quel 9% di escalation un segnale utilizzabile.
Confronto costi su un classificatore di customer support reale: 4,80 euro per 1000 messaggi con solo Opus 4.7, scende a 0,61 euro per 1000 dopo che il triage ruta il 91 percento delle chiamate ad Haiku 4.5 e fa salire solo il 9 percento a Opus
Lo stack combinato dei risparmi
I cinque trucchi non si sommano in modo additivo. Condividono lo spreco. Il trucco 2 (caching) e il trucco 5 (triage dei modelli cheap) riducono entrambi la stessa fattura, e una volta applicato uno l'altro ha meno carne da mordere.
In pratica, su tre dei miei workload in produzione, il risparmio combinato realistico si è collocato in questa fascia:
Stack applicato
Riduzione spesa totale
Solo trucco 2
60-80%
Trucco 2 + 4
65-85%
Trucco 2 + 4 + 5
75-90%
Tutti e cinque
78-92%
Il valore marginale dei trucchi 1 e 3 sta nella qualità del prompt, non nella dimensione della spesa. Servono ad assicurarti di non pagare per token che non producono niente.
Se hai un'ora da spendere sul taglio costi, fai il trucco 2. Se hai una giornata, fai i trucchi 2 + 4 + 5.
Perché i tool a pagamento non aiutano qui
I tool di prompt optimization a pagamento ottimizzano la superficie lessicale del prompt. Riscrivono "Please respond in JSON" in "Respond in valid JSON format" e lo chiamano risparmio. Il risparmio non esiste. La spesa non è guidata dalla scelta delle parole.
La spesa è guidata da dove vive il prompt (role boundary, regione di cache), quando viene mandato (frequenza, TTL), quanto spesso l'output non riesce a fare parse (retry loop), e quale modello lo esegue (triage). Nessuno di questi quattro è visibile a un optimizer a pagamento che vede solo il testo del prompt.
Verdetto, secco: paga per un tool di prompt optimization solo se gestisci più di 500 prompt distinti in un team e ti serve l'automazione di workflow. Per il lavoro da solo dev e small team, KMP Free per lo scoring più un'ora metodica di refactoring intorno ai 5 trucchi qui sopra batte qualunque abbonamento di qualunque tier.
Da dove partire
Scegli il tuo workload con il volume più alto. Scora il prompt su KMP. Apri la trace e controlla i role boundary. Se il tuo system prompt sta nel ruolo user, hai trovato il tuo trucco 2. Se hai più di tre esempi few-shot, hai trovato il tuo trucco 3. Se non stai usando structured output, hai trovato il tuo trucco 4. Se tutto passa da Opus, hai trovato il tuo trucco 5.
Probabilmente almeno tre dei cinque ti stanno aspettando sul primo workload. Parti da quello più cheap da implementare, non da quello con il risparmio più grande atteso: il momentum conta più dell'ottimizzazione al primo giro.
Lo scoring è gratis. Il refactoring è tuo. I 400€ che ho bruciato per imparare il trucco 2 sono la retta di questo articolo.
