Token sparen mit Claude Code — warum es kein Geiz ist

Ich habe neulich einer Coding-Sitzung zugeschaut, bevor sie überhaupt richtig angefangen hatte. Mein Assistent war in ein unaufgeräumtes Projekt gestartet, und das Erste, was er gemacht hat, war lesen. Die README. Die CLAUDE.md. Drei Regeldateien. Eine Status-Übersicht. Den letzten Commit. Eine Quelldatei, von der er vermutete, dass sie relevant sein könnte. Zehntausende Tokens waren durch, bevor ich ihm die erste echte Aufgabe überhaupt gestellt hatte. Mein erster Reflex: „na, kostet doch fast nichts pro Sitzung“. Mein zweiter Gedanke, ehrlich gesagt, war: „doch, summiert sich, und es ist nicht nur das Geld“. Und zwischen diesen beiden Gedanken liegt dieser Artikel.

Was ein Token wirklich ist

Bevor das Sparen einen Sinn ergibt, muss klar sein, was da eigentlich gespart wird. Ein Token ist keine Einheit, die sich eins zu eins auf ein Wort abbilden lässt — das ist die häufigste Missverständnisquelle. Der Tokenizer eines Modells zerlegt Text in Einheiten, die mal aus einem ganzen Wort bestehen, mal aus einer Silbe, mal nur aus einem Leerzeichen oder einem Sonderzeichen. Als grobe Faustregel: im Englischen entsprechen rund drei bis vier Zeichen einem Token, im Deutschen wegen der längeren Wörter und der Umlaute eher weniger. Ein deutscher Satz wird gegenüber einem englischen fast immer in mehr Tokens zerlegt — für dieselbe Information.

Input und Output werden getrennt gezählt. Was du dem Modell schickst, zählt als Input-Token. Was es zurückgibt, als Output-Token. Beide haben unterschiedliche Preise, und bei den meisten großen Modellen ist Output deutlich teurer als Input. Das ist wichtig, weil die erste intuitive Annahme — „der Preis ist der Preis“ — schon an dieser Stelle kippt. Wer Tokens sparen will, muss wissen, welchen er meint, und warum.

Wie der Preis entsteht

Pro Request zahlst du zwei Posten: Input-Tokens für den Prompt, Output-Tokens für die Antwort. Bei einer Coding-Sitzung, die über dutzende Requests geht, entsteht der eigentliche Preis aber an einer Stelle, die im einzelnen Request unsichtbar bleibt. Denn ein Sprachmodell ist stateless. Zwischen zwei Anfragen existiert in ihm kein innerer Zustand, der den bisherigen Verlauf kennt. Damit eine Sitzung zusammenhängend wirkt, schickt die Anwendung bei jedem neuen Request den bisherigen Verlauf erneut mit. Wiederholung statt Gedächtnis.

Die Folge ist unangenehm, sobald man sie einmal ausgerechnet hat. Jede Nachricht, die in einer langen Sitzung entsteht, wird in allen folgenden Requests als Teil des Prompts erneut bezahlt. Der Kontext wächst mit der Zeit, und das, was am Anfang eine hübsche überschaubare Zahl war, ist am Ende der Sitzung eine ganz andere. Was wir in der Einleitung als „zehntausende Tokens vor der ersten Aufgabe“ gesehen haben, ist nicht der Höchststand — es ist der Ausgangspunkt, auf den sich jede spätere Antwort aufbaut. Token-Sparen am Anfang einer Sitzung zahlt sich am Ende mehrfach aus. Token-Verschwendung am Anfang ebenfalls, nur eben in die andere Richtung.

Latenz statt nur Kosten

Wer beim Thema Token-Sparen nur über den Geldbetrag auf der Rechnung nachdenkt, übersieht die Hälfte der Geschichte. Der zweite Kostenposten heißt Zeit, und er verhält sich anders, als die meisten annehmen.

Im Prefill — das ist der erste Verarbeitungsschritt, bei dem ein Modell den gesamten Prompt einmal durchläuft, bevor es überhaupt anfängt zu antworten — skaliert der Aufmerksamkeits-Aufwand überproportional mit der Länge. Der Grund sitzt tief in der Mechanik der sogenannten Self-Attention: das Modell vergleicht jedes Token im Prompt mit jedem anderen. Bei doppelter Promptlänge steigen die Vergleiche nicht auf das Doppelte, sondern auf das Vierfache. Diese Eigenschaft wird in der Literatur als quadratische Skalierung beschrieben, und sie ist der eigentliche Grund, warum sehr lange Kontexte spürbar träger werden — unabhängig davon, was sie kosten.

