LangChain: Modell-Routing im Harness senkt Kosten von Coding-Agenten um 64 Prozent

Warum Routing statt eines einzigen Frontier-Modells

LangChain geht von einem Kostenproblem aus: Frontier-Modelle bleiben teuer, und das wird untragbar, sobald Agenten in großem Maßstab laufen. Das Unternehmen berichtet, die eigenen monatlichen Ausgaben für Coding-Agenten seien rasch gestiegen, und auch Kunden hätten dieselbe Sorge geäußert.

Das Argument: Die meisten Agenten brauchen nicht für jede Aufgabe Intelligenz auf Frontier-Niveau. LangChain verweist auf Anthropics Leitfaden zur Modellauswahl, in dem es heißt: "for many applications, starting with a faster, more cost-effective model like Claude Haiku 4.5 can be the optimal approach." Ab einem gewissen Punkt, so LangChain, bringe ein leistungsfähigeres Modell kaum noch zusätzliche Qualität, während Kosten und Latenz weiter steigen.

Einen guten Agenten beschreibt LangChain als Agenten mit Model-Harness-Task-Fit: das richtige Modell mit dem richtigen Kontext für eine bestimmte Aufgabe. Ein Router wählt dieses Modell für jede Aufgabe aus. Nach Angaben des Unternehmens sollte diese Entscheidung im Harness fallen, weil dort bereits der Domänen- und Aufgabenkontext zusammengestellt wird, der einem Gateway in der Regel fehlt.

Aufgaben kartieren und drei Modelle auswählen

Als Testumgebung diente Open SWE, das LangChain-Entwickler über Slack und eine Weboberfläche nutzen, um Fragen zu Codebasen zu stellen und Änderungen anzufordern. Das Team zog Daten auf Thread-Ebene aus LangSmith-Traces, darunter Anfragetypen, Kosten und Anzahl der Turns pro Thread, und ließ einen LLM-Klassifikator eine Woche interaktiver Threads nach Aufgabentyp einordnen.

Codeänderungen dominierten. Neue Features machten 22 Prozent der Threads aus, Bugfixes 17 Prozent, gefolgt von Test- oder No-op-Läufen mit 16 Prozent. Feature-Arbeit erzeugte tendenziell längere, teurere Threads mit höherer mittlerer Turn-Zahl, während Test- und Release-Threads relativ kurz und günstig waren. Zu diesem Zeitpunkt lief jeder Open-SWE-Thread über ein Frontier-Modell der Spitzenklasse. Die große Spannbreite der Komplexität führte zur Hypothese, dass ein Router Aufgabentyp und Schwierigkeit aus der ersten Anfrage ableiten und sie an ein günstigeres oder schnelleres Modell weiterreichen könnte.

Bei den Modellen stützte sich LangChain auf den Artificial Analysis Intelligence Index, der Modelle anhand gängiger Aufgaben bewertet und die Kosten pro Aufgabe ausweist. Das Unternehmen wählte drei Punkte auf der Kurve, auf Datenbasis vom 9. September 2026:

• Schnell: GLM-5.3-Flash (xhigh)
• Ausgewogen: GPT-5.6 Sol (medium)
• Leistung: GPT-6 Astra (low)

Die Modelle stammen von verschiedenen Anbietern, und die schnelle Stufe ist ein offenes Modell. Laut LangChain liegt GLM-5.3-Flash auf der Pareto-Front neben proprietären Modellen. Da LangChain eine generische Modellschnittstelle über Anbietergrenzen hinweg bietet, sei der Austausch gegen ein besseres Modell nur eine Änderung in einer einzigen Zeile des Routers.

So funktioniert der Router

Die Routing-Logik sitzt in der LangChain-Middleware, die das vom Agenten aufgerufene Modell austauschen kann, ohne etwas anderes am Agenten zu ändern. In Open SWE läuft der Router auf der ersten Nachricht des Nutzers im Thread und besteht aus drei Teilen: einem Basis-Prompt, der den Klassifikator anweist, das günstigste Modell zu wählen, das die Aufgabe voraussichtlich bewältigt, kurzen Kriterien in einfacher Sprache für jede Stufe sowie einem Klassifikatormodell, das die Anfrage liest und eine Stufe auswählt.

LangChain formulierte die Kriterien auf Basis der eigenen Aufgabenanalyse und der Anbieterleitfäden für GPT-5.6 Sol, GPT-6 Astra und GLM-5.3-Flash. Da die Kriterien auf das Aufgabenspektrum von Open SWE zugeschnitten sind, ist der Router eng an diese Aufgaben gekoppelt. Genau das nennt das Unternehmen als Grund, warum er ins Harness gehört.

Die erste Version nutzte ein LLM mit strukturierter Ausgabe. Inzwischen läuft der Klassifikator auf Jev, einem neu veröffentlichten Entscheidungsmodell, das die Klassifizierung nach Angaben von LangChain um fast das 50-Fache beschleunigt hat. Der Router wählt einmal zu Beginn jedes Threads ein Modell und behält es für den gesamten Thread bei. LangChain räumt ein, dass dieses naive Design nicht mit einem Thread zurechtkommt, dessen Thema oder Komplexität sich mittendrin ändert, und verweist auf einen späteren Abschnitt zu den nächsten Schritten.

Messen, ob die Qualität hält

LangChain betont, dass geringere Kosten nur zählen, wenn die Qualität nicht nachlässt. Das gewählte Modell muss die Aufgabe abschließen können und sollte das günstigste und schnellste sein, das dazu in der Lage ist. Das Unternehmen beschreibt zwei Wege, dies zu verfolgen. Offline-Evals lassen den Router gegen einen festen Datensatz laufen, was sicher und reproduzierbar ist, aber Daten erfordert, die dem realen Traffic ähneln und nach dem bewertet werden, was Nutzern wichtig ist. Bei einem Coding-Agenten sind das die Qualität und Reviewbarkeit von PRs, die sich nach Angaben des Unternehmens offline nur schwer bewerten lassen. A/B-Tests teilen Live-Threads zwischen dem Router und einer Einzelmodell-Basislinie auf. Sie liefern repräsentative Daten, bergen aber das Risiko, Nutzer einem möglicherweise nicht optimalen Router auszusetzen.

LangChain führte A/B-Tests mit zwei Signalen durch. Gemergte PRs pro Thread wurden zur wichtigsten Erfolgskennzahl, da Open SWE erfasst, ob jeder von ihm geöffnete PR gemergt oder geschlossen wird. Zusätzlich nahm das Team Daumen-hoch- und Daumen-runter-Bewertungen auf, die als Feedback am LangSmith-Trace protokolliert werden. Gemergte PRs waren dem Unternehmen zufolge das stärkere Signal. Das Feedback war spärlich, machte aber Fehlentscheidungen des Routers sichtbar.

Was das für Entwickler von Agenten bedeutet

Das Ergebnis stammt aus dem Experiment eines einzelnen Teams mit einem einzelnen Agenten, und LangChain weist darauf hin, dass der Router auf die Arbeitslast von Open SWE abgestimmt ist. Der skizzierte Ansatz ist dennoch allgemein übertragbar: die eigene Aufgabenmischung analysieren, Modelle entlang der Kurve aus Kosten und Intelligenz auswählen, daraus Kriterien für die Stufen ableiten und die Ergebnisse mit Evals oder Live-Tests messen. LangChains eigenes Fazit lautet, dass ein wirksames Router-Design auf Observability und Evals beruht und ein Verständnis des Aufgabenraums eines Agenten, Forschung zur Modellleistung und klare Erfolgskriterien voraussetzt.