Customize Model Access
Manage who can use, edit, and administer a Customize Model in an organization workspace.
Access to a Customize Model is determined by its owning workspace, model membership roles, and explicitly allowed groups. The current platform uses Creator, Collaborator, and can use permissions; it does not expose a Private, Group, and Public visibility selector.
Model settings may display a legacy visibility value in the summary panel, but the current UI does not provide a control for changing it. Use the members and groups under Settings → Access as the source of truth.
Personal and Organization Workspaces
| Creation location | Current behavior |
|---|---|
| Personal workspace | The owner manages the model. It cannot currently be shared with other users, assigned Collaborators, or made available to other groups. The Access subsection explains this limitation instead of offering a sharing form. |
| Organization workspace | Workspace members can use the model. Its Creator and Collaborators can manage it and can allow additional groups to use it. |
The backend also rejects sharing and co-editing updates for personal-workspace models, so this restriction cannot be bypassed through a direct API call.
Roles and Capabilities
| Identity | Use model | Edit configuration | Manage access | View request logs | Delete model |
|---|---|---|---|---|---|
| Model Creator | ✓ | ✓ | ✓ | ✓ | ✓ |
| Collaborator | ✓ | ✓ | ✓ | ✓ | ✓ |
| User in the owning organization | ✓ | — | — | — | — |
| Member of an allowed group | ✓ | — | — | — | — |
| Platform administrator | ✓ | ✓ | ✓ | ✓ | ✓ |
A regular User can use the accessible model features. If they try to open Settings, the platform redirects them to Overview. Authorization is also enforced by the backend rather than relying only on hidden UI controls.
Manage Access for an Organization Model
Open Model Settings
From the sidebar, go to My assets → My models, select a Customize Model in an organization workspace, and open Settings → Access.
Search for a Group or User
Use the add-member field to find an eligible group or a member of the current workspace. A Pending user cannot be assigned.
Choose the Grantee
- An added group receives a fixed can use role.
- An individual added in an organization workspace receives a fixed can edit Collaborator role.
- An individual Collaborator must belong to the model's owning workspace.
- You can grant access only to groups that you are eligible to select.
Save Access
Select Save access. After a successful update, the page reloads the latest allowed groups, allowed users, and Collaborators.
The Creator always retains the Creator role and is not listed as a removable grant. A Collaborator also cannot remove or downgrade themselves from their own view; another manager must make that change.
Assignment Restrictions
- The model Creator and Collaborators can update access settings.
- An allowed external group receives model-use permission, not edit permission.
- Individual assignments on organization models are currently fixed to Collaborator; there is no use-only choice.
- A selected user must exist and must not have the Pending platform role.
- The number of allowed users and Collaborators may be limited by the model owner's account or role quotas.
- On save, the backend revalidates workspace membership, group eligibility, quotas, and the caller's management permission.
How API Keys Apply Model Access
Model authorization and API-key authentication are both enforced. A valid key does not grant access to every Customize Model.
User API Keys
A user key resolves the model as the key owner. The owner must be the Creator, a Collaborator, a member of the owning organization, or a member of an explicitly allowed group to use that model Slug.
Organization or Project API Keys
An organization or project key uses the scope of its owning group. That group must own the model or be explicitly included in the model's allowed groups.
A Key May Also Narrow Its Own Reach
The rules above decide the widest set a key could reach. A key can additionally be restricted to specific models, which is applied on top as an intersection: it can only ever remove models from that set, never add one. A model the owner or organization cannot use is still refused when a key names it. See API Keys for how to set this.
The current runtime does not accept an upstream provider key, such as an OpenAI API key, from the caller to bypass platform billing. Allow user-provided API key from the old documentation is not a currently editable or runtime-enforced model access setting.
The API key must still be active, comply with its own rate limits, and permit the requested model if it has been restricted to a specific set. The Customize Model and base model must also be available. See API Keys for the key workflow.
View Request Logs
The model Creator and Collaborators can open Operate → Request logs to review API use for the model. Regular Users and members of a use-only allowed group cannot view these logs.
Records can include request status, token usage, cost, latency, evaluation scores, and available request or response traces. The exact content depends on the deployment's logging, trace, and retention configuration.