100K di contesto bastano: comprimi la memoria invece di comprare una finestra più grande

La finestra non è il problema

Ogni pochi mesi un laboratorio pubblica un modello con una finestra di contesto più grande e la conversazione riparte da zero: duecentomila token, poi un milione, poi due milioni. La promessa implicita è che la memoria sia un problema hardware e che qualcuno continuerà ad allargarla.

billion-context, un progetto TypeScript di ranxianglei che sale da fine settembre, prende la posizione opposta già nello slogan: con 100K di contesto basta. Non "basta per ora". Basta, se smetti di trattare la conversazione come un log a cui solo aggiungere.

È un proxy che sta tra il tuo agente di coding e l'API del modello. Le richieste ci passano dentro, vengono compresse e inoltrate. Le risposte vengono riscritte al ritorno. Sul modello non cambia niente. L'argomento è che la parte costosa non è mai stata la dimensione della finestra, ma quello che continuavamo a metterci dentro.

Come funziona la compressione

Il proxy analizza ogni richiesta nel formato Anthropic o OpenAI, fa girare il suo kernel di compressione sulla conversazione e inietta quattro strumenti che il modello può chiamare da solo: comprimere un intervallo di messaggi in un riassunto, decomprimere un intervallo quando servono di nuovo i dettagli esatti, cercare per parola chiave nei riassunti compressi e nei messaggi visibili, e controllare l'occupazione del contesto.

La scelta di progetto che conta è che sia il modello a decidere quando comprimere, non una soglia fissa. Il riassuntore integrato di un host di solito scatta quando la finestra si riempie e sostituisce tutto ciò che sta prima di un punto di taglio con un unico riassunto che non si può annullare. billion-context comprime a piccoli intervalli, li tiene reversibili e lascia intatta la cache dei prefissi.

Quest'ultimo è il dettaglio ingegneristico di cui vale la pena preoccuparsi. La cache dei prefissi è ciò che rende sostenibili le sessioni lunghe di un agente; se ogni compressione riscrive l'inizio della conversazione, la cache manca e paghi di nuovo prezzo pieno per tutta la cronologia. Il progetto dichiara un tasso di successo della cache del 95-97% in una sessione sana e un overhead della compressione non superiore al 2%. Sono numeri suoi, e fornisce comandi per attribuire un calo del tasso a una causa, di solito la scadenza del TTL della cache a monte o un cambio di modello.

Il numero che rende credibile la promessa

I fornitori sbandierano risparmi di token in continuazione. Qui l'insolito è uno studio longitudinale allegato al codice: quattro mesi e mezzo, tre host, 174,327 chiamate al modello, 18.76 miliardi di token di input cumulati su un solo host e circa 24.7 miliardi su tutti. Il rapporto dice che le sessioni più lunghe sono arrivate a 8,584-12,049 chiamate, con zero violazioni della finestra di contesto su modelli da 204,800 token.

Zero violazioni è la frase che conta. Vuol dire che nessuna sessione è morta perché la conversazione era diventata più grande del modello. Tutto il resto dello studio sta a valle di quella frase.

Ridefinisce anche cosa vuol dire "sessione lunga". Quasi tutti vivono i limiti di contesto come un degrado lento: l'agente diventa più vago, dimentica un vincolo di due ore prima, ricomincia a rileggere file già letti. Quando la finestra è davvero piena, la sessione di solito è già scarsa da un pezzo. Una compressione che gira di continuo affronta il degrado, non solo lo stop netto.

Se funzioni come promesso sul tuo carico di lavoro è un'altra domanda. I numeri sono autodichiarati, il benchmark è l'uso dell'autore, e "5 volte meno token" dipende interamente da quanto sono ripetitive le tue sessioni. Una sessione che legge quaranta file e ne modifica tre si comprime benissimo. Una che legge un unico file enorme e ci ragiona riga per riga ha molta meno ridondanza da piegare.

