Organizations

Organizations are the top-level tenant and budget boundary in the admin UI.

Access: platform admin or org.read for authorized organizations. Creation, starting deletion, and restoration are platform-admin actions; scoped edits require org.update. Organization owners and administrators can waive or retry an existing deletion with org.delete.expedite for that organization. See Access requirements and Tenancy and access.

What this page manages

• Organization identity and display name
• Top-level budgets and rate limits (RPM, TPM, RPH, RPD, TPD)
• Audit content storage behavior
• Direct organization-member and team counts
• The tenant boundary that callable-target and access-group grants inherit from

Typical workflow

1. Create the organization
2. Set the broad budget and rate limits across all time windows
3. Choose which models, route groups, and access groups the organization is allowed to use
4. Add teams inside the organization
5. Assign platform accounts through Access > People

Delete an organization

Platform administrators see a Danger zone on the organization overview. Delete organization first shows the complete impact, requires the exact organization name and an explicit running-work acknowledgement, then schedules durable cleanup. Access is revoked immediately; permanent deletion waits for the configured recovery window.

The same panel shows cleanup progress. It offers restore while the operation is reversible, and retry after automatic cleanup uses all its attempts. Organization owners and organization administrators can see the existing job for their organization. They can select Delete permanently now or Retry cleanup. They cannot start deletion or restore the organization. See Organization Deletion for retained history and operational behavior.

The organization header and list show the authoritative lifecycle state:

• Active — runtime access and administrative changes are available according to the viewer's permissions.
• Deletion pending — access and administrative changes are disabled immediately. The displayed “no earlier than” time is the beginning of permanent cleanup, not the time at which access is disabled. A platform administrator can restore the organization while cleanup remains reversible.
• Purging — irreversible permanent cleanup has started and restore is no longer available.
• Deletion failed — access remains disabled; an organization owner, organization administrator, or platform administrator must retry cleanup from the Danger zone.

Mutation controls such as Edit, Add Team, Add Member, Asset Access, and tier assignment changes are unavailable whenever the lifecycle state is not Active.

Rate limit fields

Field	Description
RPM	Maximum requests per minute across all keys in the org
TPM	Maximum tokens per minute across all keys in the org
Output TPM	Provider output per admission minute across text models, teams, and keys; blank means no organization output limit
RPH	Maximum requests per hour across all keys in the org
RPD	Maximum requests per day across all keys in the org
TPD	Maximum tokens per day across all keys in the org

All limits are optional. Only configured limits are enforced. Organization limits act as a shared cap — all teams and keys within the org contribute to the same counters. Output TPM requires explicit request caps and shared Redis coordination. See Output TPM.

Why it matters

Organization scope controls how teams, keys, and access are partitioned. It is the right place for tenant-wide spending and policy boundaries.

Platform admins can bootstrap runtime model and route-group visibility directly in the create/edit dialog through the organization asset access section. Teams, keys, and users can only inherit or narrow from that organization set.

Asset Access and Access Groups

Organization asset access defines the parent access universe. Grant direct callable targets when the tenant should see specific model names or route groups. Grant access groups when the tenant should see every callable target labelled with a group such as support, finance, or beta.

If the organization uses tiers, the active tier assignment can define the organization's model package. Team, API key, and runtime user Asset Access can still narrow that tier package. Asset Access also remains the control surface for route groups. See Tiers for examples.

Access-group grants are valid before a group has model members. A model can later receive that group label. After runtime reload, the organization can receive the new callable target without another direct binding.

Use organization grants deliberately:

• Grant groups to organizations before using team, key, or user restrictions.
• Keep route-group keys and public model names unique because both are callable targets.
• Avoid copying routing tags directly into access groups; tags control deployment routing, while access groups control authorization.