Inspiration

Traditional operating systems weren't built for AI. The kernel manages processes. systemd manages services. cron manages schedules. But none of these tools can reason, adapt, or heal themselves.

We asked: what if you rebuilt every core OS utility — the scheduler, the monitor, the service manager, the CLI — around intelligence instead of configuration files?

The answer is JARVIS OS: an operating system where AI IS the system layer. Not an app on top of Linux — but the orchestration brain running beneath everything, replacing dumb daemons with reasoning agents.

What it does

JARVIS OS rebuilds core system utilities as autonomous AI agents on Ubuntu 24.04 across a 6-GPU cluster (46GB VRAM).

AI-Native System Utilities replacing traditional OS tools:

  • j.py — AI CLI replacing bash: j status, j heal, j flow, j models load. One command, full cluster awareness.
  • Domino Engine — replaces cron/systemd: 835 automation chains that trigger and self-repair based on system state. Not schedules — conditions.
  • Self-Healing Service Manager — replaces manual systemctl: 18 services monitored by AI. When M1 crashes → auto-reroutes OL1 → M2 → M3 → cloud. Zero human intervention.
  • COWORK Engine — replaces manual DevOps: 662+ autonomous missions that audit code, detect gaps, write new scripts, and improve the system continuously.
  • Voice Shell — replaces the terminal: 2,658 voice commands via Whisper CUDA (<300ms). "Jarvis, heal cluster" executes a full repair sequence.
  • Weighted Consensus Scheduler — replaces single-process decisions: every critical task voted by 5+ AI models (M1/M2/M3/OL1/Gemini/Claude), quorum ≥ 0.65.
  • GPU Orchestrator — replaces nvidia-smi: real-time load balancing across 6 GPUs with auto-scaling and crash recovery.

Stats: 928+ MCP handlers | 2,728 commits | v15.4 | MIT License

How we built it

  • OS base: Ubuntu 24.04, kernel 6.17, systemd
  • Languages: Python (asyncio, aiosqlite) + TypeScript (MCP servers)
  • Inference: LM Studio (qwen3-8b, deepseek-r1) + Ollama + Gemini + Claude SDK
  • Voice: Whisper CUDA → intent router → Piper TTS
  • Orchestration: OpenClaw WebSocket gateway — 40 agents, 7 providers
  • Automation: n8n (32 workflows) + 835 Domino chains
  • Storage: SQLite (etoile.db 58MB+), Redis, Elasticsearch
  • Cluster: 4 nodes — M1 (127.0.0.1:1234), OL1 (11434), M2 (192.168.1.26), M3 (192.168.1.113)

Hard rules enforced at architecture level:

  • NEVER localhost → ALWAYS 127.0.0.1 (avoids 10s IPv6 penalty)
  • NEVER single-model decisions → always weighted consensus
  • NEVER manual restarts → always self-healing cascade
  • ALL inference local → zero data leaves the machine

2,728 commits. 18 months. One engineer. Daily shipping.

Challenges we ran into

  1. Condition-based triggers vs cron — Domino chains needed circular dependency detection, saturation limits, and deadlock prevention without a supervisor process.
  2. Self-healing without infinite loops — naive watchdogs restart crashed services forever. We built circuit breakers with exponential backoff (>80% CPU → re-route, not retry).
  3. Consensus under 5 seconds — 4+ heterogeneous models agreeing on system actions in real-time required parallel dispatch, per-node timeouts, and LRU caching of recent decisions.
  4. Voice latency under compute pressure — maintaining <300ms Whisper CUDA while 10+ background agents run required dedicated GPU pinning and process priority management.
  5. IPv4 discipline at scale — every "localhost" reference caused 10s IPv6 delays. Full audit of 662+ scripts enforced via CI hook.

Accomplishments that we're proud of

  • ✅ Every core OS utility rebuilt as an AI agent — scheduler, monitor, CLI, service manager, voice shell
  • ✅ 835 Domino chains running 24/7 — self-repaired hundreds of times without human intervention
  • ✅ <300ms voice-to-action latency on local GPU — fully sovereign, no cloud
  • ✅ 6-model weighted consensus — no single point of AI failure
  • ✅ 2,728 commits — 18 months of continuous daily iteration
  • ✅ Full MIT open-source release with 144+ documented skills and CI/CD pipeline
  • ✅ Zero cloud dependencies for core operations — runs air-gapped

What we learned

The OS layer is the most underexplored territory in AI systems engineering.

Everyone builds AI apps on top of the OS. Nobody rebuilds the OS itself.

When you replace dumb init scripts with reasoning agents, you stop configuring systems and start describing intent. "Keep the cluster healthy" becomes a running goal, not a cron job.

Strict architectural rules enforced at infrastructure level — not documentation — are what make autonomous systems actually reliable.

Local AI at scale is viable: 46GB VRAM across 6 consumer GPUs beats cloud setups on latency-sensitive multi-agent workloads at a fraction of the monthly API cost.

What's next for JARVIS OS

  • Legion Architecture v16.0 — 600 agents in 10 specialized legions with vectorial dispatch scoring
  • Open Skill SDK — external developers plug JARVIS skills into the MCP orchestration layer
  • Self-evolving codebase — COWORK already writes scripts, next it proposes architectural changes and A/B tests its own improvements
  • JARVIS Sovereign Edition — SQLCipher AES-256 storage, zero-telemetry, air-gapped enterprise deployment
  • Federated cluster — remote nodes via secure WebSocket bridges for distributed inference ## What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for JARVIS OMEGA

Built With

Share this project:

Updates