Das richtige Modell erkennen Sie erst, nachdem Sie das falsche benutzt haben

Welches Modell soll diese Aufgabe übernehmen? Die Frage hat eine richtige Antwort. Sie kommt erst, wenn Sie sie nicht mehr brauchen.

Wie schwer eine Aufgabe war, erfahren Sie, indem Sie sie erledigen. Das kleine Modell nimmt die Anfrage an, das Ergebnis sieht vernünftig aus, und das Problem zeigt sich erst später, wenn weiter hinten in der Kette etwas kaputtgeht. Bis dahin haben Sie doppelt bezahlt: einmal, um die falsche Antwort zu erzeugen, und einmal, um herauszufinden, dass sie falsch war.

Ein Router wettet dagegen. Er liest den Prompt, schätzt, welches Modell damit zurechtkommt, und legt sich fest, bevor auch nur ein einziger Token existiert. Anbieter verkaufen das als Kostenoptimierung. Tatsächlich ist es eine Qualitätsentscheidung, blind getroffen und bepreist wie ein Rabatt.

Wie sehr das ins Gewicht fällt, hängt davon ab, wer die Ausgabe liest. In einem Chat-Produkt liest jemand jede Antwort und kann bei einer schlechten im nächsten Zug widersprechen. Routing-Fehler sind dort billig. Die Nutzer fangen sie ab, Zug um Zug, und merken es meistens nie.

Ein Agent-Lauf nimmt all das weg. Er läuft Minuten oder Stunden. Niemand liest die Zwischenschritte, und jeder Schritt speist den nächsten. Eine schlechte Wahl bei Schritt vier erzeugt keine offensichtlich falsche Antwort. Sie erzeugt eine plausible, und die nächsten neunzehn Schritte bauen darauf auf. Der Fehler selbst ist billig. Was darauf gestapelt wird, ist es nicht.

Zwei verschiedene Probleme. In beide werden dieselben Produkte verkauft.

Am deutlichsten hat sich das in aller Öffentlichkeit gezeigt. Als OpenAI im August 2025 GPT-5 vorstellte, kam ein Router mit, der pro Anfrage zwischen schnellen und Reasoning-Varianten wählte, und die Modellauswahl, mit der Nutzer bis dahin selbst entscheiden konnten, verschwand. Am Tag nach dem Launch räumte Sam Altman ein, dass der Autoswitcher ausgefallen und einen Großteil des Tages außer Betrieb gewesen war und das Modell deshalb deutlich schwächer gewirkt hatte.

Sehen Sie sich an, worüber sich die Nutzer beschwert haben. Nicht darüber, dass das Routing danebengegangen war. Sondern dass das Modell schlechter geworden war. Innerhalb eines einzelnen Gesprächs ist das dasselbe, und niemand konnte es auseinanderhalten.

Dass es überhaupt aufgefallen ist, lag daran, dass Millionen Menschen ein Jahr Erfahrung zum Vergleich hatten und den Abfall spüren konnten. Ihr Agent hat keine solche Vergleichsbasis. Er sieht nie, wie das andere Modell geantwortet hätte, er bekommt keinen Eindruck von einer schlechten Woche, und er meldet Erfolg so oder so im selben Ton.

Unmessbar ist das Problem deshalb nicht. Die Gegenprobe kann man kaufen. Schicken Sie eine Stichprobe des Traffics durch beide Kandidaten, bewerten Sie die Ergebnisse, und Sie bekommen eine Schätzung, was Sie das Routing an Qualität kostet. Der Haken ist, was das mit der Rechnung macht. Die beworbene Ersparnis wird zur Bruttozahl, und Evaluierung, Drift-Monitoring und die Folgekosten sich aufschaukelnder Fehler gehen alle davon ab.

