Tenants

Platform › Customers › Tenants lists every tenant on the platform. A tenant is an isolated space: its models, agents, knowledge, keys and data are kept apart from every other tenant’s. Each tenant has a page that shows it at a glance and is where its capacity and model subscriptions are changed.

Who can open it

Platform administrators only. A tenant admin manages people, keys and budgets inside their own tenant from the Workspace pages, and cannot see other tenants.

How a tenant is put together

A tenant has one or more projects. Every tenant starts with one. A project scopes API keys, budgets and quota. See Projects.
People belong to a tenant, not to a project. An account belongs to exactly one tenant: the identity provider records the tenant’s slug on the account, and every request is checked against it. See Identity and sign-in.
Two separate envelopes. Compute is a capacity envelope per cluster (CPU, memory, storage, GPUs), divided into project quotas. Model use is token budgets, nested tenant, project, key. They never draw on each other.
Budgets on the tenant itself are set by a platform administrator only. The tenant’s own admins divide that budget across its projects and keys, and cannot exceed it. See Keys and budgets.

What you see

The All tenants table, with Search tenants and Create tenant.

Column	What it shows
Tenant	The display name, linking to the tenant’s page.
Slug	The tenant’s identifier.
Status	Active.
Created	The creation date.
Capacity	Edit capacity, which opens the tenant’s page at its capacity.

An empty platform shows No tenants yet with Create tenant.

Create a tenant

Select Create tenant. The Create a tenant dialog opens.
Identity. Enter:
- Display name: the name people see, for example Northwind Bank. Required.
- Slug: 3 to 40 lowercase letters, digits and hyphens. It becomes the tenant’s identifier and is what accounts in your identity provider carry as their tenant. It cannot be changed later.
Select Next.
First project. Enter the Project name (“default” is fine) and choose its Environment: Production (prod), Staging (staging) or Development (dev). Select Next.
Capacity (optional). Choose a Cluster to grant the tenant an envelope on now, or leave No cluster (skip) and grant it later. With a cluster chosen, the step shows the cluster’s pool, what is available and what other tenants already hold, then:
- CPU cores, Memory (GiB) and Storage (GiB);
- GPUs: Add GPU, then for each row a Whole card or MIG profile and a Count.
A model served on CPU and a vector database need vCPUs and memory here: 0 grants none. Storage at 0 means no limit. Select Next.
Review. Check the display name, slug, first project, capacity and GPUs, then select Create tenant.

The tenant and its first project are created together. If the tenant was created but its capacity was refused, the dialog says so: create again to retry the capacity alone, or set it later from the tenant’s page.

Then, to let people in, create their accounts with this tenant’s slug. With the built-in identity service and user management on, a platform administrator or the tenant’s admin invites them from Govern › Users. See Users and roles.

A tenant’s page

The header carries the tenant’s display name. Under it: Slug, Status, Created and Tenant ID.

Four tiles, each linking to the page behind it:

Tile	What it shows
Tokens this month	Tokens through the gateway for this tenant.
Monthly budget used	The share of the tenant’s monthly token budget used, or No monthly budget.
Members	People in the tenant, or “Managed in your identity provider” when the platform cannot list them.
Active API keys	Keys that can call the gateway.

Then six sections, each showing the first few rows and linking to the full page:

Projects: each project, its environment, and its namespace on each cluster (Ready, Being created, Being removed or Failed).
Budgets: token budgets on the tenant, its projects and its keys, against what each has used this period, the tenant’s own first and then those nearest their limit.
API keys: by project, how many are active, how many expire within the next days, and how many are not active.
Members: the people who can sign in, by role. A tenant with no admin who can sign in shows a warning: nobody can manage its people.
Usage this month: tokens and requests by model, with each model’s share. What it costs is on the tenant’s statements, under Billing.
Billing: the latest billing periods and the statements issued for them.

Below them, two full-width sections: Capacity and Models.

Grant capacity on a cluster

Granting a tenant capacity on a cluster is what gives it access to that cluster. Without an envelope there, the tenant cannot deploy on the cluster, and its projects cannot be given a quota there.

Open the tenant, then in Capacity select Grant cluster access.
Cluster. Only clusters the tenant has no access to yet are listed. Select Next.
Resources. CPU cores, Memory (GiB) and Storage (GiB) on this cluster. CPU cores or memory at 0 grant none; storage at 0 means no limit. Select Next.
GPUs (optional). Whole cards or MIG slices, from the GPU types this cluster’s pool holds. Skip it to grant none. Select Next.
Review. Check the envelope, then select Grant access.

