Migration guidesFrom Bifrost
From a Bifrost gateway you run
Bifrost is an open-source gateway in Go that you deploy yourself, with virtual keys, budgets, fallbacks and caching, and an Enterprise tier for guardrails, SSO and clustering. INFRO covers the same governance as a hosted service. The request barely changes; what changes is that nobody on your team operates the gateway.
Open source (Apache 2.0) Go gateway by Maxim; self-hosted, with a licensed Enterprise tier
INFRO accounts are self-serve. The catalog, the docs, and the API contract are public, the gateway is deployed, and anything beyond v1 is marked Later. Plans and trial
Where things stand
Licence
Apache 2.0, from Maxim. Guardrails, adaptive load balancing, SSO, RBAC, audit logs and clustering are in a commercially licensed Enterprise tier.
Whose account serves the request
Yours. Provider keys sit in your own Bifrost deployment.
Governance is opt-in
Without enforcement switched on, a request with no virtual key passes without governance. On INFRO every request needs a gateway key.
Bifrost is fast, open and yours to run. Keep it if one of these applies.
- The gateway must run inside your network, in a VPC or air-gapped.
- You use semantic caching, session affinity, Go plugins or async inference jobs.
- You export to Prometheus or Datadog with per-request dimensions (
x-bf-dim-*). - You call providers INFRO does not connect to, or Ollama on a laptop.
The edits, one row each. Everything not listed here stays as it is.
| Bifrost | INFRO | |
|---|---|---|
| Base URL | http://localhost:8080/openai or your deployment. | https://api.infro.io/v1 |
| Key | A virtual key (sk-bf-*) in x-bf-vk or Authorization. | An INFRO gateway key in Authorization: Bearer. |
| Model id | openai/gpt-5.6-terra, vertex/gemini-3.8-flash, azure/gpt-prod. | openai/gpt-5.6-terra, google/gemini-3.8-flash; the provider is chosen by your connections or routing.providers. |
| Headers and fields | fallbacks, x-bf-cache-*, x-bf-dim-*, x-request-id. | fallbacks, cache, metadata.tags, X-INFRO-Trace-Id. |
Before · Bifrost
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "http://localhost:8080/openai",
apiKey: process.env.BIFROST_VIRTUAL_KEY,
defaultHeaders: { "x-bf-dim-feature": "chat" },
});
await client.chat.completions.create({
model: "openai/gpt-5.6-terra",
messages: [{ role: "user", content: "Hello" }],
// @ts-expect-error Bifrost extension
fallbacks: ["anthropic/claude-sonnet-5.5"],
});After · INFRO
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.infro.io/v1",
apiKey: process.env.INFRO_API_KEY,
});
await client.chat.completions.create({
model: "openai/gpt-5.6-terra",
messages: [{ role: "user", content: "Hello" }],
// @ts-expect-error INFRO extensions
fallbacks: ["anthropic/claude-sonnet-5.5"],
metadata: { tags: { feature: "chat" } },
});Provider prefixes
INFRO's model id names the vendor, not the host: google/gemini-3.8-flash whether it runs on Google AI or Vertex. Which of your connections serves it is decided by your connections, a route, or routing.providers.
Same `fallbacks` field
Both take a list of model ids. INFRO's are tried after every connection for model has failed, up to 5.
Dimensions become tags
x-bf-dim-* headers become keys under metadata.tags, grouped in usage and filtered on the request log.
Bifrost's objects against INFRO's, from Bifrost's public documentation read on 19 October 2026 and checked against what the gateway implements. One row says INFRO has nothing.
| Bifrost | What it does there | In INFRO |
|---|---|---|
| Virtual keyssame shape | Allowed models and providers, budgets, rate limits, expiry. | Gateway keys with allowlists, provider lists, spend limits, request-rate tiers, IP ranges, rotation. |
| Hierarchical budgetssame shape | Across virtual keys, teams and customers. | Across organization, project, member, key and end customer, held under concurrency. |
| Fallbacks and retriessame shape | fallbacks and per-provider retry backoff. | fallbacks, and routes with failure rules per kind. |
| Load balancing across keyssame shape | Across provider keys; adaptive on Enterprise. | Spread across a provider's keys, standby keys last; weighted routes. |
| Semantic cachingdifferent | Exact and semantic, on your own vector store. | Exact-match only, hosted. |
| Observabilitydifferent | Prometheus metrics, OTel tracing, request logs. | Request log and traces with estimated cost, exports, spans to your OpenTelemetry collector. No Prometheus endpoint. |
| Guardrails, SSO, audit logssame shape | Enterprise tier. | Guardrails on the plans that include them; SSO and SCIM from Business; an audit log. |
| Pluginsnothing | Custom Go plugins in the request path. | Nothing. INFRO does not run your code. |
| Self-hostingdifferent | Apache 2.0, anywhere. | Hosted. Self-hosted or hybrid is an enterprise agreement.Enterprise — Available on an enterprise agreement rather than self-serve. |
Our reading of Bifrost’s published documentation, not a trial or a benchmark. If we have read something wrong, tell us and we will fix the row.
What INFRO does not do
- Run in your network without an enterprise agreement, or under an open-source licence.
- Semantic caching, session affinity, plugins, async inference jobs.
- A Prometheus metrics endpoint.
What does not come across
- Logs in your Bifrost log store. There is no importer.
- Virtual keys. Issue INFRO gateway keys and rotate callers over.
Questions
- Do I keep my provider accounts?
- Yes. They become INFRO connections and keep billing you directly. INFRO adds 0% to model spend.
- Does the `fallbacks` field still work?
- Yes. INFRO takes
fallbacksas a list of up to 5 model ids. - Can INFRO run on our infrastructure?
- Only under an enterprise agreement. The plans are hosted.
Move with us, or on your own
The migration program maps your Bifrost setup to INFRO connections, routes and budgets on a call and moves the first service with you. Your providers keep billing you directly; INFRO is a subscription and adds 0% to model spend.
Sources
Every statement on this page about Bifrost comes from one of these, read on 19 October 2026. Nothing is inferred from a trial, a benchmark, or a conversation.
- GitHub — maximhq/bifrostread 2026-10-19
- Bifrost docs — Virtual keysread 2026-10-19
- Bifrost docs — OpenAI SDKread 2026-10-19
- Bifrost docs — Request optionsread 2026-10-19
- Bifrost docs — Fallbacksread 2026-10-19
- Bifrost docs — Semantic cachingread 2026-10-19
- Maxim — Bifrost pricingread 2026-10-19