KI-Kosten um 57% gesenkt: Model-Routing für Multi-Agent-Systeme

Eine Zeile YAML. Das war alles.

1model: sonnet

Diese eine Zeile im Agent-Frontmatter hat unsere Kosten pro Agent-Run für einen der am meisten genutzten Agents in unserer Multi-Agent-Architektur um ~57% reduziert. Nicht durch weniger Features. Nicht durch schlechtere Workflow-Compliance -- sondern durch die Erkenntnis, dass nicht jeder Agent das stärkste Modell braucht. (Mit einem Tradeoff bei der Recherchebreite, den wir weiter unten aufschlüsseln.)

Ich schreibe das, weil ich den Fehler gemacht habe, den wahrscheinlich jedes Team macht, das mit AI Agents arbeitet: Alles auf dem besten verfügbaren Modell laufen lassen, weil man es kann. Und weil man sich nicht die Mühe gemacht hat, zu messen, ob es nötig ist.

Wir haben es gemessen. Hier sind die Zahlen.

Der Kontext: 9 Agents, ein Orchester

Bei Infralovers betreiben wir eine Multi-Agent-Architektur mit Claude Code. 9 spezialisierte Agents, die verschiedene Aufgaben abdecken -- von Technology Research über Content-Erstellung bis zu Knowledge-Base-Abfragen und Channel-Routing. Jeder Agent hat eine klare Aufgabe, eigene Tool-Berechtigungen und ein definiertes Skill-Set. Das ist das Microservices-Pattern, angewandt auf AI Agents.

Das System läuft auf Claude Code -- Anthropics agentisches Coding-Tool, das als CLI im Terminal läuft. Das Schöne daran: Agents werden als YAML-Frontmatter in Markdown-Files definiert. Name, Beschreibung, erlaubte Tools, geladene Skills -- und in aktuellen Claude-Code-Versionen auch das Modell. Eine Zeile im Frontmatter bestimmt, welches Claude-Modell der Agent verwendet:

1---
2name: technology-researcher
3description: Research open source projects and technology vendors
4tools: [Read, Write, Bash, Glob, Grep, WebSearch, WebFetch]
5model: sonnet  # <-- diese eine Zeile
6skills: [research, knowledge-base]
7---

Das ist kein Feature, das groß beworben wird. Es steht in der Doku, es funktioniert, aber die meisten Teams nutzen es nicht. Der Default hängt vom Account-Typ ab (z.B. Pro → Sonnet 4.6, Max → Opus 4.6) und kann bei Usage-Limits automatisch auf Sonnet zurückfallen. Und warum sollte man weniger nehmen, wenn man mehr haben kann?

Naja. Weil es Geld kostet. Und weil "mehr" nicht immer "besser" bedeutet.

Warum Sonnet 4.6 überhaupt in Frage kam

Am 17. Februar 2026 hat Anthropic Sonnet 4.6 veröffentlicht. Was mich aufhorchen ließ: Der Abstand zwischen Sonnet und Opus war noch nie so klein.

Ein paar Benchmarks zum Einordnen:

• MCP-Atlas (Tool Use): Sonnet 4.6 61,3% (max effort) vs. Opus 4.6 59,5% -- Sonnet liegt vorn (historischer Topscore: Opus 4.5 mit 62,3%)
• SWE-bench Verified (Coding): 79,6% vs. 80,8% -- marginaler Opus-Vorsprung
• Finance Agent / Vals AI: Sonnet schlägt Opus (63,3% vs. 60,1%)
• GDPval-AA (Knowledge Work): Sonnet schlägt Opus (1633 vs. 1606 Elo) -- Unterschied innerhalb des 95%-Konfidenzintervalls
• ARC-AGI-2 (Novel Reasoning): Opus 68,8% vs. Sonnet 58,3% -- hier zeigt sich der echte Unterschied

(Werte aus den Anthropic System Cards bzw. GDPval von Artificial Analysis.)

Das ist bemerkenswert. Zum ersten Mal schlägt ein Mid-Tier-Modell ein vorheriges Flagship in mehreren Benchmarks. Und zwar nicht in trivialen Aufgaben, sondern in agentic Work -- genau das, was unsere Agents tun.

Die Frage war also nicht "Ist Sonnet gut genug?" sondern "Für welche Agents ist Opus überhaupt nötig?"

Das Experiment: 18 Runs, echte Daten

