When using the OpenAI-compatible endpoints (/v1/chat/completions, /v1/embeddings),
specify the model using the provider/model format:
{
"model": "anthropic/claude-sonnet-4-20250514",
"messages": [{"role": "user", "content": "Hello!"}]
}
ARouter parses the provider prefix, routes the request to the correct upstream,
and rewrites the model field to the provider’s native format before forwarding.
Examples
| You send | Provider | Upstream model |
|---|
openai/gpt-4o | OpenAI | gpt-4o |
anthropic/claude-sonnet-4-20250514 | Anthropic | claude-sonnet-4-20250514 |
google/gemini-2.0-flash | Google | gemini-2.0-flash |
deepseek/deepseek-chat | DeepSeek | deepseek-chat |
xai/grok-2 | xAI | grok-2 |
mistral/mistral-large-latest | Mistral | mistral-large-latest |
groq/llama-3.3-70b-versatile | Groq | llama-3.3-70b-versatile |
gpt-4o | OpenAI (default) | gpt-4o |
If you omit the provider prefix, ARouter defaults to OpenAI.
So "model": "gpt-4o" is equivalent to "model": "openai/gpt-4o".
Native SDK Endpoints
For providers with their own SDK format, use the native endpoints directly.
The provider is determined by the endpoint path, not the model field:
| SDK | Endpoint | Model format |
|---|
| Anthropic | POST /v1/messages | Native: claude-sonnet-4-20250514 |
| Gemini | POST /v1beta/models/{model}:generateContent | Native: gemini-2.0-flash |
| MiniMax | POST /v1/text/chatcompletion_v2 | Native: abab6.5s-chat |
Native endpoints do not use the provider/model prefix — they use the provider’s
original model names since the provider is already implied by the endpoint path.
Generic Provider Proxy
For any provider, you can also use the catch-all proxy format:
POST /{provider}/v1/chat/completions
For example:
POST /openai/v1/chat/completions → proxied to OpenAI
POST /deepseek/v1/chat/completions → proxied to DeepSeek
POST /anthropic/v1/messages → proxied to Anthropic
This is useful when you want to bypass model-field parsing and explicitly control
which provider receives the request.
How Routing Works Under the Hood
1. Parse model field → extract provider ID
2. Check API key permissions → is this provider allowed?
3. Call router-service → select region, pick healthy key from pool
4. Rewrite model field → strip provider prefix
5. Reverse proxy → forward to upstream with provider's API key
6. Stream response back → record usage asynchronously
ARouter handles provider API key injection, health checking, and failover
completely transparently. Your application never sees the upstream provider’s credentials.