TLDR
Über Cortecs, EU Router, Requesty und OpenRouter cacht Claude nur, wenn man
cache_controlmitschickt – dann aber bei allen vier in 4 von 4 Folgeaufrufen. Ohne Marker: 0 von 4. Der Router entscheidet, welcher Upstream antwortet, und damit, ob gecacht wird und was es kostet. Router nehmen Thinking-Level an, die der Anbieter ablehnt. Kosten pro Aufruf liefern alle vier, und bei Claude stimmten sie auf den Cent; bei Open-Source-Modellen lag der berechnete Preis zwischen 80 % unter und 170 % über dem gelisteten. Teil 4 der Serie „Was ein LLM-Aufruf wirklich kostet".
Einleitung
Ein Router ist eine API vor vielen APIs: Man schickt eine Anfrage im OpenAI-Format, und der Router leitet sie an einen passenden Anbieter weiter – Anthropic, AWS Bedrock, Google Vertex, einen Open-Source-Hoster. Für europäische Unternehmen kommt ein drittes Argument dazu: Router wie Cortecs oder EU Router versprechen, dass die Verarbeitung in der EU bleibt.
Bequem ist das in jedem Fall. Ob es auch günstig ist, hängt an Details, die man erst sieht, wenn man misst.
Offenlegung: Evanto nutzt Cortecs als Partner für Managed AI in CompanyWizard. Die Messungen liefen über separate Messkonten; Cortecs hat die Ergebnisse vor der Veröffentlichung nicht gesehen.
1. Der Testaufbau
Wir haben denselben Claude-Sonnet-5-Aufruf mit einem Systemprompt von rund 7 200 Tokens fünfmal im Abstand von 20 Sekunden gesendet – direkt an Anthropic und über vier Router. Jeweils in zwei Varianten:
- Bestmöglich: mit
cache_control(TTL 1 Stunde) und, wo möglich, fest gewähltem Upstream. - Unverändert: ohne Marker, so wie die meisten Anwendungen Claude über einen Router ansprechen.
Bei OpenRouter kam eine dritte Variante dazu: cache_control mit Session-Schlüssel, aber ohne fest gewählten Upstream.
2. Caching durch den Router