Ich bin ehrlich: Benchmarks lesen ist nett, aber ich vertraue nur Zahlen aus meinem eigenen System. Also haben wir einen sauberen A/B-Test aufgesetzt.

Setup

• Agent: Technology Researcher -- unser Agent für Technologie-Evaluierungen. Recherchiert Open-Source-Projekte und Technology Vendors, analysiert Tech Stacks, bewertet Maturity und Community Health, persistiert strukturierte Findings in unserer Knowledge Base via API-Calls und generiert Evaluierungsberichte.
• Baseline (Gruppe A): Technology Researcher auf Default (in unserem Setup = Opus 4.6) -- kein model: Feld gesetzt
• Treatment (Gruppe B): Technology Researcher explizit auf model: sonnet gesetzt
• Umfang: 3 Runden pro Treatment, 3 parallele Agents pro Runde, 9 Evaluierungen pro Gruppe
• Bedingungen: Volle realistische Runs mit allen Integrationen aktiv -- WebFetch, WebSearch, API-Persistenz, Report-Generierung

Keine künstlichen Benchmarks. Keine vereinfachten Tasks. Der Agent hat genau das gemacht, was er immer macht: Websites durchsuchen, Quellen evaluieren, Daten strukturiert ablegen, Berichte schreiben. Jede Evaluierung ist ein separater Run mit eigenem Task-Input; die 3 parallelen Agents dienen nur der Laufzeitverkürzung, nicht als eigene Treatment-Variable.

Die Rohdaten

Opus 4.6 (n=9)

Sonnet 4.6 (n=9, exkl. Outlier n=8)

Ein Sonnet-Run hatte mit Infrastruktur-Problemen zu kämpfen -- Bash-Permission-Fehler führten zu Retries, die Tokens und Laufzeit auf 9,4 Millionen Tokens und 1018 Sekunden aufgebläht haben. Das ist kein Modell-Problem, das ist ein Infrastruktur-Artefakt. Deshalb die bereinigte n=8-Auswertung. Wir werten daher beides aus (n=9 und n=8) und nutzen n=8 für Deltas, weil der Outlier klar auf Infrastruktur-Retries zurückgeht.

Was die Zahlen sagen

Schauen wir uns die Deltas an (bereinigt, ohne Outlier):

Sonnet braucht ein Drittel weniger Tokens, ein Viertel weniger API Calls und ist 12% schneller. Aber -- und das ist wichtig -- es findet auch weniger: 6,3 evaluierte Projekte pro Run statt 9,0.

Die Kostenrechnung: Warum 57%

Mit "Kosten" meine ich hier ausschließlich LLM-Token-Kosten (Input, Output, Cache Read, Cache Create) -- ohne Infrastruktur- oder Tool-Provider-Kosten.

Die reinen Token-Einsparungen von 35% sind nur die halbe Geschichte. Die andere Hälfte ist der Preisunterschied.

Sonnet kostet gleichmäßig 60% des Opus-Preises über alle Token-Typen. Das ist ungewöhnlich sauber -- normalerweise variieren die Verhältnisse je nach Token-Typ. (Die Cache-Preise folgen einer festen Formel: Cache Read = Input-Preis x 0,1; Cache Create = Input-Preis x 1,25.)

Jetzt die Compound-Rechnung: In unserem Setup bestehen Agent Sessions laut Logs zu circa 90% aus Cache Reads (der Agent lädt bei jedem API Call sein System-Prompt und den bisherigen Kontext). Der relevante Preis ist also primär der Cache-Read-Preis.

Sonnet-Faktor: 0,60 (Preis pro Token) x 0,65 (Volumen, 35% weniger Tokens) = 0,39

Das heißt: Jeder Sonnet-Run kostet 39% dessen, was ein Opus-Run kostet. Oder anders formuliert: 61% Kostenreduktion pro Agent-Run.

In der Praxis sind es konservativ gerechnet circa 57%, weil die Token-Zusammensetzung (Input vs. Output vs. Cache) nicht exakt 90/10 ist und der Outlier die Durchschnitte leicht verschiebt. (Im Folgenden nutze ich ~57% als konservativen Praxiswert; die Modellrechnung ergibt 61% bei unseren Cache-Annahmen.)

Wichtig: Das ist eine Kostenreduktion pro Run, nicht automatisch pro evaluiertem Projekt. Da Sonnet im Mittel weniger Projekte pro Run abdeckt, hängt der tatsächliche "Cost per Project" davon ab, ob man Breite als Qualitätskriterium zählt.

