Skip to main content

​
Overview

The Barndoor LLM Gateway is a proxy that sits between your AI tools and one or more upstream LLM providers. It speaks the OpenAI API (Chat Completions, Completions, Responses, Embeddings) and the Anthropic Messages API natively, so most clients — the OpenAI and Anthropic SDKs, Cursor, Claude Code, Codex, LangChain, and similar tools — work by pointing their base URL at Barndoor. Pointing your client at the gateway gives you a single endpoint that:
  • Centralizes provider credentials — provider API keys and cloud roles stay in Barndoor, never on developer machines.
  • Enforces governance — token and spending budgets, rate limits, and per-user / per-group model access policies.
  • Routes intelligently — named model routes with ordered fallbacks, automatic retries on upstream 429s, and health-aware failover.
  • Records usage — per-request tokens, cost, and request duration, reported on the LLM Usage Dashboard.
Anything that speaks the OpenAI API can use the gateway by setting its base URL. Clients built on Anthropic’s Messages API (for example Claude Code) talk to the gateway directly as well. See Supported Endpoints.

​
Architecture at a Glance

Your clients
CursorClaude CodeCodexSDKscurl
bd-… API key · OpenAI or Anthropic JSON
Barndoor LLM Gateway
  1. 1AuthenticateBarndoor API key, user and org
  2. 2Rate limits & budgetsRequests, tokens, and spend
  3. 3Model accessAllow and deny policies
  4. 4RouteModel routes, retries, failover
Every request’s tokens, cost, and duration are recorded to the LLM Usage Dashboard
Provider credentials, stored encrypted
OpenAIAnthropicAzure OpenAI / Microsoft FoundryAWS BedrockGoogle Vertex AIGoogle AI (Gemini)xAI (Grok)…and more
Upstream providers

​
Key Concepts

The gateway is configured from a small set of building blocks. Each one references the one above it.

​
Credentials and providers

Credentials and providers are separate on purpose: one set of credentials can back many providers. You might save a single OpenAI key and create two providers from it — one for everyday traffic and one reserved for a specific team — or save one AWS IAM role and create a provider for each Bedrock API family you use. The split follows what each object is responsible for:
  • Credentials hold what authorizes the account: the key or identity, and the account-level location such as the base URL, AWS region, or GCP project. Rotating a key on the credentials updates every provider that uses it.
  • Providers hold how requests are made: the Model API Family (for AWS Bedrock, Google Vertex AI, and Microsoft Foundry), health-check enforcement, catalog model sync, and billing.
Because many providers can share one set of credentials, usage and cost are reported per provider, not per credential.

​
Models and routes

A model has to be enabled on a provider before anything can call it. Once enabled, it is reachable by its provider-prefixed name (for example OpenAI Prod/gpt-5.4-mini, using the provider’s name). A Model Route gives one or more enabled models a single plain name (for example gpt-5.4-mini or team-coding-model) and an order to try them in. If the first target fails with a failover-eligible error, the gateway tries the next. See Model Naming for how the gateway reads the model field, and Failover, Cooldowns, and Route Health for when it moves to the next target.

​
Routing policies

A routing policy is a virtual model name that picks a model per request — routing each request to the cheapest model strong enough for it, from an ordered list of options — and routing rules constrain that choice for particular kinds of request. See Routing Policies.
Routing policies may not be enabled for your organization yet — contact Barndoor if you don’t see Routing Policies in LLM Management.

​
Where Things Live in the Portal

Some sections of LLM Management appear only when the related feature is enabled for your organization:
  • Launch Profiles set the organization’s defaults for governed Claude Code and Codex sessions started with barndoor run. See Barndoor Bridge.
  • Routing Policies and Routing Rules — see Routing policies.
  • In some organizations, the separate Models section is replaced by a Models panel on each provider’s detail page (click the provider’s name on Providers). The controls are the same.
If a section described here is missing, contact Barndoor to have it enabled.

​
Supported Providers

Pick these from Providers → Add Provider. Cards marked Official come from Barndoor’s provider catalog, with default base URLs and model lists pre-filled.

​
Supported Endpoints

All endpoints live under your gateway base URL, https://app.barndoor.ai/api/llm-gateway/v1. For chat-style traffic, the endpoint a client calls and the provider that serves it are independent: for example, a Claude Code request on /messages can be routed to Claude on Anthropic, AWS Bedrock, Google Vertex AI, or Microsoft Foundry. Request examples are in the Quickstart Guide.

​
Authentication

Callers authenticate with a Barndoor gateway API key (bd-…), sent in either header:
  • Authorization: Bearer bd-… — what OpenAI clients send.
  • x-api-key: bd-… — what Anthropic clients send.
When both are present, the gateway reads the key from x-api-key. That lets Claude Code and Codex send the gateway key in x-api-key while passing the developer’s own Claude or ChatGPT sign-in token in Authorization for the OAuth passthrough providers. There are two ways to get a key:
  • Developers create their own under Settings → My Models → API Keys. Usage is attributed to that user.
  • Admins create keys under LLM Management → API Keys, assigned to a user, to a group, or to neither (an organization-wide key, typically for services and CI).
The gateway’s configuration API (the one behind LLM Management) uses your Barndoor login instead of a bd-… key — see the LLM Gateway API.

​
Before You Begin

You’ll need:
  • A Barndoor account with access to LLM Management (admins) and/or Settings → My Models (any user).
  • The base URL of your Barndoor portal. Throughout these guides we use https://app.barndoor.ai (the Barndoor SaaS host). The authoritative value for your tenant is on the LLM Gateway Endpoint card under Settings → My Models → Gateway Endpoint — copy it from there.
  • For admins setting up the gateway for the first time: an account with at least one upstream provider (OpenAI, Anthropic, AWS, Google Cloud, and so on) and credentials for it.
The LLM Gateway is enabled per organization. If you don’t see LLM Management or My Models in the sidebar, contact your Barndoor admin or [email protected] to have it enabled. LLM Management is visible to admins only.
Self-hosted and private-cloud deployments: if Barndoor runs on your own infrastructure, swap app.barndoor.ai for your organization’s portal hostname everywhere in these guides. The path (/api/llm-gateway/v1) is the same.

​
Next Steps

Admins set the gateway up first — continue to the Quickstart Guide, which walks through credentials, providers, models, routes, and keys, then sends a first request. After that, layer on: Developers working against an already-configured gateway can go straight to Connecting Your Tools to the LLM Gateway — getting a key, a model name, and the endpoint, then configuring Cursor, Claude Code, LangChain, and the OpenAI / Anthropic SDKs. For Codex CLI and Codex Desktop specifically, see Use Codex with the LLM Gateway.