Run Cost Limits

Set a hard credit budget on a workflow so a single run can never spend more than you allow. Learn how the cap is enforced and what happens when it's reached.

Updated Jun 2026

What a Run Cost Limit Does

A run cost limitis a hard cap on how many credits a single run of a workflow can spend. It's your safety net: if a workflow loops more than you expected, calls a tool too many times, or simply does more work than planned, the limit stops it before the spend gets out of hand.

The limit applies to each run on its own. Every time the workflow runs, it starts fresh with the full budget — the cap is not a shared monthly pool.

Great for testing

When you're building or tweaking a workflow, set a modest limit so an unexpected loop or a misconfigured step can't run up a surprise bill. Once you trust it, you can raise the limit or remove it entirely.

Setting a Limit

Open your workflow and go to Settings → Execution → Run Cost Limit. Drag the slider to choose a number of credits, or leave it at No limit for unrestricted runs.

That's it — the limit is saved with the workflow and applies to every future run, including scheduled and triggered runs.

How the Limit Is Enforced

The limit is a hard cap. The run's spending is checked at every point where it could cost credits:

  • before each step starts
  • before each pass of a loop (so a long list can't blow past the cap)
  • before each tool call
  • before each AI response

The moment any of these checks shows the cap has been reached, the run stops. This is why a workflow that loops over hundreds of items, or an AI step that calls many tools, stays safely within the budget you set.

What Happens When It's Reached

When a run hits its limit, it stops and is marked as Budget exceededin your execution history. You'll see a clear panel showing the budget you set, how much was spent, and a prompt to raise the limit if you want future runs to go further.

The run does not silently keep going — that's the whole point of a hard cap.

Finished Work Is Kept

Stopping a run early doesn't throw away the work it already did. Any steps that finished — and any items a loop already processed — are saved, so you still get partial results you can review or reuse.

Example

Say a workflow processes a list of 500 customers and hits its limit at customer 180. The results for customers 1–180 are kept and available in the run's output; the run simply doesn't start customer 181.

A Note on Small Overruns

A run can edge slightlypast the cap — at most the cost of a single AI reply that was already being generated when the limit was reached. We can't un-spend an AI response that's already underway, so the final total may land a touch over the number you set. In practice this is small, and it's the only way a run can exceed its limit.

Parallel loops are best-effort

If a loop is set to run several items at the same time (parallel processing), the items already in progress when the cap is reached will finish, so spend can go over by more than a single reply for that one step. For the strictest possible enforcement, run loops one item at a time.

Tips

  • Set a limit while building and testing, then raise or remove it once you trust the workflow.
  • If runs keep stopping early, check your execution history to see what consumed the credits — a runaway loop or an AI step doing more than expected is the usual cause.
  • Use a tighter limit on workflows that loop over large lists, where costs can add up quickly.