Skip to content

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:

ZoneWhat lives thereCredential in play
Developer machinesThe CLI, the VS Code extension, any SDK scriptA per-developer gateway credential
Your infrastructureThe gateway: sign-in, usage records, budgets, routingThe gateway checks the developer credential
Model providerAnthropic API, Amazon Bedrock, Google Cloud, Microsoft FoundryOne 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 /login and 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_TOKEN for 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 /model or the variables in Model configuration. Claude apps gateway can narrow the options with a per-group availableModels allowlist, 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_TRAFFIC to 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_TELEMETRY through 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_PROXY sits 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 to NO_PROXY so the CLI connects directly.

Where to go next