Workspaces & limits
A workspace is the tenant boundary. Skills, secrets, artifacts, memory, agents and activity all belong to exactly one workspace, and an API key is scoped to one — agents cannot reach across workspaces.
How many workspaces you can be in
Your plan sets how many workspaces you may belong to. This counts every workspace you are a member of, whether you created it or were invited into it.
| Plan | Workspaces |
|---|---|
| BYOK Mode | 1 |
| PAYG Mode | 5 |
| Based Mode | 10 |
| Deployed Mode | Unlimited |
Two consequences worth knowing before you hit them:
- You get one workspace when you sign up. It is created for you, and it counts toward your limit. A BYOK account is therefore at its limit immediately.
- Invitations are checked against the invitee’s plan, not the inviter’s. If someone invites you to their workspace and you are already at your limit, the invitation is refused — even if they are on a paid plan. Joining a workspace is a paid feature, so BYOK is a single-workspace tier. Upgrade to accept.
Being in more workspaces does not give you more compute. Concurrency is per-user: you hold at most one running execution at a time regardless of how many workspaces you belong to.
How many members a workspace can have
A workspace holds up to 100 members. This is a property of the workspace, not of any one member’s plan, so when it is full the fix belongs to the workspace owner — upgrading your own plan will not let you in.
Execution concurrency
Three limits apply to every run, in this order:
| Limit | Scope | Default |
|---|---|---|
| One running execution | Per user | 1 |
| Workspace share of the fleet | Per workspace | 10 concurrent sandboxes |
| Fleet capacity | Whole platform | 100 concurrent sandboxes |
The per-workspace share exists so no single tenant can starve the others. A workspace only approaches it when roughly ten of its members are running something at the same time, because each user holds at most one run.
If your team needs more than a share of a shared fleet, that is Deployed Mode, where the fleet is your own and you set the concurrency yourself.
If you downgrade or cancel
Limits are checked when you create or join a workspace, so downgrading does not remove you from anything. If you were in ten workspaces on Based Mode and drop to BYOK, you keep access to all ten — nothing is deleted and nothing is revoked.
What changes is headroom: you cannot create or join another until you are back
under your plan’s limit. GET /api/v1/workspaces/usage reports this as
overLimit:
{ "used": 10, "limit": 1, "mode": "byokmode", "canCreate": false, "overLimit": 9 }Two ways back under, and both stay open — resubscribe, or leave workspaces you no longer need. The platform will not choose for you, because it cannot know which of your workspaces matters.
When you hit a limit
Every refusal is an HTTP 403 with a machine-readable code in
error.details.reason:
| Reason | Meaning | Who can fix it |
|---|---|---|
WORKSPACE_LIMIT | You are in as many workspaces as your plan allows | You — upgrade |
MEMBER_LIMIT | The workspace has reached 100 members | The workspace owner |
{
"error": {
"code": "FORBIDDEN",
"message": "Your plan (BYOK MODE) allows 1 workspace and you are already in 1. Upgrade your plan to join this workspace.",
"details": { "reason": "WORKSPACE_LIMIT" }
}
}Branch on details.reason, never on the message text — the wording may change
or be translated.
Checking your usage before you act
GET /api/v1/workspaces/usage returns your current position so a client can
show the limit rather than discover it on a failed write:
{ "used": 1, "limit": 1, "mode": "byokmode", "canCreate": false }limit: 0 means uncapped (Deployed Mode).