Provider-Routing

Ein Modell wird häufig von mehreren Anbietern bereitgestellt; provider.type bindet eine Anfrage an einen davon. Welche Anbieter es gibt und warum man einen festlegt, steht unter Provider-Routing — diese Seite ist der Feldvertrag je Protokoll.

Wo das Feld steht

Das Feld steht nicht in jedem Protokoll an derselben Stelle:

Protokoll / Endpunkt	Request-Body	Request-Header
OpenAI Chat Completions · `POST /v1/chat/completions`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
OpenAI Responses · `POST /v1/responses`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
OpenAI Images · `POST /v1/images/generations`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
Anthropic Messages · `POST /anthropic/v1/messages`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
Gemini generateContent · `POST /gemini/v1beta/…`	wird still ignoriert	`X-OfoxAI-Provider-Type`
Video API · `POST /v1/videos`	`provider.type` auf oberster Ebene	—

Von den Bildmodellen wird derzeit nur openai/gpt-image-2 von mehreren Anbietern bereitgestellt (azure_foundry und openai); die übrigen sind Einzelanbieter-Modelle, und einen anderen anzugeben liefert 400 provider_type_unavailable. Zu beachten ist außerdem: Gemini-Bildmodelle haben zwei Protokoll-Eingänge — über /v1/images/generations wirkt das Body-Feld, über das native generateContent von Gemini wird es ignoriert.

Übergabe im Request-Body

extra_body muss ein wörtlicher Schlüssel im JSON-Body sein, mit provider darin verschachtelt:

cURL

Terminal


curl https://api.ofox.io/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{ "role": "user", "content": "..." }],
    "extra_body": {
      "provider": { "type": "bedrock" }
    }
  }'

Python

provider_routing.py


client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{"role": "user", "content": "..."}],
    extra_body={"extra_body": {"provider": {"type": "bedrock"}}},
)

TypeScript

provider-routing.ts


await client.chat.completions.create({
  model: 'anthropic/claude-sonnet-5',
  messages: [{ role: 'user', content: '...' }],
  extra_body: { provider: { type: 'bedrock' } },
} as any)

Bei den offiziellen OpenAI-SDKs muss extra_body als wörtlicher Schlüssel im Request-Body vorhanden sein. Das TypeScript-SDK sendet es so, wie es im Parameterobjekt steht. Das Argument extra_body= des Python-SDK verschmilzt seinen Inhalt mit der obersten Ebene des Bodys; der Schlüssel muss dort also eine Ebene tiefer verschachtelt oder stattdessen als Request-Header übergeben werden.

Das native Gemini-Protokoll ignoriert extra_body.provider im Body — die Anfrage geht durch, die Einschränkung greift schlicht nicht, und es gibt keinen Fehler. Nutze auf diesem Protokoll den Header weiter unten.

Übergabe per Header

X-OfoxAI-Provider-Type funktioniert auf allen Textprotokollen, Gemini eingeschlossen, und passt zu Integrationen, die den Request-Body nicht ändern können:

Terminal


curl https://api.ofox.io/gemini/v1beta/models/google/gemini-3.1-flash-lite:generateContent \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "X-OfoxAI-Provider-Type: vertex" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{ "parts": [{ "text": "..." }] }]
  }'

Wo beides unterstützt wird, sind Header und Body-Feld gleichwertig. Die Video-API hat keine Header-Form — siehe Video API · Provider-Routing.

Fehler

`error.type`	Auslöser
`invalid_provider_type`	Der Wert ist kein Anbietername: Tippfehler oder abgeschaffte Schreibweise.
`provider_type_unavailable`	Den Anbieter gibt es, aber er stellt dieses Modell nicht bereit. Die Meldung nennt zusätzlich die Anbieter, die es tun.

Welche Anbieter du angeben kannst

Die vollständige Liste und wie du herausfindest, welche Anbieter ein Modell bereitstellen, stehen unter Provider-Routing.