Il costo di un sistema Claude in produzione non si governa scegliendo il modello: si governa decidendo che cosa entra nel contesto, quanto lavoro autorizzate per compito e con quale strumentazione ve ne accorgete. Tre decisioni architetturali, ognuna con una controparte misurabile.
La leva più grande non è il modello
Nei benchmark pubblicati da Anthropic la voce che pesa di più è la cache: «Prompt caching was the largest lever by a wide margin: it cut agent-loop cost by a factor of 2.7 to 5.3 on this guide’s benchmarks and cut a small triage agent’s bill by 83%, or 88% with input trimming added». La tariffa spiega il perché: la lettura dalla cache costa 0,1 volte il prezzo dell’input (0,025 su Claude Fable 5.1 e Mythos 5.1), mentre la scrittura costa 1,25 volte con durata di 5 minuti e 2 volte con durata di un’ora.
Il corollario architetturale conta più del risparmio. La cache segue una gerarchia — tools, poi system, poi messages — e una modifica a un livello invalida quel livello e tutti i successivi. Ne segue che cambiare il set di strumenti a metà conversazione, o variare tool_choice, la configurazione del thinking o il livello di effort, butta via il prefisso già pagato. Se il vostro design mette contenuti dinamici in testa al prompt, avete costruito un sistema che non può usare la leva principale. I punti di rottura espliciti sono al massimo quattro: vanno collocati, non sparsi.
La seconda leva è il disaccoppiamento temporale: la Batch API «takes 50% off every token of a request, including cached ones, in exchange for results arriving any time within 24 hours». Un lotto è limitato a 100.000 richieste o 256 MB, e scade se non completa entro 24 ore. È lo strumento giusto per eval e backfill, quello sbagliato per qualunque cosa un utente stia aspettando.
Il denominatore giusto è il compito, non il token
Confrontare i modelli sul prezzo per token porta alla scelta sbagliata quando il compito è difficile: su Terminal-Bench 3 tre modelli spendono ciascuno fra 8 e 15 dollari per task, ma risolvendone rispettivamente il 7%, il 15% e il 41% il costo per compito risolto scende «from $183 to $63 to $28 up the ladder». Il modello più caro per token è il più economico per risultato.
Prima di cambiare modello c’è una manopola meno invasiva. Il parametro effort ha cinque livelli e il default è high: impostarlo «produces exactly the same behavior as omitting the effort parameter entirely». Sui carichi di ricerca e knowledge work il livello medium ha eguagliato l’accuratezza del default «at about 70% to 87% of its cost». E c’è una strategia che i comitati capiscono subito: girare tutto a effort basso e rieseguire solo i fallimenti a effort pieno ha dato «the same pass rate for half the cost, counting the failed cheap attempts».
Il tetto di spesa per compito si esprime con task_budget, che il modello vede come conto alla rovescia:
{"output_config": {"effort": "high", "task_budget": {"type": "tokens", "total": 64000}}}Attenzione a come lo presentate: è un «soft hint, not a hard cap». Il limite davvero applicato resta max_tokens. Il minimo accettato è 20.000 token, e un budget troppo stretto produce un effetto controintuitivo — il modello può declinare il compito, ridimensionarlo o fermarsi presto — quindi va dimensionato sulla distribuzione reale delle vostre esecuzioni, non su un valore di comodo.
Latenza: due grandezze, due rimedi
La documentazione distingue la latenza di base dal tempo al primo token (TTFT), e fissa l’ordine di lavoro: «It’s always better to first engineer a prompt that works well without model or prompt constraints, and then try latency reduction strategies afterward». Chi ottimizza troppo presto non scopre mai il massimo delle prestazioni. Poi le leve: un modello più rapido (Claude Haiku 4.5 quando la velocità domina), prompt e output più corti, e lo streaming, che non riduce la latenza ma la percezione. Su max_tokens la documentazione è onesta: tronca anche a metà parola, è «a blunt technique».
Che cosa esce davvero dal sistema
Claude Code e l’Agent SDK esportano tre segnali OpenTelemetry indipendenti — metriche, log events e trace in beta — attivati da CLAUDE_CODE_ENABLE_TELEMETRY=1 più un exporter per segnale. Fra le metriche ci sono claude_code.token.usage e claude_code.cost.usage; le trace producono span claude_code.interaction, claude_code.llm_request e claude_code.tool, correlabili tramite l’attributo session.id.
Due dettagli decidono se la strumentazione regge davanti all’ufficio privacy e all’esercizio. Il primo: «The content your agent reads and writes is not recorded by default»; prompt, argomenti degli strumenti e corpi delle richieste si aggiungono solo con variabili opt-in, da lasciare spente finché la pipeline non è autorizzata a conservare quel dato. Il secondo, meno ovvio: «The CLI fails silently on export errors by default», cioè l’agente continua a funzionare e la telemetria sparisce. Un monitoraggio che tace quando si rompe è peggio di nessun monitoraggio, e va sorvegliato a sua volta.
Per la riconciliazione economica ci sono endpoint dedicati: /v1/organizations/usage_report/messages, con bucket 1m, 1h o 1d, e /v1/organizations/cost_report, solo giornaliero. I dati «typically appears within 5 minutes of API request completion», servono credenziali Admin (le chiavi di workspace non funzionano) e i costi Priority Tier non vi compaiono. Un limite da dichiarare: la documentazione fornisce definizioni di misura e canali di telemetria, non un obiettivo di latenza contrattuale. L’SLO è vostro, e va derivato dalle vostre misure prima di essere promesso.