Cache-aware loop cadences: il TTL del prompt cache come variabile decisionale first-class del workspace

Riportiamo uno studio di misurazione di 6 mesi sulla selezione della cadenza dei loop autonomi prompt-cache-aware su 24 loop agentic in produzione presso Madani Lab, derivando un modello di costo in forma chiusa che spiega la forma non-monotonica delle curve costo-vs-cadenza e mostrando che la decisione di scheduling dei loop nell'infrastruttura di autonomous agent è dominantemente un problema di cache-arithmetic piuttosto che un trade-off latenza-vs-frequenza. Anthropic ha introdotto il prompt caching nell'agosto 2024 (generalmente disponibile nel 2025) con un TTL standard-tier di 5 minuti (300 secondi) e una riduzione di costo per-token di circa 10× sui cache hit. OpenAI e Google hanno seguito con meccanismi simili nel 2024-2025 (OpenAI ~5-10 minuti TTL per tier; Gemini configurabile). Nonostante il ruolo centrale della struttura della cache nell'economia dei loop autonomi, la letteratura di design tratta la durata del sleep come una decisione wall-clock e la cache come un'ottimizzazione di piattaforma trasparente. Questo produce una mis-allocazione sistematica: gli agent in produzione comunemente scelgono intervalli di 5 minuti per bias da round-number, atterrando nel regime worst-of-both-worlds dove la cache è appena scaduta ma l'iterazione è ancora abbastanza frequente da consumare token sostanziali. Strumentiamo 24 loop con telemetria di cache-hit-rate per-iterazione, eseguiamo esperimenti A/B controllati nel range di cadenza 60s-3600s per 6 archetipi di loop rappresentativi, validiamo un modello di costo in forma chiusa contro misurazioni empiriche, e riportiamo SETTE finding controintuitivi

1. (a)
   LA DECISIONE DI LOOP-CADENCE È NON-MONOTONICA A 300 SECONDI — 270s resta cache-warm ed è la più economica per detection-latency-unit; 1200s paga un singolo cache miss ammortizzato su intervalli di 20 minuti ed è comparabilmente economica; 300s è la scelta peggiore possibile, pagando il costo pieno di cache-miss ad ogni iterazione E iterando frequentemente
2. (d)
   LO SCHEDULING DEI LOOP CACHE-AWARE RIDUCE LA TOKEN SPEND DEL 60-80% SENZA IMPATTO SULL'ACCURATEZZA — il portfolio di 24 loop di Madani è passato da $8.50/giorno a $1.10/giorno post-ottimizzazione, una riduzione dell'87%; output funzionali invariati nel confronto A/B
3. (e)
   La decisione cache-ttl-aware si compone su loop long-horizonautoresearch e overnight loop che iterano migliaia di volte moltiplicano l'economia per-iterazione; per un loop che esegue 10.000 iterazioni la decisione 270s-vs-300s è la differenza tra $14 e $112 di costo ammortizzato
4. (f)
   La maggior parte dei framework di loop autonomi ignora il cache ttlCronCreate, scheduler cron-style, trigger n8n, e la maggior parte delle primitive di looping dei framework agent trattano la durata del sleep come wall-clock e lasciano 70%+ dell'ottimizzazione di costo sul tavolo; questa è la singola più grande inefficienza strutturale nell'ecosistema dei loop agentic

I loop di autonomous agent sono il tessuto connettivo dei workspace agentic. Fanno polling di sistemi esterni (aggiornamenti contatti CRM, code di support-ticket, webhook di deploy-status, ingestion di lead-source), guidano workflow schedulati (generazione newsletter, produzione daily digest, aggregazione scorecard), e ritmano la ricerca long-horizon (loop self-paced di autoresearch). La loro impronta economica si compone: un singolo loop a cadenza di 5 minuti che esegue 24/7 produce 288 chiamate LLM al giorno; 24 loop producono ~7.000 chiamate al giorno; il deployment di produzione presso Madani Lab pre-ottimizzazione era $250/mese per il solo overhead dei loop.

L'assunzione dominante nei default dei framework è che il costo dei loop scali linearmente nel token count e che le cadenze round-number (5 minuti, 15 minuti, 1 ora) siano default ragionevoli. L'introduzione del prompt caching nel 2024-2025 ha rotto entrambe le assunzioni: costo-vs-cadenza è non-monotonico, e i default round-number cadono sistematicamente nel regime peggiore.

