Claude Code Token-Kosten: Modell-Routing in der KI-Entwicklung

Jeder KI-gestützte Entwicklungs-Workflow hat eine Rechnung, die am Monatsende ankommt — und die meisten Teams lesen sie nie genau. Sie sehen einen API-Betrag, zucken mit den Schultern und buchen ihn als „Tooling”. Dabei sind Token-Kosten kein Tooling-Detail, sondern eine Engineering-Entscheidung: Wer welches Modell für welche Aufgabe einsetzt, entscheidet darüber, ob ein Feature ein Vielfaches dessen kostet, was es müsste — bei exakt gleicher Liefermenge.

In den ersten drei Teilen dieser Serie ging es darum, Claude Code im Team vertrauenswürdig zu machen: Governance mit Permissions und Rules, Parallelität mit Subagents, Absicherung mit Hooks. Drei Schichten, die aus dem Werkzeug ein Team-Werkzeug machen. Keine davon beantwortet aber die Frage, was die Arbeit kostet.

Teil 3 war als Abschluss der Serie gedacht — und für die Frage „kann man dem trauen?” war er das auch. Dieser vierte Teil stellt eine andere Frage: „Kann man sich das leisten, und zwar bei jedem Projekt?” Das ist die ökonomische Schicht, und sie entscheidet darüber, ob ein KI-gestützter Workflow ein teures Experiment bleibt oder zur tragfähigen Arbeitsweise wird.

Warum Token-Ökonomie ein Engineering-Thema ist

Es gibt eine verbreitete Annahme, KI-Kosten seien eine Sache der Beschaffung: man verhandelt einen Tarif, bezahlt ihn, fertig. Das stimmt für Strom. Für Tokens stimmt es nicht. Der Hebel liegt nicht im Einkaufspreis, sondern in der Architektur des Workflows — in der Frage, welches Modell wann läuft und wie viel Kontext es dabei mit sich trägt.

Der entscheidende Punkt: Wand-Zeit und Geld sind nicht dasselbe. Ein Subagent, der eine halbe Stunde parallel arbeitet, fühlt sich „schnell” an — aber wenn er dabei in jedem Schritt das teuerste Modell mit einem aufgeblähten Kontext füttert, ist er teuer, egal wie schnell er fertig ist. Umgekehrt kann eine Aufgabe, die nominal länger läuft, einen Bruchteil kosten, weil sie das passende Modell mit schlankem Kontext nutzt.

Das ist kein Spar-Thema im Sinne von „weniger nutzen”. Es ist ein Engineering-Thema im Sinne von „richtig dimensionieren” — dieselbe Disziplin, mit der man eine Datenbank-Query nicht über zehn Joins laufen lässt, wenn zwei reichen. Die Liefermenge bleibt gleich; nur die Verschwendung verschwindet.

Wo Tokens verbrannt werden — die vier Lecks

Bevor man routet, muss man verstehen, wo das Geld tatsächlich abfließt. In der Praxis sehen wir vier wiederkehrende Lecks — und alle vier haben mit Kontext oder Modellwahl zu tun, nicht mit der Menge an Code.

1. Aufgeblähter Kontext. Eine lange Session trägt nach einer Stunde Arbeit alles mit sich: gelesene Files, vorherige Tool-Aufrufe, halbe Diskussionen, die längst entschieden sind. Jeder neue Schritt zahlt für diesen gesamten Ballast — und zwar als Input-Tokens, in jedem einzelnen Request. Der Kontext ist der stille Kostentreiber, nicht der eigentliche Output.

2. Das Top-Modell für triviale Arbeit. Das stärkste Modell für eine mechanische Umbenennung, einen Import-Fix oder das Durchreichen eines bekannten Patterns einzusetzen, ist, als würde man einen Software-Architekten eine Stunde lang Tabs in Spaces umwandeln lassen. Die Arbeit wird erledigt — zum Drei- bis Fünffachen des nötigen Preises.

3. Re-Reads. Wenn ein Agent dieselbe Datei dreimal liest, weil er sie nicht im Kontext behalten hat — oder weil der Kontext zwischendurch verworfen wurde —, zahlt man dreimal. Re-Reads sind besonders tückisch, weil sie sich produktiv anfühlen: Es passiert ja etwas.

4. Fehlendes Caching und fehlendes Scoping. Ein stabiler System-Prompt, eine deterministische Tool-Liste, ein Repository-Layout, das sich pro Request nicht ändert: Das alles ist cachebar. Wer es nicht cacht, zahlt jeden gemeinsamen Präfix immer wieder zum vollen Preis. Und ein Agent, der Zugriff auf das ganze Repo hat, obwohl er nur ein Modul braucht, schleppt entsprechend mehr Kontext mit.