Praktisch gesehen heißt das: Ein Prompt, der dreimal so lang ist wie nötig, erzeugt nicht nur die dreifachen Kosten auf der Abrechnung. Er erzeugt auch spürbar mehr Latenz bis zum ersten Output-Token. Token-Sparen ist in diesem Sinn immer auch Latenz-Sparen. Und wer mit einem KI-Assistenten interaktiv arbeitet, merkt Latenz deutlich früher im Arbeitsfluss als einen zehnprozentigen Posten auf der Monatsrechnung.

Qualitätskosten — der unsichtbare Hebel

Jetzt kommt der Teil, der mich am längsten überrascht hat. Kosten und Latenz sind messbar, man sieht sie auf der Rechnung oder am Ladebalken. Der dritte Effekt ist unauffälliger, und er ist gleichzeitig der wertvollste: lange Kontexte produzieren schlechtere Antworten als kurze Kontexte, selbst bei identischem Informationsgehalt.

Eine Untersuchung von Liu und Kollegen aus dem Jahr 2023 trägt den Titel „Lost in the Middle“. Sie hat eine Eigenschaft aktueller Sprachmodelle systematisch vermessen: Inhalte am Anfang und am Ende eines Prompts werden deutlich stärker gewichtet als Inhalte in der Mitte. Je länger der Prompt wird, desto stärker verdünnen sich relevante Informationen irgendwo in der Mitte des Kontextfensters — und zwar messbar, nicht nur gefühlt. Das ist kein kleiner Effekt, und er ist kein Ausreißer bei einem exotischen Modell, sondern ein robust beobachtetes Muster.

Die praktische Konsequenz ist hart. Wer zwanzigtausend Tokens Kontext in den Prompt packt, damit der Assistent „auf jeden Fall alles weiß“, bekommt nicht die bestmögliche Antwort. Er bekommt eine Antwort, in der die eigentlich wichtigen Stellen zwischen Füllmaterial untergehen. Derselbe Prompt mit zweitausend Tokens verdichtetem Kontext plus einem oder zwei gezielten Nachladungen bei Bedarf liefert oft das bessere Ergebnis — schneller, billiger und inhaltlich präziser. Das Modell hat in beiden Fällen theoretisch denselben Kontext, aber der zweite Prompt gibt den relevanten Stellen die Aufmerksamkeit, die sie im ersten nicht mehr bekommen können.

Token-Sparen ist also nicht nur eine Optimierung für den Geldbeutel und den Ladebalken. Es ist eine Optimierung für die Qualität der Antwort. Wer das einmal verstanden hat, legt das Sparen als Nebenthema beiseite und behandelt es als Kernbestandteil des Arbeitens.

Drei Achsen, ein Hebel

Hier fügt sich das Bild zusammen. Token-Sparen wirkt nicht auf einer einzigen Achse, sondern auf drei gleichzeitig. Weniger Kosten, weil die Abrechnung linear mit der Tokenzahl skaliert. Weniger Latenz, weil der Prefill überproportional mit der Sequenzlänge skaliert und jeder eingesparte Token den Ladebalken beschleunigt. Bessere Qualität, weil kürzere Kontexte das Lost-in-the-Middle-Problem kleiner machen und relevante Stellen nicht im Rauschen untergehen.

Der entscheidende Punkt ist, dass diese drei Effekte sich nicht linear addieren, sondern sich gegenseitig verstärken. Ein aufgeräumter Kontext spart Kosten, und weil er schneller ist, wird das Arbeiten angenehmer, und weil die Antworten besser sind, sind weniger Nachkorrekturen nötig, was wiederum Requests spart. Die Rechnung geht in alle Richtungen gleichzeitig, und deshalb lohnt sie sich selbst dann, wenn einer der drei Aspekte für sich genommen nur ein paar Prozent bringen würde.

Das dritte Standbein, das hier noch nicht im Detail vorkommt, ist Prompt-Caching. Anthropic erlaubt es, stabile Prompt-Präfixe zu cachen — solange sich der Anfang eines Prompts nicht ändert, zahlst du für diesen Teil nur einen Bruchteil des normalen Preises. Die genauen Werte, TTLs und Bedingungen stehen in der offiziellen Anthropic-Dokumentation zu Prompt Caching. Als Größenordnung reicht: Cache-Reads sind deutlich günstiger als normale Input-Tokens, und der Cache greift dann besonders zuverlässig, wenn der Anfang des Prompts über viele Requests hinweg gleich bleibt. Was die Bedingungen dafür sind, wie man sie erfüllt und wo die häufigsten Selbst-Sabotagen sitzen, ist Thema von Teil 3 dieser Serie.

Wann es egal ist und wann nicht

