Teams, Budgets & Model Access
A workspace is a team. Invite people by email, assign roles, cap spend with hard budgets, and restrict routing to an allowlist of approved models — per team and per project.
Key Concept
Every workspace is now a team. Existing accounts were automatically made the owner of their workspace. Add teammates by inviting their email, and control exactly what each member can do with roles, budget caps, and model allowlists.
Teams & Roles
Manage your team at /app/team. Each member has one of four roles. Higher roles include everything the lower roles can do: owner > admin > member > viewer.
| Role | Can do |
|---|---|
| owner | Full control of the workspace, including deleting it and transferring ownership. Everything an admin can do. |
| admin | Manage members, API keys, budgets, model whitelists, and billing. Cannot delete the workspace. |
| member | Use the workspace — send requests, use API keys and models. Cannot change team settings. |
| viewer | Read-only. See usage and logs. Cannot send requests or change settings. |
Inviting People
Owners and admins invite teammates by email address. The invitee receives a link and joins the team by accepting it. Until then the invite is pending and can be revoked.
- Go to /app/team → Invite
- Enter the person's email address and pick a role (member and viewer are the common choices)
- They receive an invite link by email
- When they open the link and accept, they are added to the team with the assigned role
- You can change a member's role or remove them at any time from the same page
Roles, invites, and members are all available over the API — see the /workspaces/:id/members and /workspaces/:id/invites endpoints in the Workspaces API reference.
Budget Controls
Set hard spend caps that reject requests once reached — they are not just warnings. Caps apply per team and per project, and you can set both a daily and a monthly limit. Windows are the calendar day and calendar month in UTC.
Checked on every request, before any model call. When accumulated spend for the window has reached the cap, Antbase rejects the request with HTTP 402 and error code BUDGET_EXCEEDED.
Requests stay blocked until the window resets (the next UTC day or month) or an owner/admin raises the cap.
Set team caps at /app/billing and project caps on each project. A project cap can be stricter than the team cap; the lowest applicable cap wins.
402 Response When a Cap Is Reached
{
"error": {
"code": "BUDGET_EXCEEDED",
"message": "Daily budget cap of $50.00 reached for this team. Spend resets at 00:00 UTC.",
"retryable": false
}
}Model Whitelisting
A model allowlist restricts which model ids Antbase is allowed to route to. Set an allowlist on the team (at /app/settings) and optionally a narrower one per project.
Intersection, never expansion. A project allowlist is intersected with the team's — a project can only ever narrow the set of allowed models, never add models the team hasn't allowed.
Virtual models keep working. Presets like ant:auto and nests route only within the allowed set — they never escape the allowlist.
Pinning a disallowed model is rejected. Requesting a specific model that is not on the allowlist returns HTTP 403 with error code MODEL_NOT_ALLOWED.
Pinning a Non-Allowed Model → 403
curl https://antbase.ai/v1/chat/completions \
-H "Authorization: Bearer ant_your-api-key" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-4o",
"messages": [{"role": "user", "content": "Hello!"}]
}'
# openai/gpt-4o is not on this team's allowlist:
#
# HTTP/1.1 403 Forbidden
# {
# "error": {
# "code": "MODEL_NOT_ALLOWED",
# "message": "Model 'openai/gpt-4o' is not in the allowlist for this workspace.",
# "retryable": false
# }
# }ant:auto Still Routes Within the Allowed Set
curl https://antbase.ai/v1/chat/completions \
-H "Authorization: Bearer ant_your-api-key" \
-H "Content-Type: application/json" \
-d '{
"model": "ant:auto",
"messages": [{"role": "user", "content": "Hello!"}]
}'
# 200 OK — ant:auto picks the best model that IS on the allowlist.
# The response's "model" field shows which allowed model handled it.Where to Manage Each Setting
| Setting | Location | Who can change it |
|---|---|---|
| Members & roles | /app/team | owner, admin |
| Budget caps (team) | /app/billing | owner, admin |
| Budget caps (project) | Project settings | owner, admin |
| Model allowlist (team) | /app/settings | owner, admin |
| Model allowlist (project) | Project settings | owner, admin |