Der beliebteste neue Trick auf GitHub ist, weniger zu reden

Der beliebteste neue Trick auf GitHub ist, weniger zu reden

Das am schnellsten wachsende Repository auf GitHub ist diese Woche ein Go-Projekt namens caveman mit mehr als 112.000 Sternen, und seine ganze Prämisse ist ein Witz, der zufällig stimmt. Der Slogan lautet: Warum viele token benutzen, wenn wenige token reichen. Es ist ein skill und ein Proxy für Coding-Agenten, der behauptet, den token-Verbrauch um etwa 65 Prozent zu senken, indem das Modell wie ein Höhlenmensch spricht.

Zieht man den Gag ab, bleibt eine echte technische Behauptung übrig. Das meiste, was ein Coding-Agent hin und her schickt, ist keine Information. Es ist Gerüst, Höflichkeit, Wiederholung und das höfliche Räuspern, das Sprachmodelle standardmäßig betreiben. Wenn man das wegwerfen kann, ohne die Bedeutung wegzuwerfen, wird die Sitzung billiger und das Kontextfenster reicht weiter.

Der Witz ist zugleich die Diagnose. Wenn der beste Zug darin besteht, den Assistenten dümmer klingen zu lassen, liegt der Engpass nicht in der Intelligenz. Er liegt im Overhead.

Die Rechnung ist der Kontext, nicht das Modell

Es dauert eine Weile, bis man verinnerlicht hat, wie Agenten-Workloads tatsächlich teuer werden. Das intuitive Modell sagt, man zahle pro Antwort, also koste eine lange Antwort mehr. Das reale Modell sagt, man zahle pro token Kontext, den das Modell beachten muss, und dieser Kontext wächst mit jeder Runde.

Bis ein Agent ein Repository gelesen, ein paar Befehle ausgeführt, die Ergebnisse gesehen, Code geschrieben und die Fehlermeldungen gelesen hat, ist die Unterhaltung riesig. Jede neue Runde schleppt die ganze Historie mit. Der zehnte Schritt kostet weit mehr als der erste, nicht weil das Modell langsamer geworden ist, sondern weil es mehr trägt.

Deshalb ist ein Werkzeug, das 65 Prozent der token einspart, keine Randoptimierung. Auf einen Agenten angewandt, der stundenlang läuft, ist es der Unterschied zwischen einer Sitzung, die ins Budget passt, und einer, die zur Hälfte neu gestartet werden muss.

Drei Wege, dasselbe Problem anzugehen

Die anderen Projekte auf derselben Welle greifen das Problem aus verschiedenen Richtungen an, und der Vergleich ist lehrreich.

Headroom, ein Python-Projekt, das in einer Woche rund 13.000 Sterne gewann und etwa 39.000 erreichte, ist eine Kontextkompressionsschicht, die als Bibliothek, Proxy oder MCP-Server läuft. Es bietet sechs Kompressionsalgorithmen und behauptet Reduktionen von 60 bis 95 Prozent. Die wichtige Designentscheidung ist, dass es lokal arbeitet und umkehrbar ist, was zählt, weil eine Kompression, die Information zerstört, schlimmer ist als gar keine. Dekomprimieren zu können bedeutet, dass der Agent noch abrufen kann, was er vergraben hat.

Xerj geht eine bestimmte und sehr teure Angewohnheit an. Es ist ein Rust-Werkzeug, das Code, Dokumente, Logs und PDFs mit einem Befehl indexiert, damit ein Agent einen strukturierten Index abfragen kann, statt token beim grep- und sed-Erkunden zu verbrennen, jener Schleife aus Suchen, Lesen und erneut Suchen, die enormen Kontext für ein paar relevante Zeilen verbraucht. Das Projekt behauptet rund 40-mal weniger token als grep und bleibt Elasticsearch-kompatibel, sodass bestehende Clients weiter funktionieren.

Stellt man die drei nebeneinander, zeigt sich ein Muster. Caveman ändert, wie das Modell redet. Headroom ändert, was erinnert wird. Xerj ändert, wohin das Modell schaut. Die gesparten token sind dieselben token, aber der Hebel ist ein anderer, und ausgereiftes Tooling braucht am Ende alle drei.

Warum der Höhlenmenschen-Trick überhaupt funktioniert

Der Höhlenmenschen-Ansatz sollte nicht so gut funktionieren, wie man sagt, und es lohnt sich zu verstehen, warum er es tut.

