Budgets & approvals

askTheodor is built to let workers do real work unattended — which only feels safe because of the guardrails around them. This page covers that safety system: how spending is capped, how risky actions are gated behind your approval, and how to stop everything at once.

Budgets — cap the spending

Every worker run that uses an AI model costs a little money (you pay your provider per token). A Budget puts a ceiling on that:

• Scope — a budget can apply to one worker (persona), to a Company, or globally across everything (the master cap for unattended and Fleet runs).
• Cap and alert — set a monthly cap, and a warning threshold (e.g. alert at 80%).
• Warn vs hard-stop — a budget can simply warn (visibility only) or hard-stop: once the cap is hit, the app refuses the next model call and tells you inline. No surprise bills.

Per-tool limits

Beyond money, you can bound how much a worker does in a single run: limits on how many times a given tool may be called (and how much it may spend), plus a ceiling on how many back-and-forth iterations a run can take. The app is also model-aware about context size, trimming a conversation to fit the model rather than blowing past its window. Together these stop a worker from spinning in circles or hammering a tool.

The approval gate

Some actions shouldn’t happen without a human nod. When a worker tries a tool you’ve flagged — anything irreversible or destructive (sending an email, posting publicly, deleting, modifying production data) — the run pauses, drops the request into an approvals queue, and notifies you. You see exactly what it wants to do and approve or reject it. The same gate guards Plans: a plan waits in pending approval until you say go.

You can streamline the common cases (“always allow this worker to run this tool”) without lowering the bar for the genuinely risky ones, and for sensitive Routines you can even require several approvals in order.

The kill-switch

Above everything sits a single Autonomy switch. Flip it off and all unattended activity pauses — plans, routines, channel replies, heartbeats. One click, everything stops. It’s the big red button for when you want to halt the workforce immediately, no matter what’s running.

Nothing goes out silently

By default, sending an email or posting publicly is approval-gated, and inbound messages produce drafts, not sends. The app prepares; you decide what actually leaves your machine.

Tune it once

Set a sensible global budget and turn on the gate for the tools that scare you. After that you can let workers run with confidence, knowing the ceiling and the brakes are in place.

In practice

Set a global budget with hard-stop on before your first unattended run. Not after. The allowlist bounds what a runaway loop can do; only the budget bounds what it can cost. Pick a number you’d be annoyed but not hurt by, and raise it later once you know your real monthly spend.

Gate by consequence, not by how advanced the tool sounds. The rule that holds up: anything reaching a customer or the public stays gated permanently, regardless of how well a worker has been performing. Anything reversible and private — reading files, searching, writing to your own notes — should be pre-approved, or the queue fills with noise.

A noisy queue is a broken queue. If you’re approving twenty identical harmless items a day, you will start skimming, and the one that mattered will go through with the rest. The fix is pre-approving that action, not reading faster.

Layered limits, in the order they bite: the tool allowlist (can it invoke this at all?), per-run and per-tool caps (can it do it fifty times?), the budget (can it afford to?), and approvals (should a human see it first?). They solve different problems — none substitutes for another.

The realistic failure is human

In practice the gate rarely fails; attention does. Keep the queue short enough that every item still gets a real decision, and spot-check approved work occasionally rather than trusting a clean record.

🎓 Learn it hands-on: Approvals: humans approve, agents prepare · Autonomy & the kill-switch

Terms in this page

• Budget — a spending cap scoped to one worker, a Company, or everything globally, with an alert threshold and an optional hard stop.
• Token — the unit AI models read and write in; providers bill per token, which is what budgets track.
• Hard-stop — a budget mode that refuses further model calls once the cap is reached (versus warn-only).
• Per-tool limit — a cap on how often (and how much) a single tool may be used in one run.
• Iteration / max-iterations — one back-and-forth step in a worker’s run; a ceiling stops runaway loops.
• Context window — how much text a model can consider at once; the app trims to fit it.
• Approval gate — a checkpoint that pauses a run and waits for your OK before an irreversible or destructive action.
• Approvals queue — the list of pending requests awaiting your decision.
• Irreversible / destructive action — something hard to undo (send, post, delete, modify production), which the gate protects.
• Autonomy kill-switch — the single global control that pauses all unattended activity at once.
• Plan / Routine — multi-step projects and scheduled jobs that the gate and budgets apply to; see Plans and Routines.