Model Access

Model access is the part that decides which models your org may use and how. The path is the same for every model:

1. Connect a provider once.
2. Install the models you want from the marketplace, for the org or for one project.
3. Adjust the grant if you want to narrow the auth modes, efforts or projects.
4. Point stages and cards at them. See Choosing Models.

You never need a profile for each model and effort combination. A profile is an optional constraint on top.

TermsCopy Anchor Link

Connect a providerCopy Anchor Link

Open Settings, then Integrations. There is one tile per provider kind, including gateway providers such as Vercel AI Gateway. Enter the provider's key and save.

Connecting a provider does two things:

• It links the provider to models you have already installed, so an entry that was waiting for a provider becomes ready.
• It makes that provider's catalog models available to install.

Right after an LLM provider connects, the page offers Install featured provider models (n), which installs the provider's featured models in one step, and Choose…, which opens the marketplace filtered to that provider.

Which models are available to youCopy Anchor Link

A model is available to your org when at least one provider serving of it can run under at least one auth mode:

If the metered entitlement cannot be read, metered is treated as unavailable. It never defaults to allowed. The marketplace shows each model's Available via modes.

The marketplaceCopy Anchor Link

Open the Marketplace and choose Models. Org admins can install; other members and every project view are read-only.

• Featured first. Models an operator has featured sit in a Featured band at the top.
• Search. Type in the search box. The server searches display name, model id, canonical name and provider. You can also filter by provider, by capability tag such as tools, and by whether your org can run the model now.
• Load more. Results load 50 at a time (at most 100 per request), with Load more for the rest. The price limit and the sort order apply only to the models loaded so far, and the page says so.
• Status. Each card shows whether an installed model is ready, needs a provider, or needs attention.

One card represents one model, even when several providers serve it.

Install for the orgCopy Anchor Link

Select Install for org on a card. Org admins only. If more than one of your providers can serve the model, a chooser lets you pick which provider is primary and which are fallbacks.

If no provider can serve the model for your org, the install is refused with model_not_available, and nothing is created. Connect a provider first. A model an operator has withdrawn cannot be installed.

Install allCopy Anchor Link

Install all installs a provider's featured models, or a list you choose, in one request. It is bounded: there is no "install everything from this gateway".

POST /api/marketplace/models/install-batch

{ "provider": "vercel-gateway", "selection": { "kind": "featured" } }

or, for chosen models:

{
  "provider": "vercel-gateway",
  "selection": { "kind": "ids", "catalogIds": ["<catalog-id>", "<catalog-id>"] }
}

• At most 50 ids per request. If a provider has more than 50 featured models, the request is refused with too_many_featured and nothing is installed; use Choose… instead.
• Each model installs on its own, and the response reports one result per model: installed, already_installed, unavailable or failed. One failure does not undo the others.
• Every installed model gets the full set of efforts and the auth modes your org can actually run it with.
• Each created entry writes one audit event. The events from one request share a bulk operation id so they can be read back together.
• It needs an org admin signed in as a person. An API key cannot install models.

Install for a projectCopy Anchor Link

An install can be scoped to one project by passing projectId:

POST /api/marketplace/models/{id}/install

{ "projectId": "<project-id>" }

• If the model is not installed yet, a new entry is created that includes only that project.
• If it is already installed, the entry gains that project, and nothing else about the grant changes. A project install can never widen what the org admin set for other projects.
• projectId cannot be combined with grant.includedProjectIds.
• It still requires an org admin. The install-batch request accepts projectId the same way.

The Marketplace opened from inside a project lists models for reading but has no install button, so project installs go through the API for now.

Auth modes and grantsCopy Anchor Link

An entry carries the org's grant: which auth modes it may run under, which efforts, and which projects. A new entry starts open: every auth mode a serving offers, all efforts (including future ones), and all projects.

To start narrower, pass a grant when you install:

{ "grant": { "authModes": ["byok"], "efforts": ["low", "medium", "high"] } }

Every mode and effort must be offered by a live serving of the model, and metered also needs your org's entitlement.

Edit a grantCopy Anchor Link

Open Settings, then Models. Each installed model shows what it permits, and org admins can change it:

Select Save grant. Switching from all projects to selected projects requires you to name the included projects in the same save. Grant changes are audited, and saving an unchanged grant writes nothing.

A project can narrow what the org permits, for that model only: which auth modes, which efforts, whether the project is included, or whether it is disabled entirely.

PUT /api/org/{orgId}/model-library/entries/{entryId}/projects/{projectId}

{ "included": true, "disabled": false, "authModes": ["byok"], "efforts": null }

null for authModes or efforts means no narrowing. included matters only when the entry's project scope is selected, and disabled denies the project under either scope. Both routes are for org admins.

Warnings on an installed modelCopy Anchor Link

Who can do whatCopy Anchor Link

Withdrawn modelsCopy Anchor Link

An operator can withdraw a model so that no org can see or install it, and can restore it later. Withdrawing is not deprecating, and it never breaks a working setup:

• The model disappears from the marketplace and cannot be installed again.
• Existing installs keep running. Settings shows the entry with "withdrawn from the catalog (still runs)" and the entry warning above. Runs on it carry a warning on the receipt.
• A follow selection skips withdrawn models. A pinned selection on one keeps working.

If a model you depend on is withdrawn, pin or follow a replacement, or ask your platform operator whether it will be restored.

OperatorsCopy Anchor Link

Platform operators curate the catalog: they can import many models from a gateway at once, feature a subset so it shows first in every org's marketplace, and withdraw or restore models. See the operator Model Catalog reference.

Related pagesCopy Anchor Link

• Choosing Models
• Model Catalog and Routing
• Auth Modes
• Providers