ClaudeClaw spawns new process per cron job — /loop is 10x more efficient

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title

Persistent session mode: /loop is 10x more efficient than spawning new processes per cron job

Body

Problem

ClaudeClaw currently spawns a new Claude Code process for every cron job and heartbeat trigger. Each new process:

• Loads the full system prompt (~50k tokens)
• Loads CLAUDE.md, rules, plugin descriptions
• Initializes all MCP servers
• Uses ~500-800MB RAM per process

With 6 cron jobs + a 20-minute heartbeat, this means multiple concurrent processes at peak, consuming several GB of RAM and tens of thousands of tokens per trigger — even for simple tasks like sending a 2-sentence Discord reminder.

Real-world impact

Running on a ThinkPad X1 with multiple sessions:

• 15 bun.exe processes running simultaneously at peak
• RAM usage: 4-8 GB just for ClaudeClaw daemon + child processes
• Tokens per heartbeat: ~30-50k (system prompt + CLAUDE.md + plugins + actual task)
• Computer becomes noticeably sluggish during cron bursts

Better approach: persistent session + /loop

A single persistent Claude Code session with /loop achieves the same result:

claude --model sonnet --channels plugin:discord@claude-plugins-official
> /loop 20m "Send a short eye-rest reminder to Discord"

| Metric | ClaudeClaw (current) | Persistent session + /loop |
|--------|---------------------|---------------------------|
| Processes | New process per trigger | 1 persistent process |
| RAM | 500-800MB × N concurrent | ~500MB fixed |
| Tokens per trigger | ~30-50k (full reload) | ~500 (context already loaded) |
| Startup latency | 5-10s per trigger | Near instant |
| Complexity | daemon + jobs/ + settings.json | One session, one command |

Suggestion

Consider adding a persistent session mode to ClaudeClaw where:

1. The daemon maintains one (or a few) long-running Claude Code sessions
2. Cron jobs execute as prompts within the existing session instead of spawning new processes
3. Context is loaded once and reused, with auto-compression handling long-running sessions
4. /loop-style scheduling is built into the daemon architecture

This would make ClaudeClaw viable for always-on personal assistant use cases without destroying system resources.

Environment

• Windows 11 Pro, ThinkPad X1
• Claude Code v2.1.86, Claude Max subscription
• ClaudeClaw v1.0.0
• Use case: personal AI companion with Discord integration, heartbeat reminders, scheduled check-ins

What Should Happen?

Title

Persistent session mode: /loop is 10x more efficient than spawning new processes per cron job

Body

Problem

ClaudeClaw currently spawns a new Claude Code process for every cron job and heartbeat trigger. Each new process:

• Loads the full system prompt (~50k tokens)
• Loads CLAUDE.md, rules, plugin descriptions
• Initializes all MCP servers
• Uses ~500-800MB RAM per process

With 6 cron jobs + a 20-minute heartbeat, this means multiple concurrent processes at peak, consuming several GB of RAM and tens of thousands of tokens per trigger — even for simple tasks like sending a 2-sentence Discord reminder.

Real-world impact

Running on a ThinkPad X1 with multiple sessions:

• 15 bun.exe processes running simultaneously at peak
• RAM usage: 4-8 GB just for ClaudeClaw daemon + child processes
• Tokens per heartbeat: ~30-50k (system prompt + CLAUDE.md + plugins + actual task)
• Computer becomes noticeably sluggish during cron bursts

Better approach: persistent session + /loop

A single persistent Claude Code session with /loop achieves the same result:

claude --model sonnet --channels plugin:discord@claude-plugins-official
> /loop 20m "Send a short eye-rest reminder to Discord"

| Metric | ClaudeClaw (current) | Persistent session + /loop |
|--------|---------------------|---------------------------|
| Processes | New process per trigger | 1 persistent process |
| RAM | 500-800MB × N concurrent | ~500MB fixed |
| Tokens per trigger | ~30-50k (full reload) | ~500 (context already loaded) |
| Startup latency | 5-10s per trigger | Near instant |
| Complexity | daemon + jobs/ + settings.json | One session, one command |

Suggestion

Consider adding a persistent session mode to ClaudeClaw where:

1. The daemon maintains one (or a few) long-running Claude Code sessions
2. Cron jobs execute as prompts within the existing session instead of spawning new processes
3. Context is loaded once and reused, with auto-compression handling long-running sessions
4. /loop-style scheduling is built into the daemon architecture

This would make ClaudeClaw viable for always-on personal assistant use cases without destroying system resources.

Environment

• Windows 11 Pro, ThinkPad X1
• Claude Code v2.1.86, Claude Max subscription
• ClaudeClaw v1.0.0
• Use case: personal AI companion with Discord integration, heartbeat reminders, scheduled check-ins

Error Messages/Logs

Steps to Reproduce

Title

Persistent session mode: /loop is 10x more efficient than spawning new processes per cron job

Body

Problem

ClaudeClaw currently spawns a new Claude Code process for every cron job and heartbeat trigger. Each new process:

• Loads the full system prompt (~50k tokens)
• Loads CLAUDE.md, rules, plugin descriptions
• Initializes all MCP servers
• Uses ~500-800MB RAM per process

With 6 cron jobs + a 20-minute heartbeat, this means multiple concurrent processes at peak, consuming several GB of RAM and tens of thousands of tokens per trigger — even for simple tasks like sending a 2-sentence Discord reminder.

Real-world impact

Running on a ThinkPad X1 with multiple sessions:

• 15 bun.exe processes running simultaneously at peak
• RAM usage: 4-8 GB just for ClaudeClaw daemon + child processes
• Tokens per heartbeat: ~30-50k (system prompt + CLAUDE.md + plugins + actual task)
• Computer becomes noticeably sluggish during cron bursts

Better approach: persistent session + /loop

A single persistent Claude Code session with /loop achieves the same result:

claude --model sonnet --channels plugin:discord@claude-plugins-official
> /loop 20m "Send a short eye-rest reminder to Discord"

| Metric | ClaudeClaw (current) | Persistent session + /loop |
|--------|---------------------|---------------------------|
| Processes | New process per trigger | 1 persistent process |
| RAM | 500-800MB × N concurrent | ~500MB fixed |
| Tokens per trigger | ~30-50k (full reload) | ~500 (context already loaded) |
| Startup latency | 5-10s per trigger | Near instant |
| Complexity | daemon + jobs/ + settings.json | One session, one command |

Suggestion

Consider adding a persistent session mode to ClaudeClaw where:

1. The daemon maintains one (or a few) long-running Claude Code sessions
2. Cron jobs execute as prompts within the existing session instead of spawning new processes
3. Context is loaded once and reused, with auto-compression handling long-running sessions
4. /loop-style scheduling is built into the daemon architecture

This would make ClaudeClaw viable for always-on personal assistant use cases without destroying system resources.

Environment

• Windows 11 Pro, ThinkPad X1
• Claude Code v2.1.86, Claude Max subscription
• ClaudeClaw v1.0.0
• Use case: personal AI companion with Discord integration, heartbeat reminders, scheduled check-ins

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

claude code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_