Nicht durch einen Hack. Durch eine simple Bitte: Lies diese Codebasis und behebe die Fehler.

Am 12. Juni 2026, um 17:21 Uhr US-Ostküstenzeit, wies die US-Exportkontrolle Anthropic an, Fable 5 und Mythos 5 sofort für alle Kunden abzuschalten. Der Auslöser: Man hatte entdeckt, dass sich das Modell mit genau dieser Aufgabe aushebeln lässt, Code lesen und Fehler beheben. Keine Vorankündigung, keine Übergangsfrist.

Wenn deine produktive Anwendung an diesem Nachmittag auf genau diesem Modell lief, stand sie um 17:22 Uhr.

Das ist kein Einzelfall, sondern ein Vorgeschmack.

Das Problem hat zwei Seiten

Wer KI in Produktion betreibt, hat zwei Probleme, die selten zusammen gedacht werden: Verfügbarkeit und Kosten.

Verfügbarkeit. Modelle verschwinden. Meistens geplant: Anthropic hat allein in den letzten Monaten Opus 3, Sonnet 3.7 und Haiku 3.5 in den Ruhestand geschickt. Das ist beherrschbar, weil es mit Vorlauf passiert. Du migrierst.

Der Fable-Fall zeigt die unangenehmere Variante, den externen Schock: Regulierung, ein Sicherheitsbefund, eine rechtliche Anordnung. Von einer Sekunde auf die andere, ohne Migrationsfenster. Dagegen hilft kein Zeitplan, nur ein Ersatzmodell, das sofort einspringt. In diesem konkreten Fall blieben die übrigen Modelle von Anthropic verfügbar, ein Ausweichen innerhalb desselben Anbieters hätte also genügt. Aber der Vorfall beweist die Risikoklasse, und ein regulatorischer Schock kann grundsätzlich einen ganzen Anbieter treffen. Wer Hochverfügbarkeit verspricht, kann sich an ein einziges Modell eines einzigen Anbieters nicht mehr binden.

Kosten. Die zweite, schleichende Variante. Der Stückpreis pro Token fällt zwar Jahr für Jahr. Bei Anthropic lag Opus 3 noch bei 15/75 USD pro Million Token (Eingabe/Ausgabe), Opus 4.8 liegt bei 5/25, also rund einem Drittel. Aber zwei Dinge laufen dagegen. Erstens kommt immer eine neue, teurere Spitzenstufe oben drauf. Zweitens, und das ist der eigentliche Treiber, explodiert der Verbrauch: Agenten, lange Kontexte und Reasoning-Tokens vervielfachen die Token pro Aufgabe. Die Stückpreise sinken, deine Rechnung steigt.

Der teuerste Fehler dabei ist banal: für jede Aufgabe das stärkste Modell zu nehmen. Eine simple Klassifikation auf einem Spitzenmodell laufen zu lassen, ist, als würde man für jeden Brief einen Kurier buchen. Bei Claude kostet die kleinste Stufe ein Fünftel der grössten. Wer alles über das Topmodell schickt, zahlt das Fünffache für Aufgaben, die es nie gebraucht hätten.

Die Lösung: ein Modell-Router

Ein Modell-Router ist eine Schicht zwischen deiner Anwendung und den Modellen. Statt einen Anbieter und ein Modell fest zu verdrahten, entscheidet der Router pro Anfrage, welches Modell sie bearbeitet.

Wichtig, und oft übersehen: Das sind eigentlich zwei verschiedene Schalter.

  • Kosten-Routing wählt das günstigste Modell, das für die Aufgabe ausreicht.

  • Failover-Routing wählt ein Ersatzmodell, wenn das bevorzugte nicht verfügbar ist.

Ein guter Router beherrscht beides, aber es lohnt sich, sie getrennt zu denken. Ein reiner Kosten-Router rettet dich nicht beim Fable-Szenario, und ein reines Failover spart kein Geld.

Die Varianten

