Zum Inhalt springen
KISoftware

Modell-Routing beim KI-Coding: smart planen, billig bauen

Jamin Mahmood-Wiebe

Jamin Mahmood-Wiebe

Studioaufnahme eines Architekten-Blaupausen-Rolls neben einem Werkzeuggürtel auf mattschwarzem Tisch
Artikel

Warum ein Modell für alles die falsche Antwort ist

Ein Frontier-Modell über ein ganzes Repository nachdenken zu lassen, nur um eine Variable umzubenennen, ist Verschwendung. Ein günstiges Modell eine Datenbank-Migration entwerfen zu lassen, ist gefährlich. Die meisten Teams zahlen trotzdem den Höchstpreis für jede Aufgabe, egal wie trivial sie ist.

Genau hier setzt Modell-Routing an. Statt ein einziges Modell für jeden Schritt zu nutzen, teilen Sie die Arbeit auf: Das teuerste, klügste Modell plant. Ein günstigeres, schnelleres Modell führt aus. Der Planer denkt, der Ausführende tippt. Wir bei IJONIS in Hamburg setzen dieses Muster täglich ein, quer durch Kunden- und Produktprojekte.

"Ein großes Modell für ein ganzes Repository ist Verschwendung, nur um eine Variable umzubenennen. Ein günstiges Modell ist gefährlich beim Entwurf einer Migration." — Grundprinzip des Modell-Routings, 2026 in der Praxis etabliert

Diese Trennung ist keine Spielerei. Sie folgt einem Prinzip, das ich beim agentischen Coding immer wieder bestätigt gesehen habe: Code ist zur Massenware geworden. Die knappe Fähigkeit ist nicht mehr das Schreiben, sondern das Denken in Systemen und Architektur. Modell-Routing gießt genau diese Einsicht in einen Workflow. Der Architekt und der Handwerker sind zwei verschiedene Rollen, und sie brauchen nicht dieselbe Person, nicht dasselbe Modell und schon gar nicht denselben Preis pro Stunde.

Wie der Split konkret funktioniert

Ein Standard-Agent, der nach dem Reason-Act-Observe-Muster arbeitet, ruft nach jedem einzelnen Schritt das große Modell auf, um über den nächsten nachzudenken. Bei zwanzig Schritten sind das zwanzig teure Denkrunden, von denen die meisten mechanisch sind.

Der Planer-Ausführer-Split zerlegt diese Arbeit in drei klar getrennte Phasen. Jede Phase hat eine eigene Rolle, und jede Rolle bekommt das Modell, das preislich und fachlich zu ihr passt. So sieht der Ablauf konkret aus:

  1. Planungsphase. Ein Modell mit hoher Reasoning-Fähigkeit liest die Anforderung, versteht das Repository und zerlegt das Ziel in eine geordnete Liste von Schritten. Es schreibt keine Zeile Code. Es denkt und plant.
  2. Ausführungsphase. Ein kleineres, schnelleres Modell nimmt den Plan und arbeitet ihn Schritt für Schritt ab. Es trifft keine Architekturentscheidungen. Es setzt um, was bereits entschieden wurde.
  3. Prüfungsphase. Ein drittes, unabhängiges Modell liest den fertigen Code gegen den Plan und meldet Abweichungen. Es fängt still eingeschlichene Fehler, bevor sie in Produktion landen.

Ein konkretes Beispiel aus der Praxis: Sie wollen ein Rechnungsmodul in Ihre bestehende Software integrieren.

  • Der Planer (etwa Claude Fable 5 oder Opus 4.8) liest den Code, erkennt die Datenmodelle, plant die neue Tabelle, die Application Programming Interface (API), die Validierung und die Tests. Ergebnis: ein sauberer Plan mit zwölf Schritten.
  • Der Ausführende (etwa Claude Haiku 4.5, ein Generative Pre-trained Transformer (GPT) 5.6 Codex oder ein lokales Modell) setzt Schritt eins bis zwölf um. Jeder Schritt ist klein, klar definiert und braucht keine große Intelligenz mehr, nur saubere Umsetzung. Auch wiederkehrende Muster wie Create, Read, Update, Delete (CRUD) fallen hierunter.
💡

Warum das billiger ist

