Try Bifrost Enterprise free for 14 days. Request access

Claude Gateway: Route Claude and Claude Code Through One Unified AI Gateway

Claude Gateway: Route Claude and Claude Code Through One Unified AI Gateway
Bifrost is an open-source Claude gateway that routes Anthropic Claude models and Claude Code through one API with failover, governance, and caching.

A Claude gateway is a single entry point that routes requests to Anthropic Claude models and to Claude Code (the terminal coding agent) through one Anthropic-compatible API, adding failover, governance, caching, and observability without changes to application or agent code. Bifrost, the open-source AI gateway built in Go by Maxim AI, provides this by exposing a fully Anthropic-compatible /anthropic endpoint that existing Claude SDK code and Claude Code point at with a single base-URL change. This post covers how Bifrost works as a Claude gateway: the drop-in Anthropic-compatible API, multi-provider routing with failover to and from Claude, governance over Claude usage, semantic caching, observability, and how to point Claude Code at Bifrost.

What Is a Claude Gateway

A Claude gateway is an intermediary service that sits between your application (or coding agent) and Anthropic's API, accepting Anthropic-shaped requests, routing them to Claude or another configured provider, and returning responses in the Anthropic response format the client expects. It centralizes credentials, usage tracking, cost controls, and audit logging in one place.

Anthropic's own documentation describes the same pattern: a gateway gives an organization one place to manage credentials, usage tracking, cost controls, and audit logging, with the provider key kept server-side while developers hold gateway credentials instead. Per Anthropic's Claude Code gateway documentation, any gateway that exposes a supported Anthropic API format works with Claude Code. Bifrost implements exactly this contract and extends it with multi-provider routing, failover, and semantic caching.

Why Teams Route Claude Through a Gateway

Teams running Claude in production face three recurring problems that a Claude gateway addresses directly:

  • Provider outages and rate limits: Direct Anthropic API calls have no automatic failover. A 429 rate-limit response or a 5xx outage propagates straight to the application.
  • Ungoverned usage and cost: Individual API keys distributed to developers and services make it difficult to enforce per-team budgets, rate limits, or model access policies.
  • No unified observability: Requests to Claude from applications, services, and coding agents are logged separately, if at all, with no single view of latency, cost, or errors.

Bifrost consolidates these concerns. It routes Anthropic Claude traffic through one endpoint while adding retries and fallbacks, virtual keys for governance, and built-in request logging. For enterprises running Claude at scale, this consolidation is the difference between per-key firefighting and centralized control.

How Bifrost Works as a Claude Gateway

Bifrost exposes a fully Anthropic-compatible endpoint at /anthropic that accepts requests in Anthropic's Messages API format and returns responses in the same shape. This endpoint is the mechanism behind routing Claude through Bifrost: existing Anthropic SDK code keeps working, and the only change is the base URL.

The Bifrost drop-in replacement for the Anthropic SDK requires one line to change:

import anthropic

# Point the Anthropic SDK at Bifrost
client = anthropic.Anthropic(
    base_url="<http://localhost:8080/anthropic>",
    api_key="dummy-key"  # Keys handled by Bifrost
)

response = client.messages.create(
    model="claude-3-sonnet-20240229",
    max_tokens=1000,
    messages=[{"role": "user", "content": "Hello!"}]
)

Bifrost handles the request transformation, response normalization, and error mapping between Anthropic's Messages API and its internal pipeline. Because the Anthropic SDK integration preserves the existing SDK architecture, applications gain governance, load balancing, caching, and multi-provider access without a rewrite.

Does Bifrost support Anthropic beta headers?

Yes. Bifrost automatically detects and injects the Anthropic beta headers a request requires, and validates them per provider so unsupported headers do not reach the upstream API. Headers such as prompt caching, interleaved thinking, and context management are auto-injected based on request features, and unrecognized beta headers can be added to an allowlist for full compatibility.

Multi-Provider Routing and Failover To and From Claude

Bifrost, the AI gateway for enterprise Claude workloads, routes requests across 1000+ models through the same Anthropic-compatible interface. Using the Anthropic SDK format, a client can address Claude by default and other providers by prefixing the model name:

# Claude (default)
client.messages.create(model="claude-3-sonnet-20240229", ...)

# OpenAI via the same Anthropic SDK format
client.messages.create(model="openai/gpt-4o-mini", ...)

# Google Vertex via the same Anthropic SDK format
client.messages.create(model="vertex/gemini-pro", ...)

This unified access is what makes failover possible. Bifrost provides two complementary resilience layers documented in its retries and fallbacks behavior:

  • Retries: When a provider returns a transient 5xx error or a per-key failure (429, 401, 402, 403), Bifrost retries against the same provider, rotating API keys from the pool and applying exponential backoff with jitter where appropriate.
  • Fallbacks: When the primary provider fails after exhausting retries, Bifrost moves to the next provider in the fallback chain, and each fallback provider receives its own full retry budget.

Teams can configure Claude as the primary model with a secondary provider as fallback, or route to Claude as the fallback when a primary model becomes unavailable. Load balancing across multiple Anthropic API keys distributes traffic to avoid single-key rate limits. Bifrost, an open-source AI gateway built in Go, applies this routing with 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks.