INTRODUZIONE · §2 · PERCHÉ IL PROMPT CACHING CAMBIA LA GEOMETRIA. Anthropic prompt caching (rilasciato in beta nell'agosto 2024, generalmente disponibile nel 2025) consente alla piattaforma di trattenere il contesto compilato tra le richieste all'interno di una finestra TTL (5 minuti standard; 1 ora disponibile come upgrade secondo la documentazione di prompt-caching di Anthropic). I cache hit sono fatturati a circa 10% della tariffa per-token dei cache miss (il rapporto esatto è 0.1× per cache read vs 1.0× per token freschi, più un sovrapprezzo del 25% sulla scrittura iniziale della cache).

Quando due chiamate LLM all'interno dello stesso TTL condividono un prefix di lunghezza L, la seconda chiamata paga ~0.1L per la porzione cached più il prezzo pieno solo per il suffix variabile. Per i loop autonomi dove il system prompt + le tool definition + la maggior parte del contesto sono statici tra le iterazioni, questo significa che il loop paga il costo di cache-write una volta per finestra TTL e l'economico costo di cache-read su ogni iterazione successiva all'interno della finestra. La geometria di costo-vs-cadenza acquisisce una discontinuità al confine TTL: le cadenze sotto il TTL beneficiano dell'ammortamento, le cadenze sopra pagano il prezzo pieno ogni iterazione.

Facciamo quattro contributi. (1) EMPIRICO: misurazione di 6 mesi di 24 loop in produzione con telemetria di cache-hit per-iterazione. (2) FORMALE: un modello di costo in forma chiusa parametrizzato da cache TTL, hit ratio, e frequenza di iterazione che spiega le forme di costo-vs-cadenza osservate. (3) OPERATIVO: una policy HARD RULE (ogni loop deve dichiarare cache-warm <=270s o cache-cold >=1200s; la dead zone richiede giustificazione esplicita) che ha prodotto 87% di riduzione di costo nel nostro portfolio. (4) ARCHITETTURALE: cache-prefix design pattern (long-stable prefix, batch-window aggregation, multi-tier-aware scheduling) che compongono risparmi aggiuntivi sopra la decisione di cadenza.

INTRODUZIONE · §3b · NOTA SULLO SCOPE. Il pattern cache-aware che questo paper formalizza si applica a LOOP autonomi — invocazioni ripetute che condividono contesto sostanziale tra le iterazioni. Non si applica direttamente all'inferenza one-shot, alle sessioni di chat con contesto di sistema in rapida evoluzione, o agli scenari dove ogni iterazione ha prompt sostanzialmente diversi.

Lo scenario di produzione dominante per i workspace agentic, tuttavia, È loop-shaped: monitoring, polling, esecuzione di task schedulati, ricerca autonoma. Stimiamo che il 60-75% della token spend di produzione su larga scala fluisca attraverso invocazioni loop-shaped piuttosto che one-shot, rendendo l'economia dei loop cache-aware la leva di costo dominante per la maggior parte dei workspace.

INTRODUZIONE · §3c · PERCHÉ NON È STATO STUDIATO. Tre ragioni per cui il pattern cache-aware è sotto-documentato nonostante la sua magnitudo. (a) RECENZA: il prompt caching come feature fatturabile ha appena 18 mesi; la baseline empirica per la misurazione è breve. (b) ABSTRACTION HIDING: la cache è presentata dai vendor come un'ottimizzazione a livello di piattaforma piuttosto che come una variabile first-class user-facing; gli utenti non sono invitati a ragionarci sopra. (c) FRIZIONE DI MISURAZIONE: derivare il cache-hit-rate per-iterazione richiede log parsing che è non-banale negli stack di observability di default; i team che non hanno strumentato non possono vedere il costo che stanno pagando.

        CACHE-AWARE LOOP · prompt prefix stability
        ─────────────────────────────────────────

   turn N           turn N+1         turn N+2
   ┌─────────┐    ┌─────────┐    ┌─────────┐
   │ STABLE  │    │ STABLE  │    │ STABLE  │
   │ system  │    │ system  │    │ system  │
   ├─────────┤    ├─────────┤    ├─────────┤
   │ STABLE  │    │ STABLE  │    │ STABLE  │
   │ skills  │    │ skills  │    │ skills  │
   ├─────────┤    ├─────────┤    ├─────────┤
   │ VOLATILE│ ✗  │ VOLATILE│ ✗  │ VOLATILE│
   │ tool out│    │ tool out│    │ tool out│
   │ date    │    │ date    │    │ date    │
   └─────────┘    └─────────┘    └─────────┘

   anti-pattern: rotate volatile blocks INTO prefix
   → cache invalidates · cost ×10

I lavori precedenti sull'ottimizzazione dei costi LLM si focalizzano largamente sulla model selection (Pope et al., 2023, sull'efficient transformer inference), prompt compression (LLMLingua et al.), e strategie di batching. Le implicazioni di costo del caching per i loop autonomi specificamente sono sotto-esplorate — la documentazione di prompt-caching di Anthropic descrive il meccanismo ma non analizza l'applicazione ai loop autonomi. Liu et al. (2024) studiano gli effetti lost-in-the-middle nei contesti lunghi ma trattano il contesto come fenomeno single-pass piuttosto che come target di cache repeated-pass.

La letteratura di agent-scheduling (primitive cron, scheduler di workflow AutoGen, trigger n8n, nodi cron LangGraph) tratta la durata del sleep come una decisione domain-driven — "ogni quanto questo loop deve fare check?" — senza integrare la struttura della cache. La skill autoresearch di Madani (WSB-14) è una delle prime primitive agent pubblicate che rende la cadenza cache-aware una decisione di design first-class; questo paper formalizza la policy che la sottende.

A livello di inference-serving, la KV-cache management è stata studiata estensivamente (PagedAttention di Kwon et al., vLLM, SGLang). Questi lavori ottimizzano il throughput di inferenza all'interno di un singolo deployment; il nostro lavoro è al livello del workspace sopra lo stack di inferenza, trattando il prompt-cache TTL esposto dalla piattaforma come il vincolo binding.

Abbiamo modificato il runtime degli agent Madani per loggare telemetria di cache strutturata per ogni chiamata LLM: cache_creation_input_tokens, cache_read_input_tokens, input_tokens, output_tokens, model, loop_id, iteration_number, e timestamp. L'API Anthropic espone questi campi nei metadati di usage; li forwarderemo a BigQuery e un'aggregazione giornaliera produce dashboard di costo per-loop. Logghiamo anche l'intervallo inter-iterazione (il gap wall-clock dall'iterazione precedente nello stesso loop) per abilitare l'analisi del cache-hit-rate come funzione della cadenza.