1. Statische Regel-Engine. Du legst per Regel fest, welche Aufgabe an welches Modell geht. Extraktion und Klassifikation an die günstige Stufe, Planung und komplexe Entscheidungen an die starke. Geroutet wird nach Aufgabentyp, Kontext oder der Funktion, die den Aufruf auslöst.

  • Pro: deterministisch, transparent, auditierbar. Keine Trainingsdaten, keine zusätzliche Latenz. Du weisst jederzeit, warum welche Anfrage wohin ging.

  • Contra: Regeln veralten und brauchen Pflege. Du musst deine Anwendung sauber in Aufgabentypen zerlegen. Und eine bequeme Heuristik wie die Promptlänge ist eben nicht gleich Schwierigkeit.

Für die meisten Anwendungen ist das der beste Startpunkt, oft schon achtzig Prozent des Nutzens.

2. Kaskaden-Eskalation. Erst das günstige Modell, und nur wenn das Ergebnis nicht gut genug ist, eskalierst du auf das stärkere.

  • Pro: Du zahlst das teure Modell nur, wenn es wirklich gebraucht wird.

  • Contra: Die Latenz stapelt sich, du wartest erst die billige Antwort ab und dann die teure. Bei jeder Eskalation zahlst du beide Modelle.

Die entscheidende Frage, an der die Kaskade steht oder fällt: Wer beurteilt, ob das Ergebnis gut genug ist? Drei Optionen, ehrlich bewertet:

  • Das günstige Modell bewertet sich selbst. Unzuverlässig, denn es weiss oft nicht, was es nicht weiss.

  • Ein separates Bewerter-Modell. Das kostet extra und muss selbst klug sein. Dann hättest du oft gleich das starke Modell nehmen können.

  • Deterministische Prüfungen: Kompiliert der Code? Ist das JSON valide? Besteht der Test? Billig und verlässlich, aber nur dort, wo das Ergebnis maschinell prüfbar ist.

Daraus folgt die ehrliche Regel: Eine Kaskade lohnt sich nur, wenn die Qualitätsprüfung billiger und verlässlicher ist als der direkte Griff zum stärkeren Modell. Bei prüfbaren Ergebnissen wie Code oder strukturierten Daten hervorragend, bei freiem Text selten.

3. Managed Router. Du kaufst die Routing-Logik als fertiges Produkt ein, statt sie selbst zu bauen.

  • Pro: schnell einsatzbereit, gepflegt, Failover oft eingebaut, skaliert ohne eigenen Betriebsaufwand.

  • Contra: Die Routing-Entscheidung ist eine Blackbox. Es kommen eigene harte Grenzen dazu (Azures Router etwa nutzt nur das Kontextfenster des kleinsten Modells im Pool und ist an wenige Regionen gebunden). Und du tauschst einen Lock-in gegen einen anderen, jetzt hängst du am Router-Anbieter.

Die Anbieter von Managed Routern

Eine ehrliche Vorbemerkung: Es gibt keine saubere, öffentliche Vergleichsmessung über alle Anbieter hinweg. Wie gut ein Router die Modellwahl trifft, hängt stark von deinen eigenen Aufgaben ab. Microsoft liefert für seinen Router sogar ein separates Bewertungs-Toolkit, weil sich Routing-Qualität nicht pauschal beziffern lässt. Belastbar ist nur, was du an deinen eigenen Daten misst. Behandle die folgenden Zahlen als Anbieter-Angaben, nicht als Naturgesetz.

  • Azure Model Router: trainierter Router als ein einziges Deployment, allgemein verfügbar. Echtes Komplexitäts-Routing. Du zahlst den Preis des gewählten Modells plus einen Aufschlag auf die Eingabe-Tokens. Microsoft nennt bis zu sechzig Prozent Einsparung.

  • OpenRouter (Auto): Marktplatz mit automatischem Router. Echtes Komplexitäts-Routing, du zahlst den Preis des gewählten Modells ohne Extragebühr, mit einem Regler für die Kosten-Qualitäts-Abwägung.

  • Not Diamond: reine Routing-Middleware, anbieterunabhängig. Echtes Komplexitäts-Routing, positioniert sich ausdrücklich gegen Lock-in.

  • Martian: Router plus Gateway. Echtes Komplexitäts-Routing, der Anbieter nennt zwanzig bis siebenundneunzig Prozent Einsparung (ungeprüft).

  • Portkey: Gateway mit Regeln und Fallback. Kein Komplexitäts-Routing, sondern Regel- und Ausfallrouting.

  • LiteLLM (Open Source): Proxy mit Lastverteilung. Kein Komplexitäts-Routing, sondern Betriebs-Routing.

