Usage-based AI needs budget controls

Usage-based pricing makes sense for agentic engineering work. A Fixer session that investigates and validates a fix costs more than a lint check, and it should be metered that way instead of bundled into a flat seat price that either overcharges light users or undercharges heavy ones. But usage-based pricing only works if the team paying for it can see what is being spent and stop it before it runs past what they expected.

That is the gap Baz's budget controls close.

The problem with invisible spend

Engineering Work Credits already cover the agent work that goes beyond standard AI code review: Fixer sessions, Advanced Security Reviewer, Spec Review, and AI SRE. Each of those workflows has a real cost, because each one runs a model against a nontrivial amount of context. The risk for admins was never that this pricing model is unreasonable, it was that credits could get consumed by a spike in agent activity with no visibility until the invoice arrived.

Finance-conscious eng leaders do not want to choose between turning off autonomous workflows entirely or accepting an open-ended bill. They want the workflows on, with a ceiling.

What is visible now

Account Settings includes a usage summary that shows current spend against your organization's limit and any per-user limits, updated as credit-eligible sessions run rather than at the end of the billing period. The summary breaks spend down by agent work, so a spike is traceable to a specific workflow, whether that is a burst of Fixer sessions after a big refactor or an Advanced Security scan running across several repositories at once.

Fixer costs specifically get their own visibility, since Fixer sessions vary the most in cost depending on the size and complexity of the fix, and teams adopting Fixer want to see that variance directly rather than inferring it from a total.

Setting limits, and what happens at the limit

Admins can set an organization-wide monthly credit limit, a per-user monthly limit, or both. When a limit is reached, Baz stops running additional credit-eligible agent work until the limit is updated or more credits become available. Standard AI code review is unaffected either way, since it runs on the seat-based plan rather than credits.

That behavior is deliberate: a limit is a hard stop, not a warning that gets ignored. Teams that want headroom can set the limit above their expected usage and treat it as a circuit breaker for the unexpected, rather than a number they plan to hit every month.

Why this matters for adoption, not just cost control

Budget controls are as much an adoption lever as a cost control. Admins who can see spend and cap it are far more willing to turn on autonomous workflows broadly, because the downside is bounded. Without that visibility, the safe default is to under-provision access and slow-walk rollout, which defeats the point of usage-based pricing in the first place.

If your organization is running Engineering Work Credits, the usage summary in Account Settings is worth a look before your next billing cycle, if only to confirm the numbers match what you expected.