Auch die Anbieter kaufen sie. Die Dokumentation von Not Diamond zum Training eines eigenen Routers verlangt Ihre Inputs, die Antwort jedes Kandidatenmodells auf jeden Input und Bewertungen für alle. Mindestens fünfzehn Beispiele, höchstens zehntausend pro Job. Das ist die Gegenprobe, im Voraus bezahlt, bevor es den Router überhaupt gibt. Das eigene Produkt der Anbieter lässt sich ohne sie nicht bauen. Der Ärger beginnt, wenn das Kaufen aufhört. Der Router wird gegen einen festen Schnappschuss kalibriert ausgeliefert und läuft dann ein Jahr lang gegen Traffic und einen Modellpool, die sich beide verändert haben.

Also veröffentlicht die Branche die Zahl, die sie gratis bekommt. Die Kosten stehen auf der Rechnung. AWS wirbt damit, dass Intelligent Prompt Routing die Kosten um bis zu dreißig Prozent senkt, ohne Abstriche bei der Genauigkeit. Diese Zahl nennt AWS über seinen eigenen Dienst, und für die zweite Hälfte der Aussage gibt es keine veröffentlichte Methode. Ihre Finanzabteilung prüft die Einsparungen. Die Abstriche prüft niemand.

Die gute Nachricht: Routing-Produkte unterscheiden sich weit weniger, als der Markt vermuten lässt. Nehmen Sie einem Dutzend davon das Branding ab, und Sie finden fünf Mechanismen in neuer Kombination. Jeder hat eine Einschränkung, die zum Mechanismus gehört, nicht zum Anbieter.

Der erste ist ein Score mit Schwellenwert. RouteLLM, die offene Referenzimplementierung, legt das offen auf den Tisch: Eine Methode nimmt einen Prompt und liefert eine vorhergesagte Gewinnrate für das starke Modell, und alles über Ihrem Schwellenwert geht an das starke Modell. Jeder gelernte Router macht eine Variante davon. Schon der Methodenname verrät die Einschränkung. Der Score sagt einen Vergleich vorher, der nie stattfindet. Wie sicher sich der Router ist und wie oft er richtigliegt, bleiben also zwei getrennte Zahlen, und Sie sehen immer nur eine.

Der zweite ist die Art, wie Sie den Schwellenwert setzen. RouteLLM kalibriert gegen den öffentlichen Chatbot-Arena-Datensatz, und was Sie angeben, ist der Anteil des Traffics, der an das starke Modell geht. Kein Qualitätsniveau. Ein Qualitätsniveau können Sie gar nicht verlangen. OpenRouters Auto Router liefert dieselbe Idee als Parameter namens cost_quality_tradeoff, eine ganze Zahl von null bis zehn, wobei null immer das stärkste und zehn immer das billigste Modell nimmt. Voreingestellt ist sieben. Sie sollen also eine Präferenz über etwas angeben, das niemand definiert hat, auf einer Skala ohne Einheit, und die Werkseinstellung neigt Richtung Kosten.

Der dritte ist die Einschränkung der Kandidatenmenge, und er erklärt, warum in diesem Feld so viel paarweise passiert. AWS Bedrock routet zwischen zwei Modellen derselben Familie. Not Diamonds Open-Source-Router arbeitet in Paaren. Ein Modell mit einem anderen zu vergleichen, ist handhabbar. Zwölf in eine Rangfolge zu bringen, ist es nicht. Also wird das Problem immer wieder in der Größe gelöst, in der es sich evaluieren lässt, und nicht in der Größe, in der es helfen würde. Kommerzielle Frameworks trainieren durchaus über größere Kandidatenmengen, es ist also eher ein Gefälle als eine Wand, aber das Gefälle geht nur in eine Richtung. Ihren Nutzen hat die Einschränkung anderswo: OpenRouter lässt Sie den Pool per Wildcard eingrenzen, und das ist echte Kontrolle darüber, wer Ihren Traffic überhaupt zu sehen bekommt. Für die Genauigkeit bringt es nichts.