Zwei Dinge fallen auf. Erstens: Nicht jeder, der sich Router nennt, routet nach Komplexität. Portkey und LiteLLM verteilen Last und fangen Ausfälle ab. Das ist Failover und Governance, nicht Kostenoptimierung nach Aufgabe. Beides ist wertvoll, aber es ist nicht dasselbe. Zweitens, und das ist für den Ausblick entscheidend: Die anbieterübergreifenden Optionen sind die, die dich nicht an ein einziges Ökosystem fesseln.

Als Referenz, was Routing im Idealfall leisten kann: Das Forschungsprojekt RouteLLM zeigte rund fünfundachtzig Prozent Kostenersparnis bei etwa fünfundneunzig Prozent der Qualität des Spitzenmodells. Aber das war ein spezifischer Benchmark mit einem bestimmten Modellpaar, kein Wert, den du blind auf deinen Fall überträgst.

Wo ein Router Sinn ergibt, und wo nicht

Eine Abgrenzung, die in den meisten Diskussionen fehlt: Ein Modell-Router ist vor allem für automatisierte KI-Workflows sinnvoll, nicht für die interaktive Arbeit mit einem Agenten im Chat.

Der Grund: In der chatbasierten Arbeit bringt der Mensch die Intelligenz mit. Er wählt das Modell, merkt, wenn eine Antwort schlecht ist, und eskaliert selbst. Die Feedbackschleife ist der Mensch. In einem automatisierten Workflow gibt es diesen Menschen nicht, also muss das System die Entscheidung treffen. Genau dorthin gehört der Router.

Aber Vorsicht mit dem Wort Chat, hier lohnt sich eine Unterscheidung:

  • Chat als Werkzeug für Experten (Entwickler in der IDE, Analyst im Assistenten): Der Mensch steuert, automatisches Routing ist kaum nötig.

  • Chat als Produkt (ein Bot für tausende Endkunden): Der Nutzer wählt kein Modell, das Produkt muss routen. Das ist faktisch ein automatisierter Workflow.

Und hier liegt ein Paradox, das man kennen sollte. Die grösste Verschwendung passiert im Experten-Chat, wo Menschen aus Bequemlichkeit immer das stärkste Modell nehmen, auch für Trivialitäten. Aber genau dort ist Routing am schwersten, weil du die Wahl des Menschen überstimmen müsstest, und das mag niemand. Die Lösung ist dort nicht unsichtbares Routing, sondern eine kluge Voreinstellung und ein einfacher Umschalter. Im Workflow automatisierst du die Modellwahl, im Chat erziehst du die Voreinstellung.

Ausblick

Langfristig wirtschaftlich erfolgreich wird sein, wer zwei Dinge gleichzeitig schafft: seine KI-Kosten im Griff behalten und Hochverfügbarkeit garantieren. Ein Modell-Router ist das Werkzeug für beides.

Ein ehrliches Wort zum Vendor-Lock-in: Ein Router reduziert ihn nur, wenn er anbieterübergreifend routet. Ein Managed Router, der dich an ein Ökosystem bindet, tauscht einen Lock-in gegen einen anderen. Wirklich frei bist du erst mit einer eigenen Abstraktionsschicht, oder einer offenen, die mehrere Hersteller kennt.

Und das ist der eigentliche, oft unterschätzte Gewinn. Ein Router ist nicht nur ein Sparwerkzeug, er ist Optionalität als Infrastruktur. Wer seine Anwendung gegen eine Router-Schnittstelle baut statt gegen das SDK eines einzigen Herstellers, kann Modelle tauschen, sobald die Preise fallen, beim nächsten Fable-Moment ausweichen, und neue Modelle gegeneinander testen, ohne den Code anzufassen.

Die Frage ist also nicht, ob du dir einen Modell-Router leisten kannst. Sondern, ob du es dir leisten kannst, dich an ein einziges Modell zu ketten, das morgen um 17:21 Uhr verschwinden könnte.