L'utilizzo di token degli agenti OpenRouter è 5 volte il traffico umano, ma il vantaggio è dovuto soprattutto al contesto memorizzato nella cache

L'utilizzo di token degli agenti OpenRouter ha raggiunto 7,3 trilioni di token ad agosto, oltre cinque volte gli 1,4 trilioni attribuiti agli esseri umani sulla piattaforma. Eppure, secondo quanto riportato, oltre l'85% di quei token degli agenti proveniva da prompt memorizzati nella cache, non da istruzioni elaborate ex novo o risposte generate.

Questa distinzione complica l'affermazione secondo cui l'AI utilizzi ora più AI delle persone. Gli agenti generano chiaramente molto più traffico verso i modelli per attività. Tuttavia, il grafico misura i token instradati attraverso una singola piattaforma, non l'adozione globale dell'AI, la spesa, il lavoro produttivo o il valore economico.

Daniel Newman, CEO di Futurum Group, ha rilanciato i numeri in un post su X del 30 settembre. Ha previsto che il rapporto sarebbe passato da cinque a 10 volte, per poi crescere ulteriormente. Il dato di cinque volte deriva dal traffico OpenRouter osservato. Il dato di 10 volte resta una previsione senza una tempistica dichiarata né un modello di supporto.

La vera competizione non è quindi tra agenti e persone. È tra volume grezzo di token e lavoro utile. La distinzione è importante per gli sviluppatori che gestiscono cicli di agenti, le imprese che valutano i rendimenti e i fornitori di infrastruttura che pianificano la capacità di memoria.

L'utilizzo di token degli agenti OpenRouter ha superato una soglia chiara

I dati di agosto mostrano un cambiamento rilevante nel traffico verso i modelli, ma solo nell'ambiente misurato da OpenRouter.

OpenRouter gestisce un gateway che instrada le richieste tra modelli e fornitori di inferenza. La sua posizione offre all'azienda visibilità su un traffico applicativo diversificato, comprese conversazioni dirette, strumenti di coding e flussi di lavoro autonomi.

Il grafico riportato presenta l'utilizzo medio di token su sette giorni fino al 10 agosto 2026. Il traffico agentico ha raggiunto circa 7,3 trilioni di token, rispetto a 1,4 trilioni per il traffico umano.

Il rapporto risultante è di circa 5,2 a uno. Sostiene l'affermazione più circoscritta secondo cui gli agenti hanno generato cinque volte più traffico di token degli esseri umani su OpenRouter durante quel periodo di misurazione.

Non stabilisce lo stesso rapporto per ChatGPT, Claude, Gemini, deployment su cloud privati o modelli ospitati localmente. Questi sistemi rappresentano un traffico significativo che OpenRouter non può osservare.

OpenRouter ha inoltre riferito che l'utilizzo agentico era cresciuto di circa quattordici volte dal 6 febbraio. L'utilizzo umano di token è aumentato di circa 2,8 volte nello stesso periodo. Il traffico misto, che combina comportamenti umani e simili a quelli degli agenti, sarebbe cresciuto di circa 4,7 volte.

Il 6 febbraio è stata l'ultima data osservata in cui il traffico umano rimaneva superiore a quello degli agenti nel dataset. Ciò rende il risultato di agosto più significativo di un singolo picco giornaliero. Gli agenti avevano mantenuto e ampliato il loro vantaggio per circa sei mesi.

OpenRouter ha classificato ogni chiave API come agentica, umana o mista. Secondo quanto riportato, il sistema ha utilizzato sette segnali ponderati, tra cui i tassi di chiamate agli strumenti, il numero di turni e gli intervalli temporali tra le risposte.

Questo approccio è più informativo rispetto al basarsi esclusivamente sui nomi delle applicazioni. Un client API generico può eseguire un ciclo autonomo, mentre un'applicazione commercializzata come agente può restare sotto il controllo diretto di una persona.

Tuttavia, la classificazione comportamentale introduce incertezza. Le chiavi API possono servire più prodotti, team o casi d'uso. Un carico di lavoro può inoltre passare da un comportamento guidato dall'uomo a uno automatizzato senza cambiare credenziali.

