Skip to main content

One Format, All Providers

The beauty of Bifrost lies in its unified interface: regardless of whether you’re using OpenAI, Anthropic, AWS Bedrock, Google Vertex, or any other supported provider, you always get the same response format. This means your application logic never needs to change when switching providers. Bifrost standardizes all provider responses to follow the OpenAI-compatible structure, so you can write your code once and use it with any provider.

How It Works

When you make a request to any provider through Bifrost, the response always follows the same structure - the familiar OpenAI format that most developers already know. Behind the scenes, Bifrost handles all the complexity of translating between different provider formats.
  • Gateway
  • Go SDK
# Same response format regardless of provider
curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

# Returns OpenAI-compatible format:
{
  "id": "chatcmpl-123",
  "object": "chat.completion", 
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Hello! How can I help you?"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 9,
    "total_tokens": 19
  }
}

Provider Support Matrix

The following table summarizes which operations are supported by each provider via Bifrost’s unified interface.
ProviderModelsTextText (stream)ChatChat (stream)ResponsesResponses (stream)EmbeddingsTTSTTS (stream)STTSTT (stream)
Anthropic (anthropic/<model>)
Azure OpenAI (azure/<model>)
Bedrock (bedrock/<model>)
Cerebras (cerebras/<model>)
Cohere (cohere/<model>)
Gemini (gemini/<model>)
Groq (groq/<model>)🟡🟡
Mistral (mistral/<model>)
Ollama (ollama/<model>)
OpenAI (openai/<model>)
OpenRouter (openrouter/<model>)
Parasail (parasail/<model>)
Elevenlabs (elevenlabs/<model>)
Perplexity (perplexity/<model>)
SGL (sgl/<model>)
Vertex AI (vertex/<model>)
  • 🟡 Not supported by the downstream provider, but internally implemented by Bifrost as a fallback.
  • ❌ Not supported by the downstream provider, hence not supported by Bifrost.
  • ✅ Fully supported by the downstream provider, or internally implemented by Bifrost.
Some operations are not supported by the downstream provider, and their internal implementation in Bifrost is optional. 🟡 Like Text completions are not supported by Groq, but Bifrost can emulate them internally using the Chat Completions API. This feature is disabled by default, but it can be enabled by setting the enable_litellm_fallbacks flag to true in the client configuration. We do not promote using such fallbacks, since text completions and chat completions are fundamentally different. However, this option is available to help users migrating from LiteLLM (which does support these fallbacks).
Notes:
  • “Models” refers to the list models operation (/v1/models).
  • “Text” refers to the classic text completion interface (/v1/completions).
  • “Responses” refers to the OpenAI-style Responses API (/v1/responses). Non-OpenAI providers map this to their native chat API under the hood.
  • TTS corresponds to /v1/audio/speech and STT to /v1/audio/transcriptions.

The Power of Consistency

This unified approach means you can:
  • Switch providers instantly without changing application logic
  • Mix and match providers using fallbacks and load balancing
  • Future-proof your code as new providers get added
  • Use familiar OpenAI patterns regardless of the underlying provider
Whether you’re calling OpenAI’s GPT-4, Anthropic’s Claude, or AWS Bedrock’s models, your application sees the exact same response structure. This consistency is what makes Bifrost’s advanced features like automatic fallbacks and multi-provider load balancing possible.

Provider Transparency

While the response format stays consistent, Bifrost doesn’t hide which provider actually handled your request. Provider information is always available in the extra_fields section, along with any provider-specific metadata you might need for debugging or analytics. This gives you the best of both worlds: consistent application logic with full transparency into the underlying provider behavior. Learn more about configuring provider transparency: