Tokens sparen mit Claude: 6 Prinzipien, mit denen Experten doppelt so schnell arbeiten
Die teuerste Zeile in meinem Projekt war lange gar kein Code. Es war die KI, die bei jeder Aufgabe aufs Neue mein halbes Repo durchwühlte, drei Absätze ankündigte, was sie gleich tun würde, und am Ende eine Rückfrage stellte, deren Antwort offensichtlich war. Mal hundert Agent-Läufe pro Tag — das ist eine echte Rechnung in Token, Wartezeit und Geduld.
Irgendwann habe ich aufgehört, meine CLAUDE.md als Stilrichtlinie zu lesen, und angefangen, sie als Performance-Budget zu behandeln. Eine Datei voller höflicher Bitten wird ignoriert. Eine Datei voller harter Regeln, deren Bruch als Bug gilt, ändert das Verhalten. Hier sind die sechs Prinzipien, die am meisten gebracht haben.
1. Such gezielt, nicht breit — folge Pointern statt zu graben
Der größte Token-Fresser ist die blinde Suche. Eine KI, die mit zwanzig Grep-Aufrufen durchs Repo stochert, zieht bei jedem Treffer Kontext nach, den sie zu 90 Prozent nie braucht. Der Kontext füllt sich mit Rauschen, und Rauschen kostet bei jedem weiteren Schritt mit.
Mein Gegenmittel ist ein Context-Gate als allererster Schritt jeder Aufgabe: genau ein globaler RAG-Lauf — nicht, um den ganzen Kontext zu laden, sondern um Code-Pointer zu holen, also Datei und Zeile. Erst dann wird gezielt an genau dieser Stelle gelesen. Das Prinzip dahinter ist „Pointer always, content on demand”. Die KI bekommt eine Landkarte, keine vorgelesene Enzyklopädie.
Der Unterschied ist nicht kosmetisch. Es ist oft der Unterschied zwischen „Sonnet löst das” und „dafür brauche ich Opus”.
2. Begrenze den Output hart — mit Tags statt guter Vorsätze
„Fass dich kurz” funktioniert nicht. Das ist eine Bitte, und Bitten werden weginterpretiert. Was funktioniert, ist ein Output-Contract: Jede Antwort startet mit einem Tag, der ein Zeichenlimit mitbringt.
[UMGESETZT] für erledigte Aufgaben, [RECAP] für reines Lesen, [OFFEN] für Teilfortschritt, [FRAGE] nur bei schwer reversiblen Aktionen — jeweils mit hartem Limit. Der Trick ist nicht das Limit selbst, sondern dass ein Verstoß als Bug gilt, nicht als Geschmacksfrage. Das dreht die Beweislast um: Die KI muss sich Ausführlichkeit verdienen, nicht ich mir Kürze.
Der eigentliche Hebel
Nicht das Limit spart Token, sondern die Umkehr der Beweislast. Solange Kürze eine Bitte ist, gewinnt der Monolog. Erst wenn Länge sich rechtfertigen muss, wird sie selten.
3. Lass durchlaufen, statt rückzufragen
Die teuerste Verzögerung ist der unnötige Roundtrip. Ich wechsle den Screen, komme nach zehn Minuten zurück — und finde statt eines fertigen Features eine Trivialfrage zum Padding. Das ist kein Service, das ist eine Vollbremsung.
Deshalb gilt bei mir ein Autonomie-Default: sofort loslegen, bis zum Ende durcharbeiten. Reversible Entscheidungen — Naming, Reihenfolge, Refactor-Struktur, Lib-Wahl — trifft die KI selbst und markiert sie kurz. Gefragt wird nur bei echtem Risiko: Daten-Löschung, Prod-Deploy, Migration, Security.
Meine Faustregel steht wörtlich in der Regeldatei: Wäre die Antwort in unter 30 Sekunden korrigierbar — nicht fragen, machen. Ein Tippfehler im Variablennamen kostet mich fünf Sekunden Korrektur. Eine Rückfrage dazu kostet einen ganzen Roundtrip.
4. Tag-Disziplin ist ehrliches Reporting — und nebenbei Token-Sparen
Wer sauber zwischen „gelesen” und „geändert” trennt, kann nicht mehr aufblähen. Ein Read oder eine RAG-Query allein ist [RECAP] — niemals [UMGESETZT]. Tool-Aufruf ist nicht gleich Aufgabenerfüllung.
Das klingt nach Buchhaltung, ist aber der wirksamste Hebel gegen die „Schau, was ich alles getan habe”-Monologe. Wenn reines Lesen sich nicht als Erfolg verkaufen darf, verschwindet der Anreiz, drei Absätze über die eigene Gründlichkeit zu schreiben. Ein Tag kann nicht lügen: Entweder es wurde etwas geändert, oder eben nicht.
5. Wiederverwendbare Workflows statt langer Prompts
Immer gleiche Abläufe gehören nicht in den Prompt, sondern hinter ein Keyword. Kurze Trigger lösen serverseitige Workflows aus, die ihre Schritte und Schemas selbst mitbringen. Die Schritte kommen vom Server, nicht aus dem lokalen Kontext.
Ich werfe ein Wort, der Rest kommt on demand. Statt einen 40-Zeilen-Ablauf in jeden Prompt zu kopieren — und damit jedes Mal die Token zu bezahlen — liegt der Ablauf einmal zentral und wird Schritt für Schritt nachgeladen. Das ist dieselbe Logik wie die Pointer-Suche aus Prinzip 1, nur auf Prozessebene statt auf Datei-Ebene.
6. Doku als Pointer-System — Wiedereinstieg ohne Re-Discovery
Was die nächste KI-Session am meisten kostet, ist das Wiederfinden dessen, was die letzte schon wusste. Ohne Spur fängt jede Session beim Graben an.
Deshalb bekommt jede berührte Funktion einen Doc-Block mit Suchbegriffen und Code-Pointern direkt im Code. Nach der Übernahme ins RAG schrumpft der Block zu einem schlanken Marker — der Volltext wandert ins RAG, im Code bleibt nur der Zeiger. Zeiger immer, Inhalt bei Bedarf. So liest die nächste Session den Marker, holt bei Bedarf den Volltext nach und muss nicht erneut entdecken, was längst dokumentiert ist.
Fazit
Der gemeinsame Nenner ist ein einziger Satz: Lade nie etwas in den Kontext, was du auch nachladen könntest — und sag nie etwas, wofür dich niemand gefragt hat.
Pointer statt Volltext bei der Suche. Tags statt Prosa beim Output. Autonomie statt Roundtrips beim Ablauf. Keywords statt Prompt-Wänden beim Prozess. Vier Varianten desselben Gedankens.
Das Überraschende daran: Ich habe nicht nur Geld gespart, sondern bin auch schneller geworden, weil weniger Hin und Her, und ehrlicher, weil ein Tag nicht lügen kann. Sonnet erreicht inzwischen Opus-Niveau bei Aufgaben, die vorher das größere Modell brauchten — nicht weil das Modell besser wurde, sondern weil ich aufgehört habe, es mit eigenem Ballast zu bremsen.
Dieselbe Logik skaliert über eine einzelne Config-Datei hinaus: das richtige Modell auf die richtige Aufgabe zu routen, bei schlankem Kontext, ist genau das, was die KI-Orchestrierung in der boostN-App automatisiert.
Entdecke mehr
Steuerbare Remote-Coding-Sessions: eine Ebene über der IDE
Die Session-URL war plötzlich weg aus dem Terminal. Wie wir sie über einen Server-Endpoint wiederfanden — und was das für die Arbeit über der IDE bedeutet.
GlossarSpeech-to-Text (STT)
Speech-to-Text bezeichnet die automatische Umwandlung gesprochener Sprache in Text durch ein KI-Modell. Im KI-Workflow ersetzt STT die Tastatur als Eingabekanal — entscheidend ist die Modellgröße und das domänenspezifische Vokabular.
LexikonKI-Coding-Tools im Vergleich
Cursor, Windsurf, Claude Code, GitHub Copilot, Continue.dev, Aider im Vergleich. Mit Tabelle und Entscheidungshilfe für vier typische Workflows.