Modell-Routing entlastet Claude Code
Spotify hat ein internes Routing-Verfahren entwickelt, das den Token-Verbrauch von Claude Code bei umfangreichen Dateizugriffen deutlich reduziert. In Tests mit einem Java-Monorepo lag die durchschnittliche Ersparnis bei sogenannten Bulk-Read-Szenarien bei rund 90 %.
Der Ansatz beruht auf einer einfachen Trennung. Routinearbeiten wie das Lesen großer Dateien oder das Erzeugen vorhersehbaren Boilerplate-Codes übernimmt ein günstigeres Modell. Claude bleibt für Debugging, Architekturentscheidungen und andere Aufgaben reserviert, die komplexes logisches Denken erfordern.
„Das meiste, was ein KI-Coding-Agent für mich tut, ist kein Denken. Es ist I/O“, erklärt Spotify Engineering sinngemäß übersetzt.
I/O bezeichnet hier das Lesen und Schreiben von Daten. Gerade Coding-Agenten verbringen einen erheblichen Teil ihrer Arbeit damit, Dateien einzulesen, bestehende Muster zu erfassen und standardisierten Code zu erzeugen. Dafür ist ein leistungsfähiges Frontier-Modell häufig überdimensioniert.
Zwei spezialisierte Agenten übernehmen Routinearbeit
Spotify setzt dafür sogenannte AiKA Modes innerhalb seiner internen Plattform Portal ein. Ein Mode ist ein deklarativ konfigurierter, kurzlebiger Agent mit festgelegtem Modell, Anweisungen und Parametern. Für das Routing werden zwei Modi mit Gemini 2.5 Flash als Arbeitsmodell genutzt.
| Modus | Aufgabe | Ergebnis |
|---|---|---|
| bulk-reader | Große Dateien analysieren und zusammenfassen | Claude erhält nur eine kompakte, strukturierte Zusammenfassung |
| code-writer | Tests, Konfigurationen, Typdefinitionen und Boilerplate-Code erzeugen | Der Code wird direkt auf die Festplatte geschrieben |
Beim bulk-reader gelangen die vollständigen Dateien nicht in das Kontextfenster von Claude. Stattdessen liest Gemini 2.5 Flash die Inhalte und liefert nur die für die jeweilige Frage relevanten Informationen zurück.
Der code-writer arbeitet mit einer Spezifikation und einer Referenzdatei. Dadurch kann das Modell vorhandene Namenskonventionen und Strukturen übernehmen. Das Ergebnis wird direkt gespeichert, ohne dass Claude den generierten Code erneut als teure Ausgabetokens verarbeiten muss.
Plugin erzwingt die Delegation
Die erste Umsetzung basierte lediglich auf Anweisungen für Claude. Das erwies sich als unzuverlässig, weil das Modell die Routing-Regeln ignorieren konnte. Spotify entwickelte deshalb das Claude-Code-Plugin shunt, das Werkzeugaufrufe vor ihrer Ausführung abfängt.
Ein sogenannter PreToolUse Hook prüft jeden Lesezugriff. Überschreitet eine Datei den konfigurierten Schwellenwert, blockiert das Plugin den direkten Zugriff und verweist Claude auf den bulk-reader. Standardmäßig greift diese Regel ab 350 Zeilen.
| Kennzahl | Wert |
|---|---|
| Durchschnittliche Token-Ersparnis bei Bulk Reads | rund 90 % |
| Standard-Schwellenwert für große Dateien | 350 Zeilen |
| Typische zusätzliche Latenz je Delegation | 10 bis 30 Sekunden |
| Maximale Laufzeit eines Portal-Aufrufs | 30 Sekunden |
Gezielte Lesezugriffe auf einzelne Abschnitte bleiben erlaubt. Das ist notwendig, wenn Claude nach einer Zusammenfassung eine konkrete Stelle prüfen oder verändern muss. Auch Befehle, die Inhalte bereits filtern, können weiterhin direkt ausgeführt werden.
Routing hat technische Grenzen
Die Delegation eignet sich nicht für jede Aufgabe. In den Spotify-Tests übersah das günstigere Arbeitsmodell unter anderem einen subtilen Fehler bei der Thread-Sicherheit. Claude erkannte das Problem, nachdem der relevante Kontext bereitgestellt worden war.
Debugging, sicherheitskritischer Code und Architekturentscheidungen bleiben deshalb beim leistungsfähigeren Modell. Auch Änderungen an bestehenden Dateien lassen sich nicht vollständig auslagern. Zusammenfassende Modelle liefern nicht immer verlässliche Zeilennummern, weshalb Claude für konkrete Anpassungen weiterhin gezielt auf den Originalcode zugreifen muss.
Hinzu kommt die Latenz. Jeder delegierte Aufruf benötigt typischerweise 10 bis 30 Sekunden. Bei kleinen Dateien kann die Wartezeit den Kostenvorteil übersteigen, weshalb ein Mindestschwellenwert entscheidend ist.
Token-Kosten werden zum eigentlichen Preisfaktor
Nach den von Spotify genannten Zahlen gibt ein Viertel der Engineering-Führungskräfte bereits 200 bis 500 US-Dollar pro Entwickler und Monat für Tokens aus. In einzelnen Fällen liegen die Ausgaben über 2.000 US-Dollar. Eine im Bericht aufgegriffene Prognose erwartet, dass die Kosten für KI-Coding-Werkzeuge bis 2028 das durchschnittliche Entwicklergehalt übersteigen könnten.
„Nicht die Lizenzgebühr pro Nutzer schmerzt, sondern die Token. Und man füttert das alles in ein Frontier-Modell, das massiv überqualifiziert ist“, so die sinngemäße Übersetzung der Kernaussage von Spotify Engineering.
Das Beispiel ergänzt den aktuellen Preiskampf bei KI-Modellen um eine wichtige Perspektive. Niedrigere Token-Preise helfen, lösen aber nicht das strukturelle Problem einer ineffizienten Modellwahl. Auch ein günstigeres Frontier-Modell bleibt teuer, wenn jeder Dateizugriff ungefiltert durch dessen Kontextfenster läuft.
Andere Ansätze verfolgen ein ähnliches Ziel. Der Ramp Router verteilt KI-Anfragen zwischen mehreren Modellen, während Untersuchungen zum Einfluss des KI-Harness auf Agentenergebnisse zeigen, dass die Steuerung rund um das Modell mindestens ebenso wichtig sein kann wie das Modell selbst.
Was Unternehmen im DACH-Raum daraus ableiten können
Für Entwicklungsabteilungen wird damit die Kostenarchitektur wichtiger als der reine Preis einer Nutzerlizenz. Ein All-in-One-Abo schafft zwar einen einfachen Zugang, verhindert aber nicht zwangsläufig unkontrollierten Token-Verbrauch. Bei wachsender Nutzung können verbrauchsabhängige Kosten die festen Lizenzgebühren deutlich überholen.
Eigenes Modell-Routing erlaubt es, teure Modelle auf Aufgaben mit hohem Denkbedarf zu begrenzen. Dateioperationen und standardisierte Generierung können günstigere Cloud-Modelle oder, abhängig von Datenschutz und Infrastruktur, lokal betriebene Open-Source-Modelle übernehmen. Das reduziert Kosten und die Abhängigkeit von einem einzelnen Anbieter, erhöht jedoch den Aufwand für Routing-Regeln, Qualitätssicherung und Betrieb.
Unklar bleibt, ob Portal, AiKA oder die beschriebenen Plugins öffentlich als Open Source verfügbar sind. Der konkrete Aufbau lässt sich daher nicht ohne Weiteres übernehmen. Das technische Prinzip ist jedoch unabhängig von Spotify: Aufgaben klassifizieren, Kostenlimits definieren und nur dort ein Frontier-Modell einsetzen, wo dessen Fähigkeiten tatsächlich benötigt werden.