A workspace is the boundary for one app, environment, team, or customer. It keeps provider access, API Keys, budgets, usage history, and members separate from other workspaces.
If two workloads need different keys, budgets, access, or reporting, they should usually live in different workspaces.
Most dashboard tools are scoped to the active workspace, including Usage, Providers, API Keys, Members, Routing, and Settings.
What's inside a workspace?
Provider access
Provider keys are managed at the organization level. By default, a workspace can use any of them. You can pin a workspace to a specific provider key, or disable keys it shouldn't use.
API Keys
Workspace-scoped keys that your application uses to call otari.ai. API Keys live and die with their workspace.
Budgets and usage
Spending limits, token counts, costs, and request logs for everything the workspace processes.
Members and routing
Workspace-specific members, routing rules, MCP server settings, and other runtime behavior for that workload.
What lives at the organization level instead
A few things are intentionally above workspaces and apply across the whole organization:
Spend & Budgets: at the org level, which roll up across workspaces
Models: which determine what providers and models are available to the organization
Organization settings and org-level members
Wallet balance: which is shared across all workspaces in the organization
The simplest mental model is: organization equals your company, and workspace equals a project or environment inside it.
How teams use workspaces
Common patterns:
Per application: one workspace per service or product so usage and budgets stay separate
Per environment:
myapp-dev,myapp-staging, andmyapp-prodPer team: isolate keys and spending for different teams or departments
Per customer: for SaaS workloads, one workspace per customer for isolated tracking and billing visibility
A naming convention helps. {product}-{environment} scales better than ad hoc names once you have more than a handful.
Constraints worth knowing
A workspace does not own provider keys. It controls which organization-level provider keys are available to it.
Deleting a workspace is permanent. Keys, usage history, and budget configuration cannot be restored.
Workspace IDs are stable. If an application is already wired to a workspace ID, migrate it before deleting that workspace.
Ready to create one? See Manage Workspaces.