La categoria mista riconosce questa ambiguità, ma non la elimina. Riassegnare una parte di quel traffico cambierebbe il rapporto tra agenti e persone.

C'è un'altra importante questione semantica. Gli agenti non sono clienti indipendenti nel senso economico abituale. Persone e organizzazioni li implementano, ne definiscono gli obiettivi, finanziano le loro richieste e decidono se i loro risultati abbiano valore.

Gli agenti sono meglio intesi come intermediari automatizzati. Una richiesta umana può avviare pianificazione, recupero di informazioni, esecuzione di strumenti, validazione, correzione e chiamate ripetute al modello.

Questo effetto moltiplicatore è l'evento centrale. La domanda di AI non è più determinata solo da quante persone aprono una finestra di chat. Dipende sempre più da quanta attività delle macchine viene attivata da ogni richiesta umana.

Il precedente studio sui 100 trilioni di token di OpenRouter ha individuato lo stesso cambiamento strutturale. Ha descritto l'inferenza agentica come una sequenza estesa che coinvolge pianificazione, strumenti, revisioni e interazioni ripetute con il modello.

Lo studio ha rilevato che la programmazione era diventata una fonte principale della crescita dei prompt. I prompt di programmazione raggiungevano inoltre, entro la fine del 2025, una lunghezza media di diverse volte superiore a quella dei prompt per scopi generali.

Questi schemi aiutano a spiegare perché gli agenti abbiano superato la soglia. Una persona potrebbe inviare una sola richiesta di coding. Un agente può ispezionare ripetutamente file, chiamare strumenti, rivedere risultati di test e reinviare il proprio contesto di lavoro.

Il grafico di agosto cattura questa amplificazione su scala di piattaforma. Non dimostra che il software autonomo abbia sostituito la domanda umana. Mostra che la domanda umana arriva sempre più attraverso sistemi che generano molte richieste a valle.

Una singola istruzione umana può attivare migliaia di operazioni del modello

Gli agenti consumano più token perché trasformano una singola richiesta in un processo computazionale continuativo.

Un'interazione convenzionale con un chatbot segue solitamente un ritmo visibile. Una persona scrive un prompt, riceve una risposta e decide se continuare. Ogni nuovo turno dipende da un'altra azione umana.

Un agente può continuare senza quella pausa. Interpreta un obiettivo, crea passaggi, sceglie strumenti, valuta i risultati e decide se è necessario un ulteriore tentativo.

Si consideri una migrazione software. Uno sviluppatore potrebbe chiedere a un agente di trasferire un'applicazione da un servizio cloud a un altro.

La prima chiamata al modello può esaminare la richiesta e formulare un piano. Le chiamate successive potrebbero ispezionare file di configurazione, cercare documentazione, modificare codice, eseguire test, diagnosticare errori e rivedere l'implementazione.

Ogni chiamata spesso include più della sola istruzione più recente. Può contenere regole di sistema, definizioni degli strumenti, dettagli del repository, messaggi precedenti, output dei comandi e decisioni precedenti dell'agente.

Questo materiale accumulato costituisce la finestra di contesto, ovvero il testo e i dati strutturati disponibili al modello durante una richiesta. Con il proseguire dell'attività, quel contesto può diventare molto più ampio del prompt umano originale.

L'uso degli strumenti aumenta ulteriormente il traffico. Un modello potrebbe generare una query di database, ispezionarne il risultato e poi richiamare il modello per decidere il passo successivo.

Gli agenti paralleli possono moltiplicare nuovamente il processo. Un coordinatore potrebbe delegare ricerca, coding, test e revisione a lavoratori distinti. Ogni lavoratore mantiene istruzioni e cronologia dell'attività proprie.

Questo spiega perché il volume di token possa crescere molto più rapidamente del numero di utenti. L'unità di base è passata da un turno di conversazione a un passaggio del flusso di lavoro.

I dati di OpenRouter riflettono anche la crescita dei carichi di lavoro di ragionamento e programmazione. Queste attività supportano naturalmente interazioni più lunghe perché comportano stato intermedio, strumenti esterni e validazione ripetuta.

Le evidenze accademiche suggeriscono che l'amplificazione possa diventare estrema. Uno studio del 2026 sul coding agentico ha rilevato che le attività degli agenti consumavano circa 1.000 volte più token rispetto alla chat sul codice nel suo contesto sperimentale.

