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-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 eine Exportkontroll-Anordnung der US-Regierung Anthropic gezwungen, Fable 5 und Mythos 5 abzuschalten: Ausländische Staatsangehörige durften keinen Zugang mehr haben, und weil sich die Staatsangehörigkeit nicht in Echtzeit prüfen ließ, sperrte Anthropic beide Modelle für alle Kunden. Alle übrigen Modelle, damals etwa Opus 4.8, Sonnet 4.6 und Haiku 4.5, blieben laut Anthropic unberührt. Am 1. Juli kam Fable 5 weltweit zurück, zunächst nur über Anthropics eigene Kanäle; für AWS, Google Cloud und Microsoft Foundry kündigte Anthropic die Rückkehr „so schnell wie möglich“ an. Mythos 5.1 gibt es heute nur für Organisationen, die Anthropics Prüfprogramme wie das Cyber Verification Program durchlaufen haben. Wer Fable 5 fest verdrahtet hatte, stand knapp drei Wochen still. Wer eine Routing-Tabelle hatte, hat eine Zeile geändert. Mehr dazu im Hub-Artikel Claude im Unternehmenseinsatz und auf unserer Status-Seite zu Fable 5.1 und Mythos 5.1 mit Chronik.

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-5 über Anthropic”.

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

routing:
  routine:     { model: "claude-haiku-5-5",  provider: "anthropic", effort: "low" }
  standard:    { model: "claude-sonnet-5-5", provider: "anthropic", effort: "medium" }
  schwer:      { model: "claude-opus-5-5",   provider: "anthropic", effort: "high" }
  spitzenlast: { model: "claude-fable-5-1",  provider: "anthropic", effort: "high" }
fallback:
  schwer:      { model: "claude-opus-5-5",   provider: "bedrock" }
api_version: "2026-10-21"
kill_switch: false

Die Effort-Stufe steht mit in der Zeile, weil die Voreinstellungen je Modell abweichen, und die API-Version ist festgeschrieben, damit ein SDK-Update sie nicht still ändert. 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 5.5 zum Beispiel anthropic.claude-opus-5-5 statt claude-opus-5-5. Genau solche Unterschiede gehören in den Adapter und nirgendwo sonst hin. Den Zugang prüfst du dort vorab: Für alle Bedrock-Kunden offen sind laut Anthropic unter anderem Fable 5.1, Opus 4.8 und Sonnet 5, für Opus 5.5 gelten die Zugangskriterien in der AWS-Konsole.

Der Eintrag spitzenlast lief während der Fable-5-Sperre im Juni knapp drei Wochen ins Leere; für solche Fälle steht der fallback-Block bereit, der schwere Last bei Bedarf über Bedrock zieht. Seit Opus 5.5 braucht den Eintrag deutlich seltener jemand: Anthropic rät, im Zweifel mit Opus 5.5 zu starten, und nennt für Fable 5.1 zwei Fälle, anspruchsvolles Schlussfolgern und lange Agentenläufe oder Tests, in denen Opus 5.5 auch auf höherer Effort-Stufe nicht reicht. Wer spitzenlast behält, sollte ihn als Sonderfall führen und regelmäßig gegen Opus 5.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 auf der Claude API, Stand 23. Oktober 2026.

Anthropic selbst rät, im Zweifel mit Opus 5.5 zu starten. Für eine Routing-Tabelle ist das der Ausgangspunkt für schwere Aufgaben; ob Sonnet 5.5 oder Haiku 5.5 eine Routine sauber lösen, zeigt erst dein eigener Test mit echten Fällen. Welche Stufe zu welcher Aufgabe passt, vergleicht unser Überblick Claude Opus, Sonnet oder Haiku. Die kleine Stufe im Detail beschreibt Claude Haiku im Unternehmenseinsatz, die mittlere Claude Sonnet 5.5 und Sonnet 5 im Unternehmenseinsatz. Wie sich die Spitze im Sommer verschoben hat, steht in Claude Opus 5 gegen Fable 5, dort auch der ältere Stand mit Opus 4.8.

Was ändert sich fürs Routing mit Fable 5.1 und der 5.5-Reihe?

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, also der Faktor 0,025 auf den Eingabepreis, wie bei Mythos 5.1. Opus 5.5 und Sonnet 5.5 rechnen mit 0,05, alle übrigen Claude-Modelle mit 0,1. Für eine Agenten-Schleife, die denselben 120.000-Token-Kontext zwanzigmal am Tag neu liest, sind das über einen Monat 18 USD auf Fable 5.1 statt 72 USD auf Fable 5. Auf Opus 5.5 kostet derselbe Cache-Posten 14,40 USD, auf Sonnet 5.5 7,20 USD. Wie sich das in eine vollständige Kostenrechnung einfügt, steht in Claude-API-Kosten kalkulieren.

