So hält deine Grok-Subscription länger: Was wir tatsächlich gemessen haben

Wenn Grok Build mit einer Limit-erreicht-Meldung stoppt, gehen die meisten davon aus, dass sie einfach zu viel verlangt haben. Sobald man aber tatsächlich misst, wie viele Bytes durch eine Session fließen, sieht das Bild anders aus. Das meiste, was das Limit aufbraucht, sind gar nicht deine Prompts — es ist das, was der Agent von sich aus einliest.

Das haben wir nicht als Vermutung stehen lassen — wir haben es gemessen und daraufhin geändert, wie meshcode Grok startet. Dieser Beitrag dokumentiert, was wir gemessen haben, was wir geändert haben, und genau, wo die Ergebnisse gelten — und wo nicht mehr.

Die 30.4MB, die eine einzige Session eingelesen hat

Am 19. August 2026 haben wir den gesamten Eingangs-Korpus einer Grok-Session instrumentiert. Insgesamt kamen 30.4MB zusammen. Bricht man das nach Kategorie herunter, ist der Übeltäter offensichtlich.

Entscheidend ist hier die Form der Verteilung. Meistens liest Grok von sich aus 20–80 Zeilen — diese Aufrufe sind unproblematisch. Was das Budget aufbraucht, sind die 290 Aufrufe, die überhaupt kein Limit gesetzt haben, und die allein machen 1.83MB aus. Jeder einzelne hat eine ganze Datei eingelesen.

Groks Meta-Suchwerkzeug search_tool zeigt dasselbe Muster. Sein p90 liegt bei bescheidenen 11KB, aber das Maximum erreicht 39KB und die Summe kommt auf 2.75MB. meshcodes eigene Tools begrenzen sich dagegen bereits selbst — die gemessenen Maxima lagen bei 9.9KB für read und 8KB für grep. Da gibt es nichts zu reparieren.

Warum ein einziger Tail die ganze Session auffrisst

„1.83MB von 30MB sind doch nur 6%“ ist die naheliegende Schlussfolgerung. Sie ist auch die Falle.

Kontext in einer Agent-Konversation akkumuliert sich. Landet eine 30KB-Datei in Turn 3 komplett in der Session, und läuft die Session insgesamt 40 Turns, wird diese 30KB in jedem der verbleibenden 37 Turns neu verrechnet. Ein einziger unbedachter Read ist keine einmalige Kosten, sondern potenziert sich, je länger die Session läuft.

Wie wir bereits beschrieben haben, zeigt dir Groks Free-Tier-Limit keine Reset-Zeit — es zeigt dir nur ein Upsell. Je weniger Einblick du hast, wann sich ein Budget wieder auffüllt, desto teurer wird dich ein früher Leak.

Unser Ziel war also nicht „Leute sollen Grok sparsam nutzen“ — es war viel enger gefasst: normale Aufrufe nie anfassen, nur den Tail kappen.

Die vier Grenzen, die meshcode Grok auferlegt

Öffnest du in meshcode ein Grok-Pane, greifen — anders als beim nackten grok — vier Mechanismen gleichzeitig.

1. Eine 300-Zeilen-Grenze für read_file. Groks read_file ist ein Tool, das fest in die Grok-Binary eingebaut ist, sodass wir seine Ausgabe im Nachhinein nicht anfassen können. Stattdessen fangen wir den Aufruf bevor er rausgeht ab und injizieren limit=300 nur in Aufrufe, die kein Limit haben oder mehr als 300 verlangen. Normale 20–80-Zeilen-Aufrufe kommen diesem Wert nie nahe.

2. Eine 12,000-Byte-Grenze für MCP-Tool-Output. Da der p90 von search_tool bei 11KB liegt, kappt eine 12,000-Byte-Obergrenze den 39KB-Tail, ohne normale Antworten zu berühren. Sie gilt nur für den Prozess, den meshcode startet — deine ~/.grok/config.toml wird nie angefasst.

3. Kein fremder Katalog im ersten Turn. Die Grok-TUI scannt standardmäßig Cursors MCP-Konfiguration und skills/rules. meshcode läuft ohne Cursor, also deaktivieren wir jeden übrig gebliebenen Cursor-Katalog, der sich sonst gleich im allerersten Turn als Tool-Schema anhängen würde.

4. Massenexploration geht an ein günstiges Modell. Die größte Ersparnis kommt gar nicht von einer Grenze — sie kommt aus der Struktur. Wenn meshcode „Finde heraus, wo das ist“-Arbeit an eine Child-Session mit einem günstigeren Backend delegiert, gelangen die Dutzenden Megabytes, die dieses Kind liest, niemals in deine Grok-Session. Was zurückkommt, ist eine Handvoll file:line-Referenzen. meshcode verankert diese Regel beim Session-Start und erinnert mit einem kurzen Hinweis daran, falls sich Explorationsaufrufe anhäufen.

