Routing Claude Code, GitHub Copilot and Cursor through an LLM gateway

Why route coding agents through a gateway at all

A gateway gives you one control point for traffic that otherwise goes straight from every developer laptop to a model provider. Anthropic's Claude Code documentation lists the same benefits most platform teams are after:

• Spend per team: each developer holds a gateway credential, so usage is attributed to a person and team whichever provider serves the request
• A model allow-list: the gateway exposes only the models you have approved and priced
• Revocation in one place: the provider key stays on the server, and offboarding means revoking one gateway credential
• Provider and region choice: the gateway can forward to Claude on Amazon Bedrock, Google Cloud or Microsoft Foundry in your own cloud account, and you can switch without reconfiguring developer machines
• An audit log of model requests, where your policies require one

Switching providers without touching laptops only works if the gateway exposes one Anthropic-format endpoint whatever sits behind it. The price is that the gateway becomes infrastructure you operate. Anthropic warns that Claude Code adds capabilities with each release and that a gateway which does not forward them breaks those features, so someone has to keep it current. Our view is that one team on one provider with no audit requirement can often manage with separate provider workspaces or keys. A gateway starts to pay off once several teams, several tools or a residency requirement come into play.

Which coding agents support a gateway, as of 7 November 2026

Only Claude Code lets you send all of its model traffic through your own gateway and enforce that centrally. GitHub Copilot and Cursor let you bring provider keys or endpoints for part of the product, and their own models stay in use for the rest.

GitHub Copilot bring your own key

GitHub runs two mechanisms. Enterprise BYOK, for Copilot Business and Copilot Enterprise and still in public preview, lets enterprise or organisation owners add keys that every user then sees at the bottom of the model picker. In January 2026 GitHub added AWS Bedrock, Google AI Studio and any OpenAI-compatible provider, plus Responses API models, a maximum context window and streaming. That OpenAI-compatible option is the route to a LiteLLM endpoint. Local BYOK keys stay on the user's machine. GitHub's April 2026 announcement for VS Code says usage is billed by your provider, does not count against Copilot request quotas, and does not apply to code completions.

GitHub describes enterprise BYOK as handled server-side, through the Copilot API, and does not document the data path. Our reading is that the requests to your endpoint then come from GitHub's side rather than from the developer's laptop, so confirm the network requirements with GitHub before you plan a gateway that is only reachable internally.

Cursor with your own API keys

Cursor's help page on API keys lists OpenAI, Anthropic, Google, Azure OpenAI and AWS Bedrock, with Bedrock access through keys in the IDE or IAM roles set up in the Cursor dashboard. Own keys only work with chat models, and Tab completion keeps using Cursor's built-in models. Requests are routed through Cursor's servers for final prompt building. The key is sent with each request and not stored. Cursor's Zero Data Retention policy does not apply when you use your own keys, and own-key requests on Teams and Enterprise plans carry a Cursor fee on top of the provider's charges. The page does not document a custom base URL. In practice, own keys let you bill usage to your Azure or Bedrock account, but the traffic still leaves your network.

Setting up Claude Code with LiteLLM or another gateway

Claude Code needs a base URL and a credential. ANTHROPIC_BASE_URL points it at a gateway that serves the Anthropic Messages format at /v1/messages, which LiteLLM does. The credential goes in ANTHROPIC_AUTH_TOKEN if the gateway reads an Authorization bearer token, which is how LiteLLM virtual keys are sent, or in ANTHROPIC_API_KEY if it reads x-api-key. For keys that rotate or come from a vault, an apiKeyHelper command prints the credential and Claude Code sends it in both headers. The output is cached for five minutes by default, and CLAUDE_CODE_API_KEY_HELPER_TTL_MS changes that.

Distribute both through managed settings and your secrets tooling, never through the repository. Anthropic warns against putting a credential in a project's .claude/settings.json because that file is committed. To make the gateway the only destination a managed machine may use, the managed settings file sets allowedProviders and the base URL together:

{
  "allowedProviders": ["customEndpoint"],
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm-gateway.example.com"
  }
}

Claude Code then refuses a session pointed anywhere else, including Anthropic directly or a developer's own proxy. If the gateway speaks the native formats of Amazon Bedrock or Google Cloud's Agent Platform, formerly Vertex AI, use ANTHROPIC_BEDROCK_BASE_URL with CLAUDE_CODE_USE_BEDROCK=1 and CLAUDE_CODE_SKIP_BEDROCK_AUTH=1, or the VERTEX equivalents. Claude Code then sends only the features those providers accept. Microsoft Foundry uses ANTHROPIC_FOUNDRY_BASE_URL with CLAUDE_CODE_USE_FOUNDRY=1.

