Roll out models

Applies to: Merge Gateway

Pointing one machine at Gateway takes two minutes: a base URL, an API key, and a model name. Pointing every machine at it means deciding how that configuration reaches each machine, and what happens when someone changes it back. There are two paths, and most companies run both: the desktop client for the fleet, and self-setup for everything the client does not reach.

Governance is why you do this: routing policies, spend caps, model restrictions, and a per-person request log. Employee experience is why it lasts. A rollout that takes tools away pushes the work to personal accounts, where you see none of it.

Decide the inputs once

Every AI client asks for the same three values.

Choose your key strategy first

The key decides who gets attributed and which budget applies.

• Per-employee, provisioned automatically. The best option. The desktop client and the Workforce CLI both do it, spend attributes to the person, and there is no key to hand out. The client only mints a key once the device resolves to an employee.
• Project key per team. The project’s routing policy and budget apply automatically. Use this for self-setup, where nothing mints keys for you.
• Shared organization key. No per-person attribution and no per-team budget. Fine for a pilot, not for a fleet.

Anyone can read a key that lands on their laptop. A leaked project key is limited to one budget and policy and rotates without touching the fleet, which is why project keys beat an organization key. Never hand out an organization key that also has Management API access.

Compare the two paths

A good default: the desktop client for Claude Code and Codex CLI, and self-setup for every other client and anyone the client has not reached yet.

Path 1: the Merge desktop client

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

The client routes Claude Code and Codex CLI, the two clients whose Gateway settings it writes today. Route the rest, including Claude Desktop, Zed, OpenCode, and Factory Droid, with self-setup.

Connect Gateway also tags each request with the tool that sent it, in an X-Merge-Harness header (claude_code or codex_cli). LLM calls shows it as Harness in the request detail. Tools connected on an older client version get the tag the next time Connect Gateway runs. The client reports the value itself, so treat it as a strong hint, not proof.

Disconnect removes the Gateway settings the client wrote, including that tag, so the tool calls its AI provider directly again. It keeps any personal API key the employee added since, and it does not revoke the Gateway key. That key stays valid until it expires, and the next Connect Gateway mints a new one.

Path 2: self-setup

Employees configure their own tools. Use this for every client beyond Claude Code and Codex CLI, and for any machine the desktop client has not reached yet. Two things make it work:

1. Credentials they do not have to ask for. Terminal users can use the Workforce CLI: they sign in with your identity provider, get a per-device credential, and spend still attributes to them. Everyone else gets their team’s project API key, posted where that team already looks.
2. One link, not a wiki page. Every client has a setup guide that takes about five minutes.

Then check the Gateway dashboard to see who is actually routing. A team still flat after two weeks needs the desktop client, not another reminder.

Self-setup gives you coverage, not control. Anyone can stop routing by editing their config, and you will not know: a client that is not routing sends no telemetry, so no traffic looks the same as no work.

Client coverage

• Desktop client: Claude Code and Codex CLI
• Self-setup: all nine clients with a setup guide: Claude Code, Codex, Claude Desktop, Zed, Continue.dev, OpenCode, Pi, Factory Droid, and Cursor in part
• Neither: Cursor. It stores its base URL and API key in encrypted app state entered through its GUI, so neither path can write them. Its agent mode does not accept a custom API key at all, so even a hand-configured Cursor routes only Ask and Plan traffic, and Tab autocomplete never routes. Restrict it through Cursor Business or Enterprise admin settings, or block the provider endpoints at your network

Verify the rollout

Pushed configuration is not routed traffic. Check all three:

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

Finish all three on a canary group before widening. Configuration that landed everywhere but shows traffic from four people is being bypassed.

Limits to tell your security team

• Everything short of network blocking is client-side. Anyone can edit their config, and Disconnect does it in one click. Until enforcement is in force, the client does not revert changes, so treat routing as opt-in today.
• Only server-side controls cannot be bypassed from the laptop: Gateway’s authentication and your network egress policy. An unmanaged config cannot mint a Merge key.
• Cursor never routes on a managed path, and its agent mode and Tab never route at all.
• Coverage is not enforcement. Until direct provider endpoints are blocked, a routed client is one currently choosing to route.

Next steps