Models

Govern which models your employees can reach, how their requests route, and what they cost

Employees point their AI client at Gateway instead of the model provider, so every model request they make arrives somewhere you control. The Models section is where you decide what happens to it.

Four decisions. The first three live on tabs under Models in the Workforce dashboard; spend has its own page under Manage.

DecisionWherePage
Which models employees can reachAll models, Blocklist, Provider keysModel access
How requests route across those modelsRouting policiesRouting
What gets scanned on the way throughDLP, Security alertsModel guardrails
What it may costBudgetBudget

A seventh tab, Advanced, holds the controls that apply to your whole organization at once: vendor regions, zero data retention, request tags, and model migrations. It is still gated, so those settings live in the Gateway console for now. See Advanced.

What an employee’s client needs

Three values, and they are the same three in every AI client.

InputValue
Base URLhttps://api-gateway.merge.dev/v1/openai for OpenAI-compatible clients, https://api-gateway.merge.dev/v1/anthropic for Claude Code and Claude Desktop
API keyA Gateway key, minted per employee by the desktop client or issued per Group
Model nameprovider/model, such as anthropic/claude-opus-5, or default_routing

Prefer default_routing. Model choice then lives in your routing policy rather than in a config file on every laptop, and changing which model a team uses stops being a fleet-wide edit. A request that names a model still gets access checks, guardrails, and budget enforcement; it skips only the routing decision.

Sending an Anthropic client to the OpenAI base URL is the most common setup mistake. Connect employee AI clients covers the per-client values and how they reach a machine.

What a request passes through

Order matters, because it determines which of your controls an employee can and cannot route around.

  1. Access. Blocklist rules and your vendor restrictions drop the models and vendors your organization does not allow. This runs before routing, so no strategy change reaches a blocked model.
  2. Guardrails. The prompt is screened for sensitive data and injection attempts, then redacted, blocked, or recorded according to your rules.
  3. Routing. The Group’s routing policy, or the organization default, picks a model from what is left and a vendor to serve it.
  4. Budget. An exhausted budget refuses the request with a 402 before any provider is called, so a blocked request costs nothing.
  5. Response. The completion is screened on the way back, and the whole request is written to LLM calls with the model, tokens, routing outcome, and cost.

Employees see none of this unless something fires. A refusal comes back as an ordinary API error in whatever client they are using.

Next steps