KI-Modell-Routing einrichten: Anbieter in 1 Zeile tauschen

Zentrales KI-Modell-Routing heißt: Die Model-ID lebt an genau einer Stelle in deinem Code, und für jeden Aufgabentyp entscheidet eine Tabelle, welches Modell antwortet. So tauschst du Modell oder Anbieter in einer Zeile, statt halbe Tage durch Code zu suchen.

Eine Routing-Schicht trennt deine Anwendung von der konkreten Model-ID und dem Anbieter. Foto: SHOX ART auf Pexels

Was bedeutet zentrales KI-Modell-Routing und warum brauchst du es?

Zentrales KI-Modell-Routing bedeutet, dass die Model-ID an genau einer Stelle in deinem System steht und alle Anfragen über diese Stelle laufen. Statt überall im Code claude-sonnet-5 hart einzutragen, fragst du eine zentrale Funktion: Welches Modell ist für diesen Aufgabentyp zuständig? Diese eine Funktion kennt die Antwort, dein restlicher Code nicht.

Der Grund ist handfest. Wenn Model-IDs über Dutzende Dateien verstreut sind, wird jeder Wechsel zur Suchaktion mit Fehlerrisiko. Am 12. Juni 2026 hat die US-Regierung Anthropic per Exportkontroll-Anordnung gezwungen, Fable 5 und Mythos 5 abzuschalten; Opus 4.8, Sonnet 4.6 (heute Sonnet 5) und Haiku 4.5 liefen weiter. Seit dem 1. Juli 2026 ist Fable 5 wieder weltweit freigegeben; die Mythos-Reihe läuft weiterhin nur auf Einladung im Rahmen von Anthropics Project Glasswing. Wer Fable 5 fest verdrahtet hatte, stand während der dreiwöchigen Sperre still. Wer eine Routing-Tabelle hatte, hat eine Zeile geändert. Mehr dazu im Hub-Artikel Claude im Unternehmenseinsatz und in Fable 5 ist zurück, Mythos 5 bleibt gesperrt.

Wie sieht die Mini-Architektur für zentrales Modell-Routing aus?

Die Architektur besteht aus drei Teilen: einer Routing-Tabelle, die Aufgabentypen auf Model-IDs abbildet, einer Abstraktionsschicht, die diese Tabelle liest und den Anbieter anspricht, und deinem Anwendungscode, der nur noch den Aufgabentyp nennt. Dein Code sagt also “fasse zusammen”, nicht “nutze claude-sonnet-5 über Anthropic”.

Wichtig ist, dass die Routing-Tabelle in einer Config-Datei oder in Umgebungsvariablen liegt, nicht im Quellcode. So änderst du das Mapping ohne Deploy. Eine anbieterneutrale Config kann minimal aussehen:

routing:
  routine:   { model: "claude-haiku-4-5",  provider: "anthropic" }
  standard:  { model: "claude-sonnet-5",  provider: "anthropic" }
  schwer:    { model: "claude-opus-5",      provider: "anthropic" }
  spitzenlast: { model: "claude-fable-5-1", provider: "anthropic" }
fallback:
  schwer:    { model: "claude-opus-5",      provider: "bedrock" }
kill_switch: false

Die Abstraktionsschicht liest diesen Block, wählt anhand des Aufgabentyps das Modell und kümmert sich um die anbieterspezifischen Details. Bei Amazon Bedrock heißt Opus zum Beispiel anthropic.claude-opus-5 statt claude-opus-5. Genau solche Unterschiede gehören in den Adapter und nirgendwo sonst hin. Der Eintrag spitzenlast lief während der dreiwöchigen Fable-5-Sperre im Juni ins Leere; genau für solche Fälle steht der fallback-Block bereit, der schwere Last bei Bedarf auf Opus über Bedrock zieht. Seit dem 1. Juli ist Fable 5 zwar wieder weltweit freigegeben, seit dem Opus-5-Start am 24. Juli braucht den Eintrag aber kaum noch jemand: Opus 5 deckt die schweren Fälle zum halben Fable-Preis ab. Wer spitzenlast behält, sollte ihn als Sonderfall führen, auf die aktuelle Stufe claude-fable-5-1 zeigen lassen und regelmäßig gegen Opus 5 gegentesten.

Welches Claude-Modell passt zu welchem Aufgabentyp?