Der vierte ist das Pinning. Ein Router pro Anfrage würde in jedem Zug ein anderes Modell wählen, also pinnt OpenRouter Modell und Provider für die Dauer eines Gesprächs: implizit, sobald der Provider Cache-Nutzung meldet, explizit ab der ersten erfolgreichen Antwort, wenn Sie eine Session-ID mitgeben. In einer Chat-Oberfläche ist das richtig und löst ein offensichtliches Problem. Setzen Sie es jetzt in einen Agenten. Das Modell, das vier Stunden laufen wird, wird anhand des ersten Austauschs gewählt, bevor ein Tool aufgerufen oder eine Datei gelesen wurde, bevor irgendetwas von der Arbeit passiert ist, die über die Schwierigkeit entscheidet. Minimale Information, maximale Festlegung. Der Pin läuft außerdem nach fünf Minuten Inaktivität ab. Ein Lauf, der an einer langsamen Abhängigkeit hängt, kann also auf einem anderen Modell weitermachen, ohne dass im Transkript irgendetwas davon zu sehen ist.

Der fünfte verzichtet ganz auf Vorhersage: Regeln über Dinge, die man beobachten kann. Keywords, deklarierter Aufgabentyp, Kontextlänge, ob Tools gebraucht werden. LiteLLM dokumentiert heuristisches und Keyword-Routing, das in unter einer Millisekunde entscheidet, wohlgemerkt die eigene Zahl über die eigene Software. Um Geschwindigkeit geht es aber nicht. Eine Regel, die Sie lesen können, lässt Sie den Zweig finden, der gegriffen hat, sobald Sie schon wissen, dass die Ausgabe schlecht war. Das ist Diagnose, und die ist etwas wert. Ob die Wahl richtig war, darüber schweigt eine Regel genauso wie ein neuronales Netz.

Wer die Mechanismen statt der Produkte betrachtet, sieht zwei Dinge sofort. Transparenz und Evaluierung sind verschiedene Features, und der Markt hat eines davon geliefert. OpenRouter gibt bei jeder Anfrage zurück, welches Modell sie bedient hat, also genau das, dessen Fehlen einen Flaggschiff-Launch zur Vertrauenskrise gemacht hat, und verlangt für die Routing-Entscheidung nichts. Ob die Wahl richtig war, kann es trotzdem nicht sagen. Die Antwort sagt Ihnen, was passiert ist. Ob das, was passiert ist, etwas getaugt hat, sagt sie nicht.

Ihre eigenen Logs haben dieselbe Grenze. Ein Gateway zeichnet Modell, Latenz, Tokens und Kosten auf. All das beschreibt Verhalten. Nichts davon beschreibt Qualität, und solange keine Ergebnisse der Aufgaben zurückfließen, bringt auch noch so viel Logging sie nicht hervor. Deshalb veröffentlichen mit Stand Juli 2026 jede Menge Anbieter Routing-Benchmarks und Kosten-Qualitäts-Kurven, aber keiner eine geprüfte Fehlerrate aus dem Produktions-Traffic eines Kunden. Normalerweise treibt der Wettbewerb Benchmarks ans Licht, weil ein Anbieter mit einer Zahl, die gewinnt, nicht aufhört, davon zu reden. Stattdessen bekommen wir von jedem Anbieter den eigenen Score auf dem eigenen Datensatz.

Die Zahl, die alle zitieren, bestätigt das. RouteLLM berichtet Kostensenkungen von über fünfundachtzig Prozent bei rund fünfundneunzig Prozent der Leistung des starken Modells, gemessen auf MT-Bench. Ein echtes Ergebnis, ohne Übertreibung berichtet, auf einem öffentlichen Benchmark mit Multi-Turn-Fragen, die ein anderes Modell bewertet. Es ist der beste öffentliche Beleg dafür, dass Routing funktioniert, und er stammt aus einer Verteilung, die niemandes Produktions-Traffic ähnelt. RouteLLM sagt das selbst: Der tatsächlich geroutete Anteil werde von der Kalibrierung abweichen, weil Ihre Anfragen anders aussehen als der Datensatz, und man solle mit Daten kalibrieren, die den eigenen ähneln. Diese Warnung ist das Argument dieses Textes, veröffentlicht von den Leuten, die die Referenzimplementierung geschrieben haben.

Was also tun Sie am Montag.

