Anthropic ha ridotto in silenzio il TTL della cache di Claude: come recuperare il 30% della spesa API nel 2026

Un piccolo team che gestisce un summarizer notturno su Claude ha notato qualcosa di strano a fine marzo 2026. Stesso cron, stessi prompt, stesso volume di input. La bolletta mensile è passata da 180 a 290 dollari. Nessuna modifica al codice. Nessun picco di traffico. Solo un aumento silenzioso del 60% che non compariva in nessun changelog del provider.

Non sono gli unici. Tra marzo e aprile 2026 decine di sviluppatori su GitHub, Reddit e Hacker News hanno segnalato lo stesso pattern: costi delle API di Claude in crescita, abbonati Pro che per la prima volta sbattono contro la quota di 5 ore di Claude Code, e nessuna spiegazione chiara da parte di Anthropic.

La causa è risultata essere un singolo cambio infrastrutturale silenzioso. Il TTL di default sulla cache dei prompt di Anthropic è stato ridotto da 1 ora a 5 minuti attorno al 6-7 marzo 2026. Nessun blog post, nessun avviso di deprecazione, nessun bump di versione dell'API [1]. Per i workload che si appoggiavano a cache di lunga durata, l'economia è saltata in una notte.

Questa guida ricostruisce cosa è successo davvero, perché i piccoli team lo hanno sentito di più, e cinque fix concreti che puoi applicare lunedì mattina per recuperare il budget perso.

Cosa è cambiato davvero

La documentazione ufficiale di Anthropic sul prompt caching descrive due durate di cache: 5 minuti (1.25× il prezzo base degli input token per le write) e 1 ora (2× per le write). Le read costano 0.1× indipendentemente dal TTL [3]. Fino all'inizio di marzo 2026 il default a livello di piattaforma era 1 ora. Dopo il 6-7 marzo il default è tornato a 5 minuti [1].

Uno sviluppatore di nome Sean Swanson ha pubblicato la ricostruzione più rigorosa della timeline analizzando 119.866 chiamate API di Claude Code su due macchine, dall'11 gennaio all'11 aprile 2026 [1]. Il pattern è inequivocabile:

• Dall'11 al 31 gennaio: TTL di 5 minuti (precede la disponibilità generale del tier da 1 ora)
• Dal 1 febbraio al 5 marzo: TTL di 1 ora su ogni chiamata, 33 giorni consecutivi, su entrambe le macchine
• 6-7 marzo: finestra di transizione, riappaiono i token a 5 minuti
• Dall'8 marzo in poi: TTL di 5 minuti dominante, l'uso del tier 1 ora scende a una minoranza

L'impatto sui costi nel dataset, confrontando la spesa reale con uno scenario controfattuale in cui il TTL di 1 ora fosse rimasto default:

La percentuale di spreco è identica tra i modelli perché il sovrapprezzo della cache 5m vs 1h è un moltiplicatore piatto sul volume di token, non sulla tariffa per token. Le colonne in dollari differiscono perché Opus costa di più per token.

Il "1,1%" di febbraio è il segnale: quando il TTL di 1 ora era attivo, l'economia delle cache read funzionava come da progetto. Quando è passato a 5 minuti, lo stesso workload ha pagato il 25% in più per niente.

L'unica risposta pubblica di Anthropic è arrivata tramite Jarred Sumner, un ingegnere dell'azienda, in un articolo di The Register [2]. Sumner ha riformulato il cambio come benefico per "le chiamate one-shot in cui il contesto cached viene usato una volta sola e non rivisitato". La dichiarazione non ha affrontato l'esaurimento di quota documentato né l'inflazione dei costi. La issue su GitHub è stata chiusa come "not planned" [1].

Perché i piccoli team lo sentono di più

Per capire perché un TTL di 5 minuti fa più male di quanto sembri, devi conoscere l'economia delle prompt cache.