Alle vier Lecks eint: Sie sind unsichtbar, solange niemand auf die usage-Werte schaut. Genau deshalb braucht es eine bewusste Strategie statt guten Willens.

Das Routing-Pattern: teure Enden, günstige Mitte

Die Kernidee des Modell-Routings ist simpel und folgt der Form der Arbeit selbst. Ein Feature durchläuft drei Phasen mit unterschiedlichem Anspruch:

• Spezifikation — die Aufgabe verstehen, Randfälle benennen, die Architektur der Lösung festlegen, den Vertrag zwischen Backend und Frontend definieren. Hier zahlt sich Urteilsvermögen aus. Diese Phase verbraucht wenige Tokens, profitiert aber am stärksten vom intelligentesten Modell. Das ist Arbeit auf dem Niveau eines Software-Architekten.
• Implementierung — den Spec in Code umsetzen: Dateien lesen, editieren, Tests laufen lassen, iterieren. Hier fällt das Volumen an Tokens an — Lesen und Schreiben über viele Dateien, viele Tool-Aufrufe, mehrere Durchläufe. Die Aufgabe ist gut umrissen; das Modell muss vor allem zuverlässig und solide sein, nicht maximal kreativ.
• Review — gegen die Konventionen prüfen, Trade-offs hinterfragen, schauen, ob die Lösung das richtige Problem löst. Wieder eine Frage des Urteils, wieder wenige Tokens, wieder das Top-Modell.

Daraus ergibt sich das Muster fast von selbst: die Enden sind teuer, die Mitte ist günstig. Spezifikation und Review laufen auf dem Top-Modell (Opus), die volumenstarke Implementierung auf dem günstigeren Arbeitspferd (Sonnet). Man bezahlt das stärkste Modell genau dort, wo sein Urteil den Unterschied macht — und nicht für die mechanische Masse dazwischen.

Konkret heißt das in unserem Setup: Der Orchestrator und die Review-Agents laufen auf dem Top-Modell, die Worker-Subagents für Backend- und Frontend-Implementierung auf Sonnet. In einer Subagent-Definition (siehe Teil 2) lässt sich das pro Agent festlegen:

---
name: dev-backend
description: .NET-Backend-Implementierung einer Story
model: sonnet
allowed-tools: Read, Edit, Bash
---

Du implementierst eine Backend-Story gegen den vereinbarten Spec ...

---
name: code-reviewer
description: Read-only Review gegen die CLAUDE.md-Konventionen
model: opus
allowed-tools: Read, Grep, Glob
---

Du prüfst eine fertige Story gegen Architektur und Konventionen ...

Der entscheidende Punkt ist nicht „Sonnet ist billiger, also nimm immer Sonnet”. Es ist: Setze die Modellstärke dort ein, wo Urteilsvermögen über das Ergebnis entscheidet, und nimm das günstigere Modell für die Masse, bei der Solidität zählt. Die Qualität an den Enden bleibt unangetastet — genau dort, wo schlechte Entscheidungen am teuersten würden.

Was ein Token wirklich kostet — die Zahlen

Damit das Routing kein Bauchgefühl bleibt, hilft ein Blick auf die tatsächlichen Preise. Anthropic listet die Modelle nach Input- und Output-Tokens, jeweils pro einer Million Tokens (Stand Juni 2026 — Preise ändern sich, die Verhältnisse sind das Stabile):

Modell	Input / 1M	Output / 1M
Opus 4.8 (Top-Modell)	5 $	25 $
Sonnet 4.6 (Arbeitspferd)	3 $	15 $
Haiku 4.5 (leichtgewichtig)	1 $	5 $

Zwei Dinge fallen sofort auf. Erstens: Output ist fünfmal so teuer wie Input — bei jedem Modell. Code, den ein Agent schreibt, kostet deutlich mehr als Kontext, den er liest. Zweitens: Sonnet kostet pro Token rund 40 % weniger als Opus, Haiku rund 80 % weniger als Opus. Das sind keine Rundungsfehler, sondern der Hebel.

Und es gibt einen dritten Hebel, den die Tabelle nicht zeigt: Prompt-Caching. Ein einmal gecachter Präfix — System-Prompt, Tool-Definitionen, ein stabiler Repo-Kontext — kostet beim erneuten Lesen nur noch rund ein Zehntel des Input-Preises. Das Schreiben in den Cache kostet einmalig etwas mehr (rund das 1,25-Fache bei kurzer Lebensdauer), aber ab dem zweiten Request, der denselben Präfix nutzt, rechnet es sich. Bei einem Agenten, der über eine Stunde am selben Repo arbeitet, ist der Unterschied zwischen „cacht” und „cacht nicht” dramatisch.