Per 6 archetipi di loop rappresentativi (newsletter monitor, lead-status poller, calendar-conflict detector, content-pipeline pacer, support-queue triager, deploy-status watcher), abbiamo eseguito un design A/B controbilanciato: ogni loop ha eseguito a 5 cadenze diverse (60s, 270s, 600s, 1200s, 3600s) per 7 giorni ciascuna, in ordine randomizzato tra loop per controllare gli effetti time-of-week. Abbiamo misurato: costo totale giornaliero in token (suddiviso per cache-hit, cache-write, input regolare, output), mean detection latency (tempo wall-clock dall'occorrenza dell'evento al riconoscimento dell'agent), tasso di falsi positivi, e disruption operativa (qualsiasi output del loop che gli agent downstream hanno flaggato come anomalo).

Abbiamo derivato un modello di costo in forma chiusa: costo per-iterazione C(t) = C_input I + C_write W + C_read R + C_output O, dove I = input token (non-cached), W = cache-write token (nuovo contenuto cache), R = cache-read token (contenuto cache esistente), O = output token, e C_ sono i rispettivi prezzi per-token. Lo split cache-write/read dipende da se l'iterazione cade all'interno della finestra TTL dall'iterazione precedente: se l'intervallo t < T_cache, l'iterazione è un cache-hit (R alto, W minimale); se t >= T_cache, l'iterazione è un cache-miss (R = 0, W alto). Il costo totale giornaliero è approssimativamente (86400 / t) C(t), dove la forma C(t) è piecewise — bassa nel regime cache-hit, alta nel regime cache-miss. La non-monotonicità emerge perché (86400/t) decresce al crescere di t ma C(t) salta discontinuamente a t = T_cache.

Abbiamo validato il modello contro i dati empirici A/B. Accordo predetto-vs-misurato del costo giornaliero attraverso le 30 celle (loop, cadenza): R-squared = 0.94. La varianza residua di ~6% è attribuibile a variabilità di input intra-loop (alcune iterazioni producono più output di altre a seconda del volume di eventi rilevati) e all'eviction della cache lato piattaforma (il TTL è "fino a 5 minuti" — la durata effettiva della cache può essere più breve in condizioni di cache-pressure).

RISULTATI · §11 · LO SWEET SPOT A 270s. Le cadenze appena sotto T_cache (abbiamo standardizzato a 270s, un margine di sicurezza del 10% sotto il TTL di 300s) colpiscono la cache consistentemente.

Cache-hit rate misurato: 96.4% sui 6 loop archetipo in 7 giorni. Costo: $0.12/giorno per loop in media, con l'output che domina il costo (l'input è economico grazie ai cache hit). Detection latency: 4.5 minuti worst case, comparabile a una cadenza naive di 300s. Questo è il regime cost-optimal per i loop che beneficiano del check frequente.

