Budget OpenClaw sub-agent runs before putting them on a schedule

Quick answer

Before scheduling a sub-agent, measure a few representative runs, price their input and output tokens separately, and multiply by the number of runs you actually expect. Include retries and a budget for unusually large runs. Compare that incremental amount with your existing agent bill, rather than calling the entire bill the cost of delegation.

Collect a sample that resembles the new job

Run the proposed task manually several times before automating it. From your provider usage record, note the model, billed input and output tokens, and the price applied to each run. Record whether the run produced an accepted result, failed, or launched another child. A research run, a code-edit run, and a retry after a failed test can have different token shapes; do not average them together until you know how often each occurs.

Keep the sample free of secrets when sharing a worksheet. Usage totals and a description of the job are enough. You do not need to paste an API key, full prompt, or private output into a cost estimator.

Work the incremental cost, not the sticker price

For each run: (billed input tokens / 1,000,000 x input price) + (billed output tokens / 1,000,000 x output price). Use your provider's current rate and billing categories, not a price copied from an older blog post. Sum the cost of all child runs in a parent task; then multiply by the planned tasks per day and active days. If you have cached input or other billed categories, use the provider's actual charge for those categories instead of pricing every token at one blended rate.

Here is a hypothetical arithmetic example, not a customer result or a current provider quote. Suppose a completed child run uses 10,000 input tokens at an illustrative $2 per million and 2,000 output tokens at an illustrative $8 per million. Its estimated charge is $0.020 + $0.016 = $0.036. Twelve such runs per day for 30 days would add $12.96 before retries. If one in five scheduled tasks consumes a second run, budget another 72 runs in that period: $2.59 more, for roughly $15.55 total. The extra work is counted as billed runs even if it does not yield another accepted task.

Check the expensive tail

An average alone hides a long debugging loop. In your sample, separately record the median run and the largest run, plus runs abandoned after a timeout. Put a per-task limit on child launches, set an alert against the period budget, and decide who can stop the schedule if the tail grows. A cap on the number of launches is not a token cap: one oversized run can still exceed the typical charge.

Repeat the measurement after changing the model, task instructions, or tool policy. If a cheaper model needs more retries, compare cost per accepted task as well as cost per run. If a parent also spends tokens coordinating children, keep its extra usage in the same incremental budget rather than attributing it to the child model.

Use the Clawback calculator as a scenario check

The free calculator has separate primary, heartbeat, and sub-agent model selectors, plus a sub-agents-per-day control. Set the daily frequency and child model to sketch a before-and-after scenario. Its sub-agent estimate assumes 8,000 input and 4,000 output tokens per spawn and projects 30 identical days. It does not import usage records or accept a custom child token mix, so use the worksheet above when your observed runs differ. Check the menu's displayed prices against your actual provider rate. For a single workflow, leave the channels control at one: the calculator multiplies all three categories by that setting.

If you need recurring spend tracking rather than a one-off estimate, request early access. That link currently opens an email request, not a self-service account or a paid checkout.

Decision checklist

• Can you name the outcome that makes a child run worth paying for?
• Do you have a representative token sample and the current rates for its model?
• Have you counted failed runs, retries, parent coordination, and unusual large runs?
• Is the budget based on active days and real schedule frequency, not a default slider?

If any answer is no, test the job on a small schedule first. A precise monthly number without measured workload data is false precision.