La ricerca sui costi degli agenti ha inoltre rilevato ampie variazioni tra esecuzioni ripetute. Nei test dei ricercatori, l'utilizzo di token per la stessa attività variava fino a trenta volte.

In modo cruciale, più token non hanno prodotto risultati migliori con costanza. Le prestazioni spesso raggiungevano il picco a un livello intermedio, prima che il consumo aggiuntivo smettesse di offrire guadagni proporzionati.

Questa constatazione rafforza la tensione principale dietro l'utilizzo di token degli agenti OpenRouter. Un conteggio in crescita può rappresentare automazione produttiva, ripetizione inutile o una combinazione di entrambe.

I creatori di agenti subiscono quindi pressioni per misurare il lavoro completato, non solo l'attività generata. Indicatori utili includono modifiche al codice accettate, casi di assistenza risolti, transazioni riuscite e attività completate senza correzioni umane.

Un token è solo un'unità di elaborazione del testo. Non incorpora alcuna misura intrinseca di accuratezza, difficoltà, novità o valore aziendale.

Due flussi di lavoro possono consumare lo stesso numero di token producendo risultati molto diversi. Uno potrebbe risolvere un difficile problema di ingegneria. L'altro potrebbe ripetere un piano fallito finché un limite non lo interrompe.

La progettazione del sistema circostante determina quale risultato sia più probabile. Test di completamento chiari aiutano un agente a riconoscere il successo. Politiche di ripetizione limitate impediscono a un'attività fallimentare di proseguire indefinitamente.

Buoni strumenti riducono inoltre la necessità di un ragionamento testuale prolisso. Un'API strutturata può restituire un risultato preciso che altrimenti richiederebbe navigazione e interpretazione ripetute.

L'architettura della memoria è importante per la stessa ragione. Un agente non ha bisogno di ogni vecchio dettaglio in ogni passaggio. Gli serve il sottoinsieme che rimane rilevante per la decisione corrente.

È qui che una base di conoscenza personale ricercabile può supportare flussi di lavoro guidati dall'uomo. Le evidenze recuperate possono sostituire una cronologia indiscriminata quando il sistema seleziona attentamente il contesto.

La pressione si estende oltre gli sviluppatori. Gli acquirenti aziendali devono ora valutare come i prodotti controllino i cicli, recuperino il contesto e riportino i consumi.

Un prodotto può apparire efficiente durante una breve dimostrazione ma comportarsi diversamente nei carichi di lavoro di lunga durata. Le attività di produzione incontrano autorizzazioni mancanti, obiettivi ambigui, dati in evoluzione e risposte impreviste degli strumenti.

Queste condizioni generano tentativi ripetuti. Rivelano inoltre se l'agente disponga di regole di arresto affidabili o semplicemente continui a produrre passaggi successivi plausibili.

L'adozione umana resta importante, ma non predice più da sola la domanda di inferenza. La formula più utile include utenti, attività delegate, chiamate al modello per attività e token per chiamata.

Quella formula rende in linea di principio plausibile un rapporto di dieci volte. Non rende inevitabile la previsione di Newman. Il rapporto dipenderà anche dall'ottimizzazione, dal comportamento dei modelli, dalla progettazione delle applicazioni e dal traffico al di fuori di OpenRouter.

I prompt memorizzati nella cache spiegano gran parte dell'esplosione dei token

La parte più ampia del vantaggio degli agenti sembra derivare dal contesto ripetuto, non da ragionamenti o output interamente nuovi.

Secondo quanto riportato, oltre l'85% dei token degli agenti nella presentazione di a16z proveniva da prompt memorizzati nella cache. I prompt memorizzati nella cache sono segmenti di input elaborati in precedenza che un fornitore può riutilizzare quando una richiesta successiva inizia con contenuti corrispondenti.

Un agente reinvia spesso materiale stabile. Questo materiale può includere istruzioni di sistema, descrizioni degli strumenti, file di progetto, policy e cronologia delle conversazioni precedenti.

Elaborare lo stesso prefisso da zero a ogni chiamata sprecherebbe capacità computazionale. Il caching dei prompt consente al fornitore di riutilizzare risultati intermedi associati a quel prefisso.

