If OpenClaw ever made you think, âI just burned money and got nothing,â you are not alone.
Most cost incidents are not model-quality problems. They are operator posture problems:
- runs that do not leave evidence (so you rerun them),
- broad tools before you have a stable debug loop,
- loose DM policies (so the system can be triggered too easily),
- and no kill switch when something starts looping or flooding.
This checklist is designed to be implemented in under an hour, even if you are not a hardcore operator.
0) The one rule: start bounded, expand deliberately
Do not start from âfull toolsâ and âopen DMsâ and then try to claw back safety.
Start from a bounded posture that still produces useful outcomes, then expand one dimension at a time.
If you want ready-made safe baselines, start here:
1) Tool guardrails (the fastest way to avoid runaway capability)
If your agent âonly chatsâ or âwonât use toolsâ, you are likely too narrow.
If your agent can do everything, you are likely too broad.
Pick a deliberate tools profile:
- For messaging-first workflows: keep
profile: "messaging"and add only what you need. - For a trusted coding machine: use
profile: "coding"(notfullby default).
Fix guide + safe examples:
2) Channel guardrails (reduce who can trigger you)
Cost and safety are channel problems too.
Minimum defaults:
- DMs: use
pairingorallowlist(avoidopen) - Groups: require mentions (avoid âreply to everythingâ)
Channel guides:
If you are using your personal WhatsApp number for testing and nothing replies, that is often a self-chat policy issue:
3) Evidence guardrails (the cheapest reliability upgrade)
When you cannot see what happened, you keep retrying, and spend becomes unpredictable.
Adopt two defaults:
- runs always write an artifact (file) in the workspace
- runs always produce a short human-readable âdoneâ message
Start here:
4) Model-path guardrails (probe, do not infer)
If you see:
- âno outputâ,
- âall models failedâ,
- or âeverything is rate limitedâ,
do not debug by conversation. Probe the model path directly:
openclaw models status --probeFix guide:
If you use relays/proxies, baseUrl + API mode mismatches are a classic cost sink:
5) Exec guardrails (do not âaccidentallyâ enable host power)
If you want host execution, treat it as a deliberate operator choice.
Two practical rules:
- do not try to bypass approvals by stuffing interpreters into
safeBins - decide whether commands run on the gateway host or a node host, because approvals are enforced where execution happens
Start here:
6) Kill switch (one-minute incident response)
When something starts looping or flooding, do not keep tweaking config mid-incident.
Have a one-minute sequence that:
- stops sending (disable the channel or stop the gateway)
- preserves evidence (logs + state)
- restores from a known-good config if needed
Minimum evidence capture:
openclaw status --all
openclaw logs --limit 400 --plainBackup/rollback discipline:
If the symptom is duplicate/flashy streaming previews (a common âflood-lookingâ panic):