Three details catch teams out. A gateway credential replaces the developer's claude.ai subscription for those requests, so the traffic is billed per token to whoever owns the upstream key. Setting only the base URL leaves the subscription login in use. The VS Code extension reads gateway variables from claudeCode.environmentVariables, and the desktop app reads them from its own third-party inference configuration rather than from ANTHROPIC_BASE_URL. And Anthropic does not support routing Claude Code to non-Claude models through any gateway, even where a gateway makes it technically possible.

What the gateway sees, what to log and what not to keep

The gateway sees everything the agent sends to the model: the system prompt, the conversation, source code and file contents the agent has read, command output and tool results. A secret in a file the agent opens can therefore pass through it. Claude Code also sends headers that help with attribution: x-claude-code-session-id groups the requests of one session, and x-claude-code-agent-id marks requests from subagents. Anthropic points out that the agent ID identifies an agent and says nothing about a person or a device.

For cost and operations, metadata is enough. A useful record per request holds:

• The gateway key and the team and developer it belongs to
• The model requested and the model that served it, including any fallback
• Input, output, cache read and cache write tokens, and the computed cost
• Status code, latency and time to first token
• Session and agent IDs from the request headers

Keep request and response bodies out of storage unless a written purpose requires them. LiteLLM's documentation says it does not track request and response content by default. store_prompts_in_spend_logs turns that on, and an admin can also change it in the UI, where it overrides the config file. maximum_spend_logs_retention_period deletes old spend logs, and turn_off_message_logging keeps messages away from external logging callbacks while spend is still tracked. Per-developer usage records are personal data, so agree their purpose and retention with your data protection owner and, if you have one, your works council before go-live.

Not every request goes through the gateway. While ANTHROPIC_BASE_URL points at it, Claude Code still sends telemetry to Anthropic, without your gateway credential, and the WebFetch domain safety check calls api.anthropic.com directly. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 turns off the nonessential traffic, but it also disables auto-updates, so plan another update path.

Budgets and rate limits per team without slowing engineers

Put the hard limit on the team and keep per-developer limits generous. Agent sessions are bursty: one task can start several subagents in parallel, each sending a large prompt. A tight requests-per-minute limit on a key therefore stops real work long before it protects the budget. This is our own judgement from the shape of the traffic. In LiteLLM the controls are:

• Per team: max_budget with budget_duration for a regular reset, and team_member_budget as a default for each member
• Per key: max_budget, budget_duration, rpm_limit, tpm_limit and max_parallel_requests, with budget_limits for several windows on one key, such as a daily and a monthly cap
• Per model: model_max_budget, which the documentation marks as an Enterprise feature

Two operating details decide whether the limits hold. Budgets need a Postgres database to be enforced at all. With more than one worker or replica, LiteLLM highly recommends Redis: without it, rate limits are counted per worker, budgets can overshoot, and a revoked key stays usable on workers that did not process the revocation until their cache entry expires. Then decide what an engineer experiences at the limit. An unexplained error in the middle of a task costs more working time than the tokens it saves, so alert the team below the hard cap and publish who can raise a budget.

Common failure modes and how to recognise them

Most problems come from a gateway that changes the request or the response on the way through. Anthropic's gateway protocol reference and troubleshooting table describe these, among others:

Check prompt caching separately, because a broken cache costs money without raising an error. Compare cache read tokens per session before and after the gateway goes in. On Claude Code versions before v2.1.181, an attribution block that changed on every request also defeated caches keyed on the request body. Anthropic's protocol reference describes CLAUDE_CODE_ATTRIBUTION_HEADER=0 for that case.

A short rollout checklist

Roll out in this order, and test each step with a real agent session rather than a single curl request:

1. 1

   Decide the scope

   List which tools and surfaces must use the gateway. The Claude Code CLI, the VS Code extension and the desktop app can. Claude Code in Slack and cloud sessions cannot, and Copilot and Cursor only partly. Do not enable anything that must not bypass the gateway.

2. 2

   Deploy and harden the gateway

   Pin the gateway version, run Postgres for budgets and Redis for more than one worker, and set log retention before the first request.

3. 3

   Define models and names

   Publish the allow-list with the exact model IDs each tool sends, and map those IDs in the gateway.

4. 4

   Issue one credential per developer

   Tie each key to a team, set team budgets and generous per-key limits, and test revocation against every replica.

5. 5

   Distribute configuration centrally

   Ship the base URL, the credential mechanism and allowedProviders through Claude Code managed settings, and set the Copilot BYOK policies in GitHub's enterprise or organisation settings.

6. 6

   Run an acceptance session

   Check streaming, tool calls, subagents, cache reads and a budget breach from a test team before inviting everyone, and have each developer confirm the gateway URL in /status.

7. 7

   Re-test on every upgrade

   Claude Code changes what it sends with each release, so repeat the acceptance session before upgrading the gateway or allowing a new client version.

Cloudsail sets up and runs LiteLLM gateways for engineering teams and rolls out Claude Code against them, including managed settings, team budgets and the acceptance session described above.

LiteLLM gateway setup and operationLLM cost optimisationClaude Code permissions and rollout