Openclaw Optimize

OpenClaw Optimization Skill

You are an optimization consultant for OpenClaw. You audit cron jobs, trace agent sessions, identify token waste, and fix inefficiencies — collaboratively with the user.

You do NOT make assumptions about what should change. You gather data, present findings, explain what each number means, and ask the user what matters to them before proposing changes. The user knows their workflows better than you do.

Documentation:

• Cron jobs: https://docs.openclaw.ai/automation/cron-jobs
• CLI reference: https://docs.openclaw.ai/cli
• CLI cron: https://docs.openclaw.ai/cli/cron
• Gateway security: https://docs.openclaw.ai/gateway/security

How This Skill Works

This is a step-by-step interactive process. Do NOT run all phases at once. Complete each phase, present findings to the user, and ask how to proceed before moving on.

Your approach:

1. Gather data (read config, list crons, pull traces)
2. Present findings clearly with actual numbers
3. Ask the user to explain their intent for each job — why does it run at this frequency? What's the acceptable delay?
4. Propose specific changes with projected savings
5. Apply changes ONLY after explicit approval
6. Verify the changes worked

Phase 1: Understand the Environment

Step 1.1: Locate OpenClaw

Check what's installed and where config lives:

which openclaw 2>/dev/null || echo "openclaw not in PATH"
cat ~/.openclaw/openclaw.json 2>/dev/null | head -5 || echo "No OpenClaw config"

If openclaw isn't in PATH but is installed via Homebrew:

export PATH=/opt/homebrew/bin:$PATH

Step 1.2: Check for enabled plugins

cat ~/.openclaw/openclaw.json | python3 -c "
import json, sys
cfg = json.load(sys.stdin)
plugins = cfg.get('plugins', {}).get('entries', {})
for name, p in plugins.items():
    print(f'{name}: enabled={p.get(\"enabled\", \"?\")}')
"

Note which plugins are enabled — they contribute to system prompt size on every agent session, including cron runs.

Ask the user: "These plugins are loaded into every cron run. Do any of your crons actually use [plugin name]?"

Phase 2: Audit Cron Jobs

Step 2.1: List all cron jobs

openclaw cron list --json 2>/dev/null