Als Faustregel: Wenn euer Ziel "maximale Coverage" ist, bewertet zusätzlich Cost per Project. Wenn euer Ziel "Top-Findings mit wenig Noise" ist, reicht Cost per Run plus Compliance oft als Primärmetrik.

Für ein Team, das täglich Dutzende Agent-Runs fährt, ist das kein Rundungsfehler. Das ist ein struktureller Kostenvorteil.

Die Qualitätsfrage: Weniger ist nicht schlechter

"57% billiger klingt super, aber was verliert man?" -- die einzige Frage, die zählt.

Beide Modelle haben alle Agent-Instruktionen vollständig befolgt. Der Workflow war identisch:

1. Ziel in der Knowledge Base auflösen
2. Enrichment-Check durchführen
3. Websites via WebFetch recherchieren
4. Relevante Quellen via WebSearch finden
5. Strukturierte Daten über API-Calls persistieren
6. Evaluierungsbericht generieren
7. Dokumentationsseiten für manuelles Review öffnen

Kein einziger Run hat einen Schritt übersprungen. Kein einziger Run hat Instruktionen ignoriert. In allen 18 Runs haben wir keinen Step-Skip beobachtet; alle 7 Workflow-Schritte wurden ausgeführt.

Wo sich die Modelle unterscheiden (qualitative Beobachtungen aus 18 Runs)

Die zentrale Erkenntnis: Opus wirft ein breiteres Netz, Sonnet ist selektiver. Opus findet mehr, inklusive sekundärer und tangentialer Ergebnisse. Sonnet findet weniger, aber mit höherem Signal-to-Noise-Ratio.

Welcher Ansatz besser ist, hängt vom Use Case ab. Für explorative Recherche, wo man möglichst viele Ansatzpunkte will, hat Opus einen Vorteil. Für fokussierte Evaluierungen, wo Präzision wichtiger ist als Breite, ist Sonnet mindestens gleichwertig.

Für unseren Use Case -- Technologie-Evaluierungen für einen Technology Radar -- ist Sonnets Selektivität sogar ein Vorteil. Wir wollen die 5-7 relevantesten Findings, nicht 10 mit Noise dazwischen.

Das Kubernetes-Analogon: Right-Sizing für AI Agents

Wer mit Kubernetes arbeitet, kennt das Problem: Man setzt Resource Requests auf "großzügig", weil man sich keine Sorgen machen will. Jeder Pod bekommt 2 CPU Cores und 4GB RAM, obwohl die meisten mit 0,5 Cores und 512MB problemlos laufen. Dann schaut man auf die Cloud-Rechnung und wundert sich.

Model-Routing für AI Agents ist exakt dasselbe Pattern. Man hat ein großes Modell (Opus = der fette Pod) und ein effizientes Modell (Sonnet = der right-sized Pod). Die Frage ist nicht "Was ist das beste Modell?", sondern "Was ist das richtige Modell für diesen spezifischen Agent?"

Das ist kein neues Konzept. Die Forschung dazu ist solide:

• FrugalGPT (Stanford) hat gezeigt, dass intelligentes Model-Routing 50-98% Kostenreduktion bringen kann -- je nach Task
• Static Routing (was wir gemacht haben): Modelle werden zur Design-Zeit zugewiesen. Kein Overhead, kein Classifier, kein Routing-Layer. Eine Zeile YAML.
• Dynamic Routing: Ein Classifier entscheidet pro Query, welches Modell antwortet. Komplexer, aber adaptiver.
• Cascade: Startet billig, eskaliert bei niedriger Konfidenz. Smart, aber erfordert Konfidenz-Metriken.

Was wir gemacht haben, ist die einfachste Variante: Static Routing. Kein Machine-Learning-Classifier, kein Routing-Framework, keine zusätzliche Infrastruktur. Eine Entscheidung, einmal getroffen, in einer Zeile YAML kodiert. Das ist absichtlich langweilig -- und absichtlich effektiv.

Interessant: Anthropic selbst praktiziert das intern. Claude Codes eigener Explore-Agent läuft per Default auf Haiku -- dem kleinsten Modell in der Claude-Familie. Wenn Anthropic für seine eigenen Agents Modell-Tiering verwendet, sollte das ein starkes Signal sein.

Unsere Modell-Zuweisung: Das Ergebnis

Nach dem Benchmark haben wir alle 9 Agents in unserer Architektur explizit mit Modellen versehen:

