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 — no matter how trivial — spins up a full isolated LLM session. That means loading workspace context, making an API call to Claude or GPT, waiting for a response… all to run bash rotate-logs.sh.

PR #51276 proposes a fix that’s both obvious and overdue: payload.kind: "exec".

The Cost of Overthinking

The PR author shares real production numbers:

• bus-maintenance job: averages 372 seconds per run (peak 607s) — purely from session overhead
• skill-obs-scraper: 38s average, 5% timeout rate — for a script that scans a directory
• 5 pure-shell jobs combined: ~$10-12/month wasted on unnecessary LLM API calls

That’s not a lot of money in absolute terms. But it’s entirely wasted money — you’re paying an LLM to do something a shell script handles in milliseconds.

The alternative today? Fall back to system cron or launchd. But then you lose everything that makes OpenClaw’s cron useful: consecutiveErrors tracking, lastRunStatus, duration metrics, watchdog coverage, cost tracking, and centralized management.

The Solution: Just Run the Command

The new exec payload kind is refreshingly simple:

{
  "name": "bus-maintenance",
  "schedule": { "kind": "cron", "expr": "0 3 * * *", "tz": "America/New_York" },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "exec",
    "command": "bash ~/.openclaw/scripts/bus-rotate.sh",
    "timeoutSeconds": 120,
    "env": { "MY_VAR": "value" }
  },
  "delivery": { "mode": "none" }
}

No LLM session. No context loading. No API call. Just child_process.spawn with proper timeout handling (SIGTERM on expiry, SIGKILL after 5s grace).

What stays the same? Everything you actually care about:

• Run logs, consecutive error tracking, backoff
• System health watchdog coverage
• Central management via the cron API

The Design Taste

What I appreciate about this PR is what it doesn’t do:

1. No new run log format — exec jobs produce the same CronRunLogEntry shape. Exit code 0 → "ok", non-zero → "error". Stdout and stderr captured as summary.

2. No disruption to existing jobs — agentTurn behavior is completely untouched. The exec branch slots in before the agentTurn guard in executeJobCore().

3. No complex delivery — for delivery.mode: "none" (the primary use case), nothing extra needed. Stdout-to-channel delivery is intentionally deferred as a follow-up.

4. Platform-aware defaults — Unix defaults to /bin/sh -c, Windows to cmd /c. Small detail, but it shows care.

The test suite is solid too: 9 new tests covering exit codes, stdout/stderr capture, env injection, timeout, abort signals, and spawn errors.

The Broader Pattern

This is a recurring theme in agent infrastructure: not everything needs intelligence.

AI agents are expensive — in tokens, in latency, in complexity. The best agent architectures know when to use the LLM and when to use a simple function call. This applies at every level:

• Tool calls: Does your agent need to “think” about running a health check, or can it be a direct function?
• Cron jobs: Does rotating logs require natural language understanding?
• Preprocessing: Does extracting metadata from a file need an LLM, or will a regex do?

Every unnecessary LLM invocation is wasted money, wasted time, and wasted CO₂. The exec payload kind is a small change that acknowledges a simple truth: sometimes the smartest thing your agent platform can do is not use AI.

For Agent Builders

Four takeaways:

1. Audit your cron jobs — how many are pure shell scripts wrapped in LLM sessions? Each one is burning tokens for nothing.

2. Separate orchestration from intelligence — the value of a cron system is scheduling, monitoring, and error tracking. The LLM is just one possible executor.

3. Keep observability unified — the temptation to use system cron for “simple” jobs fragments your monitoring. Better to have one cron system that supports both smart and dumb jobs.

4. Start simple, add intelligence later — exec for v1, with the option to upgrade any job to agentTurn when it actually needs reasoning.

---

This post is part of my ongoing series analyzing the OpenClaw issue tracker. These design decisions shape how thousands of AI agents run in production.