Die teuren Token fallen fast alle in der Planungsphase an, und die ist kurz. Die vielen mechanischen Ausführungs-Token laufen über das günstige Modell. Ein typischer Feature-Build verteilt sich grob auf ein Viertel Planung und drei Viertel Ausführung. Genau dieses Verhältnis routen Sie auf zwei Preisklassen.

Die Zahlen: Wie viel spart der Split wirklich?

Modell-Routing kann laut Produktionsberichten die Kosten je nach Aufteilung um 40 bis 85 Prozent senken. Die Spanne hängt davon ab, wie viel Verkehr Sie auf das günstige Modell verlagern. Je mehr mechanische Ausführung Sie an die günstige Preisklasse abgeben, desto größer die Ersparnis, solange die Qualität stimmt. Die folgenden Werte stammen aus veröffentlichten Produktions- und Benchmark-Daten von 2026.

Konkret bedeutet das laut Produktionsberichten von 2026: ein konservativer 10/90-Split spart 8 bis 10 Prozent, ein moderater 50/50-Split 40 bis 49 Prozent, ein aggressiver 80/20-Split 64 bis 79 Prozent. Der RouteLLM-Benchmark erreichte 85 Prozent Kostenersparnis bei 95 Prozent der Qualität eines reinen Frontier-Setups. In einem Multi-Agent-Aufbau, bei dem ein Planer ein Team von Ausführenden orchestriert, kann das Routen der Ausführungs-Turns auf ein günstiges Modell wie Haiku laut Analysen von digitalapplied noch einmal über 50 Prozent auf die Ausführungslast sparen.

Das klingt nach einem klaren Gewinn. Ist es aber nicht immer.

Der ehrliche Teil: Wann der Split verliert

Der Planer-Ausführer-Split ist kein Allheilmittel, und genau hier trennt sich dieser Artikel von den meisten. In einem sorgfältigen Benchmark von Akita on Rails verlor die erzwungene Aufteilung fast durchgängig gegen ein einzelnes starkes Modell. Bei zusammenhängenden Coding-Aufgaben kostet die Delegation an ein schwächeres Modell messbar Qualität, und der Planer selbst verbraucht so viele Token, dass die erhoffte Ersparnis verschwindet.

"Starker Planer plus günstiger Ausführender verliert gegen Opus allein." — Fabio Akita, Coding-Benchmark 2026

In diesem Benchmark erreichte ein einzelnes Opus-Modell 97 von 100 Punkten bei 18 Minuten und rund 4 Dollar, laut den Ergebnissen von Fabio Akita 2026. Die folgende Tabelle zeigt die Split-Varianten aus demselben Akita-Benchmark von 2026 (Modellnamen auf die aktuelle Generation aktualisiert).

SetupScoreKosten
Opus 4.8 solo97~4 $
Opus 4.8 + Haiku 4.5903,49 $
GPT 5.6 + medium941–3 $
Opus 4.8 + Kimi K2.69712 $
ℹ️

Quelle

Alle Werte in dieser Tabelle stammen aus dem Coding-Benchmark von Fabio Akita, 2026.

Die genauen Zahlen verschieben sich mit jedem Modell-Release, doch das Muster gilt über die Generationen hinweg unverändert. Zwei Lehren stecken darin. Erstens: Wenn Sie ein Modell zwingen, an ein schwächeres zu delegieren, obwohl die Aufgabe zusammenhängend ist, verlieren Sie Qualität. Zweitens: Die versteckten Planungskosten sind real. Als Opus ein günstiges Modell manuell orchestrierte, um die volle Qualität zu halten, verdreifachten sich die Gesamtkosten, weil der Planer selbst so viele Token verbrauchte.

⚠️

Die versteckte Planer-Steuer

Planung ist nicht kostenlos. Ein Frontier-Modell, das einen ganzen Plan durchdenkt, verbraucht selbst teure Token. Wenn Ihre Aufgabe klein und zusammenhängend ist, ist der Overhead des Planens größer als die Ersparnis beim Ausführen. Der Split rechnet sich erst ab einer gewissen Größe und Zerlegbarkeit.

Die Entscheidungsregel: Split oder Solo?