Die Logik dahinter:

Sonnet für alles, was strukturiertes Reasoning braucht, aber keinen Novel-Reasoning-Breakthrough. Das deckt den Großteil agentic Work ab: Instruktionen befolgen, Tools koordiniert einsetzen, Daten sammeln und strukturieren, Berichte schreiben. Genau die Aufgaben, bei denen Sonnet 4.6 in Benchmarks mit Opus gleichzieht oder es schlägt.

Haiku für alles, was im Wesentlichen Transformation ist: Daten von A nach B schieben, ein Format in ein anderes konvertieren, ein Transcript extrahieren. Aufgaben, bei denen selbst das kleinste Modell zuverlässig ist, weil die kognitive Anforderung gering ist.

Opus bleibt verfügbar für den Orchestrator -- den Haupt-Claude-Code-Prozess, der die Agents startet und koordiniert. Dort, wo strategische Entscheidungen getroffen werden, wo der Kontext komplex ist und wo Novel Reasoning tatsächlich einen Unterschied macht.

Die DORA-Perspektive: AI Agent Performance messen

Ein Gedanke, der mich nicht loslässt: Wir messen Software-Delivery-Performance seit Jahren mit DORA Metrics. Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Recovery -- und in neueren DORA-Reports Reliability als fünfter Metric. Die Forschung zeigt, dass High-Performing Teams in allen Dimensionen besser sind, nicht nur in einer.

Warum messen wir AI Agent Performance nicht genauso systematisch?

Die Analogie ist fast 1:1:

Unser Benchmark hat im Grunde genau das gemacht: Throughput (Tokens, Duration), Fehlerverhalten (Outlier-Analyse) und Output-Qualität (Evaluierungstiefe, Compliance) systematisch verglichen. Die DORA-2025-Erkenntnis "AI amplifies team dysfunction as often as capability" passt hier perfekt: Ein schlecht konfiguriertes Multi-Agent-System wird durch ein besseres Modell nicht besser -- es wird teurer.

Meine Perspektive

Ich bin ehrlich: Ich hätte diesen Benchmark früher machen sollen. Wir haben wochenlang jeden Agent auf Opus laufen lassen, weil es der Default war und weil die Ergebnisse gut waren. "Gut" heißt aber nicht "optimal". Und "Default" heißt nicht "richtig konfiguriert".

Was mich überrascht hat: Nicht die Kostenersparnis (die war erwartet), sondern wie wenig Qualität wir verloren haben. Oder präziser: wie anders die Qualität ist. Sonnet produziert nicht "schlechtere" Ergebnisse, sondern "andere" -- selektiver, knapper, mit besserem Signal-to-Noise. Für die meisten unserer Use Cases ist das ein Upgrade, kein Downgrade.

Was mich nachdenklich macht: Immer mehr Teams setzen auf mehrere Modell-Familien parallel. Aber die wenigsten treffen bewusste Entscheidungen darüber, welches Modell welchen Task bekommt. Das ist, als würde man in Kubernetes jedem Pod die gleichen Resource Limits geben, weil man zu beschäftigt ist, die Actual Usage zu messen. Es funktioniert -- bis die Rechnung kommt.

Und noch etwas: Multi-Agent-Architekturen werden zum Standard in Enterprise-AI-Projekten. Und alle diese Deployments werden an diesen Punkt kommen. Die Frage ist nicht ob, sondern wann. Und die Teams, die früh anfangen zu messen und zu optimieren, werden einen strukturellen Vorteil haben -- nicht nur bei den Kosten, sondern auch bei der Qualität ihrer Outputs.

Der Markt bewegt sich schnell. Aber laut Branchenerhebungen operieren rund 50% der eingesetzten Agents in Silos, ohne koordiniertes Management. Model-Routing ist ein erster, simpler Schritt aus dem Silo heraus: Wenn man anfängt, bewusst über Modell-Zuweisung nachzudenken, fängt man automatisch an, über Agent-Architektur nachzudenken. Und das ist der eigentliche Gewinn.

Limitierungen

Das Ergebnis gilt primär für unseren Technology Researcher (Tool-heavy, Web-Recherche, Knowledge-Base-Writes) und unseren spezifischen Prompt- und Cache-Mix. Andere Agents -- etwa Output-heavy, mehr Planning, weniger Tool-Nutzung -- können andere Kosten- und Qualitätsprofile zeigen. Unsere Stichprobe (n=9 pro Gruppe) ist am unteren Ende statistischer Belastbarkeit; größere n würden Konfidenzintervalle verengen.

