Skip to content
/

osModa

osmoda · bolivian-peru/os-moda · ★ 99 · last commit 2026-05-22

Primitive shape 113 total
Skills 20 Subagents 2 MCP tools 91
00

Summary

osmoda — osModa (bolivian-peru/os-moda)

osModa is a genuine NixOS-based operating system distribution with an AI-native system management layer — 10 Rust daemons, 91+ structured MCP tools, a TypeScript gateway (osmoda-gateway) with pluggable runtime drivers for Claude Code and OpenClaw, and a self-teaching skill engine (osmoda-teachd). Unlike every other framework in this corpus, osModa is not a Claude Code harness or a methodology — it is an actual operating system that installs to bare metal or cloud VMs, replacing the host OS with NixOS and deploying its daemons via systemd. The agent has root-level access to the entire system through structured MCP tool calls; every mutation is SHA-256 hash-chained to a tamper-proof SQLite audit ledger; NixOS atomic rollback provides safe-rollback for all system state changes. A pre-indexed code knowledge graph (CodeGraph, tree-sitter + SQLite via WASM) gives the agent navigational awareness of codebases without grep.

Compared to the seeds, osModa is unlike any seed archetype — it is closest to the MCP-anchored toolserver pattern (claude-flow Archetype 3) but taken to the extreme: rather than bundling MCP tools as a plugin, osModa is the compute substrate that MCP tools control. The specific delta from claude-flow is: actual OS ownership (not just agent orchestration), NixOS transactional state (not just file state), self-teaching (teachd learns from agent behavior), and CodeGraph pre-indexing.

01

Overview

Overview — osModa (bolivian-peru/os-moda)

Origin

osModa was built to solve the "missing infrastructure half" of AI agent frameworks. From the README:

"Every AI agent framework assumes your infrastructure is someone else's problem. They give you an agent that can think — but nowhere for it to live."

The project is in public beta — described as "a working system deployed on real servers, not a demo."

Philosophy

From README:

"osModa is the other half: the machine itself is AI-native. 91 structured tools across 10 Rust daemons give the AI typed, auditable access to the entire operating system. No shell parsing. No regex. system_health returns structured JSON. Every mutation is SHA-256 hash-chained to a tamper-proof ledger."

Architecture thesis: "Why NixOS? Every system change is a transaction. Every state has a generation number. Rolling back is one command. This makes AI root access meaningfully safer than on any traditional Linux distribution."

Three Trust Tiers

From CLAUDE.md:

TIER 0: Claude Code + agentd (full system, root-equivalent)
  ↓ grants capabilities to ↓
TIER 1: Approved apps (sandboxed, declared capabilities)
  ↓ even more restricted ↓
TIER 2: Untrusted tools (max isolation, no network, minimal fs)

Target Users

  • Solo developers running their own servers (self-healing at 3am)
  • AI agent builders who need infrastructure
  • Small teams tired of on-call rotations
  • "Anyone building an AI workforce" — osModa is the compute substrate for agents

Runtime Architecture

OpenClaw is the DEFAULT/executive runtime (as of 2026.5.20); Claude Code is a fully-supported peer selectable via the Engine tab. The osmoda-bridge (91 system tools) is installed as a native OpenClaw plugin or as an MCP server for Claude Code.

02

Architecture

Architecture — osModa (bolivian-peru/os-moda)

Distribution

  • Type: Full NixOS operating system distribution (not an app or plugin)
  • Install (NixOS flake):
    inputs.os-moda.url = "github:bolivian-peru/os-moda";
    imports = [ os-moda.nixosModules.default ];
    services.osmoda.enable = true;
    
  • Install (any Linux, experimental):
    curl -fsSL https://raw.githubusercontent.com/bolivian-peru/os-moda/main/scripts/install.sh | sudo bash
    
    ⚠️ Converts Ubuntu/Debian to NixOS — destructive, irreversible operation.

Required Runtime

  • Bare metal server, cloud VM (Hetzner, DigitalOcean, AWS), or QEMU/KVM
  • x86_64 or aarch64
  • 2 GB RAM minimum (4 GB recommended), 20 GB disk
  • NOT supported: Docker, LXC, WSL, OpenVZ, any container runtime (lacks systemd)

10 Rust Daemons (crates/)

