Non Esiste Il Contesto

// Due Contesti Diversi, Stessa Risposta

Qualche settimana fa ho misurato una cosa spiacevole: quando lavori con un agente su un repository vero, la parte utile del contesto e' una briciola. Il resto e' l'harness che si racconta addosso, file riletti identici, output di comandi lunghi come romanzi. In Sei lo 0,1% ho messo i numeri sotto la lamentela. Bene. Questo e' il pezzo in cui smetto di lamentarmi e costruisco il pezzo di codice che rimette a posto la faccenda. Ma la parte che mi interessa non e' l'ottimizzazione, e' l'osservazione da cui esce. Parte da un articolo determinativo che nessuno guarda: il contesto.

La molla, per onesta', non e' stata il codice. E' stato un libro: Spectral Theory and Quantum Mechanics di Valter Moretti (Springer), un mattone sulla teoria degli operatori negli spazi di Hilbert, roba di meccanica quantistica che con gli agenti non c'entra niente. Leggendo di proiettori, kernel e decomposizioni spettrali mi e' venuta in mente la cosa che sto per raccontarti: e' lo stesso vocabolario che serve a dire cosa un agente puo' buttare via senza cambiare risposta. Metto le mani avanti subito, prima di riempire l'articolo di formule. Prendo in prestito le parole, proiezione, kernel, classe di equivalenza, non pretendo che qui viva un isomorfismo con quella matematica. E' un'analogia, la uso con cautela: serve a pensare la cosa giusta, non a fare le pulci a un teorema.

Prendi un agente che risolve un task. Chiamalo \( Q \). Dagli in pasto un contesto, cioe' il repository, la conversazione, gli output dei tool, e lui produce una risposta. Questa e' una funzione, niente di piu':

Adesso la mossa. Una funzione manda robe diverse sullo stesso valore in continuazione. Due contesti diversi possono darti la stessa identica risposta per quel task. E se ti danno la stessa risposta, per \( Q \) sono la stessa cosa. Questa e' una relazione di equivalenza, la scrivi cosi':

Da qui esce la frase che regge tutto l'articolo, e il plugin: non esiste "il" contesto. Il contesto non e' una cosa che l'agente riceve, e' una cosa che il task ritaglia. Esistono infinite rappresentazioni equivalenti sotto il task, una classe intera, \( [x]_Q \). L'agente non ha bisogno del documento. Ha bisogno di un rappresentante qualsiasi della classe. Se sai scegliere un rappresentante piccolo, hai vinto senza aver toccato la risposta. Non stai buttando via informazione, stai scegliendo un altro elemento della stessa classe. Questa mossa ha un nome preciso, ed e' astrazione, non compressione.

// Il Projector, E Cosa Butta Via

Scegliere un rappresentante piccolo e' applicare una mappa. La chiamo projector indotto dal task, \( \pi_Q \), e le chiedo due sole proprieta':

Il pedice \( Q \) non e' decorazione. Cambia la domanda e cambia cosa puoi buttare via. Quello che e' invisibile a "sistema questo KeyError" puo' essere l'unica cosa che conta per "controlla le intestazioni di licenza". Un projector senza indice del task o e' banale o e' sbagliato. Il projector non fa altro che applicare trasformazioni che stanno nel kernel del task:

Ho scritto \( T \) e non "\( x + \delta \)" apposta. Sommare due repository non vuol dire niente, non esiste un piu' tra due codebase. Una trasformazione si': tagliare un file, deduplicare un log, buttare una pagina di documentazione. Una \( T \) sta nel kernel del task quando, applicata a qualunque contesto, non sposta mai la risposta. Il kernel e' l'insieme di queste mosse gratis. Le millequattrocento pagine di documentazione di pandas che un errore su una merge non guardera' mai. I ventitre installer nella cartella Download quando il task e' rinominare le bollette. Applichi le trasformazioni del kernel, tieni il resto, la risposta non si accorge di niente.

// Due Kernel Di Natura Diversa

Il kernel si spezza in due pezzi, e la forma del plugin viene tutta da questa spaccatura. C'e' la roba invisibile a ogni task, e la roba invisibile solo a questo task.

Il kernel sintattico non dipende dalla domanda. Sono i codici ANSI di colore, le barre di avanzamento che si ridisegnano venti volte, le righe duplicate consecutive, un file riletto identico a quello che hai gia' in contesto. Roba che nessun task guardera' mai. Poiche' non serve sapere cosa stai facendo per sbatterla fuori, la togli in modo ambientale, con un hook che gira sempre e non chiede niente a nessuno.

