8. Token-Ökonomie — was in den Kontext kommt und was draußen bleibt

Dies ist Teil 8 der Alice Way-Serie. Die Teil 1 bis Teil 7 behandelten, wo, wie und mit wem man die Last des Geistes verteilt. Dieser Beitrag handelt von der grundlegendsten Ressource, von der all diese Entscheidungen abhängen — dem context window, also Tokens.

0. Token-Ökonomie ist die bewusste Auswahl, was in den Geist kommt

Das context window des Kollaborateurs ist endlich. Nicht alles passt hinein. Aber die wichtigere Tatsache — was hineinkommt, bestimmt die Qualität der Entscheidung. Mit Rauschen gefüllt, schwächt das Signal. Auf Signal komprimiert, kann dasselbe Fenster eine weit tiefere Entscheidung tragen.

Token-Ökonomie ist also nicht nur Kostenreduzierung. Es ist die bewusste Auswahl, was in den Geist aufgenommen wird. Auto-Load vs. On-Demand, Gedächtnis vs. außerhalb des Gedächtnisses, Haupt vs. Sub — jede Entscheidung, die die Serie behandelt hat, konvergiert auf ein einziges Ressourcenzuteilungsproblem.

Dieser Beitrag ist eine Aufzeichnung der Vier-Schichten-Platzierung dieser Zuteilung, wie Token-Einsparungen in Entscheidungsqualität übersetzt werden, und der Audit-Werkzeuge, die akkumulierten Kontext ordentlich halten.

1. Vier-Schichten-Platzierung — Kanäle, durch die Token hereinkommen

Die Token-Platzierung, auf die ich mich festgelegt habe, hat vier Schichten.

Schicht	Was	Wann kommt es rein	Token-Kosten
L1 inline	Persona · Entscheidungsbefugnis · Sicherheitswächter	Jede Sitzung, automatisch	Immer (am teuersten)
L2 auto-load	Erste N Zeilen des Gedächtnisindex, Projekt-CLAUDE.md	Jede Sitzung / beim Verzeichniseintritt	Immer (bedingt)
L3 on-demand Read	Gedächtnisinhalte, sprachspezifische Regeln, Code-Dateien	Wenn Arbeit diesen Bereich betritt	Nur in dieser Arbeit
L4 externer Verweis	Gesamte Codebase, Build-Logs, externe API-Antworten	Sub-Agent empfängt / nur Zusammenfassung an Haupt	Haupt sieht nur Zusammenfassung

Das Kernprinzip: L1·L2 müssen kurz sein, weil oft gesehen; L3·L4 können lang sein, weil selten gesehen. Dieselbe Information in der falschen Schicht verschwendet Token.

Falschplatzierung	Ergebnis
L4 → L1 (gesamter Code in Persona)	Massiver Kontext-Verbrauch jede Sitzung
L1 → L4 (Rollendefinition in externer Datei)	Kollaborateur kennt seine Persona nicht jede Sitzung
L2 → L3 (Gedächtnisindex als On-Demand)	Kollaborateur weiß nicht, dass sein eigenes Gedächtnis existiert
L3 → L2 (alle Gedächtnisinhalte auto-geladen)	Index-Auto-Load verliert seine Bedeutung

2. Token-Einsparungen → Entscheidungsqualität — die Kausalitätskette

Warum Token-Einsparungen ein Entscheidungsqualitätsproblem sind, nicht nur ein Kostenproblem.

2.1 Signal-Rausch-Verhältnis

Angenommen, ein 100k context window. Wenn Persona + Gedächtnis + irrelevante Auto-Loads 80k belegen, bleiben nur 20k für entscheidungsrelevantes Signal. Schrumpft die Auto-Load-Last auf 30k, wächst der Signalraum auf 70k. Dieselbe Entscheidung entfaltet sich weit tiefer.

Entscheidungsqualität skaliert mit dem Signal-Verhältnis, nicht der Kontextgröße.

2.2 Aufmerksamkeitsdiffusion

Der Kollaborateur wird, wie ein Mensch, unsicherer darüber, was wichtig ist, wenn der Kontext wächst. Die Schlüsselzeile in 100k zu finden ist weniger präzise als in 30k. Rauschen zu reduzieren hebt die Entscheidungsqualität bereits für sich allein.

2.3 First-Token-Latenz

Weniger Token bedeutet schnellere Antwort. Schnellere Antwort hält den Fluss des Betreibers intakt. Ununterbrochener Fluss reduziert auch die kognitive Last des Betreibers. Qualität steigt damit auch auf der Betreiberseite.

3. Einsparungsmuster im Betrieb

Was ich aktiv für Token-Einsparungen betreibe.

3.1 Gedächtnisindex auf unter 200 Zeilen begrenzt

MEMORY.md-Index bleibt unter 200 Zeilen. Über dem Auto-Load-Fenster verliert er seine Bedeutung. Der 200-Zeilen-Druck wird selbst zur Motivation für Beschneiden.

3.2 Kein Lesen ganzer Verzeichnisse

Ein großes Verzeichnis auf einmal lesen bläst Token auf. Erst mit ls auflisten, mit grep eingrenzen, dann nur spezifische Dateien einlesen. Als Sicherheitswächter in die Persona eingebaut.

3.3 Header/Range zuerst für Dateien über 500 Zeilen

Eine große Datei nie von Ende zu Ende lesen. Die ersten 100 Zeilen für Struktur lesen, dann nur den benötigten Bereich einlesen. Dieselbe Entscheidung trifft gegen 200 Zeilen Kontext, nicht 1000.