Ich bin kein Freund davon, alles zu optimieren, was sich optimieren lässt. Bei einem dreißig Sekunden langen Throwaway-Skript, das einmal im Monat läuft, ist Token-Disziplin Overkill. Da darf der Assistent ruhig lesen, was er will, und die fünfundzwanzig Cent sind nichts gegen die zwei Minuten, die es gekostet hätte, den Kontext vorher sauber einzugrenzen. Wer an dieser Stelle pingelig wird, optimiert die falsche Stelle.

Die Stelle, an der es anfängt, sich zu lohnen, ist eine andere: das tägliche Arbeiten an einem Projekt über Wochen oder Monate hinweg. Hier laufen die Effekte unbemerkt auf. Fünfzig Sitzungsstarts pro Woche mit jeweils mehreren tausend überflüssigen Tokens sind nach einem Monat ein Posten, der sich nicht mehr ignorieren lässt. Und die Latenz-Kosten sind in der Summe unangenehmer als die Rechnung, weil sie direkt in den Arbeitsfluss eingreifen. Dreißig Sekunden Wartezeit pro Sitzungsstart sind fünfundzwanzig Minuten pro Woche. Niemand merkt sie im Moment, aber jeder merkt sie am Ende des Monats.

Die Regel, die bei mir gilt: Bei allem, was länger als eine Woche läuft und mehr als einmal pro Tag angefasst wird, lohnt sich Token-Disziplin. Bei allem darunter ist sie optional. Ein Projekt wird nicht dadurch besser, dass jeder Einzelrequest auf drei Tokens genau optimiert ist — es wird besser, wenn die Struktur stimmt, in der gearbeitet wird.

Token-Sparen ist Hygiene, kein Geiz

Die ehrliche Bilanz nach einiger Zeit mit diesem Thema: Token-Sparen ist kein Geiz, sondern eine Form von Hygiene. Wer sich angewöhnt, auf seinen Token-Verbrauch zu achten, bekommt nebenbei etwas, das auf den ersten Blick nichts mit Tokens zu tun hat. Er denkt klarer darüber nach, was der Assistent wirklich wissen muss. Er schreibt knappere Spezifikationen. Er hält sein Projektwissen sauberer, weil der Assistent dieses Wissen immer wieder liest und jeder überflüssige Absatz in einer Regeldatei ab sofort dreifach weh tut — in Kosten, in Latenz, in Qualität.

Das ist der Grund, warum ich Token-Disziplin inzwischen nicht mehr als technische Optimierung betrachte, sondern als eine Art angewandtes Ordnungsdenken. Tokens sind das Symptom, nicht die Krankheit. Die Krankheit ist ein Projekt, in dem Wissen unaufgeräumt herumliegt und bei jedem Sitzungsstart erneut mühsam rekonstruiert werden muss. Wer seine Regelarchitektur für die KI-Zusammenarbeit sauber hält, seine Memory-Datei verdichtet statt sammelt und nur das lädt, was wirklich gebraucht wird, spart nicht nur Tokens. Er arbeitet anders — und meistens besser.

Diese Einsicht hat sich bei mir nicht über eine Sitzung hinweg eingestellt, sondern während eines Audits über knapp zwanzig Projekte, bei dem ich Schritt für Schritt nachgezogen habe, wo der Token-Verbrauch eigentlich herkommt. Was ich dabei gefunden habe, war selten überraschend und fast immer vermeidbar. Es waren keine exotischen API-Tricks, sondern ein paar grundlegende Patterns, die man beachten oder ignorieren kann — mit sehr unterschiedlichen Ergebnissen. Wer tiefer in den Memory-Aspekt einsteigen will, findet den Begleitartikel zum Memory-Management in derselben Kategorie. Und ein systematisches Regel-Audit deckt oft dieselben Muster auf, nur an einer anderen Stelle des Setups.

Wie es weitergeht

Dieser Teil hat die Mechanik aufgemacht — Kosten, Latenz, Qualität, und warum die drei sich multiplizieren statt zu addieren. Der nächste Teil wird konkreter. Er geht dem größten sichtbaren Token-Posten im Alltag nach: der CLAUDE.md, die bei jedem Sitzungsstart automatisch geladen wird und in den meisten Projekten unbemerkt auf dreistellige Zeilenzahlen anwächst. Dort sitzt der Hebel, den man nicht spürt, bis man ihn ansieht — und dann nicht mehr ignorieren kann.

Was mit Prompt-Caching passiert, wie man einen Cache-Präfix stabil hält, warum die Read-Disziplin im Alltag der eigentlich größte Hebel ist und welche Fehler sich bei fast jedem wiederfinden lassen — das ist Teil 3. Bis dahin reicht es, einen einzigen Satz zu verinnerlichen: Jeder Token, den der Assistent liest, ist ein Token, den du ihn etwas anderes nicht tun lässt. Was er nicht gelesen hat, kann er auch nicht wiederholen. Und was er nicht wiederholt, kostet nichts.