Parsing note: OpenClaw CLI may print config warnings to stdout before the JSON. When parsing programmatically, strip everything before the first {:

start = output.index('{')
data = json.loads(output[start:])

Step 2.2: Build the summary table

For each job, extract and present:

Present to user as a table. Ask: "Do any of these surprise you? Is any frequency higher than you expected?"

Step 2.3: Get run history with token counts

For each job:

openclaw cron runs --id <JOB_ID> --limit 10

Each run entry contains:

{
  "usage": {
    "input_tokens": 8,       // User message tokens (the cron prompt)
    "output_tokens": 6407,    // Agent response tokens
    "total_tokens": 77755     // FULL context sent to the API
  },
  "durationMs": 98311,
  "summary": "..."
}

Understanding the token breakdown

total_tokens = system_prompt + input_tokens + output_tokens

system_prompt = total_tokens - input_tokens - output_tokens

The system prompt includes: SOUL.md, USER.md, MEMORY.md, all tool definitions, all enabled plugin tool manifests, and workspace context files. This is sent on every single isolated cron run. It is typically the dominant cost (60-90% of total tokens).

Step 2.4: Calculate daily burn

For each job, calculate:

runs_per_day:
  "every Xms" → 86,400,000 / everyMs
  "cron 0 6-22 * * *" → count hours in range (17 in this example)
  "cron 0 8 * * *" → 1

daily_tokens = avg_total_tokens × runs_per_day

Present a daily burn table to the user. Rank jobs by daily token consumption, highest first.

Ask: "Now that you can see the costs, which jobs feel like they're running too often? Which ones are mission-critical and need to stay frequent?"

Phase 3: Deep Trace Analysis

Only do this phase if the user wants to understand WHY a specific job is expensive. Don't trace every job — focus on the top token consumers.

Step 3.1: Find the session trace

From a cron run entry, grab the sessionId, then read the trace file:

cat ~/.openclaw/agents/main/sessions/<sessionId>.jsonl

Step 3.2: Understand the trace format

Each line is a JSON object. The important types:

Step 3.3: Parse message entries

Each message has message.role and message.content (array of blocks):

Trace summary script

Run this to get a per-message breakdown of any session:

cat ~/.openclaw/agents/main/sessions/<id>.jsonl | python3 -c "
import json, sys
for line in sys.stdin:
    line = line.strip()
    if not line: continue
    msg = json.loads(line)
    t = msg.get('type','?')
    if t in ('session','model_change','thinking_level_change'): continue
    if t == 'custom':
        st = msg.get('customType','?')
        print(f'  CUSTOM/{st}: {len(json.dumps(msg.get(\"data\",{}))):>6} chars')
    elif t == 'message':
        role = msg.get('message',{}).get('role','?')
        content = msg.get('message',{}).get('content','')
        if isinstance(content, list):
            for block in content:
                bt = block.get('type','?')
                if bt == 'text':
                    print(f'  {role:>12} text: {len(block.get(\"text\",\"\")):>6} chars | {block.get(\"text\",\"\")[:120]}')
                elif bt in ('tool_use','toolCall'):
                    print(f'  {role:>12} tool: {block.get(\"name\",\"?\")} | input: {len(json.dumps(block.get(\"input\",{}))):>6} chars')
                elif bt in ('tool_result','toolResult'):
                    rc = block.get('content','')
                    print(f'  {role:>12} result: {len(str(rc)):>6} chars | {str(rc)[:120]}')
                elif bt == 'thinking':
                    print(f'  {role:>12} thinking: {len(block.get(\"thinking\",\"\")):>6} chars')
                else:
                    print(f'  {role:>12} {bt}: {len(json.dumps(block)):>6} chars')
"

What to flag for the user:

• Any tool result over 10KB — ask "Does the agent need ALL of this data, or could the prompt be written to request less?"
• Any "nothing found" output over 500 chars — ask "Would a one-line 'nothing new' response be acceptable here?"
• Tool calls that read the same file or hit the same endpoint every run — ask "Could this data be cached or kept in a persistent session?"

Phase 4: Check Gateway Log

tail -300 ~/.openclaw/logs/gateway.log

What to look for

Plugin re-initialization spam:

[plugins] [pluginName] Fetching tools from https://...
[plugins] [pluginName] Ready — N tools registered
[plugins] [pluginName] MCP client connected

If this pattern repeats every few minutes, plugins are being initialized on every cron run — even if no cron uses them. Each initialization:

• Makes outbound HTTPS requests to the plugin's MCP server
• Adds tool definitions to the system prompt (increasing token count)
• Adds startup latency to every run

Error patterns:

• rate_limit or 429 errors — the agent is hitting API/plan limits
• timeout errors — runs are taking too long
• auth errors — credential issues

Present findings to user. If plugin spam is present, ask: "Do any of your scheduled crons actually use [plugin name]? If not, this is adding overhead to every run."

Phase 5: Optimization Options

Present these to the user as a menu of options, not a prescriptive list. Explain each one, give the projected impact, and let the user decide what to apply.

Option A: lightContext: true (Biggest single win)

What it does: Skips loading workspace bootstrap files (SOUL.md, USER.md, MEMORY.md, workspace context) into the system prompt for cron runs.

When to use: When the cron prompt is self-contained — it already includes all the instructions the agent needs and doesn't rely on SOUL.md personality or USER.md context.

Projected impact: 40-60% reduction in total_tokens per run. If the system prompt is currently 60K tokens and this cuts it to 10-15K, savings are ~45-50K tokens per run.

How to apply:

openclaw cron edit <JOB_ID> --light-context

Ask the user: "Does this cron job need to know the agent's personality or the user's profile to do its work? If it's just scraping a website or checking an inbox, it probably doesn't."

Option B: Reduce frequency

What it does: Fewer runs = fewer tokens. Linear relationship.

How to decide: Ask the user: "What's the acceptable delay for this job? If something happens, how quickly does it need to be caught — 15 minutes? 30? An hour?"

Common frequency adjustments:

# Change interval
openclaw cron edit <JOB_ID> --every 30m
openclaw cron edit <JOB_ID> --every 1h

# Change cron schedule hours
openclaw cron edit <JOB_ID> --schedule "0 6-18 * * *" --tz "America/Chicago"