La telemetria della cache di OpenRouter separa i token memorizzati nella cache dai token di prompt elaborati ex novo. Può inoltre identificare i token scritti in una cache per il riutilizzo futuro.

Ciò significa che 7,3 trilioni di token non devono essere interpretati come 7,3 trilioni di unità di nuovo lavoro del modello. Una quota ampia rappresenta informazioni che il sistema ha già incontrato.

La distinzione incide sui costi. I fornitori generalmente applicano un prezzo inferiore per una lettura dalla cache rispetto all'elaborazione di nuovo input, perché gran parte del calcolo precedente è già avvenuto.

Tuttavia, memorizzato nella cache non significa gratuito. Il sistema deve identificare la voce della cache, recuperarne i dati e rendere disponibile durante l’inferenza lo stato del modello associato.

Lo stato del modello rilevante viene spesso chiamato cache chiave-valore, o cache KV. Memorizza informazioni di attenzione derivate dai token precedenti, così il modello può proseguire senza ricalcolare ogni posizione precedente.

Prompt più lunghi generano cache KV più grandi. Più sessioni di agenti in contemporanea ne generano di più. I flussi di lavoro di lunga durata possono inoltre richiedere accessi ripetuti a un contesto memorizzato sostanziale.

Questo sposta il collo di bottiglia dell’infrastruttura. Il calcolo resta importante, ma capacità di memoria, larghezza di banda della memoria e spostamento dei dati diventano sempre più rilevanti.

Ecco perché la quota memorizzata nella cache non rende privi di significato i dati di OpenRouter. Cambia ciò che i dati significano.

Il grafico è meno solido come prova della domanda di nuovo ragionamento. È più solido come prova del fatto che i sistemi di agenti trasportano ripetutamente cronologie estese attraverso molte chiamate al modello.

La differenza ricorda la consultazione ripetuta dello stesso grande raccoglitore di progetto. Rileggere pagine già familiari richiede meno preparazione che analizzare pagine nuove, ma il raccoglitore deve restare disponibile.

La cache può anche rendere finanziariamente tollerabile una progettazione inefficiente degli agenti. Un flusso di lavoro potrebbe reinviare un enorme prompt di sistema perché la lettura della cache scontata nasconde una parte del costo.

Quella progettazione continua comunque a consumare capacità. Può aumentare la latenza, complicare il routing e creare dipendenza da prefissi di prompt stabili.

I cache hit non sono garantiti in ogni configurazione. Modificare una parte iniziale del prompt può invalidare il materiale memorizzato successivamente nella cache. Anche instradare le richieste tra provider può influire sul riutilizzo.

I dati dinamici presentano un’altra sfida. Se timestamp, documenti recuperati, risultati degli strumenti o dettagli specifici dell’utente compaiono vicino all’inizio, possono ridurre la stabilità del prefisso.

Gli sviluppatori di agenti hanno quindi bisogno di una struttura del contesto intenzionale. Le istruzioni stabili dovrebbero stare vicino all’inizio, mentre le informazioni variabili dovrebbero comparire dopo le sezioni riutilizzabili, quando il comportamento del provider lo consente.

Anche l’affinità di sessione può essere importante. Le richieste che restano associate a un provider compatibile hanno maggiori probabilità di riutilizzare il contesto precedente rispetto a richieste instradate in modo imprevedibile.

Anche il dato dell’85% merita un’attribuzione attenta. Secondo il rapporto fonte, è apparso nel modo in cui a16z ha presentato i dati di OpenRouter. L’analisi originale di OpenRouter è stata descritta anche come indicativa di una quota inferiore secondo un altro calcolo.

Denominatori diversi possono produrre percentuali diverse. Un metodo può aggregare l’intero volume di token, mentre un altro calcola la media della quota memorizzata nella cache tra le richieste.

Alcuni flussi di lavoro enormi possono dominare il volume totale senza rappresentare la richiesta tipica. Al contrario, una percentuale media per richiesta può sottostimare l’influenza dei carichi di lavoro più grandi.

