Provider access

Organizations created on or after an access-gated provider’s cutoff need access enabled before calling its models. Gating follows the model’s author, so it covers every host, including the provider’s own API and Amazon Bedrock.

Which providers are gated

Every other provider is ungated.

Who has access

Gating covers every model ID starting with the provider’s slug: anthropic/claude-sonnet-4-5-20250929 is gated on Anthropic and Bedrock, but meta/llama-3.1-70b-instruct or Amazon Nova on Bedrock aren’t. Vendor restrictions, by contrast, filter on the host.

Gated models stay visible. Model Explorer labels them Requires access, and each GET /v1/models entry carries access_required (true or false) and access_reason ("vendor_access_required" or null).

How requests behave without access

A request that names a gated model directly returns 403:

{
  "error": {
    "type": "blocked_by_policy",
    "code": "vendor_access_required",
    "message": "Anthropic models are not enabled for this organization. Contact support@merge.dev, or use the in-app chat, to request access."
  }
}

Branch on code, not the message. These requests are logged as blocked, not as errors, so they don’t count toward your error rate.

Under a routing policy or default_routing, gated candidates are skipped and the next permitted model serves. Only a policy whose every candidate is gated returns the 403.

Saving configuration

Saving a gated model to a routing policy (any scope), a model alias, or a migration candidate returns a 400 naming the model, the provider, and how to request access. A migration baseline may always be gated, so you can migrate off a provider you lost access to.

Requesting access

Use the in-app chat or email support@merge.dev with the provider, models, and expected volume. A grant applies org-wide with no change on your side: 403s stop, the Requires access label disappears, and the models become saveable.

Next steps