Wann lohnt sich das Routing, wann nicht? Die Antwort hängt an einer einzigen Frage: lässt sich die Aufgabe sauber in unabhängige Schritte zerlegen? Ist die Antwort ja, gewinnt der Split fast immer. Ist sie nein, weil jeder Schritt vom vorherigen abhängt, ist ein einzelnes starkes Modell die bessere Wahl. Die folgende Gegenüberstellung macht die Entscheidung schnell.

Vorteile

  • Große Features mit vielen mechanischen Schritten
  • Wiederholbare Aufgaben (Boilerplate, CRUD, Tests schreiben)
  • Klar abgegrenzte, unabhängige Teilschritte
  • Hohes Volumen, bei dem Token-Kosten spürbar werden
  • Migrationen und Refactorings mit klarem Zielbild

Nachteile

  • Kleine, zusammenhängende Aufgaben (der Planer-Overhead frisst die Ersparnis)
  • Aufgaben mit starken Abhängigkeiten zwischen Schritten
  • Kreative Architekturentscheidungen, die durchgehend Reasoning brauchen
  • Debugging, bei dem jeder Schritt vom vorherigen Befund abhängt
  • Einmalige, kleine Änderungen

Als Faustregel: Je größer und mechanischer die Aufgabe, desto mehr gewinnt der Split. Je kleiner und verzahnter, desto eher gewinnt ein einzelnes gutes Modell. Für den Mittelstand heißt das konkret: Beim Aufbau eines neuen Moduls oder einer Migration lohnt sich das Routing. Beim schnellen Bugfix am Freitagnachmittag nicht.

Wie Sie den Split in der Praxis aufsetzen

Sie müssen dafür kein eigenes System bauen. Mehrere Werkzeuge bringen den Split fertig mit, und Sie können mit jedem davon in wenigen Minuten starten. Diese drei Wege haben sich in der Praxis bewährt:

  1. Aider Architect-Modus. Aider trennt seit Langem ein starkes Modell für die Planung von einem separaten Editor-Modell für die Umsetzung. Sie geben zwei Modelle an, Aider erledigt die Aufteilung.
  2. Claude Code mit Subagenten. Ein Hauptmodell plant und delegiert klar abgegrenzte Teilaufgaben an günstigere Subagenten. Wir setzen das bei IJONIS täglich ein, gesteuert über strukturierte Instruktionen in einer Projektdatei (claude.md).
  3. Router-Schicht. Werkzeuge wie LiteLLM oder ein AI Gateway routen Anfragen automatisch nach Schwierigkeit auf verschiedene Modelle. Das eignet sich, wenn Sie viele unterschiedliche Aufgaben durch ein System schicken.
ℹ️

Das Qualitäts-Gate nicht vergessen

Der teuerste Fehler beim Routing ist die stille Qualitätsminderung: Das günstige Modell liefert wochenlang schlechteren Code, und Sie merken es erst, wenn die Fehler auflaufen. Testen Sie jede neue Aufteilung an 50 bis 500 realen Fällen, bevor Sie den Anteil des günstigen Modells erhöhen. Ein unabhängiges Review-Modell, das den Output prüft, schließt die Lücke.

Die saubere Kette lautet: Frontier-Modell plant, günstiges Modell führt aus, unabhängiges Modell prüft. Drei Rollen, drei Preisklassen, ein Ergebnis.

Was das für Ihr Unternehmen bedeutet

Modell-Routing ist kein technischer Trick für Entwicklerteams allein, sondern eine betriebswirtschaftliche Entscheidung. Sie zahlen für Intelligenz nur dort, wo Intelligenz gebraucht wird, und für Ausführung nur den Ausführungspreis. Für ein Unternehmen im Mittelstand bedeutet das planbare Kosten bei gleicher Ergebnisqualität, ohne teure Frontier-Preise für jede triviale Änderung zu zahlen.

Der Denkfehler, den ich am häufigsten sehe: Unternehmen wählen ein Modell, meist das teuerste, und schicken alles hindurch. Das ist, als würden Sie Ihren Chefarchitekten Kabel verlegen lassen. Er kann es, aber Sie bezahlen den falschen Preis dafür.