Die Regel lautet: kleinstes Modell, das die Aufgabe sauber löst. Routine-Last verschwendet auf einem Spitzenmodell nur Geld, und schwere Analyse auf einem kleinen Modell kostet dich Qualität. Die folgende Tabelle ordnet jeden Aufgabentyp einem Claude-Modell zu, mit Listenpreis, Cache-Treffer-Preis und Begründung. Alle Beträge gelten je 1 Million Token, Stand 4. September 2026.

Die Zahlen hinter dem Wechsel an der Spitze haben wir in Claude Opus 5 gegen Fable 5 durchgerechnet; den älteren Stand mit Opus 4.8 findest du in Claude Fable 5 gegen Opus 4.8 im Detail. Für die meisten Betriebe tragen Haiku und Sonnet den Großteil der Last, Opus 5 kommt punktuell dazu, Fable bleibt die Ausnahme. Was der dauerhafte Sonnet-Preis für deine Kalkulation bedeutet, steht in Claude Sonnet 5 im Unternehmenseinsatz.

Was ändert sich fürs Routing mit Claude Fable 5.1?

Am 1. September 2026 hat Anthropic Claude Fable 5.1 veröffentlicht, Model-ID claude-fable-5-1, zum unveränderten Grundpreis von 10 USD Input und 50 USD Output je 1 Million Token. Bewegt hat sich der Preis für Cache-Treffer: 0,25 statt 1,00 USD je 1 Million Token. Anthropic rechnet auf dieser Stufe mit dem Faktor 0,025 auf den Eingabepreis, während alle anderen Claude-Modelle bei 0,1 bleiben. Für eine Agenten-Schleife, die denselben 120.000-Token-Kontext zwanzigmal am Tag neu liest, sind das über einen Monat 18 statt 72 USD allein für den Cache-Posten. Wie sich das in eine vollständige Kostenrechnung einfügt, steht in Claude-API-Kosten kalkulieren.

Für eine Routing-Schicht wiegen drei Verhaltensänderungen schwerer, die Anthropic selbst als Breaking Changes führt. Sie treffen genau das Muster, das dieser Artikel beschreibt, und die Dokumentation nennt den Router ausdrücklich als Beispiel.

Ein Denkblock gehört dem Modell, das ihn erzeugt hat. Lesbar ist er nur für dieses Modell oder ein neueres. Fable 5.1 liest die Denkblöcke aller älteren Claude-Stufen, umgekehrt liest keine ältere Stufe die von Fable 5.1. Für dein Routing heißt das: Ein Wechsel nach oben nimmt die bisherige Argumentationskette mit, ein Wechsel nach unten mitten im Gespräch verwirft sie, und das ausweichende Modell rollt den Fall aus den sichtbaren Nachrichten neu auf. Die API entfernt die unlesbaren Blöcke, bevor die Anfrage das Modell erreicht; sie kosten nichts und tauchen in input_tokens nicht auf. Ohne den Beta-Header thinking-binding-controls-2026-08-01 passiert das stillschweigend, mit ihm meldet die Antwort den Vorgang im Feld input_transformations als model_binding_mismatch. Wer nach einem Fallback einen Qualitätseinbruch sucht, findet ohne diesen Header keinen Hinweis im Log.

Die zweite Bindung geht auf den Gesprächsverlauf. Sie gilt nur für Fable 5.1, Mythos 5.1 führt die Prüfung nicht aus. Die Signatur eines Denkblocks deckt den System-Prompt, das tools-Array und alle vorangehenden Nachrichten ab. Änderst du davon etwas zwischen zwei Anfragen, weist die API die nächste Anfrage mit einem 400er ab, dessen Meldung lautet: The block is bound to a different conversation. Das ist für Routing-Schichten der unangenehmste Punkt, weil viele genau so gebaut sind: Der System-Prompt wird je Aufgabentyp neu zusammengesetzt, das Werkzeug-Array je Schritt neu befüllt, alte Nachrichten werden gekürzt, sobald der Kontext eng wird. Anthropic erzwingt die Prüfung seit dem 31. August 2026 für neu angelegte Konten. Ältere Konten laufen vorerst ohne Zwang, sollen aber mit künftigen Modellen nachziehen, weshalb sich das Aufräumen jetzt lohnt.

