Until now an Antbase workspace belonged to one person. That's fine for a solo build, but teams asked for three things before they could standardize on it: bring the whole team into one account, put a hard ceiling on spend, and control which models each group is allowed to call. All three are live today, and all three are enforced on the server — not just shown in the dashboard.
Teams: one workspace, many people, real roles
A workspace is now a team. Invite people by email, they accept with one click, and they share the same keys, projects, usage, and billing. Every member has a role, and the role decides what they can do:
- •Owner — full control, including billing, budgets, whitelists, and transferring ownership.
- •Admin — manage members, API keys, budgets, and model whitelists. The day-to-day operator role.
- •Member — use the workspace and its keys; no governance controls.
- •Viewer — read-only access to usage and logs.
Your existing account became the owner of your workspace automatically — nothing to migrate. Add teammates from the new Team page; they show up the moment they accept.
Budgets: a hard stop, not a warning email
The point of a budget is that it holds. Set a daily and/or monthly cap on a team — or on an individual project — and once spend for that window reaches the cap, Antbase stops accepting requests and returns a clear error until the window resets or you raise the cap. No overage, no surprise invoice. The cap is checked on every request, before any model is called.
- •Caps apply per team and per project, so one noisy project can be contained without throttling the rest.
- •Windows are calendar day and calendar month (UTC); spend resets automatically when the window rolls over.
- •A blocked request returns HTTP 402 with a message telling you which cap was hit and when it resets.
{
"error": {
"type": "insufficient_quota",
"code": "BUDGET_EXCEEDED",
"message": "Team daily budget reached: $50.00 of $50.00. Requests are paused until the next UTC day or the cap is raised."
}
}Model whitelisting: control what each team can call
Set an allowlist of models on a team, on a project, or both — and Antbase will only ever route to models on that list. Pin a model that isn't allowed and the request is rejected with a clear MODEL_NOT_ALLOWED error; send a virtual model like ant:auto and the router simply picks the best allowed model. A project's allowlist is intersected with the team's, so a project can only ever narrow what the team permits, never widen it.
This is how you keep an experimental team on cheap open models, hold a regulated project to a specific approved set, or make sure nobody accidentally routes production traffic to a model you have not signed off on.
# Team allowlist excludes gpt-5; pinning it is rejected up front.
curl https://antbase.ai/v1/chat/completions \
-H "Authorization: Bearer $ANT_API_KEY" \
-d '{"model":"gpt-5","messages":[{"role":"user","content":"hi"}]}'
# → 403 MODEL_NOT_ALLOWED
# ant:auto still works — it routes only within the allowed set.
curl https://antbase.ai/v1/chat/completions \
-H "Authorization: Bearer $ANT_API_KEY" \
-d '{"model":"ant:auto","messages":[{"role":"user","content":"hi"}]}'One place to govern it
Members and roles, team and project budgets, and model allowlists all live in your dashboard. Set them once; they apply to every key and every request the team makes.
