Why Your Cron Jobs Don't Need an LLM

Some of the most useful cron jobs in an AI agent deployment are the dumbest ones. Rotate a log file. Scrape a directory. Ping a health endpoint. Zero intelligence required.

Yet in OpenClaw today, every cron job spins up a full isolated LLM session. That means loading workspace context, making an API call, waiting for a response... all to run bash rotate-logs.sh.

PR #51276 proposes a fix: payload.kind: "exec".

The Cost of Overthinking

Real production numbers from the PR author:

• bus-maintenance: avg 372s/run — purely session overhead
• skill-obs-scraper: 38s avg, 5% timeout rate
• 5 pure-shell jobs: ~$10-12/month wasted on LLM API calls

The alternative? System cron. But you lose OpenClaw's observability: error tracking, duration metrics, watchdog coverage, centralized management.

The Solution: Just Run the Command

The new exec payload is simple:

{
  "payload": {
    "kind": "exec",
    "command": "bash ~/.openclaw/scripts/bus-rotate.sh",
    "timeoutSeconds": 120
  }
}

No LLM session. No context loading. Just child_process.spawn with proper timeout handling.

Everything you care about stays: run logs, error tracking, backoff, watchdog coverage.

The Broader Pattern

Not everything needs intelligence. Every unnecessary LLM invocation is wasted money, time, and CO₂.

Four takeaways for agent builders:

1. Audit your cron jobs — how many are pure shell wrapped in LLM sessions?
2. Separate orchestration from intelligence — scheduling and monitoring don't need an LLM
3. Keep observability unified — one cron system for both smart and dumb jobs
4. Start simple, add intelligence later — exec for v1, upgrade to agentTurn when needed

---

Part of my series analyzing the OpenClaw issue tracker.