Una cache write costa 1.25× la tariffa base degli input token con TTL 5 minuti, oppure 2× con TTL 1 ora. Una cache read costa 0.1× indipendentemente dal TTL. L'arbitraggio è il delta 12.5× tra write e read. Il caching è profittevole quando un prefisso cached viene letto molte volte prima che il TTL scada. Un system prompt lungo letto 50 volte all'ora si ripaga subito. Lo stesso prompt letto una volta ogni 30 minuti? Inutile.

I workload dei piccoli team somigliano esattamente al secondo caso:

• Un cron notturno che riassume i ticket della giornata: una chiamata a notte, 24 ore di gap tra cache write e la prossima volta che lo stesso contesto compare.
• Un side project che riceve traffico a burst di 10 minuti quando il creator sta debuggando: 5-10 read dentro il burst, poi nulla per ore.
• Un bot Slack che gestisce qualche messaggio al giorno: ogni chiamata è di fatto a freddo.
• Un agent loop con 8-15 minuti tra un input umano e l'altro: scrive la cache, supera il TTL di 5 minuti, la riscrive al turno successivo.

Il riframing di Anthropic presuppone un workload in cui dominano le chiamate one-shot e il sovrapprezzo del 1.25× per la write è sprecato. Per alcuni team è vero. Per i piccoli team che fanno girare workflow Claude long-context su cadenze irregolari, il nuovo default li costringe a pagare il sovrapprezzo write su ogni chiamata, senza l'ammortamento delle read a compensarlo.

Il colpo sulla quota Pro ha aggiunto al danno la beffa. I piani Pro di Claude Code contano i token di creazione cache contro il limite di 5 ore alla tariffa piena; le read pesano pochissimo. Con TTL 1 ora, il primo prompt della giornata pagava il costo write una volta sola e la sessione poi viaggiava sulle read. Con TTL 5 minuti, ogni pausa caffè invalidava la cache e il messaggio successivo pagava di nuovo il costo write. I racconti tipo "ho sbattuto contro la quota Pro in 5 ore e prima non mi capitava mai" risalgono esattamente a questa dinamica [2].

Cinque fix da applicare lunedì

Sono ordinati per sforzo. I primi tre sono meccanici. Gli ultimi due richiedono di ristrutturare come il tuo codice parla con l'API di Claude.

Fix 1: imposta il TTL 1 ora esplicitamente

Il tier di cache 1 ora è ancora disponibile. Non è più il default. Se il tuo workload ha una qualsiasi forma di sessione più lunga di 5 minuti, sovrascrivi il default in ogni chiamata API:

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral", "ttl": "1h"}
        }
    ],
    messages=[...]
)

Il sovrapprezzo write a 1 ora (2× vs 1.25×) è più caro per write, ma lo paghi una volta all'ora invece che una volta ogni 5 minuti. Per qualunque workload che rilegge un prefisso cached più di 4-5 volte all'ora, il tier 1 ora è matematicamente più economico. I numeri li lavoriamo nella decision matrix più avanti.

Fix 2: ristruttura i prompt per stare nella finestra dei 5 minuti

Se il tuo traffico è genuinamente bursty e non vuoi pagare il sovrapprezzo write 2×, puoi ristrutturare il lavoro per stare dentro 5 minuti. Funzionano bene due pattern:

Burst-batch. Invece di lanciare una chiamata a Claude per ogni messaggio utente che arriva, mettili in coda fino a 60 secondi e mandali come un singolo batch. Cinque messaggi in sequenza ammortizzano la cache write su cinque read invece che cinque rewrite.

Pipeline collapsing. Se il tuo agent loop ha una pipeline a tre step "pianifica, raffina, esegui" con approvazione umana tra uno e l'altro, lancia tutte e tre le chiamate Claude prima della review umana. La cache resta calda. Riprompt solo se viene rigettato.

Fix 3: heartbeat di cache-warming (solo a volte)

Se un singolo prefisso cached serve più utenti, oppure un agent loop sparso paga molto in fresh write, puoi tenere la cache calda con un keepalive minimale ogni 4 minuti:

