Multi-Provider-LLM ist bei uns kein Notnagel, sondern Architektur-Default. Im Ragistry-Backend (FastAPI, MCP-Tool-Calling, SSE-Streaming ans Widget, pgvector in Supabase) sitzt eine Provider-Abstraktion, die zwei Welten gleichzeitig sprechen muss: Anthropic Claude Sonnet 4.5 als Primär-Modell für Beratungsdialoge, Claude Haiku 4.5 für Klassifikation und Routing, und OpenAI GPT-4o als Fallback, wenn Anthropic-Rate-Limits oder ein API-Vorfall zuschlagen.
Diese Reihenfolge — Anthropic primär, OpenAI sekundär — ist keine Religionsfrage. Sie ist das Ergebnis einer technischen Abwägung, die wir alle paar Monate neu prüfen. Dieser Artikel macht die Abwägung transparent: was wir gemessen haben, was die Quellenlage hergibt, wo wir Annahmen treffen mussten — und wann die umgekehrte Reihenfolge die richtige wäre.
Warum Multi-Provider, nicht Single-Vendor
Die ehrliche Antwort: Weil jeder Provider Ausfälle hat, jeder Provider Rate-Limits hat, und kein Provider in allen Disziplinen führt. Wer in einem RAG-System eine einzige LLM-API hart verdrahtet, baut sich einen Single Point of Failure ins Produkt — und verliert Verhandlungsmasse, sobald sich Preise oder Modell-Lifecycles ändern.
Ein Beispiel für letzteres: GPT-4o ist mit dem Launch der GPT-4.1-Familie im Januar 2026 in „grandfathered legacy"-Status übergegangen (pecollective.com, April 2026). Es läuft weiter, der Preis bleibt, aber strategisch ist GPT-4.1 die Linie, auf die OpenAI Produktions-Workloads verschiebt. Teams, die noch nicht migriert haben, fahren GPT-4o weiter — was diesen Vergleich operativ relevant macht, aber den Blick auf GPT-4.1 als Forward-Looking-Variante nicht ersetzen sollte.
Die Kostenbasis, Stand 2026
Bevor wir über Streaming und Tool-Schemata reden, der Preisrahmen — denn jede technische Entscheidung kippt unter ökonomischer Realität.
| Modell | Input ($/1M Tok) | Output ($/1M Tok) | Context |
|---|---|---|---|
| Claude Sonnet 4.5 | 3,00 | 15,00 | bis 1.000.000 |
| Claude Haiku 4.5 | 1,00 | 5,00 | 200.000 |
| GPT-4o | 2,50 | 10,00 | 128.000 |
| GPT-4o Mini | 0,15 | 0,60 | 128.000 |
Quellen: Anthropic-Announcement zu Sonnet 4.5 (29.09.2025), pricepertoken.com, finout.io (April 2026), pecollective.com (April 2026), aifreeapi.com (Januar 2026).
Auf den ersten Blick ist GPT-4o auf rohem Input mit 2,50 $ günstiger als Sonnet 4.5 mit 3,00 $. Auf den zweiten Blick — sobald Caching ins Spiel kommt — kehrt sich das Bild für Multi-Round-RAG-Workloads um.
Prompt-Caching: Wo Anthropic für RAG ökonomisch vorbeizieht
Bei Anthropic kosten Cache-Reads 0,1× des Standard-Input-Preises — also 0,30 $ pro Million Tokens bei Sonnet 4.5. Cache-Writes kosten 1,25× (5-Minuten-TTL, 3,75 $) bzw. 2× (1-Stunden-TTL, 6,00 $). Break-even ist nach einem einzigen Cache-Hit erreicht (metacto.com, Mai 2026; livechatai.com, April 2026).
OpenAI hat für GPT-4o automatisches Caching mit 50 % Rabatt auf Cached-Input — also 1,25 $ pro Million Tokens, ohne separate Write-Gebühr (langcopilot.com; aifreeapi.com, Januar 2026).
Für unsere Architektur — langer System-Prompt mit Tool-Definitionen, mehrere Tool-Roundtrips pro Konversation, derselbe RAG-Kontext über mehrere Folgefragen — bedeutet das: Anthropic erreicht laut metacto.com „bis zu 95 % Kostenreduktion" in Anwendungen mit wiederholtem Kontext, wenn man Caching mit der Batch-API (50 % Rabatt) kombiniert. Selbst ohne Batch sind 88–95 % Cost-Reduction für RAG-Systeme realistisch.
Konkreter Hebel im Ragistry-Stack: Anthropic weist offen darauf hin, dass fünf MCP-Server (~58 Tools) rund 55.000 Tokens vor dem ersten User-Turn verbrauchen, im Worst Case 134.000 (Anthropic Engineering, „Advanced Tool Use", 2026). Genau diese Tool-Definitionen sind Cache-Kandidaten Nummer eins. Auf Anthropic zahlt man 0,30 $/1M für deren Re-Use. Auf OpenAI 1,25 $/1M.
Wichtige Einschränkung: Eine kontrolliert vergleichende Studie für Sonnet 4.5 vs. GPT-4o mit identischer RAG-Workload-Spezifikation existiert in der Quellenlage nicht. Die Aussagen oben basieren auf den Pricing-Mechaniken beider Anbieter, nicht auf einem unabhängigen Head-to-Head-Benchmark.
Streaming-Latenz: Was wir wissen — und was nicht
Time to first token (TTFT) ist für ein Widget, das wie ChatGPT streamen soll, die einzige UX-Metrik, die zählt. Artificial Analysis misst auf der Anthropic-Direct-API (10k Input-Tokens, P50 über 72 h, Stand 03.06.2026):
- Claude 4.5 Haiku: 0,75 s TTFT, 97,9 Tokens/s Output
- Claude 4 Sonnet: 1,06 s TTFT
- Claude 4.5 Sonnet: 1,21 s TTFT
Das ist die saubere, dokumentierte Datenbasis. Was wir an dieser Stelle ehrlich sagen müssen: Für den Long-Context-Fall, der RAG ausmacht — 50k bis 200k Input-Tokens, große Tool-Result-Returns aus Web-Crawls oder Datenbank-Lookups — gibt es keinen publizierten, kontrollierten Drittanbieter-Benchmark, der beide Provider vergleicht. Die markaicode.com-Benchmark nutzt 340 Input-Tokens. Artificial Analysis testet bei 10k. Beides ist nicht der Punkt, an dem RAG-Systeme weh tun.
Was wir aus dem eigenen Betrieb beobachten, halten wir bewusst zurück, bis wir es als reproduzierbares Benchmark-Set veröffentlichen können. Was wir sagen können: Anthropic ist in unserem Stack der Provider, dessen Streaming bei großen Tool-Result-Payloads (Markdown-Scrapes im niedrigen dreistelligen KB-Bereich) seltener in degenerierte Zustände läuft. „Seltener" ist eine qualitative Aussage, kein Benchmark — und sollte auch so verstanden werden.
Tool-Calling: Zwei Modelle, ein Switch-Layer
Hier wird der Architektur-Unterschied strukturell. Anthropic und OpenAI haben Tool-Use grundverschieden modelliert.
Anthropic liefert Tool-Calls als getypte Content-Blöcke im Response-Array, mit input als geparstes Objekt:
{
"stop_reason": "tool_use",
"content": [
{ "type": "text", "text": "Ich prüfe den Bestand." },
{
"type": "tool_use",
"id": "toolu_01...",
"name": "check_stock",
"input": { "sku": "X300", "warehouse": "DE-01" }
}
]
}
OpenAI trennt Message-Content und Tool-Calls auf Top-Level, arguments ist ein JSON-String:
{
"message": {
"content": "Ich prüfe den Bestand.",
"tool_calls": [{
"id": "call_...",
"type": "function",
"function": {
"name": "check_stock",
"arguments": "{\"sku\":\"X300\",\"warehouse\":\"DE-01\"}"
}
}]
}
}
Rick Hightower bringt es auf den Punkt: „While OpenAI separates message content from function calls, Claude treats everything as content items within a message." (Medium, 25.06.2025). Die Anthropic-Doku ergänzt: „Claude responds with stop_reason: 'tool_use' and one or more tool_use blocks, your code executes the operation, and you send back a tool_result." (platform.claude.com, März 2026).
Für den Provider-Switch heißt das: Beide Seiten brauchen einen Normalisierungs-Layer, der intern ein einziges Tool-Call-Schema kennt. Bei uns sieht das vereinfacht so aus:
@dataclass
class NormalizedToolCall:
id: str
name: str
arguments: dict # immer geparst, nie String
def from_anthropic(block) -> NormalizedToolCall:
return NormalizedToolCall(
id=block.id, name=block.name, arguments=block.input
)
def from_openai(call) -> NormalizedToolCall:
return NormalizedToolCall(
id=call.id,
name=call.function.name,
arguments=json.loads(call.function.arguments),
)
Wer das nicht zentral macht, doppelt jede Tool-Logik. Wer es zentral macht, kann den Primär-Provider per Config-Flag drehen.
Ein Hinweis zur OpenAI-kompatiblen Anthropic-Endpoint (api.anthropic.com/v1/): Anthropic empfiehlt sie explizit nicht für Produktion. Der strict-Parameter für Function-Calling wird ignoriert, Prompt-Caching ist nicht unterstützt. Anthropic schreibt selbst: „For the best experience and access to Claude API full feature set […], use the native Claude API." (docs.anthropic.com, März 2026). Wer ernsthaft beide Provider fahren will, baut den Switch im eigenen Code, nicht über die Kompatibilitäts-Fassade.
Context-Window: 1M vs. 128k — und der Pricing-Bruch dazwischen
Sonnet 4.5 unterstützt offiziell bis zu 1.000.000 Input-Tokens, Haiku 4.5 200.000, GPT-4o 128.000. Wichtige Fußnote: Anthropic schaltet ab 200k Input-Tokens auf 1M-Context-Modellen in ein Long-Context-Premium-Pricing — also nicht der reguläre 3,00 $/1M-Satz (silicondata.com, März 2026).
Praktisch heißt das für RAG-Architekturen: Wer Retrieval und Tool-Returns sauber zusammenstutzt, kommt mit beiden Modellen aus. Wer Web-Crawl-Ergebnisse ungefiltert in den Kontext kippt, zahlt bei Anthropic Premium oder rennt bei OpenAI in die 128k-Wand. Die größere Context-Reserve ist ein Sicherheitspolster, kein Freibrief für unsauberes Retrieval.
DACH-Realität: Datenresidenz, AVV, EU AI Act
Hier wird es regulatorisch konkret — und uneindeutig zugleich.
Anthropic direkt (api.anthropic.com): Bietet als inference_geo-Parameter nur us und global. „Workspace data storage is US only." (waimakers.com, Mai 2026). Für DACH-Mittelständler mit ernsthaftem DSGVO-Setup keine Option für PII-tragende Prompts.
Claude via AWS Bedrock eu-central-1 (Frankfurt): De-facto-Standardweg für deutsche Enterprise-Deployments. Anthropic behält bei Bedrock-Zugriff keine Prompts/Outputs zu Training-Zwecken. Der primäre Auftragsverarbeiter-Vertrag verschiebt sich auf AWS (AWS-DPA), Anthropic-Modellanbieter-Terms greifen on top (compound.law, April 2026). Single-Region-Hosting ist auch in Ireland (eu-west-1) und Stockholm (eu-north-1) verfügbar. Bedrock-Regional-Endpoint-Pricing liegt etwa 10 % über Global-Endpoint-Pricing.
Claude via Azure AI / Microsoft Foundry: Aktuell auf Anthropic-managed Infrastructure, nicht voll Azure-native regional verarbeitet. Microsoft listet EU-Support als „Coming 2026" ohne konkretes Datum (Microsoft Q&A, April 2026). Für EU-only-Anforderungen heute keine Lösung.
GPT-4o via Azure OpenAI Service EU: Verfügbar in West Europe und Sweden Central. Etabliert für DACH-Compliance-Setups.
compound.law fasst die strikte Linie zusammen: „Companies with EU-only data residency requirements must use AWS Bedrock or Google Cloud Vertex AI instead." (April 2026).
Wichtiger Disput in der Quellenlage: sota.io argumentiert (Mai 2026), dass AWS' Exposure gegenüber US CLOUD Act und FISA 702 ein strukturelles DSGVO-Art.-46-Problem schafft, das SCCs allein nicht vollständig heilen — und rät für regulierte Branchen von AWS Bedrock ab. Die pragmatische Industrie-Lesart (innfactory.ai, padiso.co) sieht Bedrock Frankfurt als Standardweg, mit Rest-CLOUD-Act-Risiko, das in einem Transfer Impact Assessment dokumentiert gehört. Welche Lesart für ein konkretes Deployment trägt, entscheidet die jeweilige Compliance — nicht der LLM-Anbieter und nicht wir.
EU AI Act Art. 50 (Transparenzpflicht): Verlangt, dass Nutzer:innen erkennen, mit einer KI zu interagieren. Provider-spezifische DPA-Dokumentation, die das für einen Widget-Use-Case wie unseren explizit adressiert, haben wir in der Recherche nicht gefunden. Die Pflicht trifft den Betreiber des Widgets — also den Ragistry-Kunden — nicht den LLM-Provider. Lösung: sichtbare „KI-Antwort"-Kennzeichnung im Widget plus Hinweis im Erstkontakt.
Warum bei uns Anthropic primär ist
Zusammenfassend, mit den oben belegten Kriterien:
- Caching-Ökonomie für RAG. 90 % Cache-Read-Discount auf wiederholten System-Prompt, Tool-Definitionen und stabilen RAG-Kontext sind bei Multi-Turn-Beratungsdialogen der größere Hebel als 0,50 $ Differenz im Roh-Input-Preis.
- Tool-Use-Schema. Content-Blöcke mit geparstem
input-Objekt sind in einer normalisierten Abstraktion stabiler zu handhaben als JSON-String-Arguments — besonders beim Streaming von partiellen Tool-Argumenten. - Long-Context-Reserve. 1M-Context-Modell mit Premium-Aufschlag schlägt 128k-Hard-Limit, wenn unerwartet großes Tool-Result-Payload zurückkommt.
- EU-Pfad über Bedrock Frankfurt. Etabliert, dokumentiert, kein „Coming 2026".
- Streaming-Stabilität. Qualitativ — siehe Caveat oben.
Wann die umgekehrte Reihenfolge richtig ist
OpenAI ist in unserem Stack Fallback, nicht Verlierer. Es gibt Workloads, in denen wir die Reihenfolge umkehren würden:
- Strukturierte Datenextraktion mit strict JSON-Schema. OpenAIs
strict: truemit garantierter Schema-Konformität ist hier sauberer als alternative Konstruktionen. - Hochfrequente, kostensensitive Klassifikation. GPT-4o Mini zu 0,15 $/1M Input ist nochmals deutlich günstiger als Haiku 4.5 (1,00 $/1M) — wenn die Klassifikationsqualität trägt.
- Bildverarbeitung in Volumenszenarien. OpenAIs Vision-Pipeline ist in vielen Produktions-Workloads heute günstiger und schneller.
- Compliance-Setup mit bestehender Azure-OpenAI-Beziehung. Wenn DPA, AVV und Azure-Tenant ohnehin stehen, ist die Switching-Cost auf Bedrock real — und nicht jedes Projekt wert.
Wie der Switch-Layer aussieht (verkürzt)
Im Backend liegt eine LLMProvider-Abstraktion mit drei Methoden: stream_chat, normalize_tool_calls, format_tool_result. Beide Implementierungen — AnthropicProvider, OpenAIProvider — produzieren denselben internen Stream-Event-Typ (TextDelta, ToolCallStart, ToolCallDelta, ToolCallEnd, MessageEnd). Das Widget-Frontend sieht in beiden Fällen denselben SSE-Strom. Provider-Switch ist ein Config-Flag plus Credential-Rotation, kein Refactor.
Der Punkt ist nicht, ob beide Provider gleich gut sind — sie sind es nicht, in keiner Richtung. Der Punkt ist, dass das Geschäftsmodell „AI-Chat auf Kundendaten" Provider-Risiko nicht an Anthropic oder OpenAI delegieren darf. Multi-Provider ist Hygiene, nicht Luxus.
Pragmatischer Schluss
Für RAG-Beratungsdialoge mit Multi-Round-Tool-Calling im DACH-Mittelstand ist Anthropic Claude Sonnet 4.5 heute unsere Default-Wahl. Die Begründung ist eine Mischung aus Caching-Ökonomie, Tool-Use-Schema und EU-Hosting-Reife — nicht „Anthropic ist besser". Wer Klassifikation, strukturierte Extraktion oder Bildverarbeitung in Volumen fährt, kommt zu einer anderen, gleich legitimen Antwort.
Und wer noch GPT-4o produktiv fährt: Der Lifecycle-Hinweis Richtung GPT-4.1 (2,00 $/8,00 $ pro 1M Tokens, 1M Context, laut pecollective.com) ist ernst zu nehmen. Spätestens bei der nächsten Architektur-Review sollte beides auf den Tisch — Provider-Switch und Modell-Switch innerhalb des Provider.
Ein letzter Hinweis in eigener Sache: Mehrere Aussagen in diesem Artikel — Streaming-Stabilität bei großen Tool-Result-Payloads, TTFT-Verhalten bei 50k+ Input-Tokens, konkrete Failure-Modes im Long-Context-Streaming — sind aus eigener Beobachtung im Ragistry-Betrieb formuliert, nicht aus publizierten Drittanbieter-Benchmarks. Wir arbeiten an einem reproduzierbaren Long-Context-Benchmark-Set und veröffentlichen die Zahlen, sobald die Methodik sauber steht. Bis dahin: Vertrauen Sie keinem Provider-Vergleich, der die Lücke nicht offenlegt.