Entrambe le misurazioni possono essere accurate pur rispondendo a domande diverse. Il grafico pubblico non fornisce dettagli metodologici sufficienti per riconciliare in modo indipendente ogni percentuale di cache riportata.

La conclusione più prudente è quindi direzionale. Il contesto memorizzato nella cache costituisce la netta maggioranza del traffico di token degli agenti, mentre la quota precisa dipende da come la piattaforma aggrega le richieste.

Questo mette anche in discussione l’espressione “l’AI usa l’AI”. Gli agenti non stanno necessariamente compiendo trilioni di atti indipendenti di ragionamento. Gran parte del loro traffico consiste nel ripristinare il contesto necessario per proseguire il lavoro delegato.

Questo comportamento può comunque generare valore reale. Un agente di coding ha bisogno dello stato del repository e delle decisioni precedenti per evitare di ripartire da zero dopo ogni chiamata a uno strumento.

La questione dell’efficienza riguarda la selezione. L’agente ricarica il contesto utile più piccolo, oppure reinvia ripetutamente tutto perché è più semplice da implementare?

Con l’aumento del volume di token, questa differenza diventa una scelta ingegneristica sostanziale. Una gestione efficiente del contesto può ridurre la domanda di memoria senza indebolire le prestazioni del compito.

Cinque Volte i Token Non Significano Cinque Volte il ROI

Il volume di token misura l’utilizzo, mentre il ritorno sull’investimento dipende da risultati riusciti e dal costo operativo totale.

Newman ha sostenuto che le aziende si concentrano troppo sull’adozione da parte delle persone quando valutano i rendimenti dell’AI. Il suo punto più ampio ha valore, perché un singolo utente può ora avviare molta più inferenza di quanto riveli una metrica di adozione basata sulla chat.

Gli utenti attivi mensili possono sottostimare la domanda infrastrutturale. Il numero di postazioni può inoltre non cogliere il lavoro automatizzato che continua dopo che i dipendenti hanno lasciato la scrivania.

Eppure sostituire il conteggio degli utenti con il conteggio dei token crea un’altra misura incompleta. I token rivelano attività, ma non mostrano se quell’attività ha generato ricavi, ridotto il lavoro umano, migliorato la qualità o aumentato il rischio.

Il rapporto di cinque volte confronta inoltre due categorie di traffico, non due attori economici. Le richieste degli agenti restano a valle di decisioni umane o organizzative.

Un’azienda non ottiene un rendimento perché un agente ha consumato più token. Ottiene un rendimento quando l’agente completa un lavoro di valore a un livello di costo e rischio accettabile.

Una valutazione utile parte dal successo del compito. I team dovrebbero chiedersi se il flusso di lavoro ha completato l’azione prevista e se una persona ha accettato il risultato.

La domanda successiva riguarda l’intervento. Un agente che conclude senza supervisione ha un profilo operativo diverso da uno che richiede correzioni ripetute.

Anche la latenza conta. Un flusso di lavoro che alla fine riesce può comunque fallire commercialmente se i clienti devono attendere troppo o se le code infrastrutturali crescono sotto carico di picco.

Poi arriva il costo totale. I costi dei token sono solo una componente. Chiamate agli strumenti, servizi di ricerca, database, sandbox, osservabilità, revisioni di sicurezza e correzioni umane possono aggiungere spese sostanziali.

Contano anche i risultati corretti per il rischio. Un agente che modifica sistemi di produzione necessita di controlli più rigorosi rispetto a un agente che riassume documenti pubblici.

Il grafico di OpenRouter non può rispondere a nessuna di queste domande. È stato progettato per descrivere il traffico, non i rendimenti aziendali.

La stessa limitazione si applica alla previsione di Newman di 10 volte. Estrarre il rapporto presuppone che il traffico degli agenti continui a crescere più rapidamente del traffico umano senza una correzione dell’efficienza comparabile.

Questa ipotesi può fallire per diverse ragioni. Le applicazioni possono comprimere il contesto, usare modelli più piccoli per i passaggi di routine, sostituire il ragionamento ripetuto con software deterministico e interrompere prima i cicli.

I miglioramenti dei modelli possono ridurre i tentativi ripetuti. Anche interfacce degli strumenti migliori possono restituire informazioni più pulite, riducendo il numero di chiamate necessarie per completare un compito.