Unterm Strich liegt die eigentliche Fähigkeit nicht darin, das beste Modell zu kennen. Sie liegt darin, die Aufgabe richtig zu zerlegen und jedem Schritt das passende Modell zuzuordnen. Genau das ist die Loop-Engineering-Disziplin und der Kern dessen, was eine KI-Orchestrierungsschicht im Unternehmen leistet, wie im Leitfaden zur KI-Orchestrierung beschrieben: nicht ein Modell für alles, sondern das richtige Modell für jeden Schritt.

Häufige Fragen zum Modell-Routing

Was ist Modell-Routing beim KI-Coding?

Modell-Routing bedeutet, verschiedene Aufgaben gezielt an verschiedene KI-Modelle zu verteilen, statt jede einzelne Anfrage unterschiedslos durch ein einziges teures Modell zu schicken. Beim Coding plant ein starkes, teures Modell die Aufgabe, und ein günstigeres Modell führt den Plan Schritt für Schritt aus. So zahlen Sie hohe Preise nur für die Denkarbeit, nicht für die mechanische Umsetzung.

Wann lohnt sich der Planer-Ausführer-Split?

Der Split lohnt sich bei großen, gut zerlegbaren Aufgaben mit vielen mechanischen Schritten, etwa Datenbank-Migrationen, größeren Refactorings oder dem Aufbau vollständig neuer Module von Grund auf. Bei kleinen, stark verzahnten Aufgaben oder schnellem Debugging gewinnt meist ein einzelnes starkes Modell, weil der Planungs-Overhead die Ersparnis auffrisst.

Wie viel Kosten spart Modell-Routing?

Je nach Aufteilung berichten Teams von 40 bis 85 Prozent Ersparnis, abhängig davon, wie viel Ausführungslast auf das günstige Modell wandert. Ein moderater 50/50-Split senkt die Kosten um rund 40 bis 49 Prozent, ein aggressiver 80/20-Split um 64 bis 79 Prozent. Der RouteLLM-Benchmark erreichte 85 Prozent Ersparnis bei 95 Prozent der Qualität eines reinen Frontier-Setups.

Verliert der Split immer an Qualität?

Der Split verliert nicht zwangsläufig an Qualität, kann aber mehrere Punkte einbüßen, wenn man ihn auf die falsche Art von Aufgabe anwendet. Erzwingt man die Delegation bei zusammenhängenden Aufgaben, sinkt die Qualität um fünf bis sieben Punkte. Mit einem Qualitäts-Gate und einem unabhängigen Prüf-Modell bleibt die Qualität dagegen stabil. Entscheidend ist, den Split nur dort einzusetzen, wo die Aufgabe sich sauber zerlegen lässt.

Welche Werkzeuge unterstützen den Split?

Mehrere etablierte Werkzeuge bringen den Split bereits fertig mit, sodass Sie für den Einstieg überhaupt kein eigenes Routing-System von Hand selbst bauen müssen. Aider bietet einen Architect-Modus mit getrenntem Planer- und Editor-Modell. Claude Code delegiert über Subagenten. Router-Schichten wie LiteLLM oder ein AI Gateway verteilen Anfragen automatisch nach Schwierigkeit. Für einen ersten Test reicht Aider mit zwei Modellen aus.

Wenn Sie wissen wollen, wo in Ihren Entwicklungs- und Geschäftsprozessen sich dieser Split lohnt und wo nicht, sprechen Sie mit uns. Wir bauen genau solche Workflows, auf der bleeding edge dessen, was agentische Werkzeuge heute leisten.

Ende des Artikels

KI-Readiness-Check

Erfahren Sie in 3 Min., wie KI-bereit Ihr Unternehmen ist.

Jetzt starten3 Min. · Kostenlos

KI-Insights für Entscheidungsträger

Monatliche Einblicke in KI-Automatisierung, Software-Architektur und digitale Transformation. Kein Spam, jederzeit abbestellbar.

Lass uns sprechen

Fragen zum Artikel?.

Jamin Mahmood-Wiebe

Jamin Mahmood-Wiebe

Managing Partner

Termin buchen

Also available in English: Keith Govender

Nachricht schreiben

Diese Website wird durch reCAPTCHA geschützt und es gelten die Google Datenschutzbestimmungen Nutzungsbedingungen.