AI CodeOps

AI coding budgets: soft limits, hard caps and per-workflow caps

How to budget for AI coding agents: choosing a period, setting soft limits and hard caps, where enforcement must happen, and per-workflow caps.

An AI coding budget is a spending limit on model usage, enforced by the tools that run the agents rather than discovered on the invoice. A workable budget has a period, such as a day, week or month; a soft limit that warns people as spend approaches the cap; a hard cap that refuses new sessions and stops running ones before their next model call; and separate caps for the workflows that can spend the most. The difference between a budget and a report is enforcement: if nothing stops at the limit, it is a forecast.

This page goes deeper on the controls described in How much does AI coding cost?.

Why the invoice is not a control

Model providers bill after the fact. An agent stuck in a loop, a schedule set to run every hour instead of every day, or a large task given to the most expensive model can all spend a month's expected amount before anyone looks. A monthly invoice shows that it happened; it does not stop it.

Agents make this more likely than chat, because their cost grows faster than their length: each turn resends a growing context. A budget for agent work has to act while the work is running.

Choosing the period

PeriodStrengthWeakness
DailyCatches runaway spend within a dayA heavy but legitimate day can block work
WeeklySmooths daily variationA problem on Monday can use the week's money by Tuesday
MonthlyMatches invoices and planningSlowest to catch a runaway
Rolling 30 daysNo reset cliff at the start of a monthHarder to explain and to reconcile with invoices

Two details matter for any period: the time zone in which it resets, and what happens to work running at the moment of the reset. Write both down so a cap that "should" have reset is not a surprise.

Soft limits and hard caps

A soft limit is a warning line. Past it, work continues, but people see that spend is high. It exists to let someone react: look at what is running, pause a schedule, or raise the cap on purpose.

A hard cap is the actual budget. Past it, new work is refused and running work stops.

Set the soft limit low enough that there is time to act before the cap, for example after most of the period's budget is spent. Make sure the warning reaches people who look: a line on a page nobody visits is not a warning.

Where enforcement has to happen

A budget can be checked at three points, and only some of them bound the bill.

  1. When a session starts. Necessary, but not enough: one long session that starts just under the cap can run far past it.
  2. Before each model call. This is what bounds spend. A session that crosses the cap stops before its next call, and only calls already in flight can take spend past the limit.
  3. After the fact, from billing data. Useful for reconciliation, too late for control.

The check should also fail closed when work starts. If the budget service cannot answer, refusing to start new work is safer than starting it unmetered.

Per-workflow and per-team caps

One workspace cap treats every kind of work the same. In practice, a few workflows account for most of the spend: long multi-agent workflows, large refactors and anything that runs on a schedule. Give those their own caps inside the workspace budget, so one kind of work cannot use money meant for everything else.

Separate caps are most useful for:

  • Scheduled work, which spends without anyone watching.
  • Long multi-step workflows, whose cost per session is highest.
  • Experiments, such as trying a new model or a new kind of task.

Estimating the first budget

There is no reliable industry figure to copy. Estimate from your own usage:

monthly spend ≈ people × sessions per person per working day × working days × average cost per session

Measure the average cost per session from a few weeks of real work, because it depends heavily on your tasks, models and session length. Set the hard cap with headroom above the estimate, then adjust it from what you see. The worked example in How much does AI coding cost? shows the arithmetic.

When the cap is hit

A hard cap will eventually stop someone's work. Plan for it so the response is a decision rather than a scramble.

  • Say why. The message should name the limit that was reached and who can change it.
  • Decide who can raise it, and make that quick for the people with authority. A cap that takes days to raise invites workarounds.
  • Record changes. Every change to a budget should leave an audit entry with who made it.
  • Look at what spent the money before raising the cap. A runaway schedule needs fixing, not funding.

Reviewing spend

Once a budget is in place, review it on a regular cadence:

  • the most expensive sessions of the period, and whether their tasks could be smaller;
  • spend by workflow and by model, to see where caps or model choices should change;
  • schedules, and whether each still earns its cost;
  • how often the soft limit and the hard cap were reached.

If you use your own provider key, set limits at the provider too. A provider-side limit is a backstop if anything else misbehaves.

How AI CodeOps does it

In AI CodeOps, owners, admins and billing admins set a workspace cost budget under Configure → Billing → Cost budget:

  • Period: daily, weekly, monthly (the default) or rolling 30 days. Periods start in UTC, and weeks start on Monday.
  • Soft limit: past it, starting a session in the console shows a warning with the period's spend, and the crossing is recorded under Recent decisions on Secure → Policies. Sessions keep running, and no email or notification is sent.
  • Hard limit: new sessions are refused, and the budget is checked before every model call, so a running session that crosses the limit stops with the status Blocked by budget. A single model call already in flight can take spend slightly past the limit.
  • Per-workflow caps: an optional hard cap for each workflow, on top of the workspace limit. There are no per-agent budgets; each agent step's cost is shown on the session's page.

The spend bar turns amber from 70% of the hard limit and red from 90%. If the budget check fails when a session starts, the session is blocked rather than run unmetered; if it fails during a session, the session keeps running. Creating the budget and every later change are recorded in the audit log as budget.updated.

A weekly budget of $200 with a warning at $150, and a $40 cap on scheduled dependency refreshes, in millionths of a US dollar:

{
  "enabled": true,
  "period": "weekly",
  "softLimitMicros": 150000000,
  "hardLimitMicros": 200000000,
  "perWorkflowLimits": { "dependency-refresh": 40000000 }
}

The budget applies to every session, whether it runs on the platform's models, on credits or on your own provider key. Platform models also have a monthly token allowance per tier, and workspaces with billing set up can set a monthly limit on credit spend. AI CodeOps is free during the open beta; see pricing.

See Cost controls for every setting, Usage and spend for where to read spend, and AI coding cost controls for the overview.

Frequently asked questions

How do I choose the first AI coding budget?

Measure before you tighten. Run normal work for a few weeks under a generous cap, look at cost per session and sessions per day, and set the hard cap with headroom above what you saw. Then review it once you know which workflows and schedules drive spend.

Should a budget stop sessions that are already running?

Yes, at the next safe point. A cap that only blocks new sessions can be overrun by one long session. Checking before each model call lets a running session stop without wasting the work already paid for.

Is a monthly or a daily budget better?

A monthly budget matches invoices but lets a runaway loop spend the whole month's money in one afternoon. A daily or weekly cap catches that sooner. Many teams use a monthly cap with per-workflow caps for the expensive or scheduled work.

What should happen when the budget check itself fails?

Starting new work should be blocked, so nothing runs unmetered. For work already running, decide explicitly whether to stop it or let it finish, and document the choice.