| Weg | Treffer in Aufruf 2–5, bestmöglich | Treffer, unverändert | Upstream |
|---|---|---|---|
| Anthropic direkt | 4/4 | 0/4 | – |
| Cortecs (Residency) | 4/4 (auf Bedrock gepinnt) | 0/4 | amazon_ireland bzw. google |
| EU Router | 4/4 | 0/4 | aws-bedrock |
| Requesty | 4/4 | 0/4 | nicht gemeldet |
Requesty nur mit auto_cache |
4/4 | – | nicht gemeldet |
OpenRouter, provider.order = Anthropic |
4/4 | 0/4 | Anthropic bzw. Claude Platform on AWS |
| OpenRouter, nur Session-Schlüssel | 4/4 | – | Claude Platform on AWS |
Das Muster ist eindeutig: Ohne cache_control cacht Claude über keinen Router, mit Marker über alle.
Im Detail:
- EU Router reicht
cache_controldurch, obwohl die Dokumentation es nicht erwähnt. - Requesty setzt mit
"requesty": {"auto_cache": true}die Breakpoints selbst – ohne Änderung am Prompt. Cache-Writes meldet Requesty alscaching_tokens, aufgeteilt nach 5 Minuten und 1 Stunde. - OpenRouter reicht
cache_controlinklusive 1-Stunden-TTL durch und hielt alle Folgeaufrufe mit Session-Schlüssel beim selben Upstream – Sticky Routing funktioniert. - Cortecs cacht nur, wenn der Upstream cacht. Ohne Vorgabe ging jeder unserer Aufrufe an Google Vertex – ohne einen einzigen Treffer. Auf
amazon_irelandgepinnt: 4 von 4. Ein Anbieterwechsel zwischen den Aufrufen war dabei nicht das Problem; der Router blieb konsequent beim Upstream, der nicht cacht.
Lesson Learned: Bei einem Router ist Caching keine Eigenschaft des Modells, sondern des Weges. Wer die Ersparnis will, muss den Weg festlegen.
3. Wer antwortet eigentlich?
Cortecs und EU Router nennen den gewählten Upstream in einem Antwort-Header (x-cortecs-provider, x-provider-slug), OpenRouter im Feld provider der Antwort, Requesty gar nicht. Das ist mehr als ein Detail: Derselbe Prompt zählte bei Cortecs auf amazon_ireland 5 426 Prompt-Tokens, auf google 7 238. Der Upstream beeinflusst also nicht nur den Cache, sondern auch die Zahl, nach der abgerechnet wird.
Tipp: Protokollieren Sie den Upstream-Header zu jedem Aufruf. Ohne ihn lassen sich Kostensprünge im Nachhinein nicht erklären.
4. Thinking-Level durch den Router
Router nehmen gern alles an. Cortecs akzeptierte für Claude alle sieben Effort-Werte, auch none und minimal, die Anthropic direkt mit HTTP 400 ablehnt. EU Router nahm für Claude ebenfalls jeden Wert an. Requesty meldet für Claude keine Reasoning-Tokens, sodass sich nicht prüfen lässt, ob der Wert ankommt. OpenRouter nahm für Claude ebenfalls alle sieben Werte an, lehnte für gpt-oss-120b aber none ab.
Cortecs dokumentiert, dass es Effort für Claude in Thinking-Budgets von 1 024 bis 4 096 Tokens übersetzt (nicht messbar). Requesty nennt Budgets bis 16 384 Tokens (nicht messbar). Beides sind Übersetzungen, die die neueren Claude-Modelle laut Anthropic gar nicht mehr annehmen – ein direkter budget_tokens-Aufruf endete bei uns mit HTTP 400. Was der Router tatsächlich weitergibt, bleibt damit eine Black Box.
5. Was es kostet
Alle vier Router liefern die Kosten in jeder Antwort mit:
- Requesty in USD (
usage.cost). - OpenRouter ebenfalls in USD (
usage.cost). - EU Router in USD und Euro, umgerechnet zum EZB-Tageskurs.
- Cortecs als Ganzzahl in Mikro-Euro – entgegen der eigenen API-Referenz, die keine Kosten im Response nennt. Auch die Cache-Felder liefert Cortecs, anders als die API-Referenz vermuten lässt.
Für Claude stimmten diese Kosten mit unserer Formel auf den Cent. Anders bei Open-Source-Modellen:
| Router | Modell | berechnet vs. gelistet (Median) |
|---|---|---|
| EU Router | gpt-oss-120b | +103 % |
| Cortecs | gpt-oss-120b | +50 % bis +67 % |
| Cortecs | DeepSeek V4.1 Flash | +44 % |
| Requesty | gpt-oss-120b über Fireworks | 0 % |
| OpenRouter | gpt-oss-120b | −75 % |
Der gelistete Preis entspricht oft nicht dem Upstream, der tatsächlich antwortet – bei Cortecs und EU Router war es teurer, bei OpenRouter deutlich günstiger. Requesty vermeidet das, weil man dort den Upstream im Modellnamen festlegt (fireworks/gpt-oss-120b).
Und Aufschläge gibt es auch: EU Router listet Claude Sonnet 5 mit 2,20 $ statt 2,00 $ je Million Input-Tokens – 10 % über Anthropic, OpenRouter und Requesty.
6. Open-Source-Modelle: der Hoster entscheidet
Bei Open-Source-Modellen ist der Router nur die halbe Wahrheit; entscheidend ist der Hoster dahinter. Dasselbe gpt-oss-120b cachte bei Cortecs und bei Requesty über Fireworks vollständig, bei EU Router und IONOS gar nicht. Auch die akzeptierten Effort-Werte unterscheiden sich je Hoster – IONOS lehnte für Qwen3.8-27B sogar high ab, aber nicht xhigh.
7. Was „EU" jeweils heißt
„EU" ist bei Routern kein einheitliches Versprechen:
- Cortecs unterscheidet Konten bzw. Schlüssel: Mit dem Sovereign-Schlüssel standen 49 Modelle zur Wahl, ohne Claude; mit dem Residency-Schlüssel 87, darunter Claude über Bedrock und Vertex.
- EU Router filtert Anbieter nach
data_residency,eu_ownedundmax_retention_days(nicht messbar). - Requesty hält mit dem EU-Endpunkt nur die eigene Verarbeitung in der EU; ob auch die Inferenz dort läuft, entscheidet die Modellwahl (nicht messbar).
Ob Daten die EU tatsächlich nie verlassen, lässt sich von außen nicht messen. Messen lässt sich, welcher Upstream antwortet – siehe Abschnitt 3.
8. So haben wir es in .NET gelöst
In Evanto.ChatClients laufen alle Router über die OpenAI-kompatible Chat-Completions-API, auch wenn sie in der Konfiguration als „OpenAI" geführt werden. Die Responses-API gibt es nur für den echten OpenAI-Host:
internal static Boolean UsesResponsesApi(EvChatClientSettings settings)
=> String.Equals(settings.ProviderName, "OpenAI", StringComparison.OrdinalIgnoreCase)
&& Uri.TryCreate(settings.Endpoint, UriKind.Absolute, out var endpoint)
&& String.Equals(endpoint.Host, OPENAI_API_HOST, StringComparison.OrdinalIgnoreCase);
Quelle: UsesResponsesApi (Auszug)
Router-spezifische Felder wie eu_native (Cortecs) oder rule_name (EU Router) setzt CompanyWizard über frei konfigurierbare Zusatzfelder im Request-Body.
Was bei uns noch fehlt: cache_control erlauben wir bisher nur für den Anbietertyp Anthropic. Ein Claude-Modell hinter einem Router bekommt also kein explizites Caching – genau die Variante, die in dieser Messung 0 von 4 Treffern brachte. Die Lücke ist bekannt; geschlossen ist sie noch nicht.
9. Was bewusst offen blieb
- Last und Ausfälle: Failover-Verhalten unter Last haben wir nicht getestet.
- Datenflüsse: Wo Daten physisch verarbeitet werden, lässt sich von außen nicht prüfen.
Fazit: übertragbare Patterns
cache_controlimmer mitschicken, wenn Claude über einen Router läuft – oderauto_cachebei Requesty einschalten.- Den Upstream festlegen, wenn Cache oder Preis wichtig sind.
- Den Upstream-Header protokollieren, um Kosten im Nachhinein erklären zu können.
- Effort-Werte am Anbieter prüfen, nicht am Router – der nimmt fast alles an.
- Bei Open-Source-Modellen den Hoster wählen, nicht nur das Modell.
Alle Rohdaten und Skripte: github.com/evanto-media-ag/llm-caching-reasoning-costs
Die Serie
- Teil 1: Prompt Caching im Vergleich – was den Cache trägt und was ihn bricht
- Teil 2: Thinking-Level im Vergleich – sieben Werte, zwölf Interpretationen
- Teil 3: Kostentransparenz – Formeln, Feldnamen, Preisquellen
- Teil 4: Router im Vergleich – Cortecs, EU Router, Requesty, OpenRouter
Referenzen
- Cortecs: Prompt Caching, Reasoning, Routing
- EU Router: Chat API, Routing
- Requesty: Auto-Caching, EU-Routing
- OpenRouter: Prompt Caching
Sie wollen Claude oder Open-Source-Modelle über einen EU-Router betreiben? Lassen Sie uns 30 Minuten über Ihren konkreten Workflow sprechen – unverbindlich, kostenlos, mit konkreten Vorschlägen am Ende. 30-Min-Gespräch buchen
Hinweis: Artikel mit KI-Unterstützung erstellt.