Spend control: does my AI budget actually stop a run
Does my AI budget actually stop a runaway run?
Ask in plain words how your spend budgets are set up and whether one would stop a run that burns through its cap. Quox reads the budget records and tells you straight, before a runaway run finds out for you.
What you get: a straight answer to the question that matters about AI spend: if an automated run goes wrong, does anything stop it? In this run the answer was no. The one budget covered a single agent, only warned at its cap, and had expired months earlier. You find that out from one question, with nothing changed, instead of from an invoice.
The setup
Section titled “The setup”You are worried about runaway AI spend. You ask Quox, in your own words, three things: how many budgets you have, what the main one covers, and whether it stops a run or only warns. This is the exact question from the recorded run:
I'm worried about runaway AI spend. First, how many spend budgets do I have set up? Then tell me what scope my main budget covers: the whole org, a team, or a single agent? And the thing I actually care about: if an automated run burns through its cap, does my budget actually STOP it or just warn me? Tell me the iteration cap and whether it is a hard stop. Don't run any shell commands.
▤ AOCL │ L1 identity complete · allowed · 1ms
▤ AOCL │ L3 policy gate complete · proceed · 7ms
◐ SPEND │ status ✔ SPEND │ status │ 1 count, 1 budgets · 1.6s
⛓ AEE │ envelope opened · ops.tool · spend_status ok
⛓ AEE │ envelope opened · stream_success
You have one spend budget, and it won't stop a runaway run. It only warns. • Scope: The budget covers a single agent's iterations, not the whole org or a team. Its scope is "iteration", tied to sentinel-heartbeat . • Cap: The iteration cap is 10,000, and the cost cap is $1.00. It sets no token, tool-call or duration limits. • Hard stop: No. hard_stop is false, so if the run reaches its cap, nothing halts it. • Usage: $0 spent (0%). • Period: The period ran from 8 May to 7 June 2026, so it expired months ago. It may no longer be enforced at all. Nothing caps spend for the org or for any other agent, so a runaway run elsewhere would have no budget watching it. I'd recommend a new org-wide budget with the hard stop switched on, and a fresh period for the existing one. Both are changes, so each would raise an approval card for you. Do you want me to prepare the org-wide one?
14.5s · 1 tool · 0 approvals
quox.✔ Machine verified against the CLI on 4 Nov 2026 · test report mw2g22
The work
Section titled “The work”The whole job took 14.5 seconds and one tool call. Nothing was written, so nothing needed your approval.
- Quox takes the question. The router handed it to Quox, the orchestrator. Before any model ran, the request passed Quox’s five control checks, including who is asking and whether policy lets the request go ahead. All five passed in about 31 milliseconds.
- Quox picks the right tool. Out of 317 tools, 16 were offered for this question. Quox chose one:
spend_status, the read-only view of your budgets. - The budget records are read.
spend_statusreturned in 1.6 seconds with one budget. The call was written to the audit record as an evidence envelope, so it can be traced later. - Quox reads the record, not the label. It checked the scope, every cap, the
hard_stopflag and the budget period, and worked out what each one means for a runaway run. - Quox answers and proposes, but does not act. It told you the budget will not stop a run, then recommended an org-wide budget with the hard stop on and a fresh period for the existing one. It did not make either change. It said each would raise an approval card for you, and asked whether you want the first one prepared.
- The answer is checked on the way out. The final checks (verify and audit) passed and the turn closed with an audit record.
The result
Section titled “The result”The answer, from the budget record itself:
- Budgets set up: one.
- What it covers: a single agent’s iterations (
sentinel-heartbeat), not the whole org and not a team. - Caps: 10,000 iterations and $1.00 of cost. No token, tool-call or duration limits.
- Does it stop a runaway run: no.
hard_stopis false, so when a run reaches its cap, nothing halts it. It only warns. - Is it even live: its period ran from 8 May to 7 June 2026, so it had expired months before the question.
- Everything else: nothing caps spend for the org or for any other agent.
What that got you: the honest picture, which is not the reassuring one. Your spend control was a warning on one agent, and an expired one. You learned it from a question, without anything being changed behind your back, and the fix is waiting on your yes.
This is the budget record the proof engine read with quox budget list during the run:
scope_kind iterationscope_id sentinel-heartbeatperiod_start 2026-05-08T19:04:55.440Zperiod_end 2026-06-07T19:04:55.440Zmax_iterations 10000max_cost_usd_micro 1000000max_tokens nullmax_tool_calls nullmax_duration_ms nullhard_stop falseDo it yourself
Section titled “Do it yourself”Two read-only commands show the same thing from the CLI. List your budgets, then look at how much of one is used:
quox budget listquox budget usage <id>Look at hard_stop and period_end first. A budget with hard_stop false only warns, and a budget whose period has ended may not be watching anything.
How it is checked
Section titled “How it is checked”The proof engine asked the question above through chat and judged the answer against the budget records, not against what Quox said about them. It passed when:
- the number of budgets in the answer matched the count from
quox budget list; - the scope in the answer matched the main budget’s real
scope_kind; - the answer named the iteration cap and spoke to the hard stop, read from the same record;
- no shell command ran, and the answer never claimed to have created or changed a budget, or called the spend unlimited.
All five checks passed, in order.
Receipts
Section titled “Receipts”The run shown above is public at ev_mw2g223y_8e6f23, recorded on 4 November 2026. The same Journey passed again on 5 November 2026, at ev_mw2tmmpc_2a98f4. The receipts are the evidence, not this page.
The evidence bundle for the published run (ev_mw2tmmpc_2a98f4) is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role). The transcript above is from the earlier run, so it is not part of this bundle. Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw2tmmpc_2a98f4.json. It passes only if the bundle is the copy we published and witnessed, unchanged.
The proof engine rates this Journey VERIFIED: it passed on two UTC days, 4 and 5 November 2026.
Quox-verified, not independently audited: the run was checked by Quox’s own proof engine against the running system, and the evidence id is published so you can recompute it. It is not a third-party audit.