The AI budget guard, end to end
The guard is asked twice: before an outbound call is placed, and before an inbound one is answered. It refuses for two reasons — the AI budget is spent, or the model account itself is refusing — and both used to sound identical to a caller, because both were silence. A refused inbound call is now answered, given the closed-line message in the business's own voice, and recorded.
Why a separate guard exists at all#
Telephony minutes and model spend are two different accounts, and the carrier's cap says nothing about whether the model can be paid for. The outbound path booked minutes against the telephony ceiling and nothing asked the other question, which is how the AI ledger ran past a configured limit with blocking switched on and calls still connecting.
The guard closes that gap by asking, before a word is spoken, what one call *could* cost if it ran to the full configured ceiling — both sides of the conversation at the audio rate for the whole cap. Not what it will cost: what it could, which is the only figure available before the call exists.
The two refusals#
| Finding | Where it comes from | What happens to the call |
|---|---|---|
| The model account is refusing | The provider breaker, mirrored from the voice worker through settings | Refused, with the reason named — out of quota, or a rejected key |
| The worst case exceeds the AI budget | The cost guard, against the configured ceiling for voice | Refused before the carrier is asked to do anything |
| The guard itself is unavailable | An error inside the guard | The call proceeds. A broken guard must not bar calls |
Stage by stage#
- Trigger — an outbound call is about to be placed, or an inbound call has arrived at a line and is about to be answered.
- User or external event — for inbound, a real person is on the line right now. That fact governs every choice below.
- Authentication and workspace resolution — the workspace comes from the line that was dialled, not from the caller's number, which is only ever data about the call.
- Ingest or request — the engine asks the guard, passing the voice configuration so the ceiling and the call cap are the ones actually in force.
- Canonical record — a refused inbound call still creates a call row. Before that, a refusal was a call nobody could see afterwards.
- Reasoning — none yet. The guard runs before the model session opens, which is the entire point: an unaffordable call should not first cost a model call to discover it.
- Knowledge, memory and rules — the closed-line message is composed from the business's own persona, so a refusal sounds like the business rather than like a system.
- Autonomy and approval — untouched. The guard is about affordability, and a workspace's rules about placing calls are checked separately, on their own terms.
- Action through a provider — on a refusal, nothing is asked of the carrier for an outbound call; for inbound, the worker speaks one sentence and hangs up.
- Result — outbound: a refusal carrying the reason. Inbound: an ended call, zero duration, hung up by the agent, with the refusal code as its outcome.
- Relationship, timeline and memory — the call appears in the caller's history as a call that was answered and closed with a reason, not as a mystery.
- Audit, usage and Needs You — the refusal is recorded, the summary says the caller heard the closed-line message, and the line's health surfaces for a person.
What the caller hears#
A sentence, in the business's voice, and then the line ends. It is not a good outcome — a caller who wanted an answer did not get one — but it is an outcome, and the alternative is worse than it sounds. Answering into a model that cannot speak produces a connected call with nothing on it, which the caller experiences as being ignored by a business that picked up.
The record matters as much as the sentence. A refused inbound call is a call row with a zero duration, an outcome naming the refusal, and a summary saying the caller heard the closed-line message. Somebody reviewing the day can see that three people rang and were turned away, which is exactly the signal that was missing when the room was simply deleted without a word.
- The line being switched off produces the same shape of refusal, with its own code.
- A call outside the line's configured hours produces one too, unless the line routes after-hours calls to the agent anyway.
- All three are visible on the call record and none of them is silence.
Getting calls flowing again#
Find out which of the two refusals it is. The reason is on the call record and on the line's health.
Result You know whether to change a budget or fix an account, which are unrelated actions.
If the model account is refusing, resolve it at the provider — the key or the account itself.
Result The breaker closes on the next successful call rather than on a timer you have to wait out.
If it is the budget, raise the ceiling or let the period turn over.
Result The guard's next answer is different immediately; nothing is cached and no restart is needed.
Place one test call before assuming the line is well.
Result A single successful call is the only evidence that both accounts are answering.
Questions#
Does the guard stop a call already in progress?
No. It is asked before a call starts. A call already running is bounded by the configured session cap and by the sweep that closes rows nothing can end any more, which also charges what it closes.
Why does a refusal cost anything at all?
It barely does — the refused inbound call speaks one short sentence, which is a fraction of a conversation. The cost avoided is the whole call that would otherwise have run against an account that cannot pay for it.
What if the guard itself breaks?
Calls proceed. A guard that fails closed would turn its own bug into an outage for the business, which is a worse failure than a call that runs when the budget was tight.