How to Set Token Budgets Per Workflow Run

The fastest way to get a surprise five-figure model bill is to let a workflow loop without a budget. An AI step that retries, re-reasons, and re-calls on every pass can burn through tokens faster than any human would ever notice. The fix is boring and it works: set a token budget per workflow run, meter against it as the run executes, and halt when the run blows through it. A budget is not a nice dashboard you check later. It is a hard stop that fires before the damage is done.

I run automation across a portfolio, and the cost of the model calls is a real line item, not a rounding error. Left ungoverned, a handful of chatty workflows will quietly become your biggest expense. So I treat token spend the way I treat any other resource that can run away: I cap it, I measure it, and I make the cap enforceable in code, not in a policy document.

Why per-run budgets beat a monthly bill alarm

A monthly billing alert tells you the house is already on fire. By the time the invoice crosses a threshold, the money is spent. A per-run budget catches the problem at the unit of work, which is where you can actually stop it. If a single run is supposed to cost pennies and it hits a dollar, something is wrong with that run right now, and you want it killed before it does that a thousand more times.

This is the same logic behind why your cloud bill keeps climbing: costs that are invisible at the moment they are incurred always drift up. Making the cost visible and enforceable at the run level is what keeps it flat.

How to set a token budget that actually holds

Budget the run, not just the account. Assign each workflow a maximum token spend per execution. A simple lookup that classifies one email should have a tiny budget. A research task that reads twenty documents gets a larger one. The number comes from what the task is worth, not from what the model is capable of consuming.

Meter as you go. Track tokens consumed across every step in the run. Each model call adds to a running total for that execution. This has to be live. A budget you only reconcile after the run finishes cannot stop a runaway loop mid-flight.

Halt on breach. When a run crosses its budget, stop it. Do not let it start the next step. Park it in a failed state, log the overage, and alert. A hard stop feels aggressive until the first time it saves you from a loop that would have run all night.

Set a step ceiling too. Beyond the run budget, cap tokens per individual step. This catches the pathological case where one step, usually one with an unbounded input, tries to swallow the entire budget in a single call. Ceiling the step and the run and you have caught both the slow bleed and the single gusher.

Where the token spend actually hides

Retries. A step that fails and retries three times spends four times the tokens. If your retry logic re-runs an expensive reasoning step, the budget has to account for it. This is another reason to make AI agents recover from failure at the step level with checkpoints, so a retry does not replay the whole expensive chain.

Re-reasoning loops. An agent that re-plans on every iteration can spin. Bound the iterations and bound the tokens, and the loop cannot become an open drain.

Oversized context. Stuffing a whole document into every call, when the step only needs a paragraph, multiplies cost on every single execution. Trim the context to what the step needs. This is often the single biggest lever, and it costs nothing but attention.

Budgets are a governance control, not just a cost one

A per-run budget is also a safety mechanism. A workflow that suddenly wants ten times its normal token spend is telling you something changed: the input got weird, a loop is stuck, or someone pointed it at the wrong data. The budget breach is a signal, not just a cost cap. I feed those breaches into monitoring the same way I feed any other anomaly, which ties into how you measure AI agent reliability over time.

We enforce per-run and per-step budgets in the execution layer at Girard AI, so no workflow can quietly outspend its worth. Cost control that lives only in a spreadsheet is not control. It has to be code that stops the run. If you are pricing out an automation platform, ask the vendor how it caps spend on a single runaway execution. If the only answer is a billing alert, you are the backstop, and you will find out at the worst possible time.