Für eine Routing-Schicht wiegen die Verhaltensänderungen schwerer. Anthropic führt für Fable 5.1 vier Breaking Changes, drei davon treffen genau das Muster dieses Artikels, und mit der 5.5-Reihe gelten sie in ähnlicher Form für Opus 5.5, Sonnet 5.5 und teils Haiku 5.5. Die Dokumentation nennt Router und Fallback ausdrücklich als Beispiel.

Trägt eine Anfrage einen Block, den das Zielmodell nicht lesen kann, etwa weil ein Router oder Fallback mitten im Gespräch das Modell wechselt, entfernt die API den Block, bevor das Modell ihn erhält.

— Anthropic, Neuerungen in Claude Fable 5.1, abgerufen am 23. Oktober 2026 (eigene Übersetzung)

Ein Denkblock gehört dem Modell, das ihn erzeugt hat. Lesen kann ihn nur dieses Modell und eine feste Liste weiterer Modelle; die Faustregel, jedes neuere Modell lese die Blöcke der älteren, trägt seit der 5.5-Reihe nicht mehr. Fable 5.1 liest die Blöcke von Fable 5, Opus 5 und älteren Stufen, auf der Claude API auch die von Opus 5.5. Seine eigenen Blöcke lesen nur Fable 5.1 und Mythos 5.1, auch das spätere Opus 5.5 nicht. Haiku 5.5 liest keine Blöcke von Opus 5, Opus 5.5 und Sonnet 5.5. Umgekehrt lesen Opus 5.5 und Sonnet 5.5 auf der Claude API und bei Google Cloud (Google managed) die Blöcke von Haiku 5.5, Opus 5.5 dort auch die von Sonnet 5.5. Für dein Routing heißt das: Eine Eskalation von Haiku 5.5 über Sonnet 5.5 auf Opus 5.5 nimmt die Argumentationskette auf der Claude API mit. Wer dagegen von Sonnet 5.5 oder Haiku 5.5 auf Fable 5.1 eskaliert oder von Fable 5.1 auf Opus 5.5 ausweicht, verliert sie, und das Zielmodell 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 für Fable 5.1, Opus 5.5, Sonnet 5.5 und Haiku 5.5; Mythos 5.1 und alle Modelle vor Fable 5.1 prüfen nicht. 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. Parameter wie effort, max_tokens oder tool_choice gehören nicht zu diesem Präfix, die darfst du je Schritt ändern. Für Routing-Schichten ist das 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 standardmäßig für Konten, die am oder nach dem 31. August 2026 angelegt wurden, auf der Claude API und auf den Cloud-Plattformen. Ältere Konten prüft die API nur, wenn die Anfrage das Feld prefix_mismatch_behavior setzt. Anthropic rät trotzdem, unabhängig vom Kontoalter anfügend zu bauen, damit derselbe Code auf jedem Konto läuft.

Die dritte Bindung geht aufs Konto. Denkblöcke von Sonnet 5.5 und Haiku 5.5 gelten nur in dem Konto, das sie erzeugt hat, oder in einem damit verknüpften. Schickt ein anderes Konto sie mit, verwirft die API sie still. Das trifft Router, die Last über mehrere Organisationen oder API-Konten verteilen.

Erzwungene Werkzeugnutzung fällt weg. tool_choice mit dem Typ any oder tool beantworten Fable 5.1, Opus 5.5 und Sonnet 5.5 mit einem 400er, auto und none bleiben unverändert. Haiku 5.5 nimmt die erzwungene Wahl an, antwortet dann aber ohne Denkblock. Wenn dein Adapter für bestimmte Aufgabentypen ein Werkzeug erzwingt, um verlässliches JSON zu bekommen, brauchst du auf diesen Stufen auto mit 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; die gibt es auf der 5.5-Reihe, auf Fable 5.1, Opus 5 und Opus 4.8, auf Sonnet 5 dagegen nicht. 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”. Er verwirft den strittigen Block und jeden späteren Denkblock, statt die ganze Anfrage abzuweisen; Anthropic empfiehlt das nur als Übergangslösung, weil danach deutlich mehr Ausgabe-Token anfallen können.

Was ändert die API-Version 2026-10-21 an deiner Routing-Schicht?

Am 21. Oktober 2026 hat Anthropic die API-Version 2026-10-21 veröffentlicht. Sie entfernt die Parameter temperature, top_p und top_k: Jede Anfrage, die einen davon mitschickt, endet auf jedem Modell mit einem 400er, auch mit dem Standardwert. Unter der alten Version 2023-06-01 löst nur ein Nicht-Standardwert auf Claude 4.7 und neuer den Fehler aus; auf älteren Modellen wie Haiku 4.5 wirken die Parameter dort weiter. Außerdem lehnt die neue Version document-Blöcke in assistant-Nachrichten und citations in user-Nachrichten ab.

