Anthropic ha pubblicato una serie di indicazioni per ridurre i costi operativi delle applicazioni basate sulle API Claude senza compromettere le prestazioni, concentrandosi sull’eliminazione delle elaborazioni che non contribuiscono effettivamente al completamento del compito. L’approccio proposto non consiste semplicemente nello scegliere un modello meno costoso o nell’accorciare indiscriminatamente i prompt, ma nel misurare quante risorse vengono impiegate per portare a termine correttamente una determinata attività. Le principali aree di intervento sono tre: prompt caching per evitare di elaborare ripetutamente gli stessi contenuti, revisione delle istruzioni per eliminare ragionamenti e chiamate agli strumenti non più necessari e regolazione dell’Effort Level per controllare quanta elaborazione il modello deve dedicare alla risposta.
Il prompt caching è indicato come uno degli interventi più diretti per ridurre sia i costi sia i tempi di risposta nelle applicazioni che inviano ripetutamente a Claude grandi porzioni di contenuto identico. Prima di generare una risposta, il modello deve infatti elaborare elementi come system prompt, definizioni degli strumenti, documenti e cronologia della conversazione trasformandoli nella propria rappresentazione interna. Quando queste informazioni rimangono invariate tra richieste successive, il sistema può conservare e riutilizzare la cache key-value già calcolata anziché ripetere l’intero processo. Per ottenere un buon tasso di cache hit è però necessario mantenere stabile soprattutto la parte iniziale del prompt: inserire all’inizio informazioni dinamiche come timestamp o identificativi delle richieste, modificare l’ordine delle definizioni degli strumenti oppure cambiare modello può impedire il riutilizzo della cache. Anthropic suggerisce quindi di collocare nella parte iniziale le istruzioni di sistema e le definizioni degli strumenti più stabili e di caricare gli strumenti utilizzati raramente soltanto quando risultano effettivamente necessari.
Un secondo elemento riguarda quella che Anthropic definisce “instruction debt”, cioè il progressivo accumulo di istruzioni introdotte per compensare limiti o comportamenti dei modelli utilizzati in precedenza. Durante lo sviluppo di un’applicazione possono essere aggiunte indicazioni come eseguire una doppia verifica, seguire particolari procedure di ragionamento, produrre spiegazioni molto dettagliate o utilizzare determinati strumenti in circostanze specifiche. Quando l’applicazione viene successivamente aggiornata con un modello più avanzato, queste istruzioni possono diventare superflue e continuare a generare token di ragionamento, chiamate agli strumenti e passaggi aggiuntivi. Tra i possibili problemi vengono citate procedure di verifica ripetitive, richieste eccessive di dettaglio, scratchpad o percorsi di ragionamento rigidamente prescritti, esempi progettati per modelli precedenti e regole entrate nel tempo in conflitto tra loro.
Anthropic ha verificato questo approccio introducendo sei di questi anti-pattern in un prompt destinato all’assistenza clienti e utilizzando successivamente il comando /claude-api prompt-audit di Claude Code per individuarli e rimuoverli. Nel test, la revisione delle istruzioni ha prodotto una riduzione media dei costi del 14,6% accompagnata da un miglioramento dell’accuratezza del 5,3%. Il risultato è stato attribuito soprattutto alla diminuzione dei ragionamenti e delle chiamate agli strumenti non necessari e alla rimozione di configurazioni non più adeguate ai modelli recenti. Anthropic precisa tuttavia che questi valori derivano da uno specifico ambiente di test e non devono essere considerati automaticamente riproducibili in qualsiasi applicazione: le modifiche ai prompt devono quindi essere valutate utilizzando set di test rappresentativi delle attività reali del servizio.
La terza leva riguarda l’Effort Level, che determina quanta elaborazione Claude dedica al problema prima di produrre la risposta finale. Un livello elevato permette al modello di effettuare più verifiche, esplorare maggiormente il problema e approfondire il ragionamento, ma comporta anche un aumento dei token utilizzati, della latenza e del costo complessivo. Un livello troppo basso può invece ridurre le spese a scapito dell’affidabilità, portando il modello a omettere verifiche importanti o a rispondere prima di aver raccolto informazioni sufficienti. Nei test presentati da Anthropic, il passaggio dal livello low al livello max ha aumentato il tasso di risposte corrette di 19,4 punti percentuali, ma contemporaneamente ha portato il costo per attività a circa 3,5 volte quello iniziale.
La relazione tra modello ed effort non è inoltre necessariamente lineare. In alcuni casi Anthropic ha rilevato che utilizzare un modello più avanzato con un livello di effort basso può offrire un rapporto tra costo e prestazioni migliore rispetto all’impiego di un modello inferiore configurato con un effort elevato. Modello ed effort devono quindi essere valutati congiuntamente sulla base del tipo di attività, anziché essere ottimizzati separatamente, confrontando il costo effettivo necessario per ottenere una risposta corretta.
Anthropic ha aggiunto a Claude Code anche i comandi /claude-api hillclimb e /claude-api cost-optimize per supportare questo processo. Hillclimb confronta differenti combinazioni di modello ed Effort Level per individuare configurazioni più efficienti, mentre cost-optimize analizza diversi elementi che incidono sulla spesa, tra cui caching, limiti dell’output, elaborazione batch e struttura dei prompt, indicando quali interventi di ottimizzazione conviene affrontare per primi.
La metrica proposta per valutare l’efficienza di un’applicazione AI è quindi il “cost per successful task”, cioè il costo necessario per completare correttamente un’attività, anziché il semplice prezzo per token. La valutazione deve comprendere non soltanto i token di input e output, ma anche quelli utilizzati durante il ragionamento, le chiamate agli strumenti, la latenza, gli errori, gli eventuali tentativi ripetuti e soprattutto la percentuale di attività concluse con successo. Una configurazione che consuma meno token per singola richiesta può infatti risultare più costosa nel complesso se produce più errori o richiede ulteriori chiamate per completare correttamente il lavoro.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)