Roll out models

Applies to: Merge Gateway

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. What you are choosing is how that configuration reaches the machine, and what happens when someone changes it back.

There are two ways, and most companies run both: the desktop client for the fleet, and self-setup for whatever it has not reached yet.

Governance is the reason to do this: 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 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 right answer, and both the desktop client and the Workforce CLI do it. Spend attributes to the person, and there is no key for you to distribute. The client refuses to mint until the device resolves to an employee.
• Project key per team. The project’s routing policy and budget apply with nothing else to configure. Use this for self-setup, where there is no client to mint anything.
• Organization key, shared. No per-person attribution and no per-team budget. Fine for a pilot, not for a fleet.

Any key that lands on a laptop can be read by the person using it. That is the argument for per-employee minting, and for project keys over an organization key when you do hand one out: a leaked project key is scoped to one budget and policy, and rotates without touching the fleet. Never distribute an organization key that also has Management API access.

Compare the two paths

A reasonable default: the desktop client for the fleet, and self-setup for Cursor and for 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 provisions the governed AI stack, mints each employee’s Gateway key, and reports what AI tooling is 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. Every AI client except Cursor. Each of them keeps its settings in a home-directory file or a preference domain that a process on the machine can write.

Path 2: self-setup

Employees configure their own tools. This is how you cover Cursor, and anything the desktop client has not reached yet.

Remove the two things that actually stop people:

1. Give them credentials they do not have to ask for. For employees comfortable in a terminal, the Workforce CLI is cleaner: 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 put a team’s project API key where that team already looks.
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 this is working. 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 own config, and you will not know, because a client that is not routing produces no telemetry. Absence of traffic looks the same as absence of work.

Client coverage

Covered by the desktop client. Claude Code, Codex CLI, Codex desktop app, Claude Desktop, Zed, Continue.dev, OpenCode, Pi, and Factory Droid. Self-setup covers the same nine.

Not covered on any path. Cursor, and only Cursor. Its base URL and API key are entered through the GUI and held in encrypted local application state, so there is nothing for either path to write. Restrict it through Cursor Business or Enterprise team admin settings, or block the provider endpoints at your network. 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.

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.

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

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. The desktop client reverts it at its next check, which makes compliance the default and drift reversible, not 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 never routes on a managed path, and its agent mode and Tab never route at all. All of that is Cursor-side.
• Coverage is not enforcement. Until direct provider endpoints are blocked, a routed client is one that is currently choosing to route.

Next steps