Für den Router zählt, wer die Version setzt. Die neuen SDK-Hauptversionen senden 2026-10-21 automatisch, darunter Python 2.0.0, TypeScript 1.0.0, Go 2.0.0 und Java 3.0.0. Ein Bibliotheks-Update ändert also das Verhalten aller Routen auf einmal. Zwei Folgen landen direkt im Adapter. Wer Sampling-Parameter je Aufgabentyp setzt, entfernt sie zentral, bevor er das SDK hebt. Und wer einen Proxy oder ein Gateway im Pfad hat: Die neuen SDKs schicken den API-Schlüssel als Authorization: Bearer statt im Header X-Api-Key, Proxys, Log-Filter und Middleware, die X-Api-Key lesen, müssen mit. Auf Amazon Bedrock gibt es 2026-10-21 nur für Claude 4.7 und neuer. Eine Fallback-Zeile auf ein älteres Bedrock-Modell wie Opus 4.6 braucht deshalb das bisherige SDK oder die bisherige Versionskennung.

Daraus folgt eine Regel für die Routing-Tabelle: Jede Zeile trägt neben der Model-ID ein Parameter-Profil. Haiku 5.5 lehnt budget_tokens, Sampling-Parameter und Prefill mit einem 400er ab, nimmt aber erzwungene Werkzeugwahl an. Sonnet 5.5 lehnt thinking mit dem Typ disabled ab. Opus 5.5 denkt immer, abgeschaltetes Denken und ein fester budget_tokens-Wert scheitern dort. Statt diese Liste hart zu kodieren, kann der Adapter die Models API fragen: Sie meldet je Modell unter capabilities zum Beispiel, ob es abgeschaltetes Denken akzeptiert. Wie dieselbe Versionsumstellung auf deinen Ausweichpfad wirkt, beschreibt der Leitfaden zur Multi-Provider-Resilienz.

Welchen Nutzen bringt dir zentrales Routing konkret?

Der greifbarste Nutzen ist Geld. Verschiebst du Routine-Aufgaben von Opus 5.5 auf Haiku 5.5, kostet jedes Token bei Prompts bis 100.000 Token ein Vierzigstel: 0,10 statt 4 USD je Million Eingabe-Token, 0,50 statt 20 USD bei der Ausgabe. Bei hohem Volumen ist das der größte Hebel deiner KI-Rechnung, noch vor jeder Prompt-Optimierung. Achte auf die Preisstufe: Ist der Prompt eines Aufrufs länger als 100.000 Token, zahlt der ganze Aufruf 0,50 zu 2,50 USD, und Cache-Treffer und Cache-Schreibvorgänge zählen zur Promptlänge mit. Eine Routing-Regel, die lange Dokumente auf Haiku 5.5 schickt, sollte das wissen.

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, auf Opus 5.5 und Sonnet 5.5 5 Prozent, auf Fable 5.1 und Mythos 5.1 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. Prüfe dabei die Mindestlänge: Die aktuelle Reihe cacht ab 512 Token, Haiku 4.5 erst ab 4.096, ein kurzer System-Prompt bleibt dort ungecacht. Die Batch-API gibt dir 50 Prozent Rabatt auf nicht zeitkritische Last, allerdings nicht auf jedem Bezugsweg: Auf Amazon Bedrock und bei Google Cloud (Google managed) gibt es die Message-Batches-API nicht. 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, der für denselben Text rund 30 Prozent mehr Token ergibt. Ihn nutzen alle aktuellen Stufen, also Haiku 5.5, Sonnet 5.5, Opus 5.5 und Fable 5.1, dazu Sonnet 5 und Opus 5. Innerhalb der 5.5-Reihe ist der Preisabstand deshalb auch der reale Abstand: Sonnet 5.5 kostet je Eingabe-Token das Zwanzigfache von Haiku 5.5, bei Prompts über 100.000 Token das Vierfache. Haiku 4.5 rechnet noch mit dem alten Tokenizer. Wer dort Routine laufen lässt und mit Sonnet 5.5 vergleicht, sieht im Preisblatt 1 zu 2 USD, real liegt der Abstand wegen der 30 Prozent näher an 2,6. Beim Umstieg von Haiku 4.5 auf Haiku 5.5 zahlst du für denselben Text bei der Eingabe rund 13 Prozent des alten Preises, solange der Prompt höchstens 100.000 Token lang ist; die Preisliste allein legt 10 Prozent nahe. Darüber sind es rund 65 Prozent. Weil Haiku 5.5 denselben Text in mehr Token zerlegt, überschreitet ein Prompt die Schwelle schon ab rund 77.000 Token alter Zählung.