Il kernel semantico e' invisibile solo a questo task. Le millequattrocento pagine di pandas per il KeyError. Qui devi sapere qual e' \( Q \), e infatti questa e' la parte difficile. Il primo pezzo lo togli gratis e ovunque. Il secondo lo togli quando c'e' un sintomo che ti dice quale task stai risolvendo: uno stack trace, un messaggio d'errore, dei file indiziati. Non c'e' un caso in cui questa distinzione non decida l'architettura. Chi mescola i due finisce per tagliare il codice sorgente prima di aver capito cosa serve, e a quel punto ha rotto la risposta senza accorgersene.

// Il Task State, In Quattro Operatori

Definisci lo stato del task come il rappresentante canonico piccolo, quello su cui l'agente lavora davvero:

L'agente non lavora mai sul repository. Lavora sul task state. Il projector \( \pi_Q \) lo fabbrico passando per quattro operatori, ognuno con un mestiere preciso. Il primo agisce sul dialogo, gli altri tre sul codice, e agiscono su fattori diversi del contesto: per questo commutano e l'ordine non fa danni.

T1 e' un hook PostToolUse: intercetta l'output di un comando dopo che e' stato eseguito e prima che arrivi al modello. Ecco cosa vede l'agente quando lancio un pip3 list su una macchina piena:

Millecinquantatre righe reali diventano novecentonovantacinque token. Il footer non e' cosmetico, e' un contratto: ti dice esattamente quanto e' stato tolto, cosi' sai che e' successo e quanto. Su una sessione vera, misurata dal contatore che scrive un log a parte, il risparmio complessivo si e' assestato intorno al meno settantanove per cento di token, con il segnale intatto.

T2 e' quello che mi ha insegnato di piu'. Misurare il budget in file nasconde un muro: certi file sono monoliti da migliaia di righe, e un working set di "tre file" puo' essere piu' pesante di trenta. Misurato in token, il muro si vede. Li' ho smesso di contare i file e ho iniziato a contare i token. La risposta e' scendere sotto il file, al singolo simbolo. Su pandas questo porta il task state al meno novantasei per cento sotto il pavimento che avresti tagliando a livello di file. Su lodash, un vero stack trace di node su millequarantotto file diventa un working set di trenta, con tutti e quattro i frame dello stack tenuti a ogni profondita' di taglio.

Qui la parola "projector" nasconde un pezzo che vale la pena tirare fuori. Quel budget in token non e' un parametro di comodo, cambia la proiezione. Con un milione di token di finestra puoi tenere molto, dipendenze lontane e qualche file di contorno. Con ottomila devi essere spietato, il seed e poco altro. Il projector quindi non dipende solo dal task, dipende anche dalle risorse:

Stesso bug, stesso repository, ma la fetta giusta a ottomila token e la fetta giusta a un milione non sono la stessa fetta. Lo slicer lo affronta scendendo una scala: chiusura piena, poi dipendenze fino a due salti, poi uno solo, finche' non sta nel budget. La proiezione e' relativa al task e alla tasca.

// Il Duale Mancante: Il Supporto Del Task

Ho definito il task state, cioe' quello che l'agente vede. Gli manca il duale, e il duale e' la parte piu' interessante. Chiamalo supporto del task:

Il supporto non e' il contesto, e non e' nemmeno il working set. E' il motivo per cui la risposta e' quella: le poche proposizioni che, se le togli, la risposta cambia davvero. Il task state e' generoso, tiene anche roba di contorno per sicurezza. Il supporto e' avaro, tiene solo cio' che giustifica. Qui T3 smette di essere un operatore tra i quattro e diventa il piu' ambizioso: la carta del task, i vincoli con citazione file:riga, e' un tentativo di costruire proprio \( \mathrm{Supp}(Q,x) \). Non "leggi tutto il working set", ma "ecco le dieci proposizioni che reggono la risposta, e da dove vengono". Un fix che le rispetta tutte e' corretto per costruzione, nei limiti di cio' che la carta ha saputo vedere.

// Non Prometto Che Basti, Lo Misuro

Answer-preserving e' facile da scrivere in una formula e difficile da garantire con l'analisi statica pura. Un import dinamico, un container di dependency injection, una configurazione che sceglie la classe a runtime: tutte cose invisibili al grafo degli import. Quindi il plugin non da' per scontato che la fetta basti, lo verifica misurando.

Sembra una precisazione da poco. Non lo e', e' un cambio di paradigma. Lo schema che oggi si vede quasi ovunque, e quello di qui, sono le stesse parole in ordine diverso:

Nella prima riga comprimi, passi il risultato al modello e incroci le dita: se hai buttato via la cosa sbagliata te ne accorgi dalla risposta storta, quando ormai e' tardi. Nella seconda trasformi, misuri che la trasformazione non abbia spostato la risposta, e solo dopo passi al modello. Il punto di controllo si sposta prima dell'LLM invece che dopo. La differenza sembra piccola perche' sono le stesse tre parole. In pratica e' la distanza tra un sistema che speri funzioni e uno che sai dove sbaglia.

Il benchmark e' l'atto del misurare. Prendi sessanta bug veri, di quelli con uno stack trace e un fix noto. Per ognuno lasci che context-kernel tagli il contesto, poi controlli una cosa sola: nella fetta rimasta c'e' ancora tutto quello che serve per risolvere quel bug? In termini dell'articolo, la fetta contiene il supporto?

La risposta e' si' in tutti e sessanta i casi, a ogni livello di taglio. Il dato interessante e' il perche'. Quello che rovina la fetta non e' quanto tagli in profondita', e' sbagliare il punto di partenza. Tagliare la chiusura del grafo, che sembra la cosa aggressiva, e' quasi gratis. Sbagliare il seed, che sembra un dettaglio, ti fa perdere il caso. E il benchmark si e' ripagato da solo. La prima volta ne risolveva cinquantuno su sessanta. Ho guardato i nove che mancavano, e non era la profondita' del taglio: era un bug vero di seeding, path assoluti ambigui dentro la root del progetto. Corretto, con un test di regressione che adesso lo tiene fermo.

C'e' un punto che ho sottovalutato a lungo. Di tutti i pezzi, quello che conta di piu' non e' il projector, e non e' lo slicer. E' \( T_4 \), la verifica. Il resto della teoria e' elegante, e potrebbe essere sbagliato: "answer-preserving" resta una parola finche' qualcuno non prova a mostrarti che la risposta e' cambiata. \( T_4 \) e' quel qualcuno. La verifica di invarianza, il benchmark dei sessanta casi, il canary, sono l'apparato che puo' dire di no. Senza, avrei una teoria che non si puo' smentire, cioe' la peggior specie di teoria. Con, ho qualcosa che un esperimento puo' rompere. Tengo la seconda.

// L'Inverso Non Esiste, Esiste L'Accesso

Qui va detta la cosa scomoda. Gli operatori si concatenano senza attriti: applichi \( T_2 \) dopo \( T_1 \), scrivi \( T_2(T_1(C)) \), e ne componi quanti ne vuoi, il risultato e' ancora una proiezione valida. Quello che non puoi fare e' tornare indietro. Non esiste un \( \pi_Q^{-1} \) che ti ridia quello che hai tolto: l'inverso di una proiezione non e' un'operazione, e' un percorso di accesso. Se ti serve una cosa proiettata via, non la "decomprimi", la vai a prendere. Questo e' il page fault, e nel plugin e' un meccanismo di prima classe, non un errore.

Le esclusioni sono dichiarate, non silenziose. Lo slicer, quando taglia, scrive cosa ha lasciato fuori e perche'. Se poi si scopre che serviva, la si recupera con una lettura mirata, e il conto di quella lettura e' piccolo e visibile. L'ho misurato su un bug vero, usando i bug del plugin stesso come task \( Q \):

Lo slicer statico da solo aveva sotto-sliciato: i test caricavano il modulo via importlib e subprocess, un arco che il grafo degli import non vede. I due page fault dichiarati hanno corretto il working set da uno a quattro sorgenti su quattordici, senza che la slice andasse invalidata. La carta del task, i dieci vincoli con citazione, ha intercettato due cose che il fix fatto a mano aveva sbagliato: una tensione con un test legacy, e una deviazione su un invariante che il primo tentativo aveva calpestato. Il verificatore ha chiuso con dodici vincoli su dodici rispettati. La lezione e' che l'onesta' sulle esclusioni costa meno del rumore che eviti.

// Lo Strumento Che Si E' Morso La Coda

Un hook che riscrive quello che l'agente vede e' pericoloso in un modo particolare: il contratto con l'harness non e' documentato, e puo' cambiarti sotto i piedi. Se un giorno la forma dell'output cambia e la tua sostituzione non viene applicata, il modello riceve la roba integrale e tu non te ne accorgi. Per questo ogni sostituzione lascia un canarino: registra il footer esatto che dovrebbe comparire, e poi controlla che sia comparso davvero. Non e' una garanzia che il contratto tenga, e' una difesa che ti avvisa nell'istante in cui si rompe.

Ha funzionato per davvero. Un allarme del canary ha segnalato una compressione che risultava applicata ma non lo era. Tirando il filo sono usciti tre bug veri. Il primo era il peggiore: le Read non venivano mai compresse. Per una Read la risposta del tool e' annidata in un modo diverso da Bash, e l'estrazione cercava la chiave nel posto sbagliato, quindi il testo estratto era vuoto e la compressione un no-op da sempre. Il secondo: il canary si dichiarava soddisfatto per un match troppo generoso, scattava anche sui contenuti che citavano il footer, tipo i log del progetto o i transcript riletti dalle sessioni headless. Il terzo, trovato mentre sistemavo i primi due: un output che veniva solo da stderr finiva distrutto invece che compresso.

