Skip to main content

Spend Controls

What is a spend cap?

A spend cap is a limit you set on how much your own team spends on AI coding tools. For example: “Stop AI spend at 5,000acrossthewholeteampermonth,"or"5,000 across the whole team per month," or "200 per week for one developer.” These caps govern your company’s internal coding-agent spend: the usage you meter with the Claude Code & Codex spend tool. They have nothing to do with your customers. Events you record for customer billing never count toward a cap, and a cap never changes what any customer pays. You can manage caps in the dashboard’s Money tab. These endpoints are the same controls, callable from your own code. The Node SDK and the MCP tools call these exact endpoints too, so every path sees the same caps and the same numbers.

The two ideas to know first

Scope: who the cap governs.
  • org: one ceiling for the whole team.
  • dev: one developer, named by their customerExternalId (their email).
A developer cap can never be set higher than the whole-team ceiling. The API rejects the attempt with a plain message. Mode: what the cap does when spend reaches it.
  • track: watches and sends alert emails. Blocks nothing.
  • enforce: a developer’s machine stops the coding-agent tool call when the cap is reached. Enforcement only happens on machines where the team turned on the Spend Control device setup. The API itself never blocks anything; it stores the caps and reports the spend.
Every cap covers all AI tools. You can’t yet cap one provider (say, only Claude) on its own; if you send a different providerScope, the API answers with "Caps cover all AI tools for now."

Who can change caps

Reading caps, spend, and coverage works with any secret key for your organization. Creating, updating, or deleting a cap needs a key that belongs to an owner or finance user. Any other key gets a 403 Forbidden with a message naming the required role. This is the same rule the dashboard enforces: spend caps sit with the people who own the budget.

The endpoints

List caps

Returns every cap policy for your organization. Each cap includes a sentence field: the cap written out as one plain sentence, built by the server. Response (200 OK):

Create a cap

Owner or finance key required. Request body:
Response (201 Created): the full cap, same shape as the list response, including its sentence. curl example:
Common errors:
  • 400 Bad Request: a developer cap higher than the whole-team ceiling, a scopeValue that doesn’t match the scope, or a providerScope other than "all".
  • 403 Forbidden: your key doesn’t belong to an owner or finance user.
  • 409 Conflict: a cap with this scope and target already exists. Update it instead of creating a second one.

Update a cap

Owner or finance key required. You can change amountUsd, period, mode, coolOffHours, and alertThresholds. A cap’s identity (its scope and target) can’t be changed: to point a cap at someone else, delete it and create a new one. Response (200 OK): the updated cap, including its refreshed sentence. Common errors:
  • 400 Bad Request: the new amount would put a developer cap above the whole-team ceiling.
  • 403 Forbidden: your key doesn’t belong to an owner or finance user.
  • 404 Not Found: no cap with that ID in your organization.

Delete a cap

Owner or finance key required. The response echoes the removed cap’s sentence so you can confirm what was deleted. Response (200 OK):
Common errors:
  • 400 Bad Request: deleting this whole-team ceiling would leave a developer cap with nothing above it.
  • 403 Forbidden: your key doesn’t belong to an owner or finance user.
  • 404 Not Found: no cap with that ID in your organization.

Read spend against the caps

Returns your team’s internal coding-agent spend for the current period window (the server computes the window in UTC). Add customerExternalId to also get one developer’s number:
Response (200 OK):
Three honesty rules to know:
  • spentUsd is null when there’s no priced usage in the window. A null means “nothing to total yet,” never a fake $0.
  • unpricedEventCount tells you how many events exist that couldn’t be priced yet (their model isn’t in the pricing table). If it’s above zero, the true spend is higher than spentUsd shows.
  • Only internal coding-agent usage counts. Events you record for customer billing are never in these totals.

Read coverage

Answers “how many of my developers are actually protected?” over the trailing 7 days. Works with any secret key. Response (200 OK):
  • armed: developers whose machines have enforcement turned on.
  • total: developers seen at all in the window.
  • asOf is null when there’s been no recent activity. The server reports honest absence rather than making up a timestamp.
These are the same numbers the dashboard’s Money tab shows, computed by the same math.

How enforcement actually works

The API stores caps and reports spend. The stopping happens on each developer’s machine, through the Claude Code & Codex spend tool with its Spend Control option turned on. Two consequences worth knowing:
  • Enforcement fails open. If a machine can’t read fresh cap data (network down, stale file), it doesn’t block. A broken cap should never brick a developer’s day.
  • A cap in track mode never blocks anywhere. It watches and sends the alert-ladder emails, nothing more.