A grant the cluster’s pool cannot hold is refused on Review with Access was not granted and the reason.

Change or remove capacity

The Capacity section lists one row per cluster the tenant holds, each with CPU cores, Memory (GiB), Storage (GiB) and its GPUs by type, and what the tenant’s CPU deployments and vector databases already use there.

Change: edit the values in the row, then select Save on that row. Discard changes puts the row back.
Remove access: select it on the row and confirm. The tenant loses its capacity on the cluster and can no longer deploy there.

Refusal	Why
Beyond the pool	The cluster’s managed nodes cannot hold what you grant across all tenants. Put more nodes in the pool, or grant less.
Below what projects hold	The tenant’s project quotas on this cluster add up to more than the new envelope. Lower the project quotas first.
Remove access refused	Projects still hold quota on the cluster. Clear their quotas first, on Projects.
Negative value	Every value must be 0 or more.

A vector database counts against the envelope at its limits times its replicas, and a failed database counts until it is deleted. See Vector databases.

Offer a model to a tenant

Giving a tenant a model takes steps on four pages. In order:

Have it in the catalog. A self-hosted model is added on Build › Models; its weights can be packaged first in the model registry. A model a cloud provider serves is registered from Build › Models › External, over a provider connection kept in Settings. See The model catalog and External models.
Offer it as LLMaaS, from the model’s menu in the catalog (LLMaaS offering). Its token weight is set there from its GPU footprint.
Price it. Add its rate to a draft price book and make the book live, or give this tenant a negotiated rate. See Billing. An unpriced model is metered and not billed.
Subscribe the tenant and set its token budgets, on the tenant’s page: see below.
Serve it. A self-hosted model needs a ready deployment the tenant can use: deploy it on a cluster where the tenant holds capacity. A provider’s model needs no deployment. See Deploy a model.
Issue a key. The tenant’s admin issues an API key in a project, and can narrow which models it may call. See Keys and budgets.

A provider’s embedding model must be granted before the tenant’s knowledge can use it.

The Models section shows the models this tenant can call.

LLMaaS subscriptions lists every model the platform offers as LLMaaS. A model is offered from its menu in the catalog on Build › Models; until one is, the section shows No LLMaaS models offered with Go to Models.

Column	What it shows
Model	The model.
Token weight	How many tokens each of its tokens counts as against a budget: the sum of each GPU’s cost rate times its count in the model’s GPU footprint, or 1 when it has none. A model a cloud provider serves has no GPU footprint.
Subscribed	The switch.
Daily budget (tokens), Monthly budget (tokens)	Weighted-token caps for this model. 0 means no limit.
Usage this month (weighted)	What the tenant has used, with today’s figure.

To subscribe, switch Subscribed on. Applications in the tenant can call the model with their keys from then on, once a deployment of it is ready or a provider serves it.

To cap it, enter a Daily budget (tokens) or Monthly budget (tokens); it saves when you leave the field. A breached budget blocks that model at the gateway with 429, and nothing else.

To unsubscribe, switch Subscribed off and confirm Unsubscribe. Requests to the model from the tenant’s applications are refused at the gateway from then on. A deployment of the model the tenant runs itself keeps working. The budgets are kept in case you subscribe it again.

Deployed for this tenant lists the models deployed for the tenant, with the project and cluster each runs on, and Deploy a model.

Offboard a tenant

To end a customer’s access:

Revoke every API key in its projects, on Keys and budgets.
Undeploy its models, and unsubscribe it from every LLMaaS model.
Disable or delete its assistants, pipelines, collections and vector databases.
Clear its project quotas, then remove its capacity on each cluster.
Close the final billing period and issue its statements. Issued statements are frozen and kept.
Disable its people in your identity provider.

After steps 1 and 2 every gateway call for the tenant is refused. The tenant’s record, its usage and its audit trail remain; the audit trail still verifies. Shorten what is kept with Data retention, and erase named people on request with Erasure.

Limits

Limit	Value
Slug	3 to 40 lowercase letters, digits and hyphens; unique; fixed once created
Display name	Required
Projects per tenant	At least 1
Capacity values	0 or more

Tenants, projects and people
Keys, budgets and metering
Clusters for the serving pool
Billing for what a tenant is charged