Tendril
Loading lesson…
An autonomous soul without a budget is a credit-card-on-fire. Rate limits, max iterations, kill-switches, and cost caps are not optional — they're how heartbeats stay safe. Why heartbeats need budgets A reactive agent costs tokens when the user prompts.
A reactive agent costs tokens when the user prompts. A heartbeat soul costs tokens every time it beats — even when it decides to do nothing. A bug, a recursive trigger, or a self-paced soul that picks 'wake me in 1 second' can drain a $200 monthly budget in an afternoon. Budgets are the line between an autonomous agent and a financial incident.
soul:
name: pr-reviewer
heartbeat:
type: event
on: [webhook: github.pull_request.opened]
budget:
rate_limit:
max_per_minute: 6
min_interval_seconds: 5
max_iterations: 500 # auto-stop after 500 beats
cost_cap:
tokens_per_day: 2000000
usd_per_day: 25
on_cap_hit: pause_and_notifyAll four layers in one block. Rate limits stop runaways; max_iterations stops forgotten loops; cost caps stop billing surprises; on_cap_hit decides what 'stop' means.A circuit breaker watches the soul's behavior and trips when something looks wrong. Three patterns are worth setting up by default: error-rate breakers (pause if more than 50% of beats fail), no-op breakers (pause if 100 beats in a row produced zero useful action — the soul might be stuck), and divergence breakers (pause if the soul's tool calls suddenly look unlike its baseline). Breakers don't kill the soul — they pause it and notify a human.
| Failure mode | What you'd see | Which guard catches it |
|---|---|---|
| Self-paced loop picks tiny intervals | Token graph spikes, hundreds of beats per minute | Rate limit + min_interval |
| Misconfigured event trigger fires on every log line | Beats per second go vertical | Rate limit + debounce |
| Soul stuck retrying same failed tool | Same error every beat for an hour | Error-rate circuit breaker |
| Forgotten experiment soul running forever | Steady drip of cost over weeks | max_iterations + cost cap |
| Prompt injection redirects soul's tools | Tool calls suddenly outside baseline | Divergence breaker + audit log |
A good kill switch has three properties: it's fast (one command, no menus), it's authoritative (the runtime guarantees the soul stops, not 'tries to stop'), and it survives a restart (a killed soul stays killed even if the runtime reboots). Test the kill switch before you ship — a switch you've never pulled is not a switch you can trust.
# Pause one soul (next beat won't fire, current beat finishes)
openclaw soul pause pr-reviewer
# Hard kill (current beat aborted, soul marked stopped)
openclaw soul kill pr-reviewer
# Pause every heartbeat soul in the workspace — the panic button
openclaw heartbeat pause --allThree escalating levels. Pause is graceful. Kill aborts mid-beat. The --all panic button is for incidents — drill it once a quarter so you know it works.The big idea: a heartbeat without a budget is a runaway waiting to happen. Four layers — rate limit, max iterations, cost cap, kill switch — plus circuit breakers for the smart cases. Build them before the first beat fires.
15 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-openclaw-heartbeats-budgets-runaways-creators
What is the core idea behind "Heartbeat Budgets And Runaway Prevention"?
Which term best describes a foundational idea in "Heartbeat Budgets And Runaway Prevention"?
A learner studying Heartbeat Budgets And Runaway Prevention would need to understand which concept?
Which of these is directly relevant to Heartbeat Budgets And Runaway Prevention?
Which of the following is a key point about Heartbeat Budgets And Runaway Prevention?
Which of these does NOT belong in a discussion of Heartbeat Budgets And Runaway Prevention?
Which statement is accurate regarding Heartbeat Budgets And Runaway Prevention?
Which of these does NOT belong in a discussion of Heartbeat Budgets And Runaway Prevention?
What is the key insight about "The first runaway is always free" in the context of Heartbeat Budgets And Runaway Prevention?
What is the key insight about "Budget by default, not by exception" in the context of Heartbeat Budgets And Runaway Prevention?
What is the recommended tip about "Evaluate systematically" in the context of Heartbeat Budgets And Runaway Prevention?
Which statement accurately describes an aspect of Heartbeat Budgets And Runaway Prevention?
What does working with Heartbeat Budgets And Runaway Prevention typically involve?
Which of the following is true about Heartbeat Budgets And Runaway Prevention?
Which best describes the scope of "Heartbeat Budgets And Runaway Prevention"?