Skip to main content
Which AI models are available is decided only by the platform admin through the model catalog (models.enabled at /admin/models). There is no tenant-level override. On top of that global switch, the platform admin can allow or block individual models for a single user — useful for sales trials, beta access, or targeted restrictions.

​
How it works

Open a user at /admin/users/[id] and use the Model access section. Every model in the catalog has three states: The effective availability for a user is: the per-user override if one exists, otherwise the global catalog switch. A user’s assistant editor dropdowns (GET /api/models) and the server-side validation on save both respect the assistant owner’s overrides. The same user page also provides one personal default for Pipeline, Realtime, and Half-cascade. Each dropdown only includes catalog entries compatible with that mode. Use global default removes the personal row. These defaults apply whether or not the workspace has SLA; SLA is required only to pin a different model on an individual assistant. Resolution always uses assistants.created_by, not whichever team member is currently editing the assistant.
This is a platform-admin-only capability. It is not exposed on the public v1 API or MCP — only the admin endpoints below can read or change it.

​
Admin API

Both endpoints require a platform admin (requirePlatformAdmin); impersonation is ignored. GET /api/admin/users/{id}/models — returns the full catalog grouped by type (llm/stt/tts/realtime). Each model carries:
  • global_enabled — the catalog switch
  • override — null (follows global), true (allow), or false (block)
  • effective — the resulting availability for this user
PUT /api/admin/users/{id}/models with a body of overrides:
Set enabled to true/false to force allow/block, or null to remove the override so the user follows the global catalog again. Every change is written to the admin audit log.