La pressione economica incoraggerà questi cambiamenti. Le aziende hanno un incentivo a eliminare le chiamate che non migliorano i risultati, anche quando le letture dalla cache sono relativamente economiche.

La discussione di a16z sulla convergenza dei loop evidenzia lo stesso problema. Un agente può continuare a produrre lavoro aggiuntivo dopo che è già emersa gran parte del valore disponibile.

Un loop privo di un test esterno di completamento può confondere l’attività continua con il progresso. Potrebbe modificare ripetutamente un documento, rieseguire un comando che fallisce o perfezionare una risposta già accettabile.

Questo comportamento è particolarmente difficile da rilevare quando ogni singola chiamata sembra ragionevole. Lo spreco emerge lungo l’intera traiettoria anziché all’interno di una risposta.

L’osservabilità deve quindi operare a livello di compito. Gli sviluppatori hanno bisogno di tracce che colleghino ogni chiamata al modello all’uso degli strumenti, ai cambiamenti di stato, agli errori e ai risultati finali.

Anche i budget dovrebbero riflettere il valore del compito. Un’indagine ad alta rilevanza può giustificare più iterazioni di una normale richiesta di formattazione.

Le regole di escalation creano un altro confine. Quando l’agente incontra fallimenti ripetuti o autorizzazioni incerte, passare il controllo a una persona può essere più economico e sicuro.

C’è anche un effetto di selezione nel traffico di OpenRouter. La piattaforma serve sviluppatori che utilizzano deliberatamente un gateway per modelli, il che può produrre una composizione dei carichi di lavoro più tecnica rispetto alle applicazioni consumer.

La programmazione e i framework per agenti possono quindi occupare una quota maggiore in OpenRouter rispetto all’intero mercato dell’AI.

La scala di OpenRouter rende comunque importante la tendenza. I suoi dati coprono un traffico reale sostanziale tra molti modelli e provider. I risultati dovrebbero semplicemente restare legati a tale ambito.

Le relazioni della piattaforma introducono un’ulteriore considerazione. Andreessen Horowitz ha investito in OpenRouter, dando ad a16z un interesse nella crescita dell’infrastruttura di instradamento dei token.

Questo non invalida i dati. Rende più importanti una metodologia trasparente e una replica indipendente, soprattutto quando i dati supportano affermazioni ampie sull’economia dell’AI.

L’interpretazione più solida evita entrambi gli estremi. Il grafico non è né la prova che le macchine autonome siano diventate i principali clienti dell’AI né un vuoto artefatto della cache.

È la prova che le architetture degli agenti amplificano la domanda di inferenza. Mostra inoltre che questa amplificazione si basa attualmente in larga misura sul trasporto e sul recupero del contesto precedente.

Per gli acquirenti, la domanda centrale non è se un agente usi molti token. È se ogni ciclo aggiuntivo aumenti la probabilità di un risultato riuscito e di valore.

I Provider di Memoria e le Piattaforme per Agenti Affrontano una Pressione Immediata

Il cambiamento nel traffico premia i sistemi che gestiscono il contesto in modo efficiente e mette sotto pressione i prodotti che trattano il consumo di token come un indicatore del progresso.

I provider di modelli affrontano un carico di lavoro più complesso della normale chat richiesta-risposta. Le sessioni degli agenti possono restare attive più a lungo, chiamare ripetutamente strumenti e mantenere cronologie in crescita.

Questo carico di lavoro mette sotto pressione scheduler e sistemi di routing. I provider devono bilanciare località della cache, disponibilità dei modelli, latenza e affidabilità in presenza di una domanda mutevole.

Le piattaforme gateway come OpenRouter acquisiscono importanza strategica perché le applicazioni usano sempre più modelli diversi. Un flusso di lavoro può instradare pianificazione, coding, validazione e sintesi verso endpoint differenti.

Il routing dinamico può ridurre i costi o migliorare le prestazioni, ma può anche interferire con la cache. Una richiesta inviata a un provider diverso potrebbe perdere l’accesso a una cache stabilita in precedenza.

I provider che espongono metriche di cache chiare avranno un vantaggio con gli acquirenti più sofisticati. I team devono sapere quanti token erano nuovi, memorizzati nella cache, generati o scritti nello storage.