Was das für Engineering-Teams bedeutet

Drei konkrete Empfehlungen:

1. Messt, bevor ihr optimiert

Kein Benchmark, keine Entscheidung. Wir haben 18 vollständige Runs gebraucht, um belastbare Daten zu bekommen. Weniger als 10 Runs pro Variante sind statistisch nicht aussagekräftig genug, und auch unsere 9 pro Gruppe sind am unteren Ende. Trackt mindestens: Total Tokens, API Calls, Duration, und ein sinnvolles Quality-Metric für euren Use Case.

2. Startet mit Static Routing

Dynamic Routing und Cascade-Architekturen klingen sexy, aber sie fügen Komplexität hinzu, die in den meisten Fällen nicht nötig ist. Static Routing -- Modell pro Agent festlegen, basierend auf dem Anforderungsprofil -- ist die 80/20-Lösung. Zero Overhead, Zero Infrastruktur, eine Zeile Config.

Die Faustregel, die sich für uns bewährt hat:

• Haiku: Transformation, Extraction, simple Lookups
• Sonnet: Structured Reasoning, Tool Coordination, Report Generation
• Opus: Novel Reasoning, strategische Entscheidungen, komplexe Multi-Step-Planung

3. Reviewt quartalsmäßig

Modelle werden besser. Sonnet 4.6 ist nicht Sonnet 4.0. Was heute Opus braucht, könnte in sechs Monaten mit Sonnet laufen. Und was heute Sonnet braucht, läuft vielleicht bald auf Haiku. Ein quartalsmäßiger Review der Modell-Zuweisungen gehört in die Team-Routine, genau wie das Review der Kubernetes Resource Requests.

Der erste Schritt

Wenn ihr Claude Code mit Agents nutzt: Öffnet das Agent-File des Agents, der am meisten Tokens verbraucht. Fügt model: sonnet hinzu. Lauft 10 Runs. Vergleicht Tokens, Duration und Output-Qualität. Fertig.

Wenn die Qualität stimmt, habt ihr gerade eure Kosten halbiert. Wenn nicht, habt ihr wertvolle Daten darüber, wo genau Opus den Unterschied macht -- und könnt gezielt investieren statt pauschal.

Das ist das AI-Equivalent von Right-Sizing in Kubernetes: Nicht das größte Modell für jeden Task, sondern das richtige Modell für den richtigen Task. Eine Zeile YAML, ~57% weniger Kosten pro Agent-Run -- bei gleicher Workflow-Compliance und einem bewussten Tradeoff in der Recherchebreite.

Nicht schlecht für eine Zeile Config.

Ressourcen

Anthropic Modelle und Claude Code

• Claude Sonnet 4.6 Announcement (17. Februar 2026) -- Benchmark-Vergleiche Sonnet vs. Opus
• Claude Sonnet 4.6 System Card -- Detaillierte Benchmark-Daten, Sicherheits- und Leistungsbewertung
• Claude Opus 4.6 System Card (PDF) -- Opus-Benchmark-Daten und Sicherheitsbewertung
• Claude Model Overview -- Modellübersicht und Spezifikationen
• Claude Code Agents Dokumentation -- Agent-Frontmatter, model: Field
• Claude Code Sub-Agents -- Modell-Konfiguration, Default-Verhalten, Fallback
• Claude Code Security und Sandboxing -- Sandbox-Modus, Permission-System

Model Routing und Cost Optimization

• FrugalGPT: How to Use Large Language Models While Reducing Cost (Stanford, 2023) -- 50-98% Kostenreduktion durch Model Routing
• Anthropic API Pricing -- Token-Preise für Opus, Sonnet, Haiku
• Anthropic Pricing Docs -- Detaillierte Preisstruktur inkl. Cache-Formeln
• Prompt Caching -- Cache-Read/Write-Multiplikatoren und Laufzeiten

Multi-Agent-Architekturen und Performance

• DORA Report 2025 -- Erweiterte Metrics, Reliability als fünftes Maß

Infralovers Trainings

• AI Coding Essentials (IL-AICE) -- 2-Tages-Training zu AI-gestützter Softwareentwicklung mit Claude Code, GitHub Copilot und Co.
• AI Essentials for Engineers (IL-AIEE) -- 2-Tages-Training zu AI-Grundlagen für DevOps und Platform Engineers