Was „weniger verbrauchen“ wirklich bedeutet — und was nicht

Hier müssen wir ehrlich sein. Wir werden keine Zahl wie „40% weniger Tokens“ behaupten. So eine Zahl schwankt je nach Workload extrem, und sie ist auch nicht das, was wir gemessen haben.

Das können wir tatsächlich sagen:

• Eine Session hat 30.4MB eingelesen, und der größte Posten war read_file mit 11.9MB.
• Darin zielt die Grenze konkret auf die 1.83MB der 290 Aufrufe ohne Limit und den 1.32MB-Tail der Aufrufe über 10KB.
• search_tool kam auf insgesamt 2.75MB, mit einer 39KB-Antwort am Peak, und die 12,000-Byte-Grenze kappt genau diesen Tail.
• Was gekappt wird, spart nicht nur einmal, sondern bei jedem verbleibenden Turn, weil sich Kontext akkumuliert.

Was nicht stimmt: Keiner dieser Mechanismen macht Grok schlauer. Braucht der Agent mehr von einer Datei, als die 300-Zeilen-Grenze erlaubt, liest er einfach weiter — nur liest er jetzt den Teil, den er wirklich braucht. Der Sinn der Grenze ist kein Verbot; es geht darum, den Default von unbegrenzt auf bewusst umzustellen.

Den nackten grok-TUI nicht zu brechen, war ebenfalls eine Anforderung

Der schwierigste Teil dieser Arbeit war nicht die Ersparnis — es war, Nebeneffekte zu vermeiden.

Groks Hook-Dateien können nicht auf Projektebene liegen — sie gehören nur in das globale ~/.grok/hooks/. Das bedeutet, jeder Hook, den meshcode installiert, feuert auch, wenn jemand in seinem eigenen Terminal einfach grok eintippt. Die erste Implementierung ließ den Hook bei jedem Aufruf die meshcode-Binary ausführen, um zu prüfen „ist das unsere Session?“ — allein diese Prüfung kostete 895ms pro Aufruf, und unter bestimmten Bedingungen öffnete sie bei jedem einzelnen read_file-Aufruf ein Fenster. In der Session einer anderen Person.

Also haben wir die Prüfung aus der Binary heraus in ein kleines externes Shell-Skript verlagert. Trägt die Session nicht den Marker, den meshcode beim Start setzt, tut das Skript nichts und lässt den Aufruf sofort durch.

Das haben wir gestern erneut verifiziert:

Eine Ersparnis, die das Tool eines anderen ausbremst, ist keine Ersparnis. Die Kosten dieses Hooks für einen Bare-Grok-Nutzer mussten exakt null sein, und wir haben ihn erst ausgeliefert, nachdem das bestätigt war.

Die meshcode-Perspektive

meshcode ist eine native Desktop-App für macOS und Windows, gebaut darauf, mehrere Agenten parallel in eigenen Panes laufen zu lassen. Du kannst deine bestehende Grok-Subscription direkt in ein Pane einbinden — gleiche Abrechnung, gleiche Limits, meshcode nimmt sich dazwischen nichts zusätzlich.

Der Unterschied ist, dass dieselbe Subscription länger reicht. Nicht wegen irgendeines Tricks, sondern weil wir tatsächlich gemessen haben, was und wie viel in eine Session fließt, und den Tail gekappt haben. Und weil die wirklich große Explorationsarbeit von Anfang an im Kontext eines günstigeren Modells stattfindet — nicht in deinem Grok-Kontext.

Wenn du dir das Limit-Management lieber ganz sparen willst: meshcodes eigenes nutzungsbasiertes Modell steht direkt daneben bereit — keine Monatsgebühr, kein geteiltes Fenster, nur ein Guthaben, das sich mit deiner Nutzung abbaut. Das heißt, es gibt einen Ort, an den du gehen kannst, sobald eines deiner Tools „komm später wieder“ sagt. Willst du dieselbe Aufschlüsselung für Claude, haben wir sie in So hält deine Claude-Pro-Subscription länger behandelt.

Versuch nicht, dein Limit durch Prompt-Rationierung zu schonen — kapp stattdessen, was hereinfließt. meshcode ist kostenlos zum Start, und ein Grok-Pane startet von Anfang an mit allen vier oben genannten Grenzen aktiv.

👉 meshcode herunterladen — Mac, Windows.