Das Protege-Pattern
Ein 7-Milliarden-Parameter-Modell löste 42,4 % der SWE-bench-Verified-Aufgaben. Der bisherige Rekord für kleine Modelle lag bei 17,0 %. Das Modell wurde nicht intelligenter. Das Modell lernte, wann es um Hilfe bitten sollte.1
Kon et al. trainierten ein Qwen2.5-Coder-7B-Instruct-Modell zur Zusammenarbeit mit einem Frontier-Modell als Experten. Der Experte beantwortete ungefähr vier Fragen pro Aufgabe und verbrauchte dabei 11 % der gesamten Token.1 Die verbleibenden 89 % der Token stammten vom kleinen Modell, das Routineoperationen ausführte: Dateien lesen, Tests ausführen, Patches anwenden. Die Kosten sanken von 0,54–1,24 $ pro Instanz (nur Experte) auf 0,13–0,15 $ (Protege mit Experte).1 Eine 8,2-fache Kostenreduktion bei einer 25-Punkte-Leistungssteigerung gegenüber dem bisherigen State of the Art kleiner Modelle.
Das Ergebnis bestätigt ein Pattern, auf das Praktiker unabhängig voneinander konvergiert sind: das Protege-Pattern.
TL;DR
Das Protege-Pattern teilt die Agentenarbeit zwischen einem kleinen, günstigen Modell (dem Protege), das die Routineausführung übernimmt, und einem Frontier-Modell (dem Experten), das Urteilsentscheidungen trifft. SWE-Protege zeigte eine Verbesserung um 25,4 Punkte und eine 8,2-fache Kostenreduktion.1 Anthropics eigenes Multi-Agenten-Forschungssystem nutzt dieselbe Stufenaufteilung: Claude Opus für den Leitagenten, Claude Sonnet für Subagenten.3 Das Pattern funktioniert, weil der Großteil der Agentenarbeit mechanisch ist. Diese mechanische Arbeit an ein Modell weiterzuleiten, das pro Token 5-mal günstiger ist, gewinnt 80 % des Kostenbudgets zurück, ohne die Qualität bei den Entscheidungen zu opfern, die wirklich zählen.
Das Expert-Protege-Framework
SWE-Protege definiert die Beziehung mit Präzision.1 Der Protege ist der alleinige Entscheidungsträger. Der Experte initiiert nie. Der Protege entscheidet, wann eskaliert wird, welche Frage gestellt wird und wie die Antwort eingebunden wird. Reinforcement Learning trainiert den Protege, zwei konkurrierende Ziele zu optimieren: die Aufgabe lösen UND den Experteneinsatz minimieren.
Die RL-Belohnungsstruktur bestraft drei Fehlermodi:
Degeneratives Schleifen. Der Protege stellt dieselbe Frage wiederholt. Die Bestrafung unterbindet erlernte Hilflosigkeit.
Unproduktive Zusammenarbeit. Der Protege stellt eine Frage, ignoriert die Antwort und fährt mit seinem ursprünglichen Plan fort. Die Bestrafung unterbindet performative Eskalation.
Übermäßige Abhängigkeit. Der Protege leitet jede Entscheidung an den Experten weiter. Die Bestrafung unterbindet, dass der Protege zu einer reinen Durchreicheschicht wird.
Das Ergebnis ist ein Protege, der echtes Urteilsvermögen über seine eigenen Grenzen entwickelt. Das 7B-Modell lernte, zwischen Aufgaben zu unterscheiden, die es allein bewältigen konnte (Dateien lesen, Tests ausführen, einfache Patches) und Aufgaben, die Expertenintervention erfordern (Architekturentscheidungen, mehrdeutige Anforderungen, Abhängigkeitsanalysen über mehrere Dateien).1
Warum Routing funktioniert
Die akademische Grundlage für Modell-Routing geht SWE-Protege voraus. RouteLLM zeigte, dass Routing zwischen einem starken und einem schwachen Modell bis zu 3,66-fache Kosteneinsparungen erzielt und dabei 95 % der Qualität des starken Modells beibehält.11 Der Router lernt, welche Anfragen Frontier-Fähigkeiten erfordern und welche ein kleineres Modell gleich gut bewältigt.
IBM Research fand ähnliche Ergebnisse mit einer „sparsamen” Routing-Methode: kleinere, spezialisierte Modelle werden sequenziell aufgerufen, bis eines eine zuversichtliche Antwort liefert.14 Der Ansatz erzielt bis zu 85 % Kostenreduktion bei einfachen Anfragen.
Die zugrundeliegende Erkenntnis ist verteilungsbezogen. Die meisten Agentenoperationen sind nicht schwer. Eine Datei lesen, einen grep ausführen, einen klar definierten Patch anwenden, eine Testsuite ausführen: Diese Operationen erfordern korrekte Ausführung, kein tiefes Reasoning. Ein Modell, das pro Token 5-mal günstiger ist, bewältigt sie identisch zu einem Frontier-Modell.7 Die schweren Operationen (einen subtilen Bug diagnostizieren, zwischen Architekturansätzen wählen, bewerten ob eine Lösung korrekt ist) profitieren von Frontier-Reasoning. Das Protege-Pattern leitet jede Operation an die passende Stufe weiter.
Anthropics eigene Dokumentation macht die Stufenaufteilung explizit. Der Leitfaden „Choosing the Right Model” empfiehlt Haiku für „Sub-Agent-Aufgaben” und Opus für „professionelles Software Engineering” und „fortgeschrittene Agenten”.8 Die Empfehlung ist kein Marketing. Die Empfehlung spiegelt gemessene Leistungsunterschiede über Aufgabenkomplexitätsverteilungen wider.
Produktions-Implementierungen
Drei Produktionssysteme demonstrieren das Protege-Pattern im großen Maßstab.
Anthropics Multi-Agenten-Forschungssystem. Claude Opus führt, Claude Sonnet arbeitet als Subagenten.3 Das System übertraf einzelnen Claude Opus um 90,2 % bei der internen Evaluation. Die Verbesserung kam nicht von einem besseren Modell, sondern von besserer Aufgabenzerlegung. Sonnet-Subagenten verbrauchten den Großteil der Token für Rechercheoperationen, während Opus das Reasoning-Budget auf Synthese und Urteilsvermögen konzentrierte.
Carlinis C-Compiler. Sechzehn parallele Claude-Agenten erzeugten einen 100.000-Zeilen-C-Compiler in Rust, der ein bootfähiges Linux 6.9 erstellt.4 Kosten: 20.000 $ über ca. 2.000 Sitzungen. Obwohl alle Agenten auf derselben Stufe liefen, offenbarte das Projekt die selbstorganisierende Eigenschaft, die das Protege-Pattern formalisiert: Agenten gravitierten natürlich zum „nächstliegenden offensichtlichen Problem”.4 Kein zentraler Orchestrator verteilte Aufgaben.
Chris Lattner überprüfte den Compiler und identifizierte die Grenze zwischen dem, was KI-Agenten gut bewältigen, und wo menschliches Urteilsvermögen weiterhin essenziell bleibt: „Niedrigere Hürden bei der Implementierung verringern nicht die Bedeutung von Ingenieuren; stattdessen erhöhen sie die Bedeutung von Vision, Urteilsvermögen und Geschmack.”56 Die Agenten zeichneten sich beim Zusammenfügen bekannter Techniken aus. Die Agenten scheiterten an der „offenen Generalisierung, die für produktionstaugliche Systeme erforderlich ist”.5
Modell-Routing in der Praxis. Die Studie „What Claude Code Chooses” analysierte 2.430 Tool-Auswahlen über drei Claude-Modelle.9 Opus 4.6 zeigte zukunftsorientierte Präferenzen (Drizzle 100 % vs. Prisma 0 %), während Sonnet 4.5 konventionellere Entscheidungen traf.9 Die Divergenz löste eine intensive Community-Diskussion aus.10 Verschiedene Stufen bringen unterschiedliche Verzerrungen bei mehrdeutigen Entscheidungen mit. Ein Protege, der routinemäßige Tool-Auswahlen trifft, benötigt kein Frontier-Reasoning. Ein Protege, der auf eine mehrdeutige Architekturentscheidung stößt, profitiert von Eskalation.
Kostenarithmetik
Die Wirtschaftlichkeit macht das Pattern überzeugend, noch bevor Leistungsgewinne berücksichtigt werden.
Bei aktuellen Anthropic-Preisen beträgt der Stufenabstand genau 5x:7
| Modell | Input | Output | Rolle |
|---|---|---|---|
| Opus 4.6 | 5 $/MTok | 25 $/MTok | Experte |
| Haiku 4.5 | 1 $/MTok | 5 $/MTok | Protege |
Eine typische Agentensitzung verbraucht 50.000–200.000 Token in jede Richtung. Bei Annahme von 100K Input- und 100K Output-Token zum reinen Opus-Preis kostet eine Sitzung 0,50 $ Input + 2,50 $ Output = 3,00 $. Wenn der Protege 80 % der Token übernimmt und der Experte 20 %, kostet dieselbe Sitzung:
- Protege (80K Token): 0,08 $ Input + 0,40 $ Output = 0,48 $
- Experte (20K Token): 0,10 $ Input + 0,50 $ Output = 0,60 $
- Gesamt: 1,08 $ (64 % Einsparung)
SWE-Protege erzielte sogar aggressivere Einsparungen, da der Experte nur 11 % der Token verbrauchte, nicht 20 %.1 Über 100 Agentensitzungen pro Tag hinweg summiert sich der Unterschied: 300 $/Tag bei reinem Experteneinsatz gegenüber 108 $/Tag mit Protege-Routing. Über einen Monat: 9.000 $ gegenüber 3.240 $.
Die SWE-bench-Rangliste liefert den Leistungskontext.12 Claude 4.5 Opus bei hohem Reasoning erreicht eine Lösungsrate von 76,8 % bei 0,754 $ pro Instanz. Ein Protege-gerouteter Ansatz bei 42,4 % Lösungsrate kostet 0,13–0,15 $ pro Instanz.1 Für Aufgaben innerhalb der Fähigkeiten des Protege sprechen die Kosten pro gelöster Aufgabe für Routing. Für Aufgaben, die Frontier-Reasoning erfordern, steht der Experte auf Abruf bereit.
Das Kollaborativitäts-Phänomen
Wang et al. entdeckten eine Eigenschaft, die erklärt, warum das Protege-Pattern bessere Ergebnisse liefert als jedes Modell allein.13 Das „Mixture-of-Agents”-Paper fand heraus, dass Modelle bessere Antworten generieren, wenn ihnen Outputs anderer Modelle präsentiert werden, selbst wenn diese anderen Modelle weniger leistungsfähig sind.13
Die Erkenntnis kehrt die erwartete Hierarchie um. Ein Frontier-Modell, das die initiale Analyse und Dateisichtung eines kleinen Modells liest, produziert bessere Ergebnisse als das Frontier-Modell, das bei null beginnt. Die Arbeit des kleinen Modells ist nicht nur günstige, vom Experten ausgelagerte Arbeitskraft. Die Arbeit des kleinen Modells liefert strukturierten Kontext, der das Reasoning des Experten verbessert.
Anthropics Multi-Agenten-Forschung bestätigte das Pattern: Das Upgrade der Subagenten von Sonnet 3.7 auf Sonnet 4 brachte „einen größeren Leistungsgewinn als die Verdoppelung des Token-Budgets bei Claude Sonnet 3.7”.3 Modellqualität auf der Protege-Stufe ist wichtig. Ein besserer Protege macht einen besseren Experten.
Was Sie damit bauen können
Drei Eskalationsmuster entsprechen progressiv autonomeren Implementierungen.
Pattern 1: Konfidenzbasiertes Routing. Die einfachste Implementierung. Der Protege generiert eine Antwort und einen Konfidenzwert. Unter einem Schwellenwert wird die Anfrage an den Experten weitergeleitet. RouteLLM bietet ein Open-Source-Framework für das Training des Routers.11 Beginnen Sie hier.
Pattern 2: Aufgabentyp-Routing. Operationen nach Typ klassifizieren und deterministisch weiterleiten. Dateien lesen, Tests ausführen und Formatierung an Haiku. Code-Review, Architekturentscheidungen und mehrdeutige Anforderungen an Opus. Anthropics Leitfaden „Building Effective Agents” nennt dies das Routing-Pattern: „Inputs klassifizieren und einfache/häufige Fragen an kleinere, kosteneffiziente Modelle weiterleiten.”2
Pattern 3: Erlernte Eskalation. Der SWE-Protege-Ansatz. Den Protege trainieren, seine eigenen Eskalationspunkte durch Reinforcement Learning zu bestimmen.1 Der Protege entwickelt echtes Urteilsvermögen über seine Grenzen. Das anspruchsvollste und leistungsstärkste Pattern, erfordert aber RL-Infrastruktur und expertengelabelte Trainingsdaten.
Jedes Pattern tauscht Implementierungskomplexität gegen Kosteneinsparungen und Autonomie. Pattern 1 erfordert einen Datensatz zur Konfidenzkalibrierung. Pattern 2 erfordert eine Aufgabentaxonomie. Pattern 3 erfordert RL-Trainingsdurchläufe. Alle drei übertreffen den Einsatz auf einer einzelnen Stufe bei kostenbereinigter Leistung.
Wichtige Erkenntnisse
- Das Protege-Pattern ist kein Load-Balancing. Der Protege trifft Entscheidungen über seine eigenen Grenzen. Der Experte liefert Urteilsvermögen, keinen Durchsatz.
- Der Großteil der Agentenarbeit ist mechanisch. Diese Arbeit an ein 5-mal günstigeres Modell weiterzuleiten, gewinnt das Kostenbudget für die Entscheidungen zurück, die Frontier-Reasoning erfordern.
- Bessere Proteges machen bessere Experten. Das Kollaborativitäts-Phänomen bedeutet, dass Outputs kleiner Modelle das Reasoning von Frontier-Modellen verbessern.13
- Lattners Beobachtung gilt für das Pattern selbst: „Da das Schreiben von Code einfacher wird, wird das Entwerfen von Software wichtiger denn je.”5 Der Protege übernimmt das einfachere Schreiben. Der Experte übernimmt das schwierigere Entwerfen.
Teil der Serie AI Engineering. Siehe auch: Context Is the New Memory, Claude Code as Infrastructure und The 10% Wall.
-
Kon, P.T.J., Pradeep, A., Chen, A., Ellis, A.P., Hunt, W., Wang, Z., Yang, J., & Thompson, S. “SWE-Protege: Learning to Selectively Collaborate With an Expert Unlocks Small Language Models as Software Engineering Agents.” arXiv:2602.22124. 42.4% Pass@1 on SWE-bench Verified, 8.2x cost reduction, expert consulted ~4 times per task. ↩↩↩↩↩↩↩↩↩
-
Schluntz, E. & Zhang, B. “Building Effective Agents.” Anthropic Research Blog. Routing pattern: easy questions to Haiku, hard questions to Sonnet/Opus. ↩
-
Hadfield, J. et al. “How We Built Our Multi-Agent Research System.” Anthropic Engineering Blog. Opus lead + Sonnet subagents, 90.2% improvement over single-agent Opus. ↩↩↩
-
Carlini, N. “Building a C Compiler with a Team of Parallel Claudes.” Anthropic Engineering Blog. 16 agents, $20K, 100K lines, bootable Linux. ↩↩
-
Lattner, C. “The Claude C Compiler: What It Reveals About the Future of Software.” Modular Blog. “Lower barriers to implementation elevate the importance of vision, judgment, and taste.” ↩↩↩
-
Willison, S. “The Claude C Compiler.” Simon Willison’s Weblog. Commentary synthesizing Carlini and Lattner perspectives. ↩
-
Anthropic Model Pricing. Pricing page. Opus 4.6: $5/$25 MTok. Haiku 4.5: $1/$5 MTok. 5x tier spread. ↩↩
-
Anthropic. “Choosing the Right Model.” API Documentation. Haiku for “sub-agent tasks,” Opus for “professional software engineering.” ↩
-
Ong, E. & Vikati, A. “What Claude Code Actually Chooses.” Amplifying Research. 2,430 tool picks, Opus shows forward-looking preferences. ↩↩
-
Hacker News. “What Claude Code Chooses.” Discussion. 573 points, 213 comments. ↩
-
Ong, I. et al. “RouteLLM: Learning to Route LLMs with Preference Data.” ICLR 2025. arXiv:2406.18665. 3.66x cost savings, 95% quality retention. ↩↩
-
SWE-bench. “SWE-bench Leaderboards.” swebench.com. Claude 4.5 Opus: 76.8% at $0.754/instance. ↩
-
Wang, J. et al. “Mixture-of-Agents Enhances Large Language Model Capabilities.” ICLR 2025 Spotlight. arXiv:2406.04692. Weaker models improve stronger models through structured collaboration. ↩↩↩
-
IBM Research. “LLM Routing for Quality, Low-Cost Responses.” IBM Research Blog. Up to 85% cost reduction with frugal routing. ↩