Anche i produttori di memoria affrontano domanda derivante da contesti più ampi e sessioni più concorrenti. La memoria ad alta larghezza di banda alimenta gli acceleratori per modelli, mentre memoria e storage convenzionali supportano i sistemi circostanti.

Tuttavia, il grafico non quantifica gli acquisti futuri di memoria. Mostra il traffico di token, non una mappatura esatta tra ciascun token e nuova capacità hardware.

La domanda di hardware dipende dall’architettura del modello, dai tipi di dati, dal batching, dall’espulsione della cache, dalla compressione e dal numero di sessioni simultanee. I miglioramenti software possono modificare ciascuna di queste relazioni.

Le piattaforme per agenti affrontano pressioni da un’altra direzione. I clienti confronteranno sempre più il lavoro utile per token, non soltanto l’accesso a modelli capaci.

I prodotti che nascondono il consumo dietro ampie dichiarazioni di utilizzo possono incontrare difficoltà quando i team finanziari aziendali richiedono un’economia a livello di compito. Gli acquirenti vorranno prove ripetibili sui propri carichi di lavoro.

Gli agenti di coding offrono un primo test perché i loro output possono essere valutati con build, test, revisioni e risultati di deployment. Questi segnali creano condizioni di arresto misurabili.

Altri ambiti restano più difficili. Ricerca, strategia e scrittura spesso non dispongono di un unico test oggettivo. Gli agenti possono continuare a perfezionare gli output senza un momento chiaro di completamento.

Questa incertezza rende più importante la revisione umana, anche quando gli agenti svolgono la maggior parte del lavoro intermedio. Rende inoltre più difficile confrontare l’efficienza dei token tra fornitori.

I fornitori di infrastruttura possono rispondere con compressione del contesto, caching dei prefissi, sessioni con stato e sistemi di recupero. Ogni approccio cerca di evitare il reinvio di cronologie non necessarie.

Gli sviluppatori di applicazioni possono separare la memoria persistente dal contesto di lavoro. La memoria persistente conserva informazioni potenzialmente utili, mentre il contesto di lavoro contiene soltanto ciò che è necessario al passaggio corrente.

Questa separazione riduce il testo ripetuto e limita le informazioni irrilevanti. Può anche migliorare l'accuratezza dei modelli, mantenendo le distrazioni fuori dal prompt attivo.

Il software deterministico dovrebbe occuparsi del lavoro deterministico. Un agente non deve ragionare su un calcolo, la convalida di uno schema o un controllo di accesso quando un codice affidabile può eseguirli direttamente.

I sistemi più efficienti probabilmente combineranno i modelli con il software convenzionale. I modelli gestiscono l'ambiguità e la pianificazione, mentre il codice applica le regole ed esegue operazioni stabili.

Questo progetto ibrido indebolisce l'ipotesi che il traffico degli agenti debba crescere senza limiti. Sistemi migliori possono completare più attività riducendo al contempo i token per attività.

Allo stesso tempo, la riduzione dei costi unitari può aumentare la domanda complessiva. Quando ogni flusso di lavoro diventa più economico, gli sviluppatori possono distribuire agenti in più contesti ed eseguirli più spesso.

Il conseguente effetto di rimbalzo può sostenere la crescita delle infrastrutture anche quando le singole attività diventano più efficienti. Questa possibilità supporta la direzione della previsione di Newman, anche se non il suo rapporto preciso.

Anche il traffico umano può crescere. Prodotti consumer migliori, nuove interfacce e una più ampia adozione nelle imprese potrebbero aumentare l'uso diretto parallelamente al traffico degli agenti.

Il rapporto futuro dipende da quale curva crescerà più rapidamente. Non è soltanto una funzione del miglioramento degli agenti.

La concorrenza tra OpenAI, Anthropic, Google, gli sviluppatori di modelli open-weight e i fornitori specializzati di inferenza plasmerà quella curva. Le loro regole di caching e le capacità degli strumenti differiscono.

Anche la scelta del modello può cambiare nel corso di un flusso di lavoro. Un modello piccolo potrebbe classificare una richiesta, mentre un modello più grande gestisce una decisione difficile.

