Use case
How to prevent an AI agent from exceeding its budget
An agent loop can burn through a month of budget in an afternoon. The fix has to sit before the call, not after the invoice.
Create a hierarchical budget scoped to that agent's agent_id with a spending cap. Calls that would exceed it are refused with HTTP 402 before Spendline forwards them to the provider, the spend never happens, rather than being reported after it already did.
How Spendline does this
Budgets in Spendline are checked in the request path, not after the fact: before forwarding a call, Spendline checks the running spend for every budget scope that call falls under (org, team, agent, customer) and refuses the call if any of them would be exceeded. Because the check happens before the provider is called, an agent cannot overspend and get billed for it; it gets a 402 instead.
Why it matters
A dashboard alert that fires after an agent has already spent $2,000 in an hour is a post-mortem, not a control. Enforcement has to happen in the same request that would cause the overspend, which is why this has to sit in the request path rather than beside it.
Frequently asked questions
What does the agent see when it hits the cap?
An HTTP 402 response instead of a model response. Your application code decides what to do with that, retry later, fall back to a cheaper model, or surface it to a human, but the spend itself never reaches the provider.
Can two concurrent calls from the same agent both slip through right at the cap?
This is the specific race condition ("check-then-act") that a naive implementation gets wrong under concurrency. Spendline's enforcement is built to avoid two in-flight calls sharing one stale spend baseline and both being approved.
See where this stands in your own setup
This page describes the mechanism. The 5 minute assessment scores your own attribution, enforcement, and reconciliation setup, so you know exactly which of these problems you actually have today.
Run the 5 minute assessment