Cosa cambia nel giro quotidiano

La differenza pratica si vede nella parte noiosa di mezzo di un compito lungo. Un agente alle prese con un refactor ha tre tipi di memoria: cosa ha deciso, cosa ha letto, cosa ha provato e scartato. Un transcript grezzo tiene tutti e tre alla stessa risoluzione, ed è per questo che un refactor da quaranta file riempie la finestra di stack trace che non contano più.

La compressione lascia all'agente le decisioni a piena fedeltà, piega le prove nei riassunti e torna a prendere le righe esatte solo quando servono. È più o meno come lavora una persona: ti ricordi di aver spostato la validazione nel middleware, non dei sei tentativi falliti prima.

La modalità di fallimento è altrettanto umana. Se un riassunto perde l'unico vincolo che contava, "questo endpoint deve restare retrocompatibile", l'agente lo romperà allegramente quaranta minuti dopo, e il livello di compressione ti avrà fatto risparmiare soldi costandoti un bug. La reversibilità è ciò che rende la cosa sopravvivibile: puoi decomprimere e controllare cosa diceva davvero il riassunto.

Perché ora è una categoria

Ci sono almeno tre approcci diversi che si contendono lo stesso problema. Uno è la risposta del laboratorio: costruire una finestra più grande. Un altro è quella dell'harness: recuperare invece di ricordare, e tenere nel contesto solo un working set. Il terzo, quello che rappresenta billion-context, è tenere la conversazione e comprimerla sul posto, in modo reversibile.

I compromessi sono reali. Una finestra più grande è la più semplice e la meno controllabile; la paghi a ogni chiamata, che la cronologia sia rilevante o no. Il recupero è il più economico ma perde continuità, perché l'agente non sa cosa ha dimenticato. La compressione sul posto prova a tenere insieme continuità e costo, al prezzo di stare dentro il percorso delle tue richieste.

È quest'ultimo costo quello su cui vale la pena ragionare. Un proxy nel mezzo vede ogni prompt e ogni completion. Per uno sviluppatore singolo va bene. Per un'azienda con regole sul trattamento dei dati è una conversazione sulla compliance, e "abbiamo letto il codice, va bene" non è la stessa cosa di un audit.

C'è anche la questione minore della licenza. Il paper tecnico è MIT e sta nel repository. La licenza del repository in sé risulta "Other" invece di una licenza OSI standard. Se lo deployi dentro un'azienda, quella distinzione salta fuori.

L'implicazione scomoda

Se la compressione funziona abbastanza bene che 100K bastano, allora buona parte del marketing sulle finestre di contesto punta a un problema che costa meno risolvere nel software. Questo non rende inutili le finestre grandi, un singolo documento da 400 pagine deve pur stare da qualche parte, ma significa che "abbiamo un milione di token" è un argomento più debole di quanto suoni. È come pubblicizzare un serbatoio più grande invece di consumi migliori.

Cambia anche come dovresti scrivere un agente. Se la memoria è comprimibile, conviene spingere l'agente ad annotare quello che impara in forma strutturata, perché le note strutturate si comprimono molto meglio dei log grezzi. Una frase come "il middleware di auth legge il tenant dall'header, non dal cookie" vale mille righe di stack trace. Il livello di compressione premia la buona contabilità, e per uno strumento è una bella proprietà.

Il progetto è sopra il migliaio di stelle e intorno alle 400,000 download npm al mese, con badge per più di venti client. Non è una base installata da hobby. Suggerisce che il dolore sia reale e molto diffuso, e che la risposta a cui la gente allunga la mano non sia un altro zero nella dimensione della finestra.

Questo è il punto utile, qualunque strumento finirai per usare. Il contesto è un budget, non un contenitore. I team che lo trattano così continueranno a fare di più per dollaro, e quelli che aspettano una finestra più grande continueranno a pagare il privilegio di non decidere cosa conta.