Quell'architettura riduce la rilevanza di un singolo conteggio aggregato di token. Un token elaborato da un modello compatto ha un profilo di risorse diverso da uno elaborato da un modello frontier.

Le imprese avranno bisogno di misure normalizzate che combinino scelta del modello, tipo di token, latenza, energia e successo dell'attività. Al momento non esiste uno standard ampiamente accettato che catturi l'intero quadro.

Finché non ne verrà sviluppato uno, l'utilizzo di token degli agenti su OpenRouter rimane un utile indicatore anticipatore. Rivela la forma della domanda prima che la rendicontazione finanziaria possa spiegarne il valore.

Tre segnali metteranno alla prova la previsione del 10x

La prossima fase dovrebbe essere valutata in base alla stabilità della classificazione, alla crescita dei token nuovi e al lavoro completato per unità di inferenza.

Il primo segnale è se il rapporto tra agenti e umani di OpenRouter continuerà a crescere dopo agosto. Un aumento sostenuto supporterebbe l'idea che i flussi di lavoro autonomi si stiano espandendo più rapidamente dell'interazione diretta.

Il confronto dovrebbe utilizzare lo stesso metodo di classificazione e la stessa finestra di misurazione. Cambiamenti nel metodo potrebbero creare una crescita apparente senza un cambiamento equivalente nel comportamento.

Il traffico misto merita particolare attenzione. Se cresce più rapidamente di entrambe le categorie, il confine tra uso umano e uso degli agenti diventerà meno affidabile.

Il secondo segnale è la composizione dei token degli agenti. Una quota crescente di token memorizzati nella cache indicherebbe che la ripetizione del contesto, e non la nuova elaborazione del modello, resta il principale motore della crescita.

Una quota di cache in calo accompagnata da un volume totale in aumento racconterebbe una storia diversa. Suggerirebbe che gli agenti stanno svolgendo più nuova inferenza invece di riprodurre principalmente contesto già stabilito.

La rendicontazione pubblica dovrebbe distinguere tra nuovi input, letture della cache, scritture della cache, token di ragionamento e output. Riunirli in un unico numero nasconde differenze rilevanti nei costi e nella domanda infrastrutturale.

Il terzo segnale è l'efficienza delle attività. I fornitori di agenti e gli utenti aziendali dovrebbero riportare il lavoro completato per chiamata al modello, i token per attività completata con successo e gli interventi umani per completamento.

Se queste misure migliorano mentre il traffico totale degli agenti aumenta, la tesi della crescita diventa più solida. Indicherebbe che adozione e automazione riuscita si stanno espandendo insieme.

Se l'uso di token aumenta mentre il successo resta invariato, il grafico descriverebbe sempre più uno spreco operativo. Un rapporto più elevato indebolirebbe allora, anziché rafforzare, l'argomento relativo al ROI.

Anche dataset indipendenti migliorerebbero la fiducia. Il traffico proveniente dalle API dirette dei modelli, dalle piattaforme cloud e dalle distribuzioni private potrebbe mostrare se OpenRouter riflette il mercato più ampio.

Per ora, le prove supportano una conclusione più circoscritta rispetto all'affermazione virale. Gli agenti hanno generato più di cinque volte il traffico di token umano osservato su OpenRouter nell'agosto 2026.

La maggior parte di quel traffico sembra riguardare contesto memorizzato nella cache. Quel contesto richiede comunque memoria, instradamento e una gestione accurata, ma non dovrebbe essere confuso con una quantità equivalente di nuovo ragionamento.

Il passaggio a 10 volte è una previsione, non un risultato già consolidato. La sua importanza dipenderà da ciò che i token aggiuntivi realizzeranno.

Gli sviluppatori dovrebbero verificare che ogni ciclo abbia uno scopo chiaro, un budget e una condizione di arresto. Gli acquirenti aziendali dovrebbero richiedere prove a livello di attività prima di considerare il consumo come adozione.

La domanda utile non è più se gli agenti genereranno più traffico delle persone. I dati di OpenRouter suggeriscono che lo facciano già. La domanda è se il prossimo trilione di token completerà più lavoro, oppure si limiterà a rileggere una parte maggiore del passato.