Erzwungene Werkzeugnutzung fällt weg. tool_choice mit dem Typ any oder tool beantwortet Fable 5.1 mit einem 400er, auto und none bleiben unverändert. Wenn dein Adapter für bestimmte Aufgabentypen ein Werkzeug erzwingt, um verlässliches JSON zu bekommen, brauchst du auf dieser Stufe Strict Tool Use oder Structured Outputs. Anthropic begründet das damit, dass ein erzwungener Werkzeugaufruf das immer aktive Nachdenken überspringen würde und die Argumente dadurch schlechter werden.

Daraus folgen drei Regeln für deine Routing-Tabelle. Halte den Verlauf anfügend, also neue Nachrichten hinten dran und ältere Turns unverändert. Instruktionen, die nur für einen Schritt gelten, gehören in eine Mid-Conversation-System-Message statt in einen neu gebauten System-Prompt. Und wenn Kontext gekürzt werden muss, nimm die serverseitige Verdichtung, denn die zählt für die Prüfung nicht als Änderung. Für den Notfall bleibt der Beta-Header mit prefix_mismatch_behavior: “drop_block”, der den strittigen Block verwirft, statt die ganze Anfrage abzuweisen.

Welchen Nutzen bringt dir zentrales Routing konkret?

Der greifbarste Nutzen ist Geld. Wenn du Routine-Aufgaben von einem teuren Modell auf Claude Haiku 4.5 verschiebst, fällt der Preis pro Token vom Niveau eines Spitzenmodells auf einen Bruchteil. Bei hohem Volumen ist das der größte Hebel deiner gesamten KI-Rechnung, noch vor jeder Prompt-Optimierung.

Dazu kommen zwei weitere Kostenhebel, die das Routing erst praktisch machen. Prompt-Caching legt wiederkehrende Prompt-Teile ab; ein Cache-Treffer kostet bei den meisten Claude-Modellen 10 Prozent des normalen Input-Preises, bei Fable 5.1 seit dem 1. September nur 2,5 Prozent. Der Schreibvorgang schlägt mit dem 1,25-fachen bei fünf Minuten Haltezeit und dem Doppelten bei einer Stunde zu Buche, das Caching trägt sich also nach einem beziehungsweise zwei Treffern. Die Batch-API gibt dir 50 Prozent Rabatt auf nicht zeitkritische Last. Beides steuerst du sauber, wenn der Aufgabentyp ohnehin schon zentral bekannt ist.

Ein Detail rechnen viele Routing-Tabellen falsch: Die Modelle zählen Token unterschiedlich. Mit Claude Opus 4.7 hat Anthropic einen neuen Tokenizer eingeführt, den seither jede neue Stufe nutzt, also auch Sonnet 5, Opus 5 und Fable 5.1. Derselbe Text ergibt dort rund 30 Prozent mehr Token als auf älteren Modellen, und Claude Haiku 4.5 rechnet noch mit dem alten. Im Preisblatt stehen zwischen Haiku und Sonnet 5 die Zahlen 1 und 2 USD, also Faktor zwei. Weil auf der Sonnet-Seite für denselben Text rund 30 Prozent mehr Token anfallen, liegt der reale Abstand näher an 2,6. Für die Frage, ob sich das Verschieben einer Routine-Last überhaupt lohnt, verschiebt das die Rechnung spürbar.

Seit Opus 5 kommt eine dritte Stellschraube dazu: die Effort-Stufe. Du regelst pro Anfrage in fünf Stufen von Low bis Max, wie viel Rechenzeit das Modell in die Antwort steckt. Fürs Routing heißt das, deine Tabelle bildet nicht mehr nur Aufgabentyp auf Modell ab, sondern Aufgabentyp auf Modell plus Stufe. Eine simple Extraktion läuft auf niedriger Stufe, eine schwierige Analyse auf hoher. Das ist der Hebel, mit dem du ein starkes Modell bezahlbar hältst, statt für jede Kleinigkeit auf ein schwächeres auszuweichen.

Routing ist kein Architektur-Luxus. Es ist die Stelle, an der du Kosten und Ausfallsicherheit zugleich steuerst.

Genauso wichtig ist die Beweglichkeit. Ein neues Modell erscheint, ein Preis ändert sich, ein Anbieter fällt aus: In allen Fällen änderst du die Routing-Tabelle, nicht den Code. Genau diese Beweglichkeit war am 12. Juni 2026 der Unterschied zwischen Stillstand und Weiterlaufen.

Welche Stolpersteine gibt es beim Modell-Routing und wie umgehst du sie?

