Compatibility Plugin

​

Compatibility Transformations

1. Text-to-Chat Conversion - Automatically converts text completion requests to chat completion format for models that only support chat APIs
2. Chat-to-Responses Conversion - Automatically converts chat completion requests to responses format for models that only support responses APIs
3. Drop Unsupported Params - Automatically drops unsupported parameters if the model doesn’t support them. A reasoning.summary value the datasheet marks unsupported (supports_reasoning_summary_detailed, supports_reasoning_summary_concise or supports_reasoning_summary_auto set to false) becomes auto when the model accepts auto, and is dropped otherwise. Reasoning effort is always kept
4. Unsupported Parameter Conversion - Automatically converts unsupported parameters to their supported equivalents
5. Reasoning-Only Models to Responses - Routes chat completion requests to the Responses API for models that cannot reason alongside tool calls on chat completions
6. Decision-to-Responses Emulation - Answers decision requests for models without a native decisions endpoint by prompting the model through the Responses API (off by default)

​

1. Text-to-Chat Conversion

1. Checking if the model supports text completion natively (using the model catalog)
2. If not supported, converting your text prompt to chat message format
3. Calling the chat completion endpoint internally
4. Transforming the response back to text completion format
5. Returning content in choices[0].text instead of choices[0].message.content

​

How It Works

• Your text prompt becomes a user message: {"role": "user", "content": "your prompt"}
• Parameters like max_tokens, temperature, top_p are mapped to chat equivalents
• Fallbacks are preserved

• choices[0].message.content → choices[0].text
• object: "chat.completion" → object: "text_completion"
• Usage statistics and metadata are preserved

​

2. Chat-to-Responses Conversion

1. Checking if the model supports chat completion natively (using the model catalog)
2. If not supported, converting your chat message to responses API format
3. Calling the responses endpoint internally
4. Transforming the response back to chat completion format

​

How It Works

​

3. Reasoning-Only Models to Responses

1. Calls the Responses API instead, where reasoning and tools work together
2. Transforms the response back to chat completion format

• should_drop_params on: when the request carries tools, reasoning is turned off (dropped, or set to none when the model supports it).
• should_drop_params off: the request is sent with its reasoning setting unchanged.

​

4. Decision-to-Responses Emulation

decisions is not supported by openai provider

1. Checks whether the model is a native decisions model: its supports_decisions datasheet entry, or without one the models Bifrost recognizes by name:
   • OpenAI’s gpt-6-luna family on openai (another provider hosting it, such as Azure or OpenRouter, serves it as a chat model)
   • Typesafe’s typesafe/ models, and every model on the typesafe provider
   • clef models (clef, clef-flash, clef-omni, by bare name or @cf/cloudflare/ ID) on cloudflare
   • pplx-decider-* on perplexity
   • nimble, tev1, clef, clef-flash, and laya (any tag) on ollama
   • Microsoft-Decision-1 on azure
   • ai_decide on databricks
2. If it is, calls the provider’s decisions endpoint without any conversion
3. If not, encodes the questions as a forced function tool, sends the input to the model’s Responses API, and maps the call’s arguments back to typed answers

• The check runs on every attempt, fallbacks included.
• An emulated response reports extra_fields.converted_request_type: "responses" and is billed as the chat call it is.
• A request with an image or other non-text part is rejected, as are passthrough extra params (x-bf-passthrough-extra-params).
• Per request, the header x-bf-compat: ["convert_decision_to_responses"] turns it on for that request only.
• In the Go SDK, it is on when the compat plugin is registered with compat.Config{ConvertDecisionToResponses: true}.

​

Enabling LiteLLM Compatibility

{
  "client_config": {
    "compat": {
      "convert_text_to_chat": true,
      "convert_chat_to_responses": true,
      "should_drop_params": true,
      "should_convert_params": true,
      "azure_deepseek": true,
      "force_reasoning_only_models_to_responses": true,
      "convert_decision_to_responses": false
    }
  }
}

​

Supported Parameters

​

Supported Providers

​

Behavior Details

• Bifrost uses the model catalog to check if a model supports text completion
• If the model has a “completion” mode in its pricing data, it supports text completion
• Conversion only happens when the model lacks native text completion support

​

Transformations Reference

​

Transformation 1: Text-to-Chat Conversion

​

Transformation 2: Chat-to-Responses Conversion

​

Metadata Set on Transformed Responses

• extra_fields.request_type: Reflects the original request type
• extra_fields.original_model_requested: The originally requested model
• extra_fields.resolved_model_used: The actual provider API identifier used (equals original_model_requested when no alias mapping exists)

​

Error Handling

• Original request type and model are preserved in error metadata
• extra_fields.converted_request_type: Set to type of request that was converted to (i.e., chat_completion or responses)
• extra_fields.provider: The provider that handled the request
• extra_fields.original_model_requested: The originally requested model
• extra_fields.dropped_compat_plugin_params: If any unsupported parameters were dropped, the keys are added here

​

Header Overrides

• When x-bf-compat: true or x-bf-compat: ["*"], enables all compat plugins options
• When x-bf-compat: ["<setting1>","<setting2>"], enables the specified settings (available settings: convert_text_to_chat, convert_chat_to_responses, should_drop_params, should_convert_params, azure_deepseek, force_reasoning_only_models_to_responses, convert_decision_to_responses)

​

What’s Preserved

• Model selection and fallback chain
• Temperature, top_p, max_tokens, and other generation parameters
• Stop sequences and frequency/presence penalties
• Usage statistics and token counts

​

When to Use This

• Migrating from LiteLLM to Bifrost without code changes
• Maintaining backward compatibility with text completion interfaces or chat completion interfaces
• Using a unified API across providers with different capabilities

• You need chat-specific features (system messages, conversation history)
• You want explicit control over message formatting
• Performance is critical (direct chat requests avoid conversion overhead)

​

Related Features

• Fallbacks - Automatic provider failover
• Drop-in Replacement - Use existing SDKs with Bifrost
• LiteLLM Integration - Using LiteLLM SDK with Bifrost