Messa in fila, la corsa completa di quel bug, dal repository al verdetto, e' questa. Numeri veri, presi dalla telemetria della pipeline:

Il modello non ha mai visto i quattordici sorgenti, ne le migliaia di righe dei log di quella sessione. Ha visto quattro file, dieci vincoli e un test rosso. Ha prodotto il fix, e un altro giro di pipeline lo ha promosso a dodici vincoli su dodici. Questa e' la teoria di sopra applicata una volta sola, dall'inizio alla fine.

// L'Oggetto: context-kernel

Fin qui l'idea. L'implementazione si chiama context-kernel, e' un plugin nativo per Claude Code con un ripiego per Codex, e non ha niente sotto che non puoi leggere: solo libreria standard di Python, zero dipendenze, zero chiavi API. Registra da solo l'hook \( T_1 \), cioe' la compressione ambientale col canary, due tool MCP per lo slice (kernel_slice e kernel_repo_slice), cinque skill e tre agent per la pipeline \( T_2 \)-\( T_4 \). Versione 0.9.1, licenza MIT, il codice sta su GitHub.

Adesso il conto. La parte che importa non e' "quanto taglia", e' "quanto taglia senza spostare la risposta". Sui token il risparmio e' quello che hai gia' visto pezzo per pezzo, messo in fila:

Gli stessi numeri, caso per caso, cosi' non devi fidarti sulla parola:

L'agente continua a risolvere gli stessi casi. Il modo pulito di vederlo e' mettere la proiezione indotta dal task accanto al troncamento cieco, quello che tanti strumenti fanno tagliando testa e coda a naso:

Curva rate-distortion misurata: la proiezione lascia nella fetta tutto il necessario anche togliendo il settantacinque per cento del contesto; tagliare alla cieca perde la risposta gia' oltre il quaranta per cento.

Questo e' il senso di risparmiare senza perdere performance. Il risparmio arriva perche' togli solo quello che il task non usera' mai, e la risposta resta identica: per costruzione dove si puo', per misura dove non si puo'. In piu' due regali. Lo slice ripetuto va quarantasei volte piu' veloce grazie alla cache del manifest, e la verifica non costa una chiamata in piu' perche' gira in sessione. Centodiciassette test in circa sette secondi ti dicono se qualcosa si e' rotto prima che lo scopra l'agente.

Una cosa, per onesta', che forse leggendo hai gia' pensato. La teoria di sopra e' piu' generale del plugin. La proiezione indotta dal task non ha niente di specifico a Claude Code: ovunque un modello riceve piu' contesto di quanto il task ne chieda, la stessa mossa vale, con altri hook, un altro linguaggio, un altro harness. context-kernel e' dove l'ho misurata, non dove finisce. Se preferisci vederlo come l'implementazione particolare di un'idea piu' grande, lo vedi giusto.

Se dovessi dirti qual e' la cosa originale, non ti direi "il projector", ne "il kernel", ne i quattro operatori. Ti direi questa, la stessa di apertura: il contesto non e' un input assoluto, e' un oggetto relativo al task. Se questa premessa non ti convince, probabilmente non ti convincera' nemmeno il resto. Se invece la accetti, i quattro operatori, il page fault, la discesa al simbolo vengono quasi da soli: c'e' una classe di contesti equivalenti, ne scegli uno piccolo, e il lavoro diventa astrarre, poi misurare di non aver spostato la risposta. I numeri li puoi rifare tu, e' tutto deterministico e offline.

E' anche il motivo per cui la chiamo un'idea e non un pacchetto di feature: non sposta la soluzione, sposta la definizione del problema. Chi la prende sul serio non si chiede piu' "come comprimo il contesto", si chiede "cosa, di questo contesto, e' il task a renderlo tale".

Nota. context-kernel e' un plugin nativo per Claude Code, con un ripiego per Codex. Tutto e' libreria standard di Python, deterministico e offline; la sola cosa che usa il modello e' la verifica di invarianza, che gira in sessione con l'abbonamento e non con una chiave. I numeri vengono da misure ripetibili: pip3 list reale (14.900 -> 995 token), il benchmark di sessanta bug veri (in tutti la fetta tagliata bastava a risolverli), pandas e lodash su stack trace veri, e la telemetria della pipeline su un bug reale del plugin stesso. Centodiciassette test in circa sette secondi. Licenza MIT. I blocchi qui sopra sono estratti, condensati per leggibilita'; il codice integro sta nel repo. Panna, come al solito, non ha letto una riga e sta benissimo.