MIRA OS presents a novel approach to creating persistent AI entities, designed for users seeking a continuously learning and tool-using agent. It offers an "elegant brain-in-box" experience, automating tool configuration and memory management to provide a seamless, self-directed interaction model. The primary benefit is a semblance of continuity and recall within an inherently ephemeral digital framework.

How It Works

MIRA OS employs asynchronous conversation processing and dynamic context window manipulation to achieve persistence. Memories are discrete, decaying naturally via a formula unless actively referenced, thus preventing context rot without manual intervention. Long-form content is managed via a domaindoc_tool that allows autonomous expansion and subsectioning. Tools are self-contained, self-registering on startup, and dynamically loaded into the context window only when needed, managed by the invoke_other_tool. The architecture is synchronously event-driven, enabling loosely coupled modules to extend functionality easily.

Quick Start & Requirements

• Install: Run the provided deployment script:

  curl -fsSL https://raw.githubusercontent.com/taylorsatula/mira-OSS/refs/heads/main/deploy.sh -o deploy.sh && chmod +x deploy.sh && ./deploy.sh
  

• Prerequisites: API keys for LLM providers, Python virtual environment, spaCy (~800MB), mdbr-leaf-ir-asym (~300MB), optional Playwright (~300MB). Requires HashiCorp Vault, PostgreSQL, and Valkey services.
• Setup: The deploy.sh script automates platform detection, dependency installation, model downloads, service initialization (Vault, DB), and verification.
• Links: Hosted version available at miraos.org.

Highlighted Details

• Self-Configuring Tools: Tools automatically register and configure themselves on startup, with definitions stored internally.
• Automated Memory Decay: Context rot is mitigated through a formulaic decay of unreferenced memories.
• Dynamic Tool Loading: Tools are loaded into the context window only when required and expire if unused, optimizing token usage.
• Event-Driven Architecture: Modules are loosely coupled via events (e.g., SegmentCollapseEvent), facilitating easy extension.

Maintenance & Community

The project is primarily maintained by the author, with significant contributions acknowledged from the Claude Code team and MemGPT. Contributions are explicitly welcomed. No specific community channels (Discord, Slack) or roadmap links are provided in the README.

Licensing & Compatibility

The repository is released as "open source technology," but a specific license type (e.g., MIT, Apache 2.0) is not explicitly stated. The author commits to maintaining an open-source version. The system's "OEM feel" is best achieved with Claude Opus 4.5, though it supports other models like GPT-OSS-120B and Hermes3-8b with varying results.

Limitations & Caveats

The optimal user experience is tied to the closed-source Claude Opus 4.5 model. MIRA OS enforces a single, continuous conversation thread, lacking functionality to start new chats, which requires users to manage persistence within this constraint. The setup involves multiple external services (Vault, PostgreSQL, Valkey) and significant model downloads.