Roll out Gateway to your fleet

Pointing one machine at Gateway takes two minutes: a base URL, an API key, a model name. Pointing every machine at it is a different problem, and what you are really choosing is how that configuration reaches the machine and what happens when someone changes it back.

There are three ways. They are not mutually exclusive, and most companies run two: a managed path for the clients that support it, and voluntary setup for the rest.

Governance is the reason to do this. Once traffic runs through Gateway you get routing policies, spend caps, model restrictions, and a per-person request log. Employee experience is the reason it lasts. A rollout that takes tools away, or makes people fight their own config, moves the work to personal accounts on personal machines, where you see none of it.

Decide the inputs once

Every AI client asks for the same three values. Settle them at the organization level and each path below becomes a delivery problem rather than a design problem.

Choose your key strategy first

The key decides who gets attributed and which budget applies.

• Organization key, shared. One key for everyone. Fast, and you get no per-person attribution and no per-team budget. Fine for a pilot, not for a fleet.
• Project API key per team. Create a project per team and push its key to that team’s machines. The project’s routing policy and budget apply automatically with nothing else to configure. This is the right answer for the MDM and voluntary paths.
• Per-employee key, provisioned automatically. The desktop client and the Workforce CLI both do this. The desktop client mints a key scoped to the signed-in employee’s billing project, so spend attributes to the person rather than the team, and it refuses to mint until the device is attributed to a resolved employee. The CLI mints a credential per device off the employee’s own sign-in, so there is no key for you to distribute.

If per-person spend attribution is a requirement, the desktop client and the Workforce CLI are the two paths that give it to you without minting and distributing keys by hand.

Compare the three paths

A reasonable default: your own MDM for Claude Desktop, since it has native support and covers the largest non-technical population; the desktop client for the engineering fleet; voluntary for the long tail.

Path 1: the Merge desktop client

The client is a background service you deploy through your MDM. It provisions the governed AI stack, mints each employee’s Gateway key, and reports what AI tooling is actually installed. It needs an MDM-managed fleet, because several of the macOS permissions it uses can only be granted by a configuration profile.

What the client covers. It routes Claude Code and Codex CLI. Every other AI client it finds is reported to you as a device finding with remediation steps rather than switched automatically, because the rest keep their base URL in a GUI or an OS keychain where no config file can reach it.

Path 2: your own MDM

No Merge client on the machine. Your MDM writes each client’s own configuration, the same values a developer would set by hand. What is possible depends entirely on where the client keeps its settings.

The rest of this section is the summary. Deploy with your MDM is the full guide: the delivery mechanism for each client, a worked re-assertion script, and how the payload maps onto Jamf, Intune, Mosyle, Workspace ONE, and Group Policy.

Native MDM support

Claude Desktop is the best-supported client by a wide margin, and it covers Chat, Cowork, and the built-in Claude Code surface. Configure one machine through Developer → Configure Third-Party Inference, then use the app’s Export button to produce a ready-to-deploy .mobileconfig or .reg. The keys:

1
{
2
  "inferenceProvider": "gateway",
3
  "inferenceGatewayBaseUrl": "https://api-gateway.merge.dev/v1/anthropic",
4
  "inferenceGatewayApiKey": "mg_your_key",
5
  "inferenceGatewayAuthScheme": "bearer",
6
  "modelDiscoveryEnabled": true
7
}

Leave discovery on and the picker populates itself from Gateway at launch, so new models appear without a config change. Before you push this, confirm your vendor and region restrictions leave at least one callable route for the models the app will pick: its connection test sends a real inference request and fails if the model it chooses has no allowed vendor. Full setup in the Claude Desktop guide.

Environment variables

Claude Code is configured entirely by environment variables, which your MDM can set with a profile or a login script:

$
export ANTHROPIC_BASE_URL="https://api-gateway.merge.dev/v1/anthropic"
$
export ANTHROPIC_AUTH_TOKEN="mg_your_key"
$
export ANTHROPIC_API_KEY=""
$
export ANTHROPIC_DEFAULT_OPUS_MODEL="default_routing"
$
export ANTHROPIC_DEFAULT_SONNET_MODEL="default_routing"
$
export ANTHROPIC_DEFAULT_HAIKU_MODEL="anthropic/claude-haiku-4-5-20251001"

ANTHROPIC_API_KEY must be explicitly empty. If it is set to anything, Claude Code prefers it and bypasses Gateway, which is the most common silent failure in a fleet rollout. Setting the tier variables to default_routing hands model choice to your routing policy; leaving the haiku tier pinned keeps Claude Code’s frequent background tasks cheap and predictable.

Zed, OpenCode, Pi, and Factory Droid also read their key from MERGE_GATEWAY_API_KEY, so the same mechanism delivers the credential for all of them.

Configuration file drops

These clients read a file in the user’s home directory, which your MDM writes with a script on its check-in cycle. The files are user-owned, so an employee can edit them between runs and the script re-asserts on the next one.

Not deployable

Cursor cannot be configured this way. Its base URL override and API key are entered through the GUI and held in encrypted local app state. Your options are the Cursor Business or Enterprise team admin settings, or network policy. Separately, Cursor’s Agent mode does not accept custom API keys at all, so only Ask and Plan modes route through Gateway on any path.

Path 3: voluntary adoption

Employees configure their own tools. This is the fastest way to cover the clients the other two paths cannot reach, and it is how most companies should handle their long tail.

Remove the two things that actually stop people:

1. Give them credentials they do not have to ask for. Where employees are comfortable in a terminal, the Workforce CLI is the cleaner option: they sign in against your identity provider and get a per-device credential, so there is no key for you to hand out and spend still attributes to the person. Otherwise create a project per team and put its project API key where the team already looks, and the project’s routing policy and budget apply automatically.
2. Send one link, not a wiki page. Every client has a dedicated setup guide, each about five minutes end to end

Then measure it. The Gateway dashboard shows who is actually routing, which is the only number that tells you whether voluntary adoption is working. If a team stays flat after two weeks, that is the signal to move them onto a managed path rather than send another reminder.

Voluntary gives you coverage, not control. Anyone can stop routing by editing their own config, and you will not know, because a client that is not routing produces no Gateway telemetry. Absence of traffic looks the same as absence of work.

Client coverage

Verify the rollout

Configuration pushed is not traffic routed. Check all three:

1. The Gateway dashboard. Requests appear within a few seconds. This is the only source that proves traffic is flowing, and it needs nothing on the endpoint.
2. The client’s own check. Claude Code’s /status should report Auth token: ANTHROPIC_AUTH_TOKEN and the Gateway base URL. Claude Desktop’s Test connection runs discovery and a real inference request.
3. Coverage, not only success. Compare who is routing against your employee list. The fleet view does this for you, including devices that enrolled but never resolved an identity.

Limits worth stating up front

Tell your security team these before they find them:

• Every path short of network blocking is client-side. Someone with local admin can edit a config file inside your MDM’s check-in window. Managed configuration makes compliance the default and drift visible and reversible. It does not make bypass impossible.
• The controls that cannot be bypassed from the endpoint are server-side: Gateway’s own authentication and your network egress policy. An unmanaged config cannot mint a Merge key.
• Cursor Agent mode and Cursor Tab never route through Gateway, on any path. That is a Cursor-side restriction.
• Coverage is not enforcement. Until direct provider endpoints are blocked, a routed client is a client that is currently choosing to route

Next steps