> For the complete documentation index, see [llms.txt](https://docs.otari.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.otari.ai/learn/workspaces.md).

# Workspaces

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? <a href="#h_01dce8ea97" id="h_01dce8ea97"></a>

#### 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 href="#h_731b8fcce5" id="h_731b8fcce5"></a>

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.

{% hint style="info" %}
The simplest mental model is: organization equals your company, and workspace equals a project or environment inside it.
{% endhint %}

***

### How teams use workspaces <a href="#h_fa9d5864a2" id="h_fa9d5864a2"></a>

Common patterns:

* **Per application**: one workspace per service or product so usage and budgets stay separate
* **Per environment**: `myapp-dev`, `myapp-staging`, and `myapp-prod`
* **Per 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 href="#h_028623e1d2" id="h_028623e1d2"></a>

* 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 a Workspace?

{% content-ref url="/pages/73b7faa18afc90c9ae3c6c1ae24f9ed214289c08" %}
[Manage Workspaces](/how-to-guides/manage-workspaces.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.otari.ai/learn/workspaces.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.