Mac Mini Persistent Claude Code Pattern — Evaluation

TL;DR

The current Mission Control architecture is the community-validated pattern. You're not behind — you already built it. The one gap worth piloting: a persistent /loop session for Telegram instead of spawning a fresh Claude CLI instance per message. Everything else (cron, MCP, LaunchAgents) should stay as-is.

What the Community Pattern Describes

Headless Mac Mini + Telegram interface + MCP + cron → handles CRM, briefings, lead alerts, invoicing

The architecture is validated. The community arrived at the same destination.

The One Real Gap: Session Model

Current Telegram flow:

Message arrives → telegram_watcher.py → spawn claude CLI (new session, 20min max) → reply → session dies

Community "persistent" pattern:

Message arrives → route to long-running Claude session → reply → session stays alive

Why this matters for Telegram specifically:

• Conversation context doesn't carry across messages (each spawn is fresh, limited to 5-exchange history in JSON)
• 20-minute session timeout can cut off mid-task
• Spawn overhead (2-4s) on every message
• /loop keeps MCP connections warm — no re-init per message

Why this doesn't matter for scheduled tasks:

• Cron + spawn-per-task is correct for scheduled automation: isolation, parallelism, clean failure recovery
• Don't swap LaunchAgents for a persistent session loop

June 15 Billing Risk — Flag

Starting June 15, 2026: claude -p and programmatic Claude Code usage moves to a separate non-rollover credit pool at full API rates.

A persistent /loop session for Telegram would likely fall under programmatic usage. Before piloting:

• Estimate monthly Telegram message volume × average session cost
• Size against the programmatic credit pool for your tier
• If volume is low (< 50 messages/day), the persistent model is probably fine
• If volume is high, the spawn-per-message model may actually be cheaper (you only pay when messages arrive)

Recommendation: Don't pilot persistent sessions until after June 15 billing is understood.

What to Actually Pilot

Option A: /loop for Telegram (Persistent Session)

• Replace telegram_watcher.py spawn-per-message with a persistent claude --loop session
• Telegram messages are fed as input; replies go back via API
• Risk: June 15 billing, context accumulation over long sessions, harder crash recovery
• Benefit: Natural conversation continuity, no spawn overhead, MCP stays warm

Option B: Improve Spawn-Per-Message (Current Path)

• Extend history TTL from 30min → 4h
• Increase MAX_HISTORY from 5 → 10 exchanges
• Use prompt caching for the system prompt (saves 40-60% on repeated context)
• Risk: None — incremental improvement to working system
• Benefit: No billing exposure, no architecture change, quick to implement

Option C: Hybrid — Persistent for Telegram, Cron for Scheduled

• Keep all 50+ LaunchAgents exactly as-is
• Only swap Telegram watcher to persistent /loop model
• Evaluate after June 15 billing is understood
• Risk: Medium — Telegram watcher is a critical path (Cole's primary interface)
• Benefit: Full community pattern without disrupting scheduled automation

Recommendation

Do Option B now. Revisit Option C after June 15.

Rationale:

1. Current system has 23 active scripts, 50+ LaunchAgents — it's working
2. June 15 billing changes could make persistent sessions expensive
3. The biggest pain point (conversation context loss) is solvable with longer history without architecture changes
4. The community pattern is validated by what you've already built — no need to rebuild

Specific action for Option B:

• In telegram_watcher.py: increase HISTORY_TTL from 30min to 4 hours
• Increase MAX_HISTORY from 5 to 15 exchanges
• Add prompt caching header to the Claude API calls in the API path

If You Want to Pilot the Persistent Model Anyway

Minimal pilot scope (2 hours of work):

1. Create scripts/telegram_loop.py — wraps /loop with Telegram I/O
2. Run it manually for 48 hours alongside the existing watcher (shadow mode)
3. Compare: response latency, context quality, crash frequency
4. Decide after data, not theory

Don't touch LaunchAgents, the orchestrator, or the 50+ scheduled scripts — that's not what the community pattern is about.

Conclusion

The Mac Mini persistent Claude Code pattern is confirmed viable by community use. Mission Control already implements 95% of it. The remaining 5% (persistent vs spawn-per-message for Telegram) is an optimization, not a gap. Evaluate after June 15 billing changes are understood.

Effort to implement Option B: ~30 minutes Effort to implement Option C: ~2-4 hours + monitoring Risk of doing nothing: Zero — current system is production-ready