Spending limits for agent runs
I check the remaining budget before a provider request and default autonomous spending to zero until an operator raises it. Checks need to cover retries and each calling path. A spending limit does not bound how long a run takes.
How do I check spending limits before an agent call?
I check the remaining budget before a provider request and default autonomous spending to zero until an operator raises it. Checks need to cover retries and each calling path.
Implementation
- Default autonomous budget to zero; an operator raises it explicitly per run.
- Check the remaining ceiling before issuing a provider call, not after.
- Apply ceilings at three levels: per caller, per run, per agent.
- Price every call at issue time using a checked-in price table, so the number does not depend on a billing export.
- Halt the run and emit an event when a ceiling is hit, rather than degrading silently.
What can go wrong
- Checking the budget after a response does not prevent paying for an over-budget call.
- A separate retry path can bypass a budget check.
- Using the wrong rate for long-context calls can underestimate cost.
Checks to try
- Set a ceiling of one cent and confirm the run halts on the first call.
- Reconcile a week of recorded cost against the provider invoice.
Questions this pattern answers
How do I check spending limits before an agent call?
I check the remaining budget before a provider request and default autonomous spending to zero until an operator raises it. Checks need to cover retries and each calling path.
What steps does this method use?
Default autonomous budget to zero; an operator raises it explicitly per run. Check the remaining ceiling before issuing a provider call, not after. Apply ceilings at three levels: per caller, per run, per agent. Price every call at issue time using a checked-in price table, so the number does not depend on a billing export. Halt the run and emit an event when a ceiling is hit, rather than degrading silently.
How can I check the result?
Set a ceiling of one cent and confirm the run halts on the first call. Reconcile a week of recorded cost against the provider invoice.
What can go wrong with this approach?
Checking the budget after a response does not prevent paying for an over-budget call. A separate retry path can bypass a budget check. Using the wrong rate for long-context calls can underestimate cost.
Related projects
ClawKeeper →
ClawKeeper checks proposed Claude agent actions against explicit rules before a model call. Autonomous spend defaults to zero, and the database enforces an append-only audit log.
TechTide Harness Kit →
TechTide Harness Kit uses JSON Schema to declare skill permissions, risk tiers, network access, and approval requirements. Automated checks validate declarations and run prompt-injection fixtures.
CipherClaw →
CipherClaw analyzes recorded agent activity without model calls. It builds causal graphs, scores possible causes, and flags failure patterns.
Swarm 357 →
357 Claude agent roles across six business layers, with portable memory, enforced cost caps, a bash policy gate, and durable checkpoints.
Related patterns
Acceptance tests for agent work →
Executable checks test the task and detect regressions.
Evaluation tests for releases →
A fixed evaluation suite checks release requirements.
MCP tool permissions →
The server checks which tools a caller may use.
Recording agent runs →
A shared trace ID connects the records of a run.
I explain this method here. Current service scope, prices, and terms are on TechTide AI.
Systems Decision Audit at TechTide AI→© 2026 Alex Cinovoj · TechTide AI · Columbus, OH