Provider Compatibility
Provider compatibility depends on both the caller-facing endpoint and the upstream provider configuration behind the model alias. A model can work on a broad chat endpoint and still be rejected on a provider-specific endpoint.
AISIX has two compatibility layers:
| Layer | Purpose |
|---|---|
| Adapter families | Decide how chat-style requests are encoded for upstream providers. See Adapter Protocol Families. |
| Endpoint rules | Decide whether a specific proxy route accepts the selected model alias. |
Check both layers when planning a route. The adapter tells AISIX how to talk to the upstream provider; the endpoint's own rules decide whether that proxy route supports the selected provider or adapter family.
Endpoint Compatibility
Use the caller's API format and provider support requirements to choose a proxy route.
| Need | Route | Provider support |
|---|---|---|
| Broad chat compatibility | /v1/chat/completions | OpenAI, Anthropic, Bedrock, Vertex AI, Azure OpenAI, and OpenAI-compatible providers through their configured adapter. |
| Anthropic-style clients | /v1/messages | Anthropic upstreams natively; non-Anthropic upstreams through translation with limited feature coverage. |
| Anthropic token counting | /v1/messages/count_tokens | Anthropic-backed models only. |
| Streaming chat | /v1/chat/completions or /v1/messages with stream: true | Same provider support as the chosen endpoint. Streaming uses the first selected target and does not fail over mid-stream. |
| Embeddings | /v1/embeddings | OpenAI-compatible upstreams, Amazon Titan and Cohere embedding models on Bedrock, and Google-publisher embedding models on Vertex AI. Other provider and model combinations return 501 not_implemented. |
| OpenAI Responses API | /v1/responses | OpenAI upstreams through verbatim forwarding, and non-OpenAI upstreams through the Responses bridge when the provider adapter supports the translated request shape. |
| Image generation | /v1/images/generations | Models whose configured provider is OpenAI. |
| Audio | /v1/audio/transcriptions, /v1/audio/translations, /v1/audio/speech | OpenAI-style upstream audio routes. AISIX forwards the audio format; it does not translate audio across provider families. |
| Rerank | /v1/rerank | Cohere and Jina, or an OpenAI-compatible upstream that uses the openai provider value and implements /v1/rerank. The public OpenAI API does not provide this endpoint. |
| Provider-native routes | /passthrough/:provider/*rest | Any provider value with an accessible model and provider key, with limited gateway normalization. |
Provider-Specific Support
All supported chat and Responses routes can stream. The table below highlights additional endpoint support and important provider boundaries.
| Provider setup | Endpoint support and boundaries |
|---|---|
| OpenAI | Supports chat completions, Responses, embeddings, image generation, and audio. The public OpenAI API does not provide a rerank endpoint. |
| Anthropic | Supports Messages and token counting natively. Chat completions and Responses use translation. Embeddings, image generation, and rerank are not supported. |
| Amazon Bedrock | Supports chat completions and Responses. Embeddings are limited to Amazon Titan and Cohere embedding model IDs. Image generation and rerank are not supported. |
| Google Vertex AI | Supports chat completions and Responses. Embeddings are limited to Google-publisher embedding models. Image generation and rerank are not supported. |
| Azure OpenAI | Supports chat completions and Responses. The Azure OpenAI adapter does not implement embeddings, image generation, or rerank. |
| Gemini, Qwen, DeepSeek, Groq, Mistral, and Together AI | Support chat completions and bridged Responses requests. Image generation and rerank are not supported. |
| Other public OpenAI-compatible providers | Require an OpenAI-compatible chat-completions route. Embeddings depend on the upstream route. Rerank also requires a provider value accepted by the rerank route. |
| Private OpenAI-compatible endpoints | Must implement each upstream route that applications call. Embeddings depend on the private endpoint. The example's vllm provider value is not accepted by the rerank route. |
Endpoint Rules
The tables above are the primary route reference. The rules below clarify cases where provider identity, adapter family, and endpoint behavior differ.
- Chat completions is the broadest normalized route. For non-OpenAI upstreams, the provider-facing request can still use Anthropic, Bedrock, Vertex AI, Azure OpenAI, or another adapter-specific format behind the gateway.
- Responses uses provider-specific handling. OpenAI-backed models forward to the upstream Responses API. Other providers are bridged through the chat adapter path and return a Responses-shaped result for supported request features.
- Image generation is an OpenAI-provider route. An OpenAI-compatible vendor can use the OpenAI adapter for chat completions and still be rejected on this route when its provider value is not
openai. - Embeddings dispatch through the resolved adapter. The OpenAI adapter forwards the OpenAI request shape, while the Bedrock and Vertex adapters translate requests for their supported embedding model families. Audio remains an OpenAI-style forwarding route and is not translated across provider families.
- Rerank uses a route-specific provider allowlist. Accepted provider values are
openai,cohere, andjina, but the configured upstream must provide/v1/rerank. Theopenaivalue supports compatible rerank providers; it does not imply that the public OpenAI API provides this endpoint. - Anthropic Messages supports native Anthropic upstreams and translated non-Anthropic upstreams. Token counting requires an Anthropic-backed model.
Provider-specific response fields outside the OpenAI response envelope are not normalized by default. When an OpenAI-compatible provider returns reasoning content in a custom field, configure response.reasoning_field on the provider key.
Cross-Provider Content Limitations
When a request crosses provider families, AISIX translates the message text but drops non-text content blocks. This applies, for example, to an OpenAI-shaped chat request routed to an Anthropic- or Gemini-backed model. Image blocks (image_url), audio, and other non-text parts are skipped on the translated request; only the text reaches the upstream.
Non-text content passes through unchanged only when the caller format and the resolved provider are in the same family. An OpenAI-shaped vision request routed to an OpenAI-provider model follows this path. If a request depends on images or other non-text content, route it to a model whose provider matches the caller format.