3.4 Tiefe Arbeit an Sub-Agents übergeben

Suche, Überprüfung, Build, Test gehen tief in Subs; Haupt sieht nur die Zusammenfassung. Der Hauptkontext bleibt im Entscheidungsmodus. (Siehe Teil 6 — Multi-Agent-Delegation.)

3.5 Gedächtnis-Beschneidungsrhythmus

Projekt-Gedächtnis monatlich, Feedback-Gedächtnis quartalsweise, Referenz-Gedächtnis halbjährlich. Veralteter Kontext sollte keine bedeutungslosen Slots belegen. Die Memory-Struktur, auf der diese Kadenzen arbeiten, wird in Teil 3 — Memory-System behandelt.

3.6 Token-Audit-Werkzeug

Ein Werkzeug wie /token-audit läuft regelmäßig und meldet, welche Einträge seit mehr als 60 Tagen nicht referenziert wurden, welche Gedächtnisse aufgebläht sind, welche Auto-Loads ungenutzt bleiben. Die Ausgabe ist die Grundlage für Beschneidungsentscheidungen.

4. Teure Kontext-Positionen — wo zuerst beschneiden

Token-Kosten variieren nach Position. Dieselben 100 Zeilen können je nach Platzierung zehnmal mehr kosten.

Position	Kosten pro Zeile (relativ)	Beschneidungspriorität
Persona (L1)	× jede Sitzung × jede Antwort	★★★ top
Gedächtnisindex (L2)	× jede Sitzung	★★
Projekt-CLAUDE.md (L2)	× jede Sitzung in dem Projekt	★★
Gedächtnisinhalt (L3)	× nur wenn eingelesen	★
Code-Datei (L4)	× nur wenn eingelesen	(kein Beschneiden — Aufteilen)

Die Persona ist am teuersten. Dieselben 100 Zeilen in der Persona kosten × jede Sitzung × jede Antwort. Also bleibt die Persona am kleinsten und wird am häufigsten beschnitten.

5. Fallen — Muster, bei denen Token-Ökonomie schiefläuft

5.1 „Für alle Fälle" inline

Einen Wächter, eine Richtlinie, ein Beispiel zur Persona hinzufügen, weil es irgendwann nützlich sein könnte. Ein Jahr später ist die Persona 1.000 Zeilen. → An der Regel festhalten: „nur zur Persona promovieren, wenn es tatsächlich zweimal ausgelöst hat."

5.2 Gedächtnisinhalt in den Index kopiert

Teil eines Gedächtnisinhalts als „Zusammenfassung" in den Index kopieren — der Index selbst bläht sich auf. → Der Index trägt immer nur einzeilige hooks. Inhalte bleiben in ihren Dateien.

5.3 Keine regelmäßige Token-Überprüfung

Täglich nutzen, aber keine Ahnung, wohin Token gehen. → Token-Audits einplanen: welche Auto-Loads groß sind, welche Gedächtnisse ungenutzt bleiben.

5.4 Sub-Ergebnisse vollständig in Haupt absorbiert

Sub gibt 1.000 Zeilen zurück und Haupt absorbiert alles. Der Grund für den Sub geht verloren. → Sub-Ergebnisse immer aufteilen: Zusammenfassung (für Haupt) + vollständig (für Dateien oder nächsten Sub-Aufruf).

5.5 Das Kontextlimit erreichen

Token erreichen das Ende des Fensters und automatische Verdichtung setzt ein, oder ältester Kontext wird fallen gelassen. Der fallen gelassene Ausschnitt könnte einer sein, den der Betreiber nicht bewusst im Blick hatte. → Kontextnutzung immer im Blick behalten; bei 80% Auslastung aufräumen.

6. Akkumulierte Token-Ökonomie — was sich ändert

Veränderungen, seit ich Token-Ökonomie als Erstklassiges behandle.

Element	Vorher	Nachher
Kontext beim Sitzungsstart	Flach 60–70k	Index + Persona = 15–20k
Token verfügbar für tiefe Arbeit	30–40k	80–85k
Häufigkeit der Kontext-Verdichtung	Oft	Selten
Entscheidungsqualität für dieselbe Arbeit	Durchschnittlich	Tief (weniger Rauschen)
Antwortgeschwindigkeit	Durchschnittlich	Schnell

Das Kernprinzip zeigen die letzten zwei Zeilen — dieselbe Arbeit entfaltet sich in eine tiefere Entscheidung und entfaltet sich schneller. Token-Einsparungen übersetzen sich direkt in Entscheidungsqualität.

7. Auf ein Prinzip verdichtet

Der Kern von Token-Ökonomie-Design kollabiert auf einen Satz.

„Inline nur, was jede Sitzung gesehen werden muss; auto-load, was oft gesehen wird; on-demand lesen, was gelegentlich gesehen wird; extern für was fast nie gesehen werden sollte. Der teure Fehler ist die falsche Schicht."

Wenn das gilt, wird Token-Ökonomie zum Beschleuniger der Entscheidungsqualität. Wenn es bricht, frisst Rauschen den Entscheidungsraum und der Kollaborateur verwirrt sich darüber, was wichtig ist.

Der nächste Beitrag ist der letzte. Er behandelt, wie all das — Persona, Gedächtnis, Skills, Hooks, Multi-Agent, Verifikation, Token — tatsächlich jeden Tag startet und endet. Teil 9 — Session-Protokolle.