Ein vereinfachtes Rechenbeispiel macht den Routing-Effekt greifbar. Nehmen wir an, ein typisches Feature verteilt seinen Token-Verbrauch grob so:

• Spezifikation: ~10 % des Volumens, urteilsintensiv
• Implementierung: ~80 % des Volumens, mechanisch-solide
• Review: ~10 % des Volumens, urteilsintensiv

Lässt man alles auf dem Top-Modell laufen, zahlt man für 100 % des Volumens den Opus-Preis. Routet man die 80 % Implementierung auf Sonnet, fällt für diesen Löwenanteil ein um ~40 % niedrigerer Preis an — und weil die Implementierung das output-lastige Stück ist (geschriebener Code), schlägt die günstigere Output-Rate doppelt durch. Das Ergebnis ist grob ein Drittel weniger Kosten pro Feature, ohne dass an den urteilsintensiven Enden auch nur ein Token an Qualität verloren geht. Wer zusätzlich nicht-latenzkritische Batch-Arbeit über die Batch-API laufen lässt (halber Preis) oder den Repo-Kontext sauber cacht, drückt weiter.

Die genauen Prozentzahlen variieren von Projekt zu Projekt — die Mechanik nicht: Das große Volumen gehört auf das günstige Modell, die kleinen, entscheidungsstarken Phasen auf das teure.

Die Mechanik: wie die Serie zusammenspielt

Das Schöne am Routing ist, dass es nicht allein steht. Es zahlt genau auf die drei Schichten ein, die wir in den ersten Teilen aufgebaut haben — die ganze Serie greift hier ineinander:

Subagents als Kosten-Hebel (Teil 2). Ein Subagent startet mit eigenem, frischem Kontext — ohne die Konversations-Historie der Haupt-Session. Ein Such-Agent, der nach einem Symbol fahndet, profitiert null vom geladenen Kontext der Hauptsitzung und würde umgekehrt für jeden Schritt dafür mitbezahlen. Indem er die Aufgabe isoliert und nur das kompakte Ergebnis zurückgibt, ist die Kontext-Isolation nicht nur eine Architektur-, sondern eine Kostenentscheidung. Genau hier setzt auch das Modell-Routing an: Jeder Subagent bekommt das Modell, das zu seiner Aufgabe passt.

Scoping über Permissions und Rules (Teil 1). Ein Agent, dessen Permissions und path-scoped Rules ihn auf das relevante Modul eingrenzen, schleppt weniger Kontext mit als einer mit Zugriff auf das ganze Repo. Governance reduziert nicht nur das Risiko — sie reduziert die Token-Last.

Hooks statt Modell-Raten (Teil 3). Ein deterministischer Hook, der nach jedem Edit formatiert oder vor Schluss die Tests laufen lässt, kostet keine Tokens — er ist ein Shell-Skript. Dieselbe Prüfung dem Modell zu überlassen („schau mal, ob das sauber ist”) kostet Tokens und ist obendrein unzuverlässiger. Jede mechanische Prüfung, die in einen Hook wandert, ist Token-Last, die gar nicht erst entsteht.

Caching als Querschnitt. Über allem liegt das Prinzip, den teuren Präfix nur einmal zu bezahlen: stabiler System-Prompt, deterministische Tool-Reihenfolge, ein Kontext, der sich nicht bei jedem Request neu zusammensetzt. Das ist weniger eine Einstellung als eine Disziplin im Aufbau des Workflows.

Zusammengenommen ergibt sich ein Bild, in dem die vier Schichten nicht nebeneinanderstehen, sondern dieselbe Sache aus vier Richtungen betreiben: Governance grenzt ein, Parallelität isoliert, Absicherung verlagert Mechanisches aus dem Modell heraus — und Ökonomie setzt auf all dem das richtige Modell an die richtige Stelle.

Was das fürs Projekt bedeutet

Bis hierhin klingt das nach interner Optimierung. Der eigentliche Wert liegt aber beim Kunden — und zwar an einer konkreten Stelle: dem Festpreis.

Wir liefern eigene Projekte standardmäßig im Werkvertrag — also zum Festpreis. Ein Festpreis ist nur dann verantwortbar, wenn man die eigenen Kosten kennt und im Griff hat. Genau das leistet diszipliniertes Token-Engineering: Es macht den KI-gestützten Teil der Arbeit kalkulierbar statt zu einer Wundertüte, auf die man einen dicken Risikoaufschlag packen müsste. Wer seine Kosten nicht kontrolliert, kalkuliert entweder zu knapp (und verbrennt Marge) oder zu großzügig (und der Kunde bezahlt den Puffer). Beides ist schlechtes Engineering.