Der häufigste Fehler ist, Model-IDs doch wieder im Code zu verstreuen, weil es im Moment schneller geht. Damit ist die ganze Idee dahin. Halte die Disziplin: Jede Model-ID, die nicht in Config oder Adapter steht, ist ein Bug. Ein Code-Review-Check auf hartkodierte Modellnamen hilft.

Der zweite Stolperstein sind die API-Unterschiede zwischen Anbietern. Amazon Bedrock nutzt anthropic.-präfixierte Model-IDs, und die Behandlung von Parametern wie dem erweiterten Thinking kann je Modell variieren. Diese Eigenheiten gehören in den Adapter, damit dein Anwendungscode sie nie sieht. Wie du Datenresidenz und Wechselrechte zusätzlich vertraglich absicherst, steht in die richtigen Vertragsklauseln mit KI-Anbietern.

Der dritte Stolperstein ist fehlendes Logging. Ohne durchgängiges Kostentracking je Aufgabentyp und Modell weißt du nicht, wo dein Geld hingeht und ob ein Wechsel etwas gebracht hat. Logge bei jeder Anfrage Aufgabentyp, Modell, Tokens, Kosten und Latenz. Und plane den Fallback bewusst über einen anderen Anbieter, denn ein zweites Modell beim selben Anbieter rettet dich nicht, wenn der ganze Anbieter wegbricht. Seit Ende Juli gibt es dafür eine Option, die vorher fehlte: Moonshot hat die Gewichte von Kimi K3 offengelegt, das Modell lässt sich also bei einem europäischen Inferenz-Anbieter oder auf eigener Hardware betreiben. Als Zeile in der Routing-Tabelle ist das vor allem deshalb interessant, weil ein offenes Modell niemand abschalten oder über Nacht neu bepreisen kann. Was dafür an Hardware nötig ist, steht in Kimi K3 selbst hosten. Die Gesamtstrategie dahinter beschreibt Multi-Provider-Resilienz für den Mittelstand.

Wie richtest du Modell-Routing in 7 Schritten ein?

Du baust das Routing am besten von der Bestandsaufnahme zum Test. Die folgende Reihenfolge bringt dich von verstreuten Model-IDs zu einem System, in dem du Modell und Anbieter in einer Zeile wechselst.

1. Aufgabentypen inventarisieren. Liste auf, welche LLM-Aufgaben in deinem Betrieb laufen, wie häufig sie vorkommen und wie kritisch sie sind. Das ist die Grundlage für jede sinnvolle Zuordnung.
2. Abstraktionsschicht bauen. Schreibe eine zentrale Funktion oder ein Modul, das die Model-ID kapselt. Ab hier verweist kein Anwendungscode mehr direkt auf ein Modell.
3. Routing-Tabelle definieren. Lege das Mapping von Aufgabentyp auf Model-ID in einer Config-Datei oder Umgebungsvariable ab, niemals hartkodiert. Diese Tabelle ist dein einziger Wechselpunkt.
4. Feature-Flag und Kill-Switch einbauen. Mach Modell und Anbieter per Schalter umstellbar, ohne Deploy. So reagierst du in Minuten, wenn ein Modell wegfällt oder teurer wird.
5. Fallback und Circuit Breaker verdrahten. Bei Fehler oder Ausfall schaltet das System automatisch auf ein Ersatzmodell, idealerweise bei einem anderen Anbieter über Amazon Bedrock, Google Vertex AI oder Microsoft Foundry. Die vollständige Failover-Architektur mit Stufenmodell und Monitoring steht in unserem Multi-Provider-Resilienz-Guide, hier bleibt es bewusst beim Setup.
6. Logging und Kostentracking aktivieren. Erfasse je Aufgabentyp und Modell, welches Modell wie oft läuft, was es kostet und wie schnell es antwortet. Ohne Zahlen optimierst du blind.
7. Smoke-Test und A/B aktivieren. Vor jedem Wechsel läuft ein kurzer Funktionstest, und zwei Modelle laufen parallel zum Vergleich. So merkst du Qualitätssprünge, bevor sie Kunden merken.

Arno Hoffrichter

Chief Technology Officer, Collective Brain GmbH · Hamburg

CTO bei Collective Brain. Verantwortlich für die technische Umsetzung von Web-Projekten und SEO-Architektur.

Beratung anfragen