Safety & Deploy · Free preview

Budget the Agent

Cap the spend before it runs away

An agent in a loop can call tools forever and spend without limit, so a budget guardrail tracks cumulative spend and refuses any call that would push past a fixed cap — letting only the calls it can still afford through.

Cap the spend before it runs away

An agent in a loop is a powerful thing and a dangerous one. Give it a tool and a goal and it will keep calling — search, fetch, summarize, retry, call again — until the goal is met or something stops it. If nothing stops it, "something" is your bill. A planning loop that mis-reads its own progress can fire the same paid tool a thousand times in a minute; an agent left running overnight can burn a month's budget before anyone wakes up. "It'll probably stop on its own" is not a spending limit.

The fix is a budget guardrail: a running total of spend and a fixed cap, checked before every call. The rule is one line of arithmetic — allow a call only if spent + cost <= cap; otherwise refuse it and leave the budget untouched. The key move is what happens after a refusal: you don't stop the whole agent, and you don't quietly let the next call through either. You keep walking the queue, and every call that would still breach the cap keeps getting refused. The guardrail isn't a circuit breaker that trips once — it's a gate that every call must pass.

Walk a concrete budget of 100. search costs 30 → spend is 30, allow. fetch costs 25 → 55, allow. summarize costs 40 → 95, allow. Now translate costs 20: 95 + 20 = 115, over the cap, so refuse — and spend stays at 95, untouched. Here's the subtle part: ping costs only 5, and 95 + 5 = 100 still fits, so it's allowed even though a call just got refused. Then log costs 1: 100 + 1 = 101, over — refused. Final spend lands exactly on 100, never a cent above. A refusal isn't the end of the run; it's just this call not fitting the budget.

Below, the call queue and the print lines are wired, but the guardrail is missing — the loop charges every call and prints ALLOW no matter what, so it sails past the cap to a final spend of 121. Add the check: allow a call only when spent + call.cost <= cap (charge it and print ALLOW <name> (spent X/100)), otherwise print REFUSE <name> (would exceed 100) and don't add its cost. Get it right and the run ends with final spend: 100.

A budget guardrail is the difference between an agent that stops and an agent that stops you — checked before every call, it caps the spend no matter how long the loop runs.

In the full academy, you write and run this — live, graded:

// An agent in a loop can run away: call tools forever, spend without limit.
// A BUDGET GUARDRAIL fixes that — it caps total spend and refuses any call that
// would push cumulative spend past the cap.

const cap = 100;
const calls = [
  { name: "search", cost: 30 },
  { name: "fetch", cost: 25 },
  { name: "summarize", cost: 40 },
  { name: "translate", cost: 20 },
  { name: "ping", cost: 5 },
  { name: "log", cost: 1 },
];

// Run the calls in order, tracking cumulative spend.
let spent = 0;
for (const call of calls) {
  // TODO: this is the guardrail. ALLOW the call only if it still fits the budget:
  //   if (spent + call.cost <= cap) -> charge it and ALLOW, else REFUSE it.
  // Right now there is NO cap check — it allows everything and overspends.
  spent += call.cost;
  console.log(`ALLOW ${call.name} (spent ${spent}/${cap})`);
}
console.log(`final spend: ${spent}`);

🔒 Live code execution, real agent runs, mastery tracking and verifiable credentials unlock with the full academy.

This is 1 of 50 lessons.

The full academy: write real code, watch real agents run, and earn verifiable credentials — across 8 tracks, in a 3D campus.

Unlock the full academy — $100 →

14-day refund · 🔒 Stripe-secured checkout · lifetime access

More free lessons: An LLM Is a Function  ·  The Agent Loop  ·  Define a Tool  ·  Give an Agent a Tool  ·  Durable State

← The Agent Marketplace