RISULTATI · §12 · LA DEAD ZONE 300-1200s. Le cadenze nel range 300s-1200s mancano la cache (la cache dell'iterazione precedente è scaduta quando inizia l'iterazione successiva) ma iterano abbastanza frequentemente da consumare token sostanziali. Cache-hit rate misurato: 4.1% (solo su rare back-to-back retry all'interno della stessa finestra TTL).

Costo: $0.95/giorno per loop in media — quasi 8× il costo a 270s. La causa: ogni iterazione paga il costo pieno di cache-write (perché nulla è cached) E il count di iterazioni è ancora alto. Questo è il regime worst-of-both-worlds, ed è il default inconscio della maggior parte dei deployment di loop autonomi che auditiamo.

Gli schedule cron a 5 minuti e 10 minuti cadono qui.

RISULTATI · §13 · IL RECUPERO 1200-3600s. Le cadenze sopra 1200s mancano la cache affidabilmente ma iterano abbastanza raramente che il costo totale giornaliero si normalizza. Costo misurato: $0.18/giorno per loop a 1200s, $0.08/giorno a 3600s.

La cadenza 1200s scambia 4× detection latency per 5× riduzione di costo vs la cadenza 300s della dead-zone — un trade favorevole per la maggior parte dei loop di monitoring. La cadenza 3600s è appropriata per loop a tasso di eventi molto basso dove una detection latency fino a un'ora è accettabile.

RISULTATI · §14 · FINDING CONTROINTUITIVO 1 · COSTO-VS-CADENZA NON-MONOTONICO. La curva di costo ha la forma: bassa a 60-270s, salita ripida a 300s, plateau a 300-1200s, declino a un secondo minimo a 1200-3600s. Questo è strutturalmente identico a una discontinuità step-function a T_cache.

L'intuizione "sleep più lungo equivale a costo più basso" è sbagliata nel range 300-1200s; l'intuizione "sleep più corto equivale a costo più alto" è sbagliata nel range 60-270s. Entrambe le intuizioni sono simultaneamente violate dalla stessa meccanica della cache.

RISULTATI · §15 · FINDING CONTROINTUITIVO 2 · LA CACHE BATTE LA MODEL SELECTION PER IL COSTO. Il rapporto di costo cached-vs-uncached presso Anthropic è approssimativamente 10× (cache read a 0.1× della tariffa per-token di input fresco). Il rapporto di costo Opus-vs-Sonnet è approssimativamente 4.5× (15/3 secondo il pricing Anthropic nel Q1 2026).

Per i loop dove il contesto del workspace domina il volume di input, passare da 0% di cache hit a 70% di cache hit produce risparmi maggiori del downgrade da Opus a Sonnet. Eppure i team routinariamente auditano la model selection (una leva ad alta visibilità) senza auditare il cache hit rate (una leva a bassa visibilità ma di impatto maggiore). La nostra raccomandazione: l'audit del cache-hit-rate dovrebbe precedere l'audit della model-selection nell'ottimizzazione dei costi.

RISULTATI · §16 · FINDING CONTROINTUITIVO 3 · BIAS DA ROUND-NUMBER. Su 47 workspace auditati (Madani + audit di terze parti che abbiamo eseguito), 31 avevano la maggior parte dei loop a cadenza di 5 minuti e 9 avevano la maggioranza a cadenza di 10 minuti o 15 minuti. Tutte e tre queste scelte round-number cadono nella dead zone cache-miss.

Solo 2 workspace (entrambi influenzati da Madani) usavano la cadenza 270s. Il bias cognitivo verso i numeri tondi ("ogni 5 minuti" suona naturale; "ogni 270 secondi" suona ingegnerizzato) produce una mis-allocazione sistematica del valore di decine di migliaia di dollari annualmente a scala di workspace tipica.

RISULTATI · §17 · FINDING CONTROINTUITIVO 4 · 60-80% DI RIDUZIONE DI COSTO CON ZERO DELTA DI ACCURATEZZA. Portfolio Madani pre-ottimizzazione: $8.50/giorno (~$255/mese) su 24 loop. Post-ottimizzazione (tutti i loop spostati o a 270s cache-warm o a 1200s cache-cold basato sui requisiti di detection-latency; cache-prefix design applicato dove possibile): $1.10/giorno (~$33/mese).

Riduzione dell'87%. Output funzionali nel confronto A/B: invariati. Detection latency: entro il 10% della baseline per tutti i loop.

Tassi di falsi positivi: invariati. La riduzione di costo è pura efficienza infrastrutturale senza costo comportamentale.

RISULTATI · §18 · FINDING CONTROINTUITIVO 5 · COMPOSIZIONE SU LOOP LONG-HORIZON. Per i loop che iterano migliaia di volte (autoresearch self-paced loop, overnight scan loop, aggregazioni settimanali), l'economia per-iterazione si moltiplica. Un loop che esegue 10.000 iterazioni a 270s costa ~$14 ammortizzato; a 300s costa ~$112 ammortizzato.

Il gap factor-of-8 che è appena visibile a scala di giorno singolo diventa una differenza annua a quattro cifre a scala long-horizon. L'implicazione: i loop a esecuzione più lunga beneficiano DI PIÙ della cadenza cache-aware rispetto ai loop brevi, anche se l'intuizione suggerisce l'opposto (i loop lunghi hanno più "amortization room").

RISULTATI · §19 · FINDING CONTROINTUITIVO 6 · I DEFAULT DEI FRAMEWORK LASCIANO COSTO SUL TAVOLO. Abbiamo auditato le primitive di loop in 8 framework agent popolari (modulo scheduled-task AutoGen, cron-trigger CrewAI, interval node LangGraph, cron trigger n8n, Anthropic CronCreate, scheduled invocation OpenAI Assistant, scheduled function Inngest, cron workflow Temporal). Di questi, ZERO espongono primitive di scheduling cache-TTL-aware.

Tutti accettano un intervallo wall-clock ed eseguono il body del loop senza esporre la struttura della cache. L'implicazione: 70%+ dell'ottimizzazione di costo disponibile è invisibile a livello di astrazione del framework. I team che integrano lo scheduling cache-aware esplicitamente lo catturano; i team che si affidano ai default del framework no.

RISULTATI · §20 · FINDING CONTROINTUITIVO 7 · LA SHARED-PREFIX FRACTION È LA SECONDA VARIABILE. Oltre alla durata del sleep, la variabile dominante nell'economia della cache è la shared-prefix fraction: quanto del prompt del loop è stabile tra le iterazioni vs quanto è variabile per iterazione. I loop con system prompt stabile + input variabile (es. loop di monitoring che controllano dati che cambiano) mantengono cache hit elevato sul prefix anche quando il suffix varia.

I loop con contesto di sistema mutabile (es. loop che includono il tempo corrente nel system prompt o che mutano le tool definition per iterazione) distruggono l'eleggibilità della cache sul prefix. Abbiamo misurato la shared-prefix fraction su 24 loop: quelli con prefix > 90% del totale dei token hanno mediato il 96% di cache-hit quando la cadenza era cache-warm; quelli con prefix < 50% hanno mediato il 41% di cache-hit anche quando la cadenza era cache-warm. La lezione architetturale: progettare i prompt per essere long-stable-prefix + short-volatile-suffix per massimizzare l'eleggibilità della cache.

RISULTATI · §20b · DISTRIBUZIONE DELLA LATENCY SOTTO CADENZA CACHE-WARM. La cadenza 270s rimane all'interno del TTL ma sbatte contro il confine; abbiamo misurato l'effettiva distribuzione di cache-lifetime. Sul 96.4% di iterazioni misurate come cache-hit, la distribuzione di età della cache: 35% hit a 0-90s (back-to-back retry all'interno della stessa finestra TTL), 38% a 90-180s, 22% a 180-260s, 1.4% a 260-300s (appena prima della scadenza TTL).

La coda della distribuzione a 260-300s spiega il ~3.5% miss rate alla cadenza 270s: l'occasionale eviction lato piattaforma accorcia il TTL sotto i 5 minuti documentati. Abbiamo aggiunto un fallback: quando un miss è rilevato a cadenza cache-warm, il loop logga l'evento e la cache si resetta alla iterazione successiva; l'impatto totale sul costo nei 6 mesi di misurazione era ~3% sopra la predizione del modello, all'interno della tolleranza.

RISULTATI · §20c · DISTRIBUZIONE DEL COSTO A LIVELLO PORTFOLIO. Sui 24 loop Madani post-ottimizzazione, la distribuzione del costo giornaliero per-loop è altamente right-skewed: 18 loop costano meno di $0.05/giorno (cache-warm low-volume monitor), 4 loop costano $0.10-0.30/giorno (cache-warm high-volume), 2 loop costano $0.30-0.80/giorno (cache-cold long-horizon synthesis). I 2 top contributori di costo sono il 73% del costo totale del portfolio; i 18 in basso sono il 12%.

Questa forma power-law è strutturalmente simile alla power-law di skill-invocation da WSB-17. L'attenzione di cost-optimization dovrebbe seguire lo stesso principio di Pareto: strumentare e tunare i top 2-3 loop; accettare la coda lunga come rumore economico.

RISULTATI · §20d · EFFETTI DI CACHE-PRESSURE DURANTE LE PEAK HOURS. Il TTL documentato di Anthropic è "fino a 5 minuti"; in condizioni di carico platform-wide abbiamo osservato l'effettivo TTL accorciarsi fino a ~3 minuti durante i picchi del Q4 2025. Abbiamo aggiustato la policy Madani: durante le finestre di carico identificate (overlap US business hours con EU business hours, giorni feriali), la cadenza cache-warm è stretta a 180s.

La penalità di costo di iterazioni più frequenti è piccola; la penalità di cache-miss evitata è grande. Questo pattern dynamic-margin è la terza variabile di design cache-aware dopo cadenza e prefix-fraction.

La maggior parte degli ingegneri tratta il prompt cache come un'ottimizzazione di piattaforma trasparente. Non lo è. La cache impone una discontinuità di costo step-function al confine TTL che domina l'economia dei loop.

Abbiamo integrato questo finding nella policy dei loop autonomi Madani come una HARD RULE: ogni loop deve dichiarare la sua cadenza come CACHE-WARM (<=270s, margine di sicurezza del 10% sotto il TTL di 300s) o CACHE-COLD (>=1200s, 4× TTL per assicurare nessuna interazione di cache-pressure). Le cadenze nella dead zone 300-1200s richiedono review esplicita di cost-justification che citi perché le opzioni standard CACHE-WARM o CACHE-COLD non si adattano. Dopo 6 mesi di enforcement della policy, le cadenze dead-zone sono lo 0% dei loop attivi; pre-policy erano il 71%.

DISCUSSIONE · §22 · PORTABILITÀ CROSS-VENDOR. Il design pattern cache-aware si generalizza tra vendor ma la specifica finestra TTL varia. Al Q1 2026: il TTL del prompt cache Anthropic è 5 minuti (300s) sullo standard tier con upgrade da 1 ora disponibile; il TTL del prompt cache OpenAI è 5-10 minuti (varia per tier e modello); la cache Google Gemini è configurabile con TTL documentato.

La decisione binaria (cache-warm vs cache-cold) è la stessa tra vendor; solo il timing della soglia differisce. Raccomandiamo che le policy del workspace dichiarino le cadenze relative al TTL del vendor attivo (es. "0.9 T_cache per cache-warm, 4 T_cache per cache-cold") piuttosto che a un tempo assoluto, rendendo le policy future-proof contro i cambiamenti di pricing del vendor.

Il pattern cache-aware si estende oltre la cadenza nell'architettura del prompt. Tre pattern che abbiamo pilotato: (a) LONG-STABLE-PREFIX DESIGN: posizionare tutto il contenuto stabile (system prompt, tool definition, hard rule, brand voice, documentazione di riferimento) nel prefix; posizionare il contenuto variabile (input corrente, risultato del polling, timestamp) nel suffix. Il prefix diventa cache-eligible; il suffix è fresco per iterazione.

Il cache hit rate per la porzione prefix si avvicina al 100%. (b) BATCH-WINDOW AGGREGATION: invece di processare un item per iterazione, batchare più item all'interno di una singola finestra TTL. Questo ammortizza il costo di cache-write su più input. Abbiamo pilotato questo per il lead-status poller e ridotto il costo di un ulteriore 35% oltre l'ottimizzazione della cadenza. (c) MULTI-TIER CACHE DECISION: con il tier di upgrade da 1 ora disponibile, i loop possono scegliere finestre di cache da 5 minuti o 1 ora.

Il tier da 1 ora costa di più per cache write ma estende l'ammortamento. Per i loop che iterano una volta ogni 15-30 minuti, il tier da 1 ora è cost-optimal.

Per fare decisioni cache-aware, il workspace deve osservare il cache-hit rate per-iterazione. La maggior parte delle piattaforme lo espone via metadati di risposta, ma pochi loop in produzione lo parsano e lo loggano. Abbiamo aggiunto il cache-hit-rate allo stack di observability standard Madani (insieme a latency, error rate, token count). Il criterio di maturità L3 del WAB Pillar 09 (Observability) include "cache-hit-rate tracciato per loop con review settimanale dei cache miss".

Il portfolio di 24 loop di Madani ha risparmiato ~$2.700/anno tramite la policy di cadenza cache-aware. Estrapolando a enterprise con 100+ loop (una scala comune per deployment AI di medie dimensioni): risparmi annui attesi $11.000-25.000 per workspace. Estrapolando a enterprise con 500+ loop (scala di deployment grande): $55.000-125.000.

Questi sono numeri di puro risparmio, senza compromesso di accuratezza. La ragione per cui questa opportunità di risparmio non è già catturata è che l'economia cache-TTL non è esposta nei default dei framework o nelle dashboard; i team devono strumentare e auditare esplicitamente.

DISCUSSIONE · §26 · INTERAZIONE CON LA SKILL AUTORESEARCH (WSB-14). La skill autoresearch Madani implementa loop self-paced che iterano basandosi su composite scoring. La selezione della cadenza di sleep della skill è ora cache-aware: breve (60-270s) per ricerca high-attention dove l'agent sta raccogliendo informazioni strettamente accoppiate, lunga (1200-1800s) per fasi di esplorazione dove l'attesa permette al contesto esterno di evolvere.

La skill evita esplicitamente la dead zone 300-1200s. Riduzione di costo dalla selezione di cadenza cache-aware su una run di autoresearch di 4 ore: tipico $1.20 vs $9.40 pre-policy. Il pattern è critico per l'autoresearch perché il count totale di iterazioni può superare 100 per run.

DISCUSSIONE · §26b · INTERAZIONE CON I GOVERNANCE GATE (WSB-15). Il pattern compliance-gate da WSB-15 beneficia anch'esso del design cache-aware. I compliance gate invocano un judge sub-agent (Claude Haiku) su ogni output del primary-agent.

Il judge vede lo stesso documento di hard-rule su ogni invocazione; questo è un long-stable prefix cache-eligible. Quando abbiamo ristrutturato il prompt del judge con le rule come prefix e il check per-output come suffix, il costo del judge è calato del 73% senza cambiamento comportamentale. Il pattern cache-aware si applica ovunque un documento di riferimento fisso accompagni input variabili — governance, valutazione, classificazione, judging.

DISCUSSIONE · §26c · INTERAZIONE CON METACOG (WSB-06). Il pre-task self-assessment del MetaCogAgent da WSB-06 è anche un pattern repeated-prefix: il capability profile + assessment rubric sono stabili; la descrizione del task è variabile. Abbiamo refactorato il prompt metacog di conseguenza; il costo di assessment è calato dell'81% per invocazione. Il pattern è generale: qualsiasi chiamata LLM-judge o LLM-assessor ripetuta beneficia della ristrutturazione cache-prefix.

DISCUSSIONE · §26d · PERCHÉ ESISTE IL TTL DI 5 MINUTI. Il parametro TTL è impostato dalla piattaforma per limitare il consumo di memoria a livello di inference-serving. Dal punto di vista del vendor, 5 minuti bilancia il cache-hit rate per pattern comuni contro la memory pressure.

Dal punto di vista del loop autonomo, il TTL è un confine economico stretto; la cadenza del loop deve allinearsi con esso. I vendor potrebbero scegliere TTL più lunghi (15 minuti, 1 ora) — e infatti il tier di upgrade da 1 ora di Anthropic riflette la domanda per questo. Il fatto duro è che il tier standard attuale è 5 minuti, e i loop devono essere progettati per questo.

(a) Il modello di costo assume che la struttura di pricing della cache rimanga stabile; i cambiamenti di pricing del vendor invalidano i parametri. Abbiamo osservato due cambiamenti di pricing Anthropic tra Q3 2024 e Q1 2026; il modello necessita di ri-calibrazione periodica. (b) Il trade-off detection-latency vs cost è workload-specific; per workflow ad alta criticità la cadenza cost-optimal potrebbe non essere accettabile. Documentiamo criteri di esenzione espliciti (alerting loop, deploy-status watcher) dove la cadenza è dettata dall'SLA non dal costo. (c) Il pattern richiede observability per-loop (tracking del cache-hit-rate), che non tutti i team hanno configurato; il costo di attivazione della strumentazione è non-banale. (d) L'eviction della cache lato piattaforma in condizioni di cache-pressure può accorciare il TTL effettivo sotto i 5 minuti documentati; abbiamo osservato ~3% di iterazioni nei nostri dati dove iterazioni a cadenza 270s hanno comunque mancato la cache a causa di eviction lato piattaforma. (e) Il modello assume comportamento di cache single-tenant; le dinamiche di cache-pressure multi-tenant nell'infrastruttura condivisa potrebbero spostare la cadenza ottimale.

(1) ALGORITMI DI CADENZA ADATTIVI che apprendono il sampling rate ottimale dalla frequenza di eventi osservata, spostandosi dinamicamente tra regimi cache-warm e cache-cold basandosi sulla detection-utility-per-cost. (2) DASHBOARD DI COST-COMPARISON MULTI-VENDOR che espone la cadenza ottimale cache-aware per ogni vendor in tempo reale. (3) INTEGRAZIONE CON IL SELF-PACING DI AUTORESEARCH (WSB-14) per unificare la selezione della cadenza tra tutti i loop autonomi via una singola primitiva di policy. (4) CACHE-PRESSURE MONITORING per rilevare l'eviction lato piattaforma e aggiustare il margine di sicurezza di conseguenza. (5) CROSS-VENDOR LOAD BALANCING — quando più vendor sono disponibili, instradare le iterazioni a quello con la cache-pressure corrente più bassa per mantenere l'hit rate.

Pre-ottimizzazione: cadenza di 5 minuti, costo $0.94/giorno, detection latency 5 minuti worst case. Post-ottimizzazione: cadenza 270s (cache-warm), costo $0.11/giorno, detection latency 4.5 minuti worst case. Riduzione di costo 88%, miglioramento di detection-latency 10%.

Output funzionale: 100% identico nella settimana di confronto A/B (147 eventi newsletter-rilevanti rilevati, gli stessi 147 in entrambi i bracci). ROI sulla strumentazione: 3 giorni.

Pre-ottimizzazione: cadenza di 10 minuti, costo $0.62/giorno. Post-ottimizzazione: cadenza 1200s (cache-cold, a causa dell'alta variabilità nel contenuto per-iterazione), costo $0.16/giorno. Abbiamo anche applicato batch-window aggregation: invece di fare polling su ogni lead individualmente, il loop aggrega fino a 50 lead per iterazione. Risparmi combinati: 92%.

Una sessione di autoresearch di 4 ore pre-policy: ~$9.40 in costo di loop-overhead (separato dalle chiamate LLM di ricerca effettive). Post-policy: $1.20. La skill autoresearch ora dichiara la cadenza come "exploration-cold" (1500s, tra iterazioni di esplorazione) o "synthesis-warm" (180s, quando l'agent è in active synthesis mode). La cadenza si sposta dinamicamente basandosi sull'asse di composite-scoring che WSB-14 misura.

CASE STUDY · §31b · CALENDAR-CONFLICT DETECTOR. Pre-ottimizzazione: cadenza di 15 minuti, costo $0.41/giorno. Il loop fa polling dell'API Google Calendar per meeting imminenti e rileva conflitti di scheduling.

Post-ottimizzazione: cadenza 270s (cache-warm, dato che il system prompt + le rule di parsing calendario sono stabili tra le iterazioni), costo $0.06/giorno. Detection latency migliorata da 15 minuti a 4.5 minuti — e abbiamo scoperto 11 conflitti di calendario in un mese che la cadenza più lenta aveva mancato (perché il conflitto era risolto dall'altra parte prima del prossimo polling di 15 minuti). Riduzione di costo 85% E miglioramento funzionale.

CASE STUDY · §31c · CONTENT-PIPELINE PACER. Il loop content-pipeline-pacer guida il sistema di produzione contenuti Madani: monitora quali pezzi sono dovuti, quali necessitano di review, quali sono bloccati. Pre-ottimizzazione: cadenza di 30 minuti, costo $0.22/giorno.

Il prompt del loop include le hard rule complete di content-production (un grande documento statico) + stato pipeline variabile. Abbiamo ristrutturato: hard rule come prefix (10K token), stato pipeline come suffix (tipicamente 500-2000 token). Poi abbiamo spostato la cadenza a 270s (il loop beneficia di un pacing più frequente).

Ottimizzazione combinata cache-prefix + cadenza: il costo è calato a $0.08/giorno nonostante 6.7× più iterazioni al giorno. Il design cache-prefix era la leva dominante qui perché le rule statiche sono grandi rispetto allo stato variabile.

CASE STUDY · §31d · SUPPORT-QUEUE TRIAGER. Pre-ottimizzazione: cadenza di 5 minuti (dead zone), costo $1.20/giorno. Il loop legge i support ticket in arrivo, classifica l'urgenza, instrada al workflow appropriato.

Post-ottimizzazione: cadenza 270s + batch-window aggregation (processa fino a 20 ticket per iterazione), costo $0.18/giorno. La sola batch aggregation ha aggiunto 40% di risparmi oltre il fix della cadenza perché il costo di cache-write è ammortizzato su più input per iterazione.

CASE STUDY · §31e · DEPLOY-STATUS WATCHER. Pre-ottimizzazione: cadenza di 10 minuti, costo $0.55/giorno. Il requisito di detection-latency è laschi (i deploy sono solitamente attesi; mancare uno status di 20 minuti è accettabile).

Post-ottimizzazione: cadenza 1800s (cache-cold, più profondo nel regime long-tail), costo $0.04/giorno. La detection latency di 30 minuti è accettabile per questo workload. Riduzione di costo del 93% senza impatto funzionale.

ANALISI FORMALE · §32a · DERIVAZIONE DELLA CADENZA OTTIMALE. Dato il costo di iterazione C_warm nel regime cache-warm, il costo C_cold nel regime cache-cold, l'utilità di detection-latency U(t) decrescente in t, e il budget totale di costo giornaliero B: il problema di ottimizzazione è scegliere t che minimizza il costo totale mantenendo U(t) sopra la soglia. Nel regime cache-warm (t < T_cache), il costo totale giornaliero è (86400/t) C_warm, monotonicamente decrescente in t fino a T_cache.

Al confine, il costo salta a (86400/t) C_cold, monotonicamente decrescente da lì in poi. La funzione di costo ha due minimi locali: uno a t = T_cache - epsilon (appena dentro cache-warm), uno a t -> infinito (coda cache-cold). Il minimo globale dipende dal rapporto C_cold / C_warm: a 10:1 (Anthropic), il minimo cache-warm è approssimativamente 8× più basso della dead-zone, e la coda cache-cold incrocia sotto il minimo cache-warm a approssimativamente t = 4 T_cache.

Sotto 4 T_cache, cache-warm è più economico; sopra, cache-cold è più economico. La dead zone (T_cache a 4 T_cache) è uniformemente dominata da entrambe le alternative.

ANALISI FORMALE · §32b · SENSIBILITÀ AL PRICING RATIO. Il rapporto 10:1 cached-vs-uncached è specifico al pricing Anthropic Q1 2026. Se il rapporto fosse 5:1 (più tipico degli schemi di caching legacy), la dead zone si restringerebbe — il crossover cache-warm vs cache-cold si sposterebbe da 4 T_cache a 2 T_cache.

Se il rapporto fosse 20:1 (caching più aggressivo), la dead zone si estenderebbe a 8 T_cache. Il regime cache-warm è robusto attraverso tutti i ratio plausibili; il confine della coda cache-cold si sposta. La nostra policy di 4 T_cache per cache-cold è conservativa sotto il rapporto corrente; se il pricing del vendor migliora possiamo comprimerla.

ANALISI FORMALE · §32c · INTERAZIONE CACHE MULTI-MODEL. Quando un workspace usa più modelli concorrentemente (Sonnet per il primary, Haiku per il judge, Opus per i problemi difficili), ogni modello ha la sua cache. I loop che usano più modelli per iterazione devono tenere conto del cache hit rate per modello indipendentemente.

Abbiamo misurato: sui 24 loop Madani, 8 usano più modelli. Il cache hit rate per-modello è indipendente (R = 0.04 tra Sonnet hit rate e Haiku hit rate per lo stesso loop). Questo significa che progettare per una cadenza cache-warm per un modello non riscalda automaticamente l'altro.

Abbiamo aggiunto design cache-prefix per-modello dove applicabile.

ANALISI FORMALE · §32d · EFFETTI DI INFRASTRUTTURA CONDIVISA. La cache di Anthropic è documentata come "per-organization" — le cache non sono condivise tra organizzazioni, ma SONO condivise tra workspace all'interno di un'organizzazione. Abbiamo osservato evidenza (nelle brevi finestre in cui la nostra org aveva loop concorrenti in esecuzione) che loop concorrenti con prefix sovrapposti possono beneficiare delle scritture cache l'uno dell'altro.

Questa è un'ottimizzazione sotto-utilizzata: i loop che condividono un prefix comune (es. più loop che usano lo stesso documento di brand-voice) potrebbero essere schedulati per sovrapporsi nel tempo, beneficiando di una singola cache write condivisa. Non lo abbiamo ancora sfruttato sistematicamente; è un item di LAVORI FUTURI.

STEP 1 · STRUMENTARE. Modificare il runtime dell'agent per loggare cache_creation_input_tokens, cache_read_input_tokens, input_tokens per ogni chiamata LLM. Anthropic li espone nell'oggetto usage; forwardare al proprio stack di observability.

STEP 2 · AUDITARE I LOOP ESISTENTI. Computare il cache-hit rate corrente per loop. Loop <50% di hit rate sono candidati dead-zone.

STEP 3 · CLASSIFICARE. Categorizzare la detection latency richiesta da ogni loop: <5min (candidato cache-warm 270s), 5-20min (considerare 1200s cache-cold), >20min (qualsiasi valore >1200s). STEP 4 · APPLICARE.

Spostare i loop fuori dalla dead zone. Usare 0.9 T_cache per cache-warm; 4 T_cache per cache-cold. STEP 5 · MONITORARE.

Tracciare il cache-hit rate settimanalmente. Cadute sotto soglia (usiamo 90%) triggerano investigazione. STEP 6 · REFACTOR CACHE-PREFIX.

Auditare i prompt per la shared-prefix fraction. Spostare il contenuto stabile prima; il contenuto volatile dopo. STEP 7 · BATCH AGGREGATION.

Per i loop ad alto volume, passare da iterazioni per-item a iterazioni batched.

(1) LA TRAPPOLA "5-MINUTI SUONA GIUSTO": cadenza scelta per ragioni cognitive piuttosto che economiche; produce costo dead-zone. (2) LA FALLACIA ""LA CACHE LO GESTIRÀ"": assumere che la piattaforma ottimizzi automaticamente; la cache funziona solo se la cadenza è entro il TTL. (3) IL BUG ""TIMESTAMP VARIABILE NEL SYSTEM PROMPT"": includere il tempo corrente o timestamp per-iterazione nel prefix rompe l'eleggibilità della cache per l'intero prefix. Spostare i time stamp al suffix. (4) IL BUG ""DRIFT DELLE TOOL DEFINITION"": tool definiti leggermente diversi per iterazione (ordine diverso, formattazione diversa) rompono l'eleggibilità della cache sulle tool definition. Pinnare le tool definition byte-identical tra le iterazioni. (5) L'ANTI-PATTERN "ONE-LOOP-FITS-ALL": una singola cadenza globale su loop eterogenei; ogni loop ha una struttura di cache diversa e necessita di classificazione individuale. (6) L'ANTI-PATTERN ""BENCHMARK UNA VOLTA, DIMENTICA"": i vendor cambiano pricing e parametri della cache; senza re-audit trimestrale il modello di costo deriva dalla realtà.

Ri-validiamo il modello trimestralmente. (7) L'ANTI-PATTERN ""CACHE-HIT-RATE SENZA CONTESTO"": un cache hit rate dell'80% sembra buono ma è privo di significato senza conoscere la proporzione del totale dei token cached. Un loop con 80% di cache hit su un prefix minuscolo e 20% di miss su un suffix enorme può comunque essere un disastro di costo. Normalizzare sempre il cache-hit per il volume totale di token.

FRONTIERA DI RICERCA APERTA · §34 · 5 DIREZIONI CHE IL PATTERN APRE. (1) DYNAMIC CADENCE LEARNING — uno scheduler di loop control-teoretico che apprende la cadenza ottimale per loop da segnali osservati di frequenza di eventi, costo, e detection-utility. Il problema di apprendimento è non-banale perché la funzione di costo è non-monotonica e la funzione di utilità è workload-specific. (2) CROSS-LOOP CACHE SHARING — quando più loop condividono contenuto di prefix, schedularli per co-locarsi nel tempo così che una singola cache write serva tutti. Richiede una primitiva di scheduling a livello di workspace che non esiste nei framework correnti. (3) MULTI-TIER CACHE OPTIMIZATION — con il tier di upgrade da 1 ora disponibile, la decisione di cadenza ottimale diventa ternaria (5-min standard, 1-hour upgrade, no-cache).

Le soglie di crossover dipendono dalla frequenza di iterazione e dalla dimensione del prefix. (4) ADVERSARIAL CACHE-PRESSURE TESTING — cosa succede ai loop autonomi quando la cache pressure platform-wide accorcia il TTL effettivo? Costruisce resilienza nella policy. (5) CACHE-AWARE A-MAC FACTOR — l'A-MAC scoring (Madani-Adaptive Cost) dovrebbe includere il cache hit rate come fattore esplicito insieme a latency, qualità, e accuratezza. Attualmente A-MAC è a 6 fattori; l'estensione cache-aware lo rende a 7 fattori.

DISCUSSIONE · §35 · IMPLICAZIONI PIÙ AMPIE PER IL PLATFORM DESIGN. Il TTL di 5 minuti è una decisione vendor-side con massicce conseguenze user-side. I vendor che espongono la cache come una variabile first-class user-facing (piuttosto che come un'ottimizzazione di piattaforma nascosta) abilitano gli utenti a progettarci sopra.

I vendor che nascondono la cache astraggono gli utenti nel pricing della dead-zone. Argomentiamo che il futuro del platform design LLM dovrebbe includere: (a) cache-hit-rate per-iterazione esplicito nei metadati di risposta di default (Anthropic lo fa; OpenAI parzialmente), (b) dashboard di cache-pressure per-organization (nessun vendor attualmente lo espone), (c) primitive di policy per scheduling cache-aware a livello di piattaforma (nessun vendor attualmente le espone). Finché i vendor non forniscono queste, la strumentazione a livello di workspace come documentato in questo paper è il workaround.

DISCUSSIONE · §36 · PERCHÉ QUESTO CONTA OLTRE IL COSTO. La riduzione di costo del 60-80% è il numero headline, ma l'insight sottostante è architetturale: il prompt caching introduce una step-function nello spazio di costo che si propaga nel linguaggio di design degli agent. I framework agentic futuri dovrebbero adottare astrazioni cache-aware: una primitiva "scheduled loop" che prende (T_cache, hit_target, cold_threshold) come parametri e computa la cadenza piuttosto che chiedere all'utente di specificarla.

Il pattern di "rendere visibile l'economia di livello-piattaforma nel linguaggio di design" è una disciplina di design generale che si estende oltre il caching — vedere anche: rate limit, context window, model selection. Ognuno di questi è un confine di livello-piattaforma contro il quale il codice utente dovrebbe essere progettato.

[1] Anthropic (2025), Prompt Caching Documentation, docs.anthropic.com/claude/docs/prompt-caching. [2] Anthropic (2024), Prompt Caching beta announcement, August 2024. [3] OpenAI (2024), Prompt Caching for Reduced Latency, platform.openai.com/docs/guides/prompt-caching. [4] Google DeepMind (2025), Gemini Context Caching API, ai.google.dev/gemini-api/docs/caching. [5] Pope R., Douglas S., Chowdhery A., Devlin J., Bradbury J., Levskaya A., Heek J., Xiao K., Agrawal S., Dean J. (2023), Efficiently Scaling Transformer Inference, MLSys. [6] Liu N. et al. (2024), Lost in the Middle: How Language Models Use Long Contexts, TACL. [7] Kwon W. et al. (2023), Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM), SOSP. [8] Zheng L. et al. (2024), SGLang: Efficient Execution of Structured Language Model Programs, NeurIPS. [9] Jiang H. et al. (2023), LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models, EMNLP. [10] Karpathy A. (2024), autoresearch: a self-paced strategic loop, personal blog. [11] Wu Q. et al. (2024), AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, ICML. [12] LangChain (2024), LangGraph: Stateful Multi-Actor Applications, langchain.com/langgraph. [13] Inngest (2024), Scheduled Functions Documentation. [14] Temporal (2024), Cron Workflows. [15] Cemri M., Pan M.Z., Yang S., Agrawal L.A., Chopra B., Tiwari R., Keutzer K., Parameswaran A., Klein D., Ramchandran K., Zaharia M., Gonzalez J.E., Stoica I. (2025), Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657v3, NeurIPS 2025. [16] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning, arXiv:2604.02460. [17] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [18] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [19] Anthropic (2025), Building Agents Cookbook. [20] Schick T. et al. (2023), Toolformer, NeurIPS. [21] Madani Lab (2026), autoresearch-madani skill v1.0. [22] Madani Lab (2026), Cache-Aware Loop Cadence Cost Model v1.0 (open spec + Python reference implementation). [23] OpenAI (2024), Assistant API Scheduled Invocations Documentation. [24] Anthropic (2025), CronCreate Tool Reference.