Für den Kunden heißt das dreierlei:

• Vorhersehbare Budgets. Kein Projekt, dessen Tooling-Kosten plötzlich explodieren, weil jemand das teuerste Modell auf die ganze Codebasis losgelassen hat.
• Mehr Wert pro Euro. Das eingesparte Budget steckt nicht in verschwendeten Tokens, sondern in mehr gelieferter Substanz — oder in einem ehrlicheren Preis.
• Ein Festpreis ohne Angstaufschlag. Disziplin auf unserer Seite bedeutet, dass wir den Preis nennen können, ohne uns gegen das eigene Unwissen abzusichern.

Wichtig ist die Reihenfolge: Das Ziel ist nie „so wenig Tokens wie möglich”. Das Ziel ist, kein Token zu verschwenden — ein Unterschied wie zwischen Geiz und Sorgfalt. An den urteilsintensiven Enden geben wir bewusst das teuerste Modell aus, weil eine schlechte Architektur- oder Review-Entscheidung später ein Vielfaches dessen kostet, was man an Tokens gespart hätte.

Fünf Prinzipien für token-bewusstes Engineering

Wer das Routing in den eigenen Workflow holen will, kann sich an fünf Regeln halten:

1. Modellstärke folgt dem Urteilsbedarf, nicht der Sichtbarkeit. Spec und Review aufs Top-Modell, die volumenstarke Implementierung aufs Arbeitspferd. Nicht das, was „wichtig aussieht”, sondern das, was Urteilsvermögen verlangt, bekommt das stärkste Modell.

2. Kontext ist der eigentliche Kostentreiber — halte ihn schlank. Isoliere Aufgaben in Subagents mit frischem Kontext. Grenze Agents über Permissions und Rules auf das ein, was sie wirklich brauchen. Jeder mitgeschleppte Ballast wird in jedem Request bezahlt.

3. Cache, was stabil ist. Stabiler System-Prompt, deterministische Tool-Reihenfolge, kein Zeitstempel und keine zufällige ID im Präfix. Der gemeinsame Anteil soll einmal bezahlt und danach gelesen werden.

4. Verlagere Mechanisches aus dem Modell heraus. Was ein Shell-Skript deterministisch prüfen kann — Format, gefährliche Befehle, rote Tests —, gehört in einen Hook, nicht in einen Modell-Prompt. Token-Last, die gar nicht erst entsteht, ist die billigste.

5. Miss, bevor du optimierst. Schau auf die usage-Werte: Wo entstehen Input-Tokens, wo Output-Tokens, wie hoch ist die Cache-Trefferquote? Ohne diese Zahlen optimiert man Gefühle, nicht Kosten.

Fazit

Damit ist die Klammer der Serie wirklich geschlossen — und zwar um eine Schicht weiter, als Teil 3 es vorhatte. Vier Schichten machen aus Claude Code ein Werkzeug, dem man im Team trauen und das man sich bei jedem Projekt leisten kann:

• Governance (Teil 1): Permissions, Rules und Skills geben der KI Leitplanken.
• Parallelität (Teil 2): Subagents mit Worktree-Isolation liefern mehrere Stories gleichzeitig.
• Absicherung (Teil 3): Hooks als deterministische Quality-Gates fangen ab, was nicht scheitern darf.
• Ökonomie (Teil 4): Modell-Routing setzt die teure Intelligenz dorthin, wo ihr Urteil zählt — und nicht auf die mechanische Masse.

Token-Verschwendung ist keine Lappalie, die man am Monatsende abnickt. Sie ist die Differenz zwischen einem KI-Workflow, der ein teures Experiment bleibt, und einem, der zur tragfähigen Arbeitsweise wird — mit kalkulierbaren Kosten, ehrlichen Festpreisen und keinem Euro, der in überflüssigem Kontext verbrennt. Nicht weniger Substanz, sondern dieselbe Substanz ohne Verschwendung.

---

Wer 2026 einen KI-fähigen Software-Partner sucht, der nicht nur kann, sondern auch wirtschaftlich arbeitet — wir haben dazu sechs Kriterien aufgeschrieben. Und wenn Sie Ihren eigenen KI-gestützten Workflow auf tragfähige Kosten bringen wollen und einen Sparringspartner suchen, der das schon durchgezogen hat — buchen Sie gerne ein kostenloses Erstgespräch.

Tech42 baut individuelle Softwareentwicklung mit modernen KI-Tools im Engineering-Alltag — nicht als Marketing-Begriff, sondern als Teil unseres Stacks. Wie sich die Rolle der Entwickler dabei verschiebt, beschreibt unser Artikel Wie KI die moderne Softwareentwicklung verändert.