Daemon Purpose
agentd System bridge daemon — Unix socket API at /run/osmoda/agentd.sock; structured access to processes, services, network, filesystem, NixOS config, sysctl; append-only hash-chained event log in SQLite
agentctl CLI tool for agent control and ledger verification
osmoda-egress Outbound network management
osmoda-keyd API key and credential management
osmoda-mcpd MCP tool server daemon (exposes 91 structured tools)
osmoda-mesh Post-quantum encrypted mesh between servers (port 18800)
osmoda-routines Scheduled autonomous task runner
osmoda-teachd Self-teaching skill engine — learns from agent behavior 24/7
osmoda-voice Voice interface integration
osmoda-watch Service watchdog — detects failures, triggers self-healing

Gateway

  • osmoda-gateway (TypeScript) — pluggable runtime driver interface; supports Claude Code and OpenClaw drivers; routes agent sessions to appropriate runtime; maintains MEMORY.md auto-loaded into system prompt; JSONL transcript per session.

Skills (20+, in skills/)

Skill Purpose
self-healing Detect failures, diagnose root cause, auto-remediate
spec-driven-development Spec-first workflow
morning-briefing Daily briefing from system state
drift-detection Configuration drift detection
system-monitor Continuous system monitoring
security-hardening Security configuration hardening
app-deployer Deploy applications via SafeSwitch
natural-language-config Configure NixOS in natural language
nix-optimizer Optimize NixOS configuration
swarm-predict Multi-agent workload prediction
scaled-swarm-predict Large-scale swarm prediction
flight-recorder Event recording and replay
deploy-ai-agent Deploy new AI agents
file-manager Filesystem management
network-manager Network configuration
generation-timeline NixOS generation history
predictive-resources Resource usage prediction
service-explorer Explore system services
system-config System configuration management
system-packages Package management