Governance Over Claude Usage

Governance in Bifrost is built on virtual keys, the primary governance entity. A virtual key carries its own access permissions, budgets, and rate limits, and clients authenticate to it using standard headers, including the Anthropic-style x-api-key header that Claude clients already send.

Virtual keys give teams centralized control over Claude usage:

  • Access control: Restrict which providers and models a virtual key can call, so a key can be scoped to specific Claude models only.
  • Budgets: Attach independent dollar budgets with reset periods (1h, 1d, 1w, 1M, 1Y), checked alongside team and customer budgets.
  • Rate limits: Apply token-based and request-based throttling per virtual key.
  • Key restrictions: Limit a virtual key to specific provider API keys.

Because governance is enforced at the gateway rather than distributed across raw Anthropic keys, an organization can issue a per-developer or per-service virtual key, set its budget and rate limit, and revoke it instantly. The governance resource page covers how hierarchical cost control works across virtual key, team, and customer levels. For regulated environments, Bifrost supports audit logs that produce immutable trails for SOC 2, GDPR, HIPAA, and ISO 27001 compliance, and it can be deployed in-VPC for teams that require private cloud isolation.

Semantic Caching for Claude Requests

Bifrost, the AI gateway that fronts Claude, can cache Claude responses and replay them for repeated or semantically similar requests through semantic caching. It offers two complementary lookup paths:

  • Direct (hash) matching: Deterministic exact-match replay. The request is normalized and hashed, and an identical request is served instantly with no embeddings required.
  • Semantic (similarity) matching: Embedding-based lookup that serves a cached answer when a new request is close enough to a previous one, even when the wording differs.

Both modes reduce cost by skipping paid Claude calls for repeated prompts, and reduce latency because cache reads return in sub-millisecond time versus a multi-second provider round-trip. Streamed responses are cached and replayed chunk by chunk, so caching works for streaming Claude output as well.

Pointing Claude Code at Bifrost

Claude Code, Anthropic's terminal coding agent, reads the ANTHROPIC_BASE_URL environment variable at startup and sends every API request there instead of to Anthropic. Setting that variable to Bifrost turns Bifrost into the Claude gateway for the coding agent, and the same failover, governance, and observability apply to agent traffic. Per Anthropic's Claude Code gateway documentation, the gateway must answer in the Anthropic format, which Bifrost does through its /anthropic endpoint.

To route Claude Code through Bifrost, set the base URL to the Bifrost Anthropic endpoint and authenticate with a Bifrost virtual key. Add the following to ~/.claude/settings.json:

"env": {
  "ANTHROPIC_BASE_URL": "<http://localhost:8080/anthropic>",
  "ANTHROPIC_AUTH_TOKEN": "your-virtual-key"
}

Claude Code sends the ANTHROPIC_AUTH_TOKEN value in the Authorization: Bearer header, which Bifrost recognizes as the virtual key for routing and authentication. With this method, no separate Anthropic account login is required because Bifrost handles authentication through the virtual key.

Can Claude Code use models other than Claude through Bifrost?

Yes. Because Bifrost routes across every configured provider, a routing rule can map the model names Claude Code sends to any provider and model in Bifrost. Anthropic does not support or endorse routing Claude Code to non-Claude models, so teams that do this operate it themselves, but the mechanism is available through Bifrost routing rules and dynamic aliasing.

How does Bifrost govern Claude Code usage?

Claude Code traffic authenticates against a Bifrost virtual key, so the same budgets, rate limits, and model-access policies that govern application traffic also govern the coding agent. A per-developer virtual key attributes agent usage to that developer and can be revoked on offboarding, matching the rollout pattern Anthropic recommends for gateway credentials.

Observability for Claude Traffic

Every request routed through Bifrost is logged and can be monitored in real time. The built-in logging dashboard captures Claude application traffic and Claude Code agent traffic in one place, with filtering by provider, model, or conversation content.

For production monitoring, Bifrost, the open-source Bifrost gateway, integrates with standard observability stacks:

  • Prometheus: Native metrics through scraping and Push Gateway.
  • OpenTelemetry (OTLP): Distributed tracing compatible with Grafana, New Relic, and Honeycomb.
  • Datadog: A native connector for APM traces, LLM Observability, and metrics.

Bifrost publishes its observability configuration so teams can route Claude traffic metrics into an existing monitoring pipeline. This unified view is what allows a platform team to track Claude cost, latency, and error rates across every surface that touches the model.

Getting Started with Bifrost as a Claude Gateway

A Claude gateway consolidates routing, failover, governance, caching, and observability for Anthropic Claude models and Claude Code behind one Anthropic-compatible API. Bifrost, the open-source AI gateway built for enterprise AI workloads, implements this through its drop-in /anthropic endpoint, so pointing an application or Claude Code at Bifrost requires only a base-URL change. Teams evaluating gateways can review the LLM Gateway Buyer's Guide and the Bifrost governance resources for capability details.

To see how Bifrost can serve as the Claude gateway for your applications and coding agents, book a demo with the Bifrost team.