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; supported non-Anthropic upstreams through translation. Text has the broadest support. Image, document, and tool-calling support depends on the selected provider adapter. Signed thinking history remains Anthropic-specific.
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. A routing model can fail over before AISIX sends response bytes, but it cannot switch targets after the response stream has started.
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.
Video generation	/v1/videos and its status and content routes	Models whose configured provider is alibaba, zhipuai (or zhipu), volcengine, runwayml (or runway), or openai. Other providers return 501 not_implemented.
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, and jina, but the configured upstream must provide /v1/rerank. The openai value 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. AISIX can translate text, images, documents, and tool-calling history into its normalized request, but the selected provider adapter determines which translated content reaches the upstream. Anthropic thinking and redacted_thinking history blocks are not replayed to another provider. Token counting requires an Anthropic-backed model.

AISIX preserves reasoning_content and normalizes reasoning to that canonical field. When an OpenAI-compatible provider streams reasoning from a different delta path, configure response.reasoning_field on the provider key.

Content Translation Boundaries

Cross-provider feature support depends on the caller-facing endpoint and translation direction. Do not assume that one result applies to every pair of provider families.

For an Anthropic-shaped /v1/messages request sent to a supported non-Anthropic upstream, AISIX translates supported content into its normalized request. This includes text, base64 and URL images, documents, tool definitions, tool calls, and tool results. The selected provider adapter may support only a subset of that content. OpenAI-compatible adapters preserve image parts, while the current Bedrock and Vertex AI chat adapters use the extracted text from multimodal user content. Signed Anthropic thinking history is dropped because another provider cannot replay it.

For an OpenAI-shaped /v1/chat/completions request sent to another provider family, portable text and tool fields have the broadest support. Non-text handling depends on the selected adapter and upstream API. For example, a provider adapter may use only the concatenated text from a multimodal message even though an OpenAI-compatible upstream can accept the original image_url parts.

When an application depends on provider-specific content, prefer the matching caller-facing endpoint and provider family. Use Anthropic Messages for the exact Anthropic-shaped translation behavior and OpenAI Client with Anthropic Upstream for the reverse direction.