Il nuovo trucco più popolare su GitHub è parlare di meno

Il nuovo trucco più popolare su GitHub è parlare di meno

Il repository in più rapida crescita su GitHub questa settimana è un progetto Go chiamato caveman, con oltre 112.000 stelle, e tutta la sua premessa è una battuta che si dà il caso sia corretta. Il suo slogan recita: perché usare molti token quando pochi token bastano. È uno skill e un proxy per agenti di programmazione che dichiara di ridurre l'uso dei token di circa il 65 per cento facendo parlare il modello come un uomo delle caverne.

Togli la battuta e resta un'affermazione di ingegneria reale. La maggior parte di ciò che un agente di programmazione scambia non è informazione. È impalcatura, cortesia, ripetizione e i preamboli gentili che i modelli linguistici fanno per impostazione predefinita. Se riesci a buttare via tutto questo senza buttare via il significato, la sessione costa meno e la finestra di contesto arriva più lontano.

La battuta è anche la diagnosi. Quando la mossa vincente è far sembrare l'assistente più stupido, il collo di bottiglia non è l'intelligenza. È il sovraccarico.

La bolletta è il contesto, non il modello

Ci vuole un po' per interiorizzare come i carichi di lavoro degli agenti diventino davvero costosi. Il modello intuitivo dice che paghi per risposta, quindi una risposta lunga costa di più. Il modello reale è che paghi per ogni token di contesto a cui il modello deve prestare attenzione, e quel contesto cresce a ogni turno.

Quando un agente ha letto un repository, eseguito qualche comando, visto i risultati, scritto del codice e letto i messaggi di errore, la conversazione è enorme. Ogni nuovo turno si trascina dietro tutta la cronologia. Il decimo passo costa molto più del primo, non perché il modello sia diventato più lento, ma perché sta portando più peso.

Per questo uno strumento che taglia il 65 per cento dei token non è un'ottimizzazione marginale. Applicato a un agente che gira per ore, è la differenza tra una sessione che sta dentro un budget e una che va riavviata a metà.

Tre modi di attaccare lo stesso problema

Gli altri progetti sulla stessa onda attaccano il problema da angolazioni diverse, e confrontarli è istruttivo.

Headroom, un progetto Python che ha guadagnato circa 13.000 stelle in una settimana arrivando a circa 39.000, è uno strato di compressione del contesto che gira come libreria, proxy o server MCP. Offre sei algoritmi di compressione e dichiara riduzioni dal 60 al 95 per cento. La scelta di progettazione importante è che è locale per primo e reversibile, il che conta perché una compressione che distrugge informazione è peggio di nessuna compressione. Poter decomprimere significa che l'agente può ancora recuperare ciò che ha seppellito.

Xerj va contro un'abitudine specifica e molto costosa. È uno strumento Rust che indicizza codice, documenti, log e PDF con un solo comando, così un agente può interrogare un indice strutturato invece di bruciare token esplorando con grep e sed, quel ciclo di cercare, leggere e cercare di nuovo che consuma enormi quantità di contesto in cambio di poche righe rilevanti. Il progetto dichiara circa 40 volte meno token rispetto a grep e resta compatibile con Elasticsearch, così i client esistenti continuano a funzionare.

Mettili fianco a fianco e compare uno schema. Caveman cambia come parla il modello. Headroom cambia cosa viene ricordato. Xerj cambia dove guarda il modello. I token risparmiati sono gli stessi token, ma la leva è diversa, e un insieme di strumenti maturo finisce per aver bisogno di tutti e tre.

Perché il trucco dell'uomo delle caverne funziona affatto

L'approccio dell'uomo delle caverne non dovrebbe funzionare bene come si dice, e vale la pena capire perché invece funziona.

I modelli ottimizzati con istruzioni sono addestrati a essere utili con uno stile particolare. Riformulano la tua domanda prima di rispondere. Riassumono ciò che hanno appena fatto. Spiegano il loro ragionamento in frasi complete, chiudono con una nota amichevole e formattano tutto con intestazioni. Niente di tutto ciò è richiesto dal compito, e tutto ciò viene fatturato a token.

Se istruisci il modello a lasciar perdere la cortesia e a tenere solo le parole che portano il senso, ottieni un output che sembra grezzo e trasmette quasi la stessa cosa. La densità di informazione sale perché il cerimoniale sparisce. È lo stesso motivo per cui una nota concisa di un ingegnere può dire in dieci parole più di quanto un ordine del giorno di riunione dica in cento.

Il compromesso, però, è reale. Un output conciso è più difficile da scorrere per una persona, e un'abbreviazione ambigua crea malintesi che costano più di quanto facciano risparmiare. Togliere le parole che rendono esplicita l'intenzione è una scommessa che il contesto circostante porti abbastanza significato, e quella scommessa fallisce proprio quando il compito è insolito. La compressione aiuta soprattutto nel lavoro ripetitivo e nuoce soprattutto dove contano le sfumature, una regola da ricordare prima di applicarla ovunque.

La domanda e l'offerta di attenzione

C'è una ragione strutturale per cui questa categoria sta esplodendo proprio ora, e non ha niente a che fare con un singolo repository.

Le finestre di contesto sono diventate grandi, ma anche l'appetito di riempirle. Gli agenti che leggono interi repository, mantengono lunghe cronologie di attività e coordinano sottoagenti consumeranno tutto lo spazio che viene dato loro, perché consumare contesto è il loro modo di concludere le cose. Ogni aumento di capacità viene assorbito in poche settimane, e la pressione torna.

È una dinamica familiare. Allargare le autostrade non riduce il traffico a lungo termine, perché le persone rispondono a un tragitto più economico spostandosi di più. Con il contesto è lo stesso. Una finestra più grande non chiude la scarsità, ridefinisce ciò che conta come uso ragionevole, e la scarsità si riafferma a un livello superiore.

Il che significa che la compressione non è un tampone. È uno strato permanente dello stack, e i progetti che la fanno bene finiranno in una posizione simile a quella dei database e delle cache: invisibili, poco appariscenti e impossibili da rimuovere una volta che le persone ne dipendono.

A cosa bisogna guardare davvero

Il numero di stelle qui è una cattiva guida, perché un nome divertente viaggia più veloce di un buon algoritmo. Tre cose vale la pena controllare prima di adottare qualunque cosa di tutto questo.

La prima è la reversibilità. Una compressione con perdita che non si può annullare rende i bug più difficili da trovare, perché l'agente potrebbe ragionare a partire da un riassunto che ha lasciato cadere il dettaglio che contava. La seconda è dove si applica. Un proxy che comprime tutto il traffico indiscriminatamente finirà per inghiottire qualcosa che regge il senso, e il guasto sembrerà un'allucinazione del modello invece di un bug dello strumento. La terza è la misurazione. Il 65 per cento in meno di token è un'affermazione su un tipo preciso di sessione, e l'unico numero che conta è quello misurato sul proprio traffico.

Il punto più profondo è che il settore ha passato due anni inseguendo la capacità e ora scopre che l'efficienza è dove vive il prossimo giro di vittorie pratiche. Il modello che risponde correttamente è il minimo indispensabile. La pipeline che risponde correttamente per un decimo del costo è un prodotto. Caveman, Headroom e Xerj puntano tutti alla stessa verità: nel lavoro degli agenti, l'attenzione è la risorsa scarsa e tutto il resto è contabilità.