A workspace (ID prefix wrkspc_) is a compartment inside a Claude organization. Each workspace carries its own members, API keys, rate limits, and spend limits, and an organization can have up to 100 active workspaces. Used well, workspaces give you per-team or per-environment isolation without opening separate organizations. Used carelessly — everything in the Default Workspace — you get one undifferentiated pool of keys and budget that no audit can untangle.
What a workspace fences in
API keys. Every API key is scoped to the organization and a single workspace. A key can only touch resources — Files, Message Batches, Skills — inside its own workspace. Keys also persist when the user who created them is removed from the organization, which is a feature for continuity and a trap for offboarding reviews: removing a departed employee does not disable the keys they minted. (The one exception is the auto-created Claude Code workspace, which mints per-user keys at sign-in that die when the member is removed — and it is also the only workspace supporting per-user monthly spend limits.)
Limits. Workspace rate limits and spend limits can be set lower than the organization's limits, never higher. That makes a workspace a genuine budget fence: a runaway experiment in the staging workspace exhausts its own cap, not production's.
The Default Workspace is the odd one out: it has no ID and cannot be renamed, limited, or archived. Anything you care about governing belongs in a named workspace you created.
Prompt caches: the isolation boundary that moves
Prompt caching stores recent prompt prefixes so repeat calls are cheaper and faster — which makes "who shares a cache?" a real isolation question. The answer differs by platform:
| Platform | Prompt cache isolation |
|---|---|
| Claude API (1P) | Per workspace |
| Claude Platform on AWS | Per workspace |
| Microsoft Foundry | Per workspace |
| Amazon Bedrock | Per organization |
| Google Vertex AI (Google Cloud) | Per organization |
In every case the cache stays inside your own tenancy — no other customer shares it. The difference is internal: on Bedrock and Google Cloud, two of your teams using the same prompt prefix can interact with the same cache entries, while the per-workspace platforms keep even sibling teams' caches apart. If your internal compartmentalization model treats team boundaries as hard boundaries, that distinction belongs in your platform review.
Archiving is a kill switch, not a tidy-up
This has a defensive upside: if a workspace's keys are compromised, archiving it is a single action that guarantees every key in the compartment stops working. The corresponding operational rule: never archive as routine housekeeping without first confirming no production traffic still authenticates through that workspace. The revocation takes effect before your dashboards catch up.
The same word on Claude Platform on AWS
On Claude Platform on AWS, workspaces are the same concept wearing AWS clothing. Each workspace is bound to a single AWS region, addressed by an ARN, and serves as the platform's primary IAM resource — every request must carry the workspace ID header. Usage, quotas, cost, files, batches, and Skills roll up per workspace. Two governance differences matter: workspace member management does not exist there (AWS IAM policies on the workspace ARN control access instead), and spend limits are not available — you rely on AWS billing controls for budget enforcement.
Bedrock and Vertex AI have no Claude workspace construct at all; isolation there is built from the cloud's own primitives — AWS accounts and IAM on one side, Google Cloud projects and IAM on the other.
Where to go next
See the multi-workspace strategy guide for carving up environments, and the Admin API credentials explainer for who gets to create and archive these compartments.