Dazu kommt die Effort-Stufe als dritte Stellschraube. Du regelst pro Anfrage in fünf Stufen von low bis max, wie viel Rechenzeit das Modell in die Antwort steckt; die Stufe xhigh gibt es nur auf den Modellen ab Opus 4.7, Haiku 4.5 kennt die Stufen gar nicht. Fürs Routing heißt das, deine Tabelle bildet Aufgabentyp auf Modell plus Stufe ab. Eine simple Extraktion läuft auf niedriger Stufe, eine schwierige Analyse auf hoher. Setz die Stufe ausdrücklich: Die meisten Modelle starten auf high, Opus 5.5 und Haiku 5.5 auf medium. Wer von Opus 5 auf Opus 5.5 umstellt und effort weglässt, rechnet danach eine Stufe niedriger.

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 und lässt den Code in Ruhe. 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. Dasselbe gilt seit der API-Version 2026-10-21 für Request-Parameter wie temperature. Ein Code-Review-Check auf hartkodierte Modellnamen und Sampling-Parameter hilft.

Der zweite Stolperstein sind die Unterschiede zwischen den Bezugswegen. Amazon Bedrock nutzt anthropic.-präfixierte Model-IDs, Microsoft Foundry, Claude Platform on AWS und Google Cloud die normalen. Bei Google heißt Vertex AI seit April 2026 Gemini Enterprise Agent Platform. Auf Bedrock fehlen die Message-Batches-API und der serverseitige Parameter fallbacks, und die API-Version 2026-10-21 gibt es dort nur für Claude 4.7 und neuer. Ist ein Modell auf Bedrock im Legacy-Status, können Bestandskunden den Zugang nach 15 Tagen ohne Nutzung verlieren; ein Standby-Fallback dort braucht also regelmäßigen Testverkehr. 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, Effort-Stufe, Tokens, Kosten, Latenz und Ablehnungen. Seit dem 24. September 2026 rechnet Anthropic Ablehnungen, die vor jeder Ausgabe kommen, in den Kategorien bio, frontier_llm und reasoning_extraction ab, und jede Ablehnung zählt gegen das Rate-Limit. Und plane den Fallback bewusst über einen anderen Hersteller, denn ein zweiter Bezugsweg zum selben Modell rettet dich nicht, wenn das Modell selbst wegfällt. Seit dem 27. Juli gibt es dafür ein offenes Modell der Spitzenklasse: Moonshot hat die Gewichte von Kimi K3 unter einer eigenen Lizenz veröffentlicht, 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 Gewichte, die du selbst vorhältst, niemand zurückziehen 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 ein gleichzeitiger Ausfall zweier Anbieter aussieht, unsere Auswertung der gleichzeitigen Störung von ChatGPT und Claude.

Der vierte Stolperstein sind die Fristen fremder Anbieter. OpenAI schaltet heute, am 23. Oktober 2026, 17 ältere Modell-Snapshots ab, darunter gpt-4o-2024-05-13, o3-mini-2025-01-31 und o4-mini-2025-04-16, angekündigt im April. Die OpenAI-API liefert das Abschaltdatum maschinenlesbar im Feld shutdown_date der Modell-Liste, dein Monitoring kann es täglich abfragen. Heikler ist ein Muster bei Google: In der Gemini API leiten abgekündigte IDs teils automatisch auf den Nachfolger um, gemini-3.7-flash etwa auf gemini-3.8-flash. Der Aufruf läuft weiter, es antwortet aber ein anderes Modell. Eine Gemini-Zeile braucht deshalb einen Smoke-Test, der den Inhalt der Antwort prüft, ein HTTP-Status 200 allein sagt dort wenig.

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 Model-ID, API-Version und Request-Parameter kapselt. Ab hier verweist kein Anwendungscode mehr direkt auf ein Modell oder setzt selbst temperature oder tool_choice.
3. Routing-Tabelle definieren. Lege das Mapping von Aufgabentyp auf Model-ID, Effort-Stufe und Parameter-Profil 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. Gegen den Ausfall eines Bezugswegs hilft ein zweiter Weg zum selben Modell, etwa Amazon Bedrock, Google Cloud, Microsoft Foundry oder Claude Platform on AWS; gegen den Wegfall eines Modells nur ein zweiter Hersteller oder ein offenes Modell. 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, auf welcher Effort-Stufe, was es kostet, wie schnell es antwortet und wie oft es ablehnt. Ohne Zahlen optimierst du blind.
7. Smoke-Test und A/B aktivieren. Vor jedem Wechsel und vor jedem SDK-Hauptversions-Update läuft ein kurzer Funktionstest je Route, der auch den Inhalt der Antwort prüft, 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