Instruktionsabgestimmte Modelle sind darauf trainiert, in einem bestimmten Stil hilfreich zu sein. Sie wiederholen deine Frage, bevor sie antworten. Sie fassen zusammen, was sie gerade getan haben. Sie erklären ihre Überlegungen in vollständigen Sätzen, schließen mit einer freundlichen Bemerkung und formatieren alles mit Überschriften. Nichts davon verlangt die Aufgabe, und alles davon wird pro token berechnet.

Weist man das Modell an, die Höflichkeit zu lassen und nur die tragenden Wörter zu behalten, erhält man eine Ausgabe, die grob aussieht und fast dasselbe vermittelt. Die Informationsdichte steigt, weil das Zeremoniell verschwindet. Das ist derselbe Grund, aus dem eine knappe Notiz eines Ingenieurs in zehn Wörtern mehr sagen kann als eine Besprechungsagenda in hundert.

Der Kompromiss ist allerdings real. Knappe Ausgaben sind für Menschen schwerer zu überfliegen, und mehrdeutige Kurzschrift erzeugt Missverständnisse, die mehr kosten, als sie sparen. Die Wörter zu streichen, die die Absicht ausdrücklich machen, ist eine Wette darauf, dass der umgebende Kontext genug Bedeutung trägt, und diese Wette scheitert genau dann, wenn die Aufgabe ungewöhnlich ist. Kompression hilft am meisten bei repetitiver Arbeit und schadet am meisten dort, wo Nuancen zählen, eine Regel, die man sich merken sollte, bevor man sie überall anwendet.

Angebot und Nachfrage der Aufmerksamkeit

Es gibt einen strukturellen Grund, warum diese Kategorie gerade explodiert, und er hat mit keinem einzelnen Repository zu tun.

Kontextfenster sind groß geworden, aber der Appetit, sie zu füllen, ebenso. Agenten, die ganze Repositories lesen, lange Aufgabenhistorien halten und Subagenten koordinieren, verbrauchen jeden Platz, den sie bekommen, weil Kontext zu verbrauchen ihr Weg ist, Dinge zu erledigen. Jede Kapazitätssteigerung wird innerhalb von Wochen absorbiert, und der Druck kehrt zurück.

Das ist eine vertraute Dynamik. Autobahnen breiter zu machen reduziert den Verkehr langfristig nicht, weil Menschen auf den billigeren Arbeitsweg mit mehr Pendeln reagieren. Mit Kontext ist es dasselbe. Ein größeres Fenster beendet den Mangel nicht, es definiert neu, was als vernünftige Nutzung gilt, und der Mangel meldet sich auf höherem Niveau zurück.

Was bedeutet, dass Kompression kein Lückenfüller ist. Sie ist eine dauerhafte Schicht des Stacks, und die Projekte, die sie richtig hinbekommen, landen in einer ähnlichen Position wie Datenbanken und Caches: unsichtbar, unglamourös und nicht mehr zu entfernen, sobald Menschen von ihnen abhängen.

Worauf man wirklich achten sollte

Sternzahlen sind hier ein schlechter Maßstab, weil ein lustiger Name schneller reist als ein guter Algorithmus. Drei Dinge sollte man prüfen, bevor man irgendetwas davon einsetzt.

Das erste ist Umkehrbarkeit. Verlustbehaftete Kompression, die sich nicht rückgängig machen lässt, macht Fehler schwerer zu finden, weil der Agent vielleicht aus einer Zusammenfassung argumentiert, die das entscheidende Detail weggelassen hat. Das zweite ist, wo sie greift. Ein Proxy, der allen Verkehr unterschiedslos komprimiert, frisst irgendwann etwas Tragendes, und der Fehler sieht dann wie eine Halluzination des Modells aus, nicht wie ein Tooling-Bug. Das dritte ist Messung. 65 Prozent weniger token ist eine Aussage über eine bestimmte Art von Sitzung, und die einzige Zahl, die zählt, ist die, die man am eigenen Verkehr misst.

Der tiefere Punkt ist, dass die Branche zwei Jahre lang Fähigkeiten nachgejagt ist und nun entdeckt, dass in der Effizienz die nächste Runde praktischer Gewinne liegt. Das Modell, das richtig antwortet, ist Grundvoraussetzung. Die Pipeline, die richtig antwortet für ein Zehntel der Kosten, ist ein Produkt. Caveman, Headroom und Xerj zeigen alle auf dieselbe Wahrheit: In der Agentenarbeit ist Aufmerksamkeit die knappe Ressource und alles andere ist Buchhaltung.