CodeGraph Integration

  • Source: colbymchenry/codegraph (MIT, pure-WASM tree-sitter + SQLite)
  • Installed: On every spawn as optional MCP server (env-gated OSMODA_CODEGRAPH_ENABLED=1)
  • Indexes: /opt/osmoda (self-modification), /workspace/* (spec-kit), /srv/* (deployed apps)
  • Auto-sync: osmoda-codegraph-index.timer every 30 minutes
  • Tools: codegraph_search/context/callers/callees/impact/node/explore/files/status
03

Components

Components — osModa (bolivian-peru/os-moda)

MCP Tools (91, served by osmoda-mcpd)

Categories inferred from daemon architecture:

System Management (agentd)

  • system_health — structured JSON system health check
  • service_status — service status queries
  • shell_exec — sandboxed shell execution
  • journal_logs — systemd journal access
  • event_log — append-only hash-chained event log
  • memory_store / memory_recall — persistent memory operations
  • file_read — audited file read

Learning Engine (teachd)

  • teach_context — retrieve historical patterns by context
  • teach_patterns — retrieve learned patterns by confidence
  • teach_optimize_suggest — suggest optimizations from learned data
  • teach_optimize_apply — apply suggested optimizations

CodeGraph (osmoda-codegraph)

  • codegraph_search — semantic code search
  • codegraph_context — code context retrieval
  • codegraph_callers / codegraph_callees — call graph navigation
  • codegraph_impact — impact analysis
  • codegraph_node / codegraph_explore — code graph exploration
  • codegraph_files / codegraph_status — file and index status

Slash Commands

None (0 slash commands in .claude/commands/) — interaction is via MCP tools through the gateway.

Skills (20, in skills/)

See 02-architecture.md for full list. Skills are SKILL.md files with frontmatter including tools: lists specifying which MCP tools the skill uses, and activation: auto where applicable.

agentctl CLI Tool

agentctl — CLI for system management:

  • agentctl verify-ledger — verify SHA-256 hash chain integrity of audit ledger
  • Additional subcommands for agent control and system management

Scripts

Script Purpose
scripts/install.sh Full OS install/conversion script
scripts/deploy-hetzner.sh Hetzner-specific deploy helper

Templates

Skills use tool call templates; templates/ directory present but content not enumerated in public docs.

State Files

File Purpose
/var/lib/osmoda/config/agents.json Agent configuration
/var/lib/osmoda/config/credentials.json.enc Encrypted API credentials
/run/osmoda/agentd.sock Unix socket for agentd
MEMORY.md (per agent) Durable memory auto-loaded into system prompt
GET /sessions/:agent/:key/transcript (JSONL) Session transcript
05

Prompts

Prompts — osModa (bolivian-peru/os-moda)

Excerpt 1: Self-Healing Skill

Source: skills/self-healing/SKILL.md Technique: Tool-call sequence with teachd-first pattern (historical context before live diagnosis) and ordered remediation levels

---
name: self-healing
description: >
  Detect service failures and system anomalies. Diagnose root causes.
  Auto-remediate using NixOS rollback, service restart, or config repair.
  Every action logged to the hash-chained audit ledger.
tools:
  - system_health
  - service_status
  - shell_exec
  - journal_logs
  - event_log
  - memory_store
  - memory_recall
  - file_read
  - teach_context
  - teach_patterns
  - teach_optimize_suggest
  - teach_optimize_apply
activation: auto
---

## Detection

When you detect a service failure or anomaly during a heartbeat check:

1. **Check teachd for historical patterns first** — teachd observes the system 24/7 between conversations

teach_context({ context: "nginx failure service down" }) teach_patterns({ min_confidence: 0.5 })

This surfaces slow-burn issues (memory leaks, recurring failures, correlated events) that you wouldn't catch in a single conversation.

2. **Confirm the failure** — don't act on a single check

service_status({ service: "nginx" })

If the service is down, check again after 10 seconds. If still down, proceed.

## Remediation (ordered by safety)

### Level 1: Restart the service

shell_exec({ command: "systemctl restart nginx" })

### Level 2: NixOS config repair (if restart fails)
[Check NixOS config for the service, apply fix via SafeSwitch with auto-rollback]
### Level 3: Rollback to previous NixOS generation
[Atomic rollback to last known good generation]
### Level 4: Escalate to human
[All levels failed — page the human]

Excerpt 2: CLAUDE.md Trust Tier Architecture

Source: CLAUDE.md Technique: Hierarchical trust model with explicit tier assignments

## Architecture (3 trust tiers)

TIER 0: Claude Code + agentd (full system, root-equivalent) ↓ grants capabilities to ↓ TIER 1: Approved apps (sandboxed, declared capabilities) ↓ even more restricted ↓ TIER 2: Untrusted tools (max isolation, no network, minimal fs)


The agent has FULL system access. Root. All files. All processes. All APIs.
The sandbox exists for UNTRUSTED third-party tools, not for the agent itself.

Excerpt 3: First-Contact Workflow

Source: README.md Technique: Concrete first-action examples to establish agent context immediately

**Try something real** — *"Install nginx and reverse-proxy port 3000"* — it edits NixOS config, 
rebuilds via SafeSwitch with auto-rollback on failure, and reports back. 
The entire operation is hash-chained to the audit ledger.
09

Uniqueness

Uniqueness — osModa (bolivian-peru/os-moda)

Differs From Seeds

osModa is categorically different from all 11 seeds. The closest structural parallel is claude-flow (Archetype 3 — MCP-anchored toolserver) in that both bundle large numbers of MCP tools (claude-flow: 305, osModa: 91) and use SQLite for state. However, the architectural divergence is fundamental: claude-flow is a npm package installed on top of an existing OS; osModa IS the OS. The specific deltas: (1) NixOS transactional state — all system changes are atomic transactions with instant rollback, making AI root access semantically safe in a way no other framework achieves; (2) 10 Rust daemons as system API — 91 structured tools replace ad-hoc shell commands with typed, auditable operations; (3) osmoda-teachd — a self-teaching engine that learns from agent behavior between conversations, with confidence-scored patterns; (4) SHA-256 hash-chained audit ledger — tamper-proof record of every system mutation with cryptographic verification.

Positioning

osModa is the only framework in this entire corpus that targets the "infrastructure substrate" problem rather than the "agent behavioral discipline" problem. All other frameworks assume you have a working computer and want to make the AI agent better at using it. osModa assumes you want a computer whose native language is structured AI tool calls.

Observable Failure Modes

  1. NixOS barrier: Requires full OS replacement — incompatible with Docker, LXC, WSL, any container runtime; high adoption barrier
  2. Public beta roughness: README explicitly states "expect rough edges and rapid iteration"
  3. OpenClaw dependency: Default runtime is OpenClaw (not Claude Code), which is itself a nascent runtime — dependency on two non-mainstream pieces of infrastructure
  4. Root access risk: Despite NixOS rollback safety, the audit ledger note "NixOS rollback covers OS state — not data sent to external APIs or deleted user data" leaves an important escape hatch
  5. Single-node: No distributed consensus; mesh is for encrypted communication, not agent coordination
04

Workflow

Workflow — osModa (bolivian-peru/os-moda)

First-Boot Workflow (5 minutes)

  1. Installcurl | bash or add NixOS flake; OS converts, daemons build, gateway installs
  2. First bootagents.json + encrypted credentials.json.enc created in /var/lib/osmoda/config/
  3. Dashboard → Engine tab → Credentials section → add API key → Test → Save
  4. Agents section → pick runtime (Claude Code or OpenClaw), credential, model → Save
  5. Chat tab → start conversation; agent has all 91+ tools and does initial system_health check

Continuous Operation Workflow

osModa operates as a continuous-daemon system:

Daemon Continuous Activity
osmoda-watch Service failure detection 24/7
osmoda-teachd Pattern learning from agent behavior 24/7
osmoda-routines Scheduled autonomous task execution
osmoda-mesh Encrypted inter-server mesh maintenance

Self-Healing Workflow (from self-healing skill)

  1. Detect: teach_context for historical patterns → service_status to confirm failure
  2. Confirm: Check again after 10 seconds (no action on single check)
  3. Diagnose: journal_logsmemory_recall for past incidents → root cause determination
  4. Remediate (ordered by safety):
    • Level 1: systemctl restart <service>
    • Level 2: NixOS config repair via SafeSwitch
    • Level 3: NixOS generation rollback
    • Level 4: Escalate to human (all levels fail)
  5. Verify: Confirm service health post-remediation
  6. Log: memory_store the incident + teach_context for future learning

Phase-to-Artifact Map

Phase Artifact
Service failure detection Event in hash-chained audit ledger
Root cause analysis Incident workspace in agentd
Remediation NixOS generation change (atomic, rollback-safe)
Self-healing complete Audit ledger entry + memory store

Approval Gates

  • None for automated self-healing within safe remediation bounds
  • Human escalation required when all safe remediation levels fail
  • SafeSwitch auto-rollback if health checks fail after deploy

Scheduled Routines

osmoda-routines daemon handles:

  • Morning briefing generation
  • Drift detection runs
  • CodeGraph index refresh (every 30 minutes)
  • Scheduled maintenance tasks
06

Memory Context

Memory & Context — osModa (bolivian-peru/os-moda)

Memory Architecture

osModa has the most sophisticated memory system in this batch — three distinct layers:

1. Session Transcripts (JSONL)

  • Storage: GET /sessions/:agent/:key/transcript endpoint on osmoda-gateway
  • Format: JSONL per session
  • Purpose: Full session replay capability
  • Persistence: Disk-persisted, runtime-tagged

2. MEMORY.md (Durable System Prompt)

  • File: MEMORY.md per agent
  • Auto-loaded: Injected into system prompt on every session start via osmoda-gateway
  • Purpose: Persistent agent knowledge across conversation restarts
  • Content: Agent learns and updates MEMORY.md through interactions

3. SQLite Audit Ledger (agentd)

  • Storage: SQLite database via agentd (append-only, hash-chained)
  • Purpose: Tamper-proof record of all system mutations
  • Verification: agentctl verify-ledger validates SHA-256 chain integrity
  • Replay: Full audit trail of every system change

4. teachd Learning Engine

  • Storage: SQLite (pattern database)
  • Purpose: Learns from agent behavior between conversations
  • API: teach_context, teach_patterns, teach_optimize_suggest, teach_optimize_apply
  • Confidence scores: Patterns filtered by minimum confidence threshold
  • Temporal: Cross-conversation pattern detection (memory leaks, recurring failures)

5. memory_store / memory_recall (agentd)

  • Purpose: Explicit agent memory storage and retrieval
  • Time-indexed: memory_recall({ query: "...", timeframe: "30d" })

Context Compaction

osmoda-gateway handles transcript re-seed when a runtime session is missing or swapped. MEMORY.md provides compact persistent context that survives session resets.

Cross-Session Handoff

Yes — MEMORY.md auto-loaded on every session start; session transcripts replay-capable; teachd patterns persist across all time.

07

Orchestration

Orchestration — osModa (bolivian-peru/os-moda)

Multi-Agent Support

Yes — multiple agents supported. From CLAUDE.md:

  • osmoda agent: web/full access
  • mobile agent: Telegram/concise mode
  • Multiple agents can be configured via the Engine tab with different credentials, models, and runtimes

Skills reference multi-agent patterns (swarm-predict, scaled-swarm-predict, deploy-ai-agent).

Orchestration Pattern

Event-driven + scheduled. The system runs continuously via systemd daemons:

  • osmoda-watch: event-driven (service failure events)
  • osmoda-routines: scheduled (cron-based autonomous tasks)
  • Agent interaction: event-driven (user chat) or scheduled (routines)

Isolation Mechanism

Three-tier trust isolation:

  • Tier 0 (agent + agentd): full system access
  • Tier 1 (approved apps): declared capabilities, sandboxed
  • Tier 2 (untrusted tools): max isolation, no network, minimal fs

At the OS level, NixOS provides atomic generation-level isolation for system state changes.

Multi-Model Support

Yes — osmoda-gateway supports multiple providers:

  • Anthropic (Claude Claude Pro OAuth or API key)
  • OpenAI (API key)
  • OpenRouter (API key)
  • DeepSeek (API key)

Per-agent model configuration: each agent can be assigned a different model/credential combination.

Multi-Runtime Support

Yes — pluggable runtime drivers:

  • OpenClaw (default executive runtime, 2026.5.20)
  • Claude Code (fully-supported peer)
  • Runtime switch: Engine tab → change Runtime dropdown → Save → zero downtime

Execution Mode

Background daemon (continuous) + event-driven + scheduled.

Crash Recovery

Yes — osmoda-watch detects crashes; self-healing skill handles recovery; NixOS generation rollback for OS-level failures; SafeSwitch auto-rollback on failed deployments.

Consensus Mechanism

None (single-node, multi-agent on same system).

Cross-Tool Portability

Low-to-medium — deeply tied to NixOS and osmoda daemon infrastructure. OpenClaw and Claude Code supported; other runtimes require custom driver development.

08

Ui Cli Surface

UI & CLI Surface — osModa (bolivian-peru/os-moda)

Web Dashboard

Yes — web dashboard at https://spawn.os.moda/#/servers/<your-id>/engine (hosted) or local web UI.

Features observed from README and CLAUDE.md:

  • Engine tab: Runtime selection (Claude Code / OpenClaw), credential management, model selection per agent
  • Chat tab: Direct conversation with agent (all 91+ tools available)
  • Credentials section: Add/test API keys and OAuth tokens
  • Agents section: Configure per-agent runtime, credential, model
  • 3-column detail grid (mentioned in CLAUDE.md)
  • Smooth streaming reveal
  • Live tool-action targets display

agentctl CLI

agentctl — system management CLI:

  • agentctl verify-ledger — verify SHA-256 hash chain integrity
  • Additional subcommands for agent, config, and health management

Telegram Bot

mobile agent configured for Telegram/concise mode — agents accessible via Telegram bot interface.

API

REST API via osmoda-gateway:

  • GET /sessions/:agent/:key/transcript — session transcripts (JSONL)
  • GET /health — system health (JSON)

Observability

  • Audit ledger: SHA-256 hash-chained SQLite append-only log — every system mutation recorded
  • Session transcripts: Full JSONL per-session replay capability
  • teachd patterns: Cross-conversation behavioral learning log
  • NixOS generations: Full system state history with nixos-rebuild --list-generations
  • agentctl verify-ledger for cryptographic ledger integrity verification

This is the most comprehensive observability story in the entire batch — audit log + session replay + learning patterns + OS-level generation history.

Related frameworks

same archetype · same primary tool · same memory type

Personal AI Infrastructure (PAI) ★ 14k

Life Operating System that drives every task as a current→ideal-state transition through a 7-phase Deutsch-epistemology…

Sparo OS ★ 6

Cross-platform Tauri desktop application that acts as an Agentic OS runtime — hosting continuous AI task execution, workspace…

ClawManager ★ 1.4k

Kubernetes-native control plane for multi-tenant AI agent instance management with AI Gateway governance, desired-state…

ClawSpec ★ 43

Embed OpenSpec workflow into OpenClaw chat with visible planning, durable background implementation that survives gateway…

Onepilot

Mobile iPhone app for deploying and controlling terminal AI coding agents (OpenClaw, Hermes, Claude Code) on any SSH-accessible…

OpenClaw

AI agent runtime platform supporting plugin-based tool installation (osmoda-bridge), --local execution, multi-provider model…