async def keep_cache_warm():
    await client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=1,
        system=[{"type": "text", "text": SHARED_PREFIX,
                 "cache_control": {"type": "ephemeral"}}],
        messages=[{"role": "user", "content": "ping"}]
    )

Ogni ping costa il prezzo di una sola cache read (0.1× tariffa input) più 1 token di output. Il trade-off è contro il costo di lasciar scadere la cache e riscriverla da zero. Come regola spannometrica, un heartbeat conviene quando:

• Il prompt è grande (12k+ token), quindi ogni fresh write è cara
• Più sessioni o utenti condividono lo stesso prefisso cached
• Pagheresti più in fresh write di quanto costa l'heartbeat in read

Per un singolo utente con traffico sparso, di solito conviene lasciar scadere la cache. Fai i conti sul tuo pattern di sessione reale prima di mettere in produzione l'heartbeat.

Fix 4: audit del cache hit ratio

Non puoi correggere quello che non misuri. Ogni response API di Claude include usage.cache_read_input_tokens e usage.cache_creation_input_tokens. Il rapporto tra read e creation, pesato sui token, è il tuo cache hit ratio. Un workload long-context sano gira sopra 0,85. Sotto 0,5 vuol dire che stai pagando il sovrapprezzo write sulla maggior parte delle chiamate.

Logga entrambi i valori per request e aggrega settimanalmente. Se il tuo hit ratio è calato tra febbraio e marzo 2026, stai guardando la regressione nei tuoi stessi dati.

Fix 5: multi-model fallback sul volume

Per il lavoro ad alto volume non-frontier, la copertura più pulita è instradare per task invece di affidarsi all'economia della cache. DeepSeek V4-Pro, rilasciato il 24 aprile 2026, fa 80,6 su SWE-bench (statisticamente alla pari con Opus 4.7 a 80,8) a circa 10× meno per token e offre una context window da 1M [4]. Per classificazione, estrazione e templating, spostare l'80% delle chiamate su un modello più economico con requisiti di caching più lenti rimuove il problema interamente.

Non è una storia di sostituzione di Claude. Il ragionamento frontier resta su Opus 4.7. Ma ogni chiamata che non ha bisogno di ragionamento frontier e gira frequentemente è candidata all'offload.

Decision matrix: pagare il premio 1 ora o ristrutturare?

Il break-even tra TTL 5 minuti e 1 ora dipende da tre variabili: dimensione del prompt, frequenza di riuso e forma del burst. Ecco la matematica per un agent di coding long-context tipico.

Setup. Un system prompt da 12.000 token. Opus 4.7 a 5 $/MTok di input, quindi base write a TTL 5m è 5$ × 1,25 = 6,25 $/MTok, write a TTL 1h è 10$/MTok, read è 0,50 $/MTok in entrambi i tier.

Scenario A: 1 cache write + 8 read dentro 5 minuti.

• TTL 5m: 12k × 6,25 $+ 8 × 12k × 0,50$ = 0,075 $+ 0,048$ = 0,123 $
• TTL 1h: 12k × 10 $+ 8 × 12k × 0,50$ = 0,12 $+ 0,048$ = 0,168 $
• Verdetto: vince il TTL 5 minuti. Il lavoro sta dentro una finestra.

Scenario B: 8 read distribuite uniformemente su 30 minuti (6 finestre di cache su TTL 5m, 1 su TTL 1h).

• TTL 5m: 6 write × 0,075 $+ 8 read × 0,006$ = 0,45 $+ 0,048$ = 0,498 $
• TTL 1h: 1 write × 0,12 $+ 8 read × 0,006$ = 0,12 $+ 0,048$ = 0,168 $
• Verdetto: vince il TTL 1 ora di 3×.

Scenario C: 1 read ogni 30 minuti per 4 ore (8 read totali, 4 write allineate alle ore su TTL 1h).

• TTL 5m: 8 write × 0,075 $+ 8 read × 0,006$ = 0,60 $+ 0,048$ = 0,648 $
• TTL 1h: 4 write × 0,12 $+ 8 read × 0,006$ = 0,48 $+ 0,048$ = 0,528 $
• Verdetto: vince il TTL 1 ora di 1,2×.

La scorciatoia: se il tuo prompt viene riusato meno di 5 volte in 5 minuti ma più di una volta all'ora, passa al TTL 1 ora. Se il riuso è più denso, resta sui 5 minuti. Se il riuso è più sparso di una volta all'ora, il caching non è il tuo problema e dovresti guardare al multi-model offload.

Mettere il dito sul problema (senza diventare un flame)

I fix tecnici qui sopra ti riportano dove eri a febbraio. Non affrontano la questione di fondo: i cambi infrastrutturali silenziosi sono pericolosi per qualunque team che non gira telemetria di costo costante, e questo è quasi tutti i piccoli team.

Tre cose che Anthropic dovrebbe spedire per rendere meno probabile la prossima volta:

Un changelog pubblico per i comportamenti di default. Il TTL 1 ora diventato default a febbraio 2026 non è mai stato annunciato; il ritorno indietro a marzo non è mai stato annunciato. Entrambi avrebbero dovuto essere voci di changelog con date di efficacia. Altri cambi infrastrutturali (rate limit, instradamento dei modelli, policy di eviction della cache) probabilmente avvengono con la stessa opacità.

Default a last-known-good. Quando i default di piattaforma cambiano, il pattern operativamente sicuro è far ereditare alle API key esistenti il default precedente per una finestra di deprecazione. AWS, Stripe e la maggior parte delle piattaforme mature lo fanno. Anthropic non lo fa, almeno non ancora.

Conteggio di quota trasparente. Gli abbonati Pro che vedono "hai raggiunto il limite di 5 ore" senza un breakdown di cache write, read e token non-cached non hanno modo di fare debug. Un pannello usage che mostri dove finisce davvero la quota permetterebbe ai team di adattarsi prima di essere tagliati fuori a metà sessione.

Non sono richieste esotiche. Sono il minimo sindacale per una piattaforma API su cui i piccoli team costruiscono workflow di produzione.

Cosa significa se usi Keep My Prompts

Qualunque cosa Anthropic spedisca dopo, i prompt che sopravvivono meglio ai cambi infrastrutturali sono quelli con struttura pulita. Un system prompt lungo, ben organizzato, con sezioni chiare, va in cache come singolo blocco. Un prompt caotico che mischia istruzioni di sistema, esempi e contesto user-specific in un unico muro di testo frammenta la cache e paga il sovrapprezzo write a ogni chiamata.

Misura la qualità strutturale dei tuoi prompt prima di metterli in produzione. Se il tuo Score è sopra 4, il tuo prompt è cache-friendly per fortuna. Se è sotto 3, stai lasciando soldi di cache sul tavolo, indipendentemente dal fatto che Anthropic cambi di nuovo il TTL il mese prossimo.

Fai girare un prompt in Score su keepmyprompts.com per vedere dove si colloca. Piano free, 20 prompt, ci vogliono circa 10 secondi per uno scoring run.

Fonti

[1] Sean Swanson, "Cache TTL silently regressed from 1h to 5m around early March 2026, causing quota and cost inflation," GitHub issue #46829 su anthropics/claude-code, aprile 2026. https://github.com/anthropics/claude-code/issues/46829

[2] The Register, "Anthropic: Claude quota drain not caused by cache tweaks," 13 aprile 2026. https://www.theregister.com/2026/04/13/claude_code_cache_confusion/

[3] Anthropic, documentazione "Prompt caching". https://platform.claude.com/docs/en/build-with-claude/prompt-caching

[4] Simon Willison, "DeepSeek V4," 24 aprile 2026. https://simonwillison.net/2026/Apr/24/deepseek-v4/