EverOS

Website · Documentation · Blog · 中文

Table of Contents

• Why EverOS

• Ecosystem Integrations

• Quick Start

• Use Cases

• Documentation

• EverMind Ecosystem

• Contributing

Why EverOS

EverOS is a Python library and local-first memory runtime for agents and makers. It gives one portable memory layer across coding assistants, apps, devices, and workflows from day one. It stores conversations, files, and agent trajectories as readable Markdown, then syncs local SQLite and LanceDB indexes for fast retrieval and self-evolving reuse.

Title EverOS Other Agent Memory Libraries Markdown source of truth ✅ Canonical .md files that are readable, editable, diffable, and Git-versioned ❌ Usually API, vector, graph, dashboard, or database state Direct file editing ✅ Edit .md files; cascade watcher syncs ❌ Usually SDK, API, dashboard, or backend update paths Local three-part stack ✅ Markdown + SQLite + LanceDB; no MongoDB, Elasticsearch, or Redis required ❌ Often depends on managed services, vector DBs, graph DBs, or server stacks User + agent tracks ✅ User episodes/profile and agent cases/skills are separate first-class surfaces ❌ Usually centered on chat history, profiles, entities, facts, or retrieval records Orthogonal retrieval ✅ Search by user_id, agent_id, app_id, project_id, and session_id ❌ Usually app, namespace, tenant, thread, or graph scoped Knowledge Wiki ✅ Editable, source-backed Markdown knowledge pages with taxonomy, CRUD APIs, and topic search ❌ Usually separate from memory, trapped in a dashboard, or not tied back to source files Reflection ✅ Offline memory evolution that merges episode clusters and refines profiles and skills between sessions ❌ Usually retrieval-only memory with little background consolidation or long-horizon improvement

Ecosystem Integrations

EverOS adds durable memory to the agent and workflow platforms below—and comes built into Raven. Choose an integration to open its setup guide.

DeepSeek Harness Hermes OpenClaw Raven Dify

Quick Start

One OpenRouter API key is enough to start EverOS, write durable memories, and retrieve them with keyword search.

Prerequisites

• Python 3.12+

• One OpenRouter API key

1. Install

uv pip install everos
# or: pip install everos

2. Try the standalone demo — no key required

No API key or server setup required—run one command to quickly experience how EverOS stores and recalls memory:

# If you installed EverOS as a package:
everos demo

# If you cloned or forked this repository and have not activated .venv:
uv run everos demo

Enter something EverOS should remember, then ask a related question to watch the memory move through ingest -> extract -> index -> recall.

https://github.com/user-attachments/assets/98cb8e1e-2ca8-4504-b0a6-0b9a040a0a5c

3. Initialize and add your OpenRouter key

everos init

This creates ~/.everos/everos.toml and ~/.everos/ome.toml. Open ~/.everos/everos.toml; the generated model and OpenRouter URL are already correct, so replace only the empty api_key:

[llm]
model = "openai/gpt-4.1-mini"
api_key = "<OPENROUTER_API_KEY>"
base_url = "https://openrouter.ai/api/v1"

This is the smallest Tier 1 setup: memory add, flush, Markdown persistence, cascade indexing, and keyword search.

Use everos init --root if you want a different memory root. Pass the same --root to subsequent commands.

4. Start EverOS

everos server start

Keep the server running, then open a second terminal and check it:

curl http://127.0.0.1:8000/health

Look for "status":"ok". With this one-key setup, capabilities.llm is true; embedding and rerank remain false until you configure them.

5. Add and retrieve your first memory

Note

Business endpoints live under /api/v2. The older /api/v1 prefix still resolves to the same handlers so existing integrations keep working, but it is a legacy alias that may be removed in a future major release — write new code against /api/v2.

Add a tiny conversation:

TS=$(($(date +%s)*1000))

curl -X POST http://127.0.0.1:8000/api/v2/memory/add \
  -H 'Content-Type: application/json' \
  -d "{
    \"session_id\": \"demo-001\",
    \"app_id\": \"default\",
    \"project_id\": \"default\",
    \"messages\": [
      {\"sender_id\": \"alice\", \"role\": \"user\", \"timestamp\": $TS, \"content\": \"I love climbing in Yosemite every spring.\"},
      {\"sender_id\": \"alice\", \"role\": \"user\", \"timestamp\": $((TS+10000)), \"content\": \"My favorite coffee shop is Blue Bottle in SOMA.\"}
    ]
  }"

Flush the memory at the end of the session:

curl -X POST http://127.0.0.1:8000/api/v2/memory/flush \
  -H 'Content-Type: application/json' \
  -d '{"session_id":"demo-001","app_id":"default","project_id":"default"}'

Search it back:

curl -X POST http://127.0.0.1:8000/api/v2/memory/search \
  -H 'Content-Type: application/json' \
  -d '{
    "user_id": "alice",
    "app_id": "default",
    "project_id": "default",
    "query": "Where do I like to climb?",
    "method": "keyword",
    "top_k": 5
  }'

You should see the Yosemite memory in the response. Keep "method": "keyword" in this one-key setup because the API defaults to hybrid search, which requires an embedding provider.

Tip

First memory unlocked. You just gave EverOS a fact, flushed it into durable Markdown-backed memory, and searched it back through the local index. That is the core loop. Want to see the source of truth? Open ~/.everos and inspect the generated Markdown files.

For annotated responses and the Markdown files EverOS creates, see QUICKSTART.md.

What works with one key?

The OpenRouter one-key setup is EverOS Tier 1. It supports server startup, memory add and flush, durable Markdown storage, cascade indexing, and keyword search. Add optional providers only when you need the features below:

Missing optional capabilities are reported by /health and return a clear HTTP 422 if you request a feature that needs them.

Note

everos demo --live is different from the standalone demo in step 2: it connects to a running server and uses the real add/flush/search flow. It uses hybrid search, so add an embedding provider before you run it.