Fragen Sie, ob ein Mensch jede Ausgabe liest. Wenn ja, routen Sie ruhig drauflos. Ihre Fehlerbehandlung sitzt bei jedem Schritt dabei, die Mechanismen oben arbeiten für Sie, und eine Stichprobe gespiegelten Traffics sagt Ihnen, was Sie über die Gesamtqualität wissen müssen. Chat-Produkte haben die leichte Version dieses Problems und behandeln sie ständig wie die schwere.

Wenn niemand die Ausgabe liest, fragen Sie, wie groß der Qualitätsabstand zwischen Ihren Kandidaten wirklich ist. Routing zahlt sich im Verhältnis zu diesem Abstand aus, und im Mittelfeld ist er kleiner geworden. Liegen Ihre Kandidaten nah beieinander, ist die Ersparnis klein, der Evaluierungsaufwand aber nicht. Hören Sie hier auf. Wählen Sie ein Modell pro Workload-Klasse und lassen Sie die Maschinerie weg. Kein Anbieter in diesem Markt kann es sich leisten, Ihnen das zu raten, und es passt auf mehr Teams, als der Markt zugibt.

Wenn der Abstand groß ist und niemand liest, fragen Sie, ob sich der Erfolg von etwas anderem prüfen lässt als von dem Modell, das ihn produziert hat. Ein bestandener Test. Ein passendes Schema. Ein Retrieval, das das Dokument gefunden hat oder eben nicht. Wo es so eine Prüfung gibt, routen Sie die Teilaufgabe und eskalieren, wenn die Prüfung fehlschlägt. Damit haben Sie eine Vorhersage, die Sie korrigieren können. Wo es keine gibt, bleiben Sie beim starken Modell. Planung, irreversible Aktionen und alles, was weiterverwendet statt geprüft wird, gehören dem teuren Modell, egal was ein Router davon hält.

Loggen Sie bei jedem Aufruf das gewählte Modell, denn dieses Feld ist die einzige Aufzeichnung dessen, was der Router getan hat, und der einzige Weg, wie ein Wechsel mitten im Lauf je sichtbar wird. Schicken Sie ein bis zwei Prozent des Produktions-Traffics im Schattenbetrieb durch beide Kandidaten und bewerten Sie den Unterschied, mit einem Modell als erstem Durchgang und Menschen auf einer Stichprobe davon. Kalibrieren Sie anlassbezogen neu statt nach Kalender: wenn sich der Kandidatenpool ändert, wenn sich Ihr Traffic-Mix verschiebt, und ansonsten in dem Rhythmus, den Sie tatsächlich durchhalten.

Halten Sie Verfügbarkeits-Fallbacks aus all dem heraus. Geordnete Fallbacks über Provider hinweg, Retries mit Cooldowns, Circuit Breaker, Budgets, Allowlists, regionales Pinning. All das können Sie einsehen und mit Fault Injection testen, und es macht sich an dem Nachmittag bezahlt, an dem ein Provider anfängt, 503er zurückzugeben. Es sagt nichts vorher, und genau deshalb können Sie ihm vertrauen. OpenRouter liefert seine Fallbacks als eigenes Feature getrennt vom Router aus, und das ist richtig so. AWS gibt seinem Prompt Router etwas namens „fallback model“, was klingt wie das, was Sie auffängt, wenn ein Provider ausfällt. Tatsächlich ist es das Modell, das verwendet wird, wenn die vom Router vorhergesagte Qualitätsdifferenz unter Ihrem Schwellenwert liegt. Eine Qualitäts-Baseline mit dem Namen eines Resilienz-Features: Genau gegen diese Verwechslung sollten Sie Ihr Design absichern.

Routing zahlt sich im Verhältnis zum Qualitätsabstand aus, den es ausnutzt, und während das Mittelfeld zusammenrückt, schrumpft dieser Abstand und nimmt die Ersparnis mit. Gleichzeitig werden die Workloads, die die meisten Tokens verbrennen, länger, weniger beaufsichtigt und anfälliger für sich aufschaukelnde Fehler, und das multipliziert die Kosten einer einzigen schlechten Wahl mit der Zahl der Schritte, die danach kommen.

Aus dem Englischen übersetzt: zum Originalbeitrag