Run Claude Code through a gateway
What a model gateway does for an organisation, how Claude apps gateway compares with a gateway you already run, and what a gateway does not control.
A gateway is a proxy that your organisation operates between every copy of Claude Code and the model provider. Instead of each developer holding a provider key, Claude Code talks to the gateway with a credential the gateway issued, and the gateway makes the upstream call with a single credential your organisation owns. That gives you one place to authenticate people, attribute usage, cap spend and keep an audit trail.
You have two routes. Claude Code ships its own self-hosted gateway, Claude apps gateway, inside the claude binary, so you do not need to buy or run a separate product. If you already operate an LLM gateway or API gateway, Claude Code can use that instead.
The request path
Picture three zones:
| Zone | What lives there | Credential in play |
|---|---|---|
| Developer machines | The CLI, the VS Code extension, any SDK script | A per-developer gateway credential |
| Your infrastructure | The gateway: sign-in, usage records, budgets, routing | The gateway checks the developer credential |
| Model provider | Anthropic API, Amazon Bedrock, Google Cloud, Microsoft Foundry | One organisation credential held by the gateway |
A request leaves the developer's machine addressed to the gateway. The gateway works out who sent it, applies any access and budget rules, and forwards it upstream using the organisation's credential. Which provider sits upstream is a gateway setting. If the gateway presents one Anthropic-format endpoint to clients (Claude apps gateway always does), you can move from, say, the Anthropic API to Bedrock without touching a single laptop.
So there are always two kinds of credential:
- Developer credential. One per person, issued by the gateway. It proves who they are to the gateway and is the key for usage attribution. Offboarding someone means revoking one credential.
- Provider credential. One for the whole organisation, stored only on the gateway. Every forwarded request is billed to the account behind it.
Choosing a gateway
Claude apps gateway
This is Anthropic's gateway, run from the same claude binary your developers use. Its main traits:
- Upstreams: Amazon Bedrock, Claude Platform on AWS, Google Cloud, Microsoft Foundry, or the Anthropic API.
- Sign-in: developers run
/loginand authenticate with your corporate identity provider in the browser. - Policy: model access and managed settings are applied per IdP group.
- Telemetry: usage metrics go out over OTLP to your own observability stack, as described in Monitoring usage.
- Compatibility: it is built and tested with each Claude Code release, so it already forwards every header and request field the CLI sends. There is no forwarding list for you to maintain.
A handful of features behave differently in a gateway session; the Claude apps gateway page lists them.
The one gap to plan for: sign-in is an interactive browser SSO step and there is no service-token flow. A CI runner with nobody to approve the login cannot authenticate through it, so point pipelines at your provider directly (see GitHub Actions and GitLab CI/CD). On a machine where a developer has signed in, though, Agent SDK sessions and claude -p runs reuse that gateway session and are governed by its policies.
A gateway you already run
If there is already an LLM gateway in your estate, Claude Code works with it as long as it exposes a supported API format. Two caveats: Anthropic does not endorse, maintain or audit third-party gateway products, and routing Claude Code to non-Claude models through any gateway is not supported. Because that gateway is versioned separately from Claude Code, someone has to keep its header and field forwarding rules current as Claude Code changes. Other LLM gateways covers the rollout checklist and what the gateway must implement.
My rule of thumb: if you do not already have a gateway with an owner and an upgrade cadence, start with Claude apps gateway. If you do, and finance already reports from it, keep it and follow the compatibility guide.
Subscriptions and billing
Once a developer is using a gateway credential, their traffic is billed at API rates to the account behind the gateway's provider credential. Their personal claude.ai subscription is neither used nor charged. Two things count as a gateway credential here:
- setting
ANTHROPIC_AUTH_TOKENfor a gateway you operate, or - signing in to a Claude apps gateway with
/login.
Either one switches off subscription login for that session.
The exception catches people out. If only ANTHROPIC_BASE_URL is set, with no gateway credential, requests still travel through the gateway but a saved claude.ai login remains the active credential, so subscription limits and billing apply. Other LLM gateways explains that set-up and the header the gateway must forward for it to work.
What a gateway does not control
A gateway decides where model requests go. Several neighbouring concerns are configured elsewhere:
- Model choice. Developers still pick a model with
/modelor the variables in Model configuration. Claude apps gateway can narrow the options with a per-groupavailableModelsallowlist, but the developer chooses within it. - Non-model traffic. Version checks and downloads go straight to Anthropic, not through the gateway. Allow the domains listed in Network configuration, or set
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICto turn off the optional streams. - Client analytics with Claude apps gateway. Claude Code switches off its Anthropic-bound analytics once a session signs in to the gateway. To suppress the startup analytics sent before sign-in too, push
DISABLE_TELEMETRYthrough client-side managed settings on each device (see Claude apps gateway configuration). - Client analytics with other gateways. Whether the optional telemetry stream is sent depends on the provider; Data usage has the defaults per provider.
- Where telemetry is exported. For gateway sessions this depends on how the session signed in; Claude apps gateway explains which exports go where.
- Corporate HTTP proxies.
HTTPS_PROXYsits between Claude Code and everything it talks to, the gateway included, so configure it separately (Network configuration). For a self-hosted Claude apps gateway, sign-in checks that the proxy host is also on a private network. If it is not, add the gateway host toNO_PROXYso the CLI connects directly.
Where to go next
- Running Anthropic's gateway: start with Claude apps gateway, then deploy it.
- Using your own gateway: read Other LLM gateways and the compatibility guide.
- Planning the wider rollout: Set up Claude Code for your organisation.