DEV Community: ramsbaby

I turned my Claude Max subscription into a 24/7 AI company — here's what actually happened

ramsbaby — Wed, 18 Mar 2026 10:45:26 +0000

I turned my Claude Max subscription into a 24/7 AI company — here's what actually happened

Six months ago I asked myself a dumb question: if I have a $100/month Claude Max subscription, why is it only answering my questions for 30 minutes a day?

So I built something. I call it Jarvis Company — a personal AI automation system where Claude runs as a full-time employee 24/7, not a chatbot.

This is not a tutorial. This is a story about what I built, what actually works, and what I was completely wrong about.

The idea

I'm a backend developer. I spend most of my day writing code, reviewing docs, tracking news, maintaining side projects, and forgetting to do all of the above.

The insight was simple: Claude doesn't need to sleep.

So instead of using Claude as a question-answering chatbot, I built a structure where Claude runs scheduled jobs — like a company with departments.

Jarvis Company (me = CEO)
  └── 7 "team leads" running as cron jobs
        ├── 📡 TrendHunter     — 07:30 daily, scans tech/market news
        ├── 🔍 Audit           — 23:00 daily, reviews bot quality & KPIs
        ├── 📚 Academy         — 20:00 Sunday, generates learning plans
        ├── 🗄️ Recorder        — 23:50 daily, consolidates memory
        ├── ⚙️ Infra           — 09:00 daily, system health checks
        ├── 🚀 Growth          — 09:00 Monday, career & side project nudges
        └── 📣 Brand           — 08:00 Tuesday, open source activity

Each "team lead" is a bash script that calls Claude via the SDK with a specific system prompt and task. Results are posted to a private Discord server where I can see everything in one place.

What it actually does today

After months of iteration, this is running in production (on my Mac Mini):

56 scheduled tasks across 7 teams
~40 Claude invocations per day on average
Discord as the UI — every report, alert, and insight goes to a specific channel
Memory system — RAG-based context that persists across sessions
Escalation logic — critical issues get flagged to a "CEO channel" (me)

Real examples of things that happened this week:

Morning briefing summarized 3 papers and 2 product launches relevant to my work
Audit team caught that my bot was producing zero-tool responses (a regression I'd missed)
Growth team reminded me I haven't pushed to my open source repo in 11 days

Is this magic? No. Is it surprisingly useful? Yes.

What I got completely wrong

Wrong assumption #1: More crons = more value

I peaked at 64 scheduled tasks. Most of them were producing reports nobody read (me included). I just cut it back to 56, and the signal-to-noise ratio improved immediately. Less is more.

Wrong assumption #2: This could be a popular open source tool

I submitted to Hacker News. Got 2 points and 0 comments.

Honest self-assessment: this is not a general tool. It's deeply personal infrastructure. It requires:

A Claude Max subscription ($100/month)
macOS (hardcoded paths everywhere)
Setting up Discord, webhooks, LaunchAgents
Understanding what you want automated

It's closer to "sophisticated dotfiles" than a product. And that's fine.

Wrong assumption #3: AI will figure out what's important

Early versions had Claude summarize everything. The output was verbose and I stopped reading it.

The real value came when I was specific: "Find papers published in the last 7 days about WebFlux performance" is 10x better than "summarize tech news."

The more opinionated the prompt, the more useful the output.

The architecture (briefly)

I'm not going to pretend this is easy to replicate. But conceptually:

[LaunchAgent / launchd]
    ↓ triggers
[bash script: bot-cron.sh]
    ↓ loads task config from tasks.json
[Claude SDK (Node.js)]
    ↓ system prompt + task context
[Claude runs with tools]
    → reads files, calls APIs, checks logs
    ↓ result
[Discord webhook → private server channel]
    ↓
[Me, reading it over morning coffee]

The key design decision: Claude has tools. It's not just generating text — it can read files, run shell commands, query APIs. That's what makes the outputs actually grounded in reality.

What I'd do differently

If I were starting over:

Start with 3 tasks max — one morning briefing, one daily recap, one anomaly detector
Define "done" for each task — what does a good output look like? Write it down before prompting.
Build the Discord UI first — having a readable output channel forces you to make the output worth reading
Track whether you act on it — I have 56 tasks but probably only respond to ~20% of outputs. The other 80% are noise I'm slowly eliminating.

Is it worth $100/month?

For me, yes — but not because of the automation.

The real value is that Claude Max means no usage anxiety. I can let it run all day, fail, retry, and explore without watching a token counter. The 24/7 company only works if you're not rationing.

If you're on the free tier or a cheaper plan, most of this isn't viable.

What you can actually steal from this

Even if you don't build the whole system:

The "team" mental model — assign Claude a role with a specific responsibility. It produces better outputs than a generic assistant.
Discord as a personal ops dashboard — free, mobile-friendly, and infinitely customizable with webhooks
Scheduled briefings — even one morning summary cron can meaningfully improve how you start your day
Memory as a first-class concern — if your AI doesn't remember last week, every conversation starts from zero

What's next

I'm slowly open-sourcing the interesting pieces — not as a "install this and get a company" package, but as reference implementations of patterns I found useful.

If you're building something similar — personal AI infrastructure, Claude automation, Discord bots — I'd genuinely like to compare notes.

The code is at: https://github.com/ramsbaby/jarvis-discord

Drop a comment if you've tried something like this. Especially interested in hearing what you actually stopped automating.

Built with Claude Max + Node.js + bash + too much coffee.

Jarvis — self-hosted AI butler on Discord (Claude-powered)

ramsbaby — Wed, 18 Mar 2026 09:47:03 +0000

TL;DR

Jarvis is a self-hosted personal AI assistant that lives in your Discord server. Powered by Claude, it manages tasks, executes shell commands, monitors systems, stores long-term memory via RAG, and coordinates multiple AI agents — all from your phone.

GitHub: https://github.com/ramsbaby/jarvis

Why I built this

I wanted an AI assistant that actually does things — not just chats. One that runs on my own hardware, remembers past conversations, and is reachable from my phone 24/7.

Discord turned out to be the perfect UI: mobile notifications, slash commands, channel-based context separation.

Architecture

Discord (mobile)
     |
 discord-bot.js  <- router
     |
  +--+------------------+
  |  Claude API (sonnet) |
  |  MCP Tools           | <- exec, rag_search, health, file_peek
  |  Agent SDK           | <- multi-agent orchestration
  |  LaunchAgents (macOS)| <- scheduled crons
  +---------------------+

Key Features

Multi-Agent Council — Specialized agents (Career, Finance, Security, Health) run on schedules, post summaries to dedicated channels, and a Council agent synthesizes cross-agent insights.

RAG Memory — Conversation history is embedded and searchable. When you reference past discussions, Jarvis searches vector memory, not just the current context window.

Real Execution — Run shell commands, tail logs, check system health, manage files — all from Discord mobile.

Schedule-Aware — Integrated with external calendars for real-time schedule + earnings data.

Install in 30 seconds

git clone https://github.com/ramsbaby/jarvis
cd jarvis
bash install.sh

Requires: Node 22+, macOS, Claude API key, Discord bot token.

What I learned

Discord > custom web UI for personal AI. Mobile-first, always-on, zero maintenance.
LaunchAgents > crontab on macOS — more reliable, survives reboots, proper logging.
MCP structured tools make LLM responses dramatically more accurate than free-form prompts.
RAG memory changes the relationship — it stops feeling like a tool and starts feeling like a collaborator.

v1.1.0 | 64 E2E tests | CI passing

https://github.com/ramsbaby/jarvis ⭐

I built Jarvis — a self-hosted AI butler on Discord powered by Claude

ramsbaby — Wed, 18 Mar 2026 09:46:35 +0000

TL;DR

Jarvis is a self-hosted personal AI assistant that lives in your Discord server. It runs on Claude (Anthropic), manages tasks, reads Preply schedules, executes shell commands, monitors systems, stores long-term memory via RAG, and coordinates multiple AI agents — all from your phone via Discord.

GitHub: https://github.com/ramsbaby/jarvis

Why I built this

I wanted an AI assistant that:

Lives on my phone (Discord mobile)
Remembers context across sessions (RAG memory)
Actually executes things — not just chat
Runs on my own hardware — no cloud lock-in
Is extensible — new agents, new tools, new channels

Existing solutions were either too limited (just chat) or too complex to self-host. So I built Jarvis.

Architecture

Discord (mobile UI)
    │
    ▼
discord-bot.js        ← message router
    │
    ├── Claude API    ← LLM backbone (claude-3-5-sonnet)
    ├── MCP Tools     ← exec / file / health / rag / nexus
    ├── Agent SDK     ← multi-agent orchestration
    └── LaunchAgents  ← macOS scheduled crons

Jarvis runs as a macOS LaunchAgent (launchd), auto-starting on login. All scheduled tasks (daily KPIs, security scans, weekly career reviews) are also LaunchAgents — no crontab hacks.

Key Features

🤖 Multi-Agent Council

Multiple specialized agents (Career, Finance, Security, Health) run on schedules and post summaries to dedicated Discord channels. A Council agent synthesizes insights across all agents.

🧠 RAG Memory

Conversation history + context files are embedded and searchable. Ask "기억해?" ("remember?") and Jarvis searches vector memory, not just the current context window.

⚙️ Real Execution

Jarvis can run shell commands, peek at files, tail logs, check system health, list/create/delete cron jobs — all from Discord.

📅 Schedule-Aware

Integrated with Preply (wife's tutoring schedule) — ask "오늘 수업 있어?" and get today's lessons with earnings.

🔒 Secret-Safe

API keys live in $BOT_HOME/config/secrets/ (gitignored). The install script sets up the directory structure and guides through token setup.

Installation (30 seconds)

git clone https://github.com/ramsbaby/jarvis
cd jarvis
bash install.sh

Requires: Node 22+, macOS (LaunchAgents), Claude API key, Discord bot token.

What I learned

1. Discord is a surprisingly great AI UI. Mobile notifications, slash commands, channel-based context separation — it works better than any custom web UI I could have built.

2. LaunchAgents > crontab. On macOS, com.vix.cron is often disabled. LaunchAgents are more reliable, survive reboots, and have proper logging.

3. MCP (Model Context Protocol) is genuinely powerful. Giving Claude structured tools (exec, rag_search, health) instead of free-form text makes responses dramatically more accurate and actionable.

4. RAG memory changes the relationship with an AI. When it actually remembers past conversations, it stops feeling like a tool and starts feeling like a collaborator.

Current Status

v1.1.0 released (2026-03-17)
64 E2E tests passing
GitHub Actions CI passing (Node 22)
Used daily for task management, system monitoring, schedule tracking

What's next

Phase 3: Discord /approve for AI-drafted documents
Web dashboard (read-only)
Linux / systemd support
More agent types (Finance deep-dive, Travel planner)

If you're building something similar or have feedback, I'd love to hear it. Star the repo if it's useful ⭐

https://github.com/ramsbaby/jarvis

Self-hosted AI ops on Mac mini: Claude Max + Discord + MCP at $0/month extra

ramsbaby — Tue, 17 Mar 2026 04:34:53 +0000

Running a personal AI operations system for 2 months now. Here's the full architecture.

Hardware & Stack

Hardware: Mac mini M2 (always on, silent, no cloud bill)
Runtime: Node.js + bash
Memory: LanceDB (local vector) + SQLite (queues)
UI: Discord
AI engine: claude -p headless CLI (included in Claude Max $20/month)

What runs 24/7

Reactive Discord chat — multi-turn threads, session memory, RAG knowledge base
30 scheduled cron tasks — standups, market alerts, code audits, log rotation, vault sync
11 specialized agent teams — each has a role, schedule, and output channel
Self-healing infrastructure — 4-layer recovery: preflight → keepalive → watchdog → Claude AI diagnosis

The Context Intelligence Gateway

Main problem with 24/7 Claude agents: context window fills up in 20-30 minutes on heavy workloads.

Built a local MCP server (Nexus CIG) that intercepts every tool output, classifies type (JSON/log/table/markdown), extracts signal, drops noise before it hits Claude's context window.

315 KB raw output → 5.4 KB compressed (~98%)

Sessions now run 3+ hours reliably.

Numbers

Uptime: 99.7%
Context savings: ~98% on heavy tool use
Incidents: 14 total, 9 auto-resolved (64% autonomous recovery)
Extra cost: $0/month

Open source (MIT)

https://github.com/Ramsbaby/claude-discord-bridge
https://github.com/Ramsbaby/openclaw-self-healing — autonomous crash recovery
https://github.com/Ramsbaby/openclaw-memorybox — memory hygiene CLI

Happy to answer questions about any part of the architecture.

I turned my idle Claude Max subscription into a 24/7 AI company — $0 extra

ramsbaby — Tue, 17 Mar 2026 04:34:05 +0000

Two months ago I realized my Claude Max subscription was idle 23 hours a day. So I built a 24/7 AI operations system around it.

What it does

11 specialized AI teams — Infra, Trend, Record, Brand, Academy, Career, Standup, Security, Finance, Recon, Council
30 automated cron tasks — morning standups, market alerts, code audits, memory management, log rotation
Real-time Discord chat — ask questions, Claude answers instantly in threads with context memory
4-layer self-healing — crashes auto-diagnose using Claude, recover in ~30 seconds
98% context compression — custom MCP server keeps sessions running 3+ hours

The key insight

claude -p is Claude Code's headless CLI, included in the Max subscription. Spawn unlimited processes at zero incremental cost.

The Context Intelligence Gateway (Nexus CIG)

Built a local MCP server that sits between Claude and every system call. Instead of dumping raw logs/JSON into context, it classifies output type, extracts signal, drops noise.

Result: 315 KB → 5.4 KB (98%). Sessions run 3+ hours vs 30 min without it.

Numbers after 2 months

$0 extra per month (Max subscription only)
99.7% uptime (14 incidents, 9 resolved autonomously)
3+ hour sessions with Nexus CIG active
60/61 E2E tests passing

GitHub

Main repo: https://github.com/Ramsbaby/claude-discord-bridge
Self-healing: https://github.com/Ramsbaby/openclaw-self-healing (28 ⭐)
Memory CLI: https://github.com/Ramsbaby/openclaw-memorybox

Would love to hear if anyone else is running Claude agents 24/7. What's your approach to context management?

I Finally Fixed My AI Self-Healing System (After It Was Broken for Weeks)

ramsbaby — Mon, 23 Feb 2026 02:07:04 +0000

I Finally Fixed My AI Self-Healing System (After It Was Broken for Weeks)

I built an AI-powered self-healing system for my personal AI Gateway. It has four tiers of recovery, uses Claude Code as an emergency doctor, and sends alerts to Discord.

It was also completely broken at the most critical handoff — for weeks — and I had no idea.

This is the story of how I found the bug, why it was invisible, and what v3.1.0 does to fix it.

The System I Built

OpenClaw Self-Healing is a 4-tier autonomous recovery system for OpenClaw Gateway (an AI agent orchestration service). The tiers work like this:

Level 1 → launchd/systemd auto-restart
          (process crash → restart in seconds)
            ↓ (if still failing after 3 retries)
Level 2 → gateway-watchdog.sh
          (HTTP health check every 60s)
            ↓ (if failing for 30+ minutes)
Level 3 → emergency-recovery-v2.sh
          (Claude Code AI diagnosis + repair)
            ↓ (always, on Level 3 trigger)
Level 4 → Discord/Telegram notification
          (human escalation)

The idea: small problems fix themselves automatically. Big problems get an AI doctor. Critical problems wake up the human.

The Bug I Missed

Here's what gateway-watchdog.sh looked like in v3.0.0 (simplified):

consecutive_failures=$((consecutive_failures + 1))

if [[ $consecutive_failures -ge 30 ]]; then
    log "CRITICAL: 30+ consecutive failures. Escalating to Level 3..."
    # TODO: invoke emergency recovery
fi

See it? The log message says "Escalating to Level 3." The code never actually does it.

The emergency-recovery-v2.sh script existed. It was tested in isolation. But the watchdog never called it. The chain was broken at exactly the point where it mattered most.

Why It Was Invisible

This is the insidious part: everything looked fine.

Level 1 was working (launchd restarted crashed processes)
Level 2 was running (the watchdog was checking health every 60s)
Logs showed activity: [WARN] Health check failed (attempt 2/3)
The system appeared operational

The only way to catch this was to simulate a long-duration failure — one that lasted more than 30 minutes — and watch whether Level 3 actually fired.

I hadn't done that test. I assumed the chain worked because each component started successfully.

The Second Bug

While fixing the watchdog, I found another problem.

The installer (install.sh) in v3.0.0 set up Level 2 (the health check cron) and Level 1 (the launchd plist). But it never created .env.

Without .env, emergency-recovery-v2.sh would fail silently — no DISCORD_WEBHOOK_URL, no CLAUDE_API_KEY. Level 3 would attempt to run and immediately exit. Level 4 notifications would never fire.

Both ends of the chain were broken.

What v3.1.0 Fixes

1. The Escalation Logic

# gateway-watchdog.sh v4.1
consecutive_failures=$((consecutive_failures + 1))

if [[ $consecutive_failures -ge 30 ]]; then
    log "CRITICAL: 30+ consecutive failures. Invoking Level 3 emergency recovery..."

    if [[ -f "$EMERGENCY_RECOVERY_SCRIPT" ]]; then
        bash "$EMERGENCY_RECOVERY_SCRIPT" &
        emergency_pid=$!
        log "Emergency recovery launched (PID: $emergency_pid)"
    else
        log "ERROR: Emergency recovery script not found at $EMERGENCY_RECOVERY_SCRIPT"
        notify_discord "Level 3 unavailable — manual intervention required"
    fi
fi

The fix is three lines. The diagnosis took two days.

2. Graceful .env Loading

# emergency-recovery-v2.sh
ENV_FILE="${HOME}/.openclaw/.env"

if [[ -f "$ENV_FILE" ]]; then
    # shellcheck source=/dev/null
    source "$ENV_FILE"
    log "Environment loaded from $ENV_FILE"
else
    log "WARNING: .env not found at $ENV_FILE — Discord alerts may fail"
    # Continue anyway; Claude recovery can still run
fi

The script now handles missing .env gracefully instead of dying silently.

3. Installer Rewrite

The old installer did this:

Create launchd plist for Level 1
Set up health check cron for Level 2
Done ✓

The new installer does this:

Interactive setup (collect API keys, webhook URLs)
Create .env with all required variables
Create launchd plist for Level 1
Set up health check cron for Level 2
Wire Level 2 → Level 3 escalation path
Verify the full chain is connected
Run a test invocation of each level

Step 6 is new. The installer now outputs:

✅ Level 1: launchd plist loaded
✅ Level 2: watchdog cron active  
✅ Level 3: emergency recovery script found + executable
✅ Level 4: Discord webhook reachable (HTTP 204)
✅ Chain verification: all levels connected

If any level fails verification, the installer tells you what's wrong and how to fix it.

The Meta-Lesson

I fell into a trap I see often in infrastructure work:

"I have a monitoring/alerting/recovery system" ≠ "my monitoring/alerting/recovery chain is actually connected."

Testing that each component starts is not the same as testing that the system works end-to-end. A log message that says "escalating" is not the same as code that escalates.

For any multi-tier recovery system, the tests that matter are:

Simulate a failure that triggers Level N
Verify Level N+1 actually runs
Verify Level N+1's output reaches the next tier
Repeat for every handoff

It's tedious. It's the only way to know.

Install / Upgrade

# Fresh install
curl -sSL https://raw.githubusercontent.com/Ramsbaby/openclaw-self-healing/main/install.sh | bash

# Upgrade from v3.0.0
cd ~/openclaw-self-healing
git pull origin main
bash install.sh --upgrade

Supports macOS (launchd) and Linux (systemd). Level 3 requires CLAUDE_API_KEY. Levels 1, 2, and 4 work without it.

GitHub: https://github.com/Ramsbaby/openclaw-self-healing

If you've built something similar — or found a similar "looks fine, is broken" bug in your own infrastructure — I'd love to hear about it in the comments.

Building a Self-Healing AI System with Claude Code: When Your AI Doctor Fixes Your AI Assistant

ramsbaby — Mon, 09 Feb 2026 11:54:48 +0000

The Problem: 3 AM Wake-Up Calls

You know that feeling when your home automation dies at 3 AM and you have to SSH into your server half-asleep? I got tired of it.

I run OpenClaw, a Claude-powered AI assistant platform, on my home server. It's great when it works, but servers crash. Configs get corrupted. Things break.

So I built a self-healing system that uses Claude Code as an emergency doctor for my AI assistant.

Architecture: 4 Levels of Recovery

Level 1: Quick Restart (30 sec)
    ↓ if fails
Level 2: Claude API Diagnostics  
    ↓ if fails
Level 3: Claude Code Deep Repair
    ↓ if fails  
Level 4: Recovery Mode + Alerts

Level 1: The Watchdog

A simple LaunchAgent that runs every 60 seconds:

#!/bin/bash
if ! pgrep -f "openclaw gateway" > /dev/null; then
    openclaw gateway start
    echo "Gateway restarted at $(date)" >> /var/log/openclaw-recovery.log
fi

This catches 90% of issues. Simple crashes? Fixed in 30 seconds.

Level 2: Intelligent Diagnostics

When Level 1 fails 3 times, we call the Claude API to analyze the situation:

curl -X POST "https://api.anthropic.com/v1/messages" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -d '{
    "model": "claude-sonnet-4-20250514",
    "messages": [{
      "role": "user", 
      "content": "Analyze this error and suggest fixes: '$ERROR_LOG'"
    }]
  }'

Claude identifies patterns like:

Config syntax errors
Permission issues
Port conflicts
Missing dependencies

Level 3: Claude Code as Emergency Doctor

This is where it gets interesting. When diagnostics aren't enough, we unleash Claude Code:

/opt/homebrew/bin/claude -p \
  "You are an emergency recovery agent. The OpenClaw gateway is down.
   Error: $ERROR_LOG

   1. Analyze the root cause
   2. Attempt to fix it
   3. Validate the fix
   4. Report what you did"

Claude Code can:

Read and edit config files
Check system state
Run diagnostic commands
Apply fixes autonomously

Level 4: Recovery Mode

If all else fails, the system:

Sends Discord/Telegram alerts
Creates a detailed incident report
Enters safe mode with minimal config

Real-World Example

Last week, a config corruption crashed my gateway. Here's what happened:

19:15:00 - Gateway crashed
19:15:30 - Level 1: Restart attempted (failed - config error)
19:16:00 - Level 1: Retry (failed)
19:16:30 - Level 1: Retry (failed)
19:17:00 - Level 2: Claude API diagnosed "Invalid JSON in config"
19:17:05 - Level 3: Claude Code activated
19:17:30 - Claude Code: Found corrupted unicode character
19:17:45 - Claude Code: Fixed config, validated syntax
19:18:00 - Gateway restarted successfully

Total downtime: ~3 minutes. Without this system? I'd have woken up to broken automations.

Key Lessons

Lock mechanism is crucial - Prevent race conditions between watchdog and recovery scripts

LOCK_FILE="/tmp/openclaw-emergency-recovery.lock"
if [ -f "$LOCK_FILE" ]; then
    echo "Recovery in progress, skipping..."
    exit 0
fi

Absolute paths for LaunchAgents - Limited PATH means you need full paths like /opt/homebrew/bin/claude
Graduated escalation - Don't jump to heavy solutions; simple restarts solve most problems

Get the Code

The full implementation is open source:

GitHub: Ramsbaby/openclaw-self-healing

Includes:

Installation scripts
LaunchAgent configurations
All recovery scripts
Detailed documentation

What's Next?

I'm working on:

Pattern learning - Remember past failures to prevent recurrence
Predictive health - Detect issues before they cause crashes
Multi-node support - Coordinate recovery across distributed systems

Have you built self-healing systems? I'd love to hear about your approaches in the comments!

This post is part of my journey building autonomous AI infrastructure. Follow for more posts about Claude, home automation, and making computers fix themselves.

I Built a Self-Healing AI System Using Claude Code as Emergency Doctor

ramsbaby — Sat, 07 Feb 2026 01:26:05 +0000

The Problem

My OpenClaw AI gateway kept crashing at 3am. Every morning I'd wake up to a dead agent. Manual restarts were getting old.

The Solution: 4-Tier Self-Healing

I built an autonomous recovery system with escalating levels:

Level 1: Watchdog (180s interval)

Simple process monitoring. If the gateway process dies, restart it.

Level 2: Health Check (5min interval)

HTTP 200 verification with 3 retries. Catches zombie processes that are running but not responding.

Level 3: Claude Code Doctor (30min session)

Here's where it gets interesting. When Level 2 fails 3 times, the system spawns a Claude Code session in tmux. Claude reads logs, diagnoses issues, and attempts autonomous repair.

# Claude runs in PTY, has full system access
tmux new-session -d -s emergency-recovery
tmux send-keys "claude --dangerously-skip-permissions" Enter

Level 4: Discord Alert

If even Claude can't fix it, humans get notified.

Why This Matters

This is AI fixing AI. The meta-level self-healing: when your AI agent dies, another AI diagnoses and repairs it.

Results

Verified recovery on Feb 5, 2026
30-minute autonomous diagnosis window
Zero 3am wake-up calls since deployment

One-Click Install

curl -sSL https://raw.githubusercontent.com/Ramsbaby/openclaw-self-healing/main/install.sh | bash

GitHub: https://github.com/Ramsbaby/openclaw-self-healing

Built by Jarvis (an AI assistant) for ramsbaby. Questions welcome!