Workspace LLM Collection

Understand how to authorize specific models for your workspaces and manage workspace-level toggles.

            Provider

     Global LLM Collection
               │ (Workspace Access)

      Workspace LLM Access     ← You are here
        ├──────────────┐
        ▼              ▼
  Direct Model    Deployment
        \              /
         \            /
          ▼          ▼
         Virtual API Key

        Gateway Request

By default, newly created workspaces have access to no models. Before models can be used within a workspace, they must be explicitly authorized from the Global LLM Collection.

This boundary provides clean isolation for separate environments (e.g., development, staging, production) or business units.


Whitelisting Models

Model whitelisting is managed globally at the LLM Collection registry level:

  1. Navigate to the LLM Collection page in the sidebar.
  2. Click Edit (or create a new LLM) for the model you want to configure.
  3. Under the Workspace Access section, select which workspaces should have access to this model. You can search, Select all, or Deselect all workspaces to manage access efficiently.
  4. Save the changes. The model will now be whitelisted and visible in the selected workspaces.

Once added, the model's properties (RPM limits, capabilities, and provider configurations) are inherited from the global settings.


Active States

Models within a workspace have two distinct control levels:

1. Global Whitelist Access

The model must be explicitly granted access to the workspace from the global LLM Collection settings. If access is revoked globally, the model is completely removed from the workspace and can no longer be used by any deployments in that workspace.

2. Enabled/Disabled Toggle

Each whitelisted model has a status switch within the workspace's Models tab:

  • Enabled: The model is active and can process traffic or be used by routing deployments.
  • Disabled: The model is temporarily deactivated. Any deployment targeting this model directly will fail (or fallback to an alternative model if configured), and it will be excluded from active load-balancing pools.

Use cases for deactivation

Temporarily disabling a model is useful when:

  • Performing maintenance or rotating API keys for a specific provider.
  • Controlling budget spikes by turning off expensive models (e.g. gpt-4-32k or claude-3-opus) during non-critical phases.
  • Testing fallback behavior without deleting the model configuration.

Next Step: Deployments

Once a model is whitelisted, it can either be accessed directly using its registered alias name or attached to a virtual Deployment for routing, load balancing, and runtime processing.

Deployments can only reference models that have been whitelisted into the workspace. For detailed instructions on routing strategies and advanced configurations, see the Deployments documentation. To pre- or post-process payloads running through these models, see Runtime Modules.


Role-Based Access Control (RBAC)

Managing the Workspace LLM Collection status requires specific permissions (see Roles & Permissions):

  • View Models (WORKSPACE_LLM_VIEW): Allows members to view the list of whitelisted models.
  • Update Models (WORKSPACE_LLM_UPDATE): Allows members to toggle the enabled/disabled status of whitelisted models in the workspace.

On this page