EverOS Memory Runtime
A local-first, portable long-term memory layer for AI agents across applications and workflows.
- Source repo
- EverMind-AI/EverOS
- Stars
- ★ 14k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 45/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A team building a coding assistant can save messages from each coding session under project_id and session_id, then search prior context for a user in later sessions.
- Not a fit if
- Users who need Office document ingestion but won't install LibreOffice
- Legacy integrations that depend on /api/v1 and won't migrate to /api/v2
- Source review
- 45/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
EverOS is a Python library and local-first memory runtime for agents and makers. It stores conversations, files, and agent trajectories as readable Markdown, then synchronizes local SQLite and LanceDB indexes for retrieval. A locally started HTTP server exposes memory write, flush, and search operations under /api/v2; /api/v1 remains a legacy alias for existing integrations. Retrieval can be scoped across user_id, agent_id, app_id, project_id, and session_id, while user episodes/profile and agent cases/skills are separate first-class surfaces. The repository also describes offline reflection that merges episode clusters and refines profiles and skills between sessions, with data and indexes residing locally rather than in a managed memory service.
After everos server start, EverOS serves a local API. A client posts conversations with session_id, app_id, project_id, and messages to POST /api/v2/memory/add; EverOS writes Markdown and synchronizes local SQLite and LanceDB indexes in the background. POST /api/v2/memory/flush forces extraction for a session, and POST /api/v2/memory/search recalls results scoped by user and application/project identifiers. everos demo is a local, hardcoded terminal teaching visualizer that does not contact the server, while everos demo --live performs the /health, /api/v2/memory/add, /api/v2/memory/flush, and /api/v2/memory/search sequence. With everos[multimodal], content items sent to memory/add can include images, PDFs, audio, and office documents; office files are converted to PDF through LibreOffice.
- A team building a coding assistant can save messages from each coding session under project_id and session_id, then search prior context for a user in later sessions.
- A developer building a personal assistant that spans apps or devices can inspect and edit its Markdown memory directly while the cascade watcher synchronizes indexes.
- A multi-agent product can keep user episodes/profile distinct from agent cases/skills when persisting and retrieving long-term context.
- An application that needs durable context from images, PDFs, audio, or office files can install the multimodal extra and provision LibreOffice for office formats.
- A developer evaluating the memory lifecycle before configuring providers can run everos demo locally to see ingest, recall, source reveal, and replay.
How do you install or deploy this agent?
EverOS requires Python 3.12+. Install it and run the no-key local demo:
uv pip install everos
everos demoFor the server-backed flow, run everos init and fill EVEROS_LLM__API_KEY, EVEROS_MULTIMODAL__API_KEY, EVEROS_EMBEDDING__API_KEY, and EVEROS_RERANK__API_KEY in the generated .env. The documented default uses OpenRouter for chat and multimodal requests and DeepInfra for embedding and reranking; matching *__BASE_URL values can point to other OpenAI-compatible endpoints. For non-text input, install:
uv pip install 'everos[multimodal]'Office-document ingestion also requires LibreOffice on the host.
How do you use this agent?
After configuring .env, start the service:
everos server startCheck it from another terminal:
curl http://127.0.0.1:8000/healthThe expected response is {"status":"ok"}. For a first live invocation, run:
everos demo --liveUse /api/v2 for new integrations. The normal flow is POST /api/v2/memory/add with messages, POST /api/v2/memory/flush with session_id, app_id, and project_id, then POST /api/v2/memory/search with user_id, app_id, project_id, query, and top_k. Markdown is written synchronously, but the local index catches up in the background, so an initial empty search may need a retry.
What are this agent's strengths and limitations?
- Markdown is the canonical store, so memory is readable, directly editable, diffable, and suitable for Git versioning.
- Its documented local stack is Markdown, SQLite, and LanceDB, with no MongoDB, Elasticsearch, or Redis requirement.
- Retrieval supports orthogonal scoping by user_id, agent_id, app_id, project_id, and session_id instead of a single thread or namespace boundary.
- It provides a Python package, a local HTTP server, and a no-credential CLI demo for separate evaluation and integration paths.
- The real server-backed flow requires credentials for chat, multimodal, embedding, and reranking providers; the documented defaults use OpenRouter and DeepInfra.
- Index synchronization is asynchronous, so a just-written memory can produce an empty initial search result.
- Office-document ingestion depends on system-installed LibreOffice; without it, .doc, .docx, .ppt, .pptx, .xls, and .xlsx uploads return HTTP 415.
- The README identifies /api/v1 as a legacy alias that may be removed in a future major release, creating a migration requirement for older clients.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| EverOS Memory Runtime This agent | 45 · Major gaps | CLIFree + model costs | ★ 14k | today | Python | — |
| LycheeMemory | 52 · Major gaps | CLIFree + model costs | ★ 1.1k | 3mo ago | Python | Claude Code · OpenAI API |
| MemOS 2.0 Stardust | 53 · Major gaps | Self-hosted serviceFreemium | ★ 12k | 2d ago | TypeScript | — |
| PowerContext | 55 · Major gaps | CLIFree | ★ 1.5k | 1d ago | Python | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: server defaults to binding 127.0.0.1, docs explicitly warn against exposing to untrusted networks, API keys stored in local .env and never transmitted except to configured providers. This reflects partial least privilege, but lacks user confirmation mechanisms (e.g., no explicit user confirmation before writing/deleting memory). Data flow transparency is described in README and SECURITY.md, but no detailed logging or audit features. Sensitive data handling: docs mention plaintext .md storage and recommend OS-level permissions or disk encryption, but no built-in encryption option. Dependency security: pyproject.toml pins lancedb version range with comments on known issues, but no vulnerability scanning mentioned. External effects: server defaults to local-only, but no description of impact on system files or network. Rollback: no rollback mechanism provided. Source attribution: README lists multiple external integrations, but does not clarify their provenance or trustworthiness.
Evidence shows: project has strict test suite including consistency checks (tests/_consistency_assertions.py) and CI config, indicating good self-consistency. Dependency availability: dependencies clearly listed in pyproject.toml, CI uses uv.lock for frozen versions, but no availability guarantee. Failure messages: docs mention office uploads return HTTP 415 with clear error, but overall error handling not detailed.
Evidence shows: README clearly identifies target audience (developers, AI agents) and multiple use cases (e.g., Reunite, Hive), indicating broad audience and scenarios. Capability boundaries: docs clarify demo is local educational, not connecting to server, and multimodal requires extra install, but not all feature limitations detailed. Trigger precision: API call examples provided, but no trigger conditions or permission controls. Environment fit: supports Python 3.12+, provides install instructions for macOS and Linux, but no Windows support mentioned.
Evidence shows: information architecture: README well-structured with TOC and doc links, but no full API reference. Install notes: pip install and config steps provided, but system dependencies (e.g., LibreOffice) not detailed. Naming stability: API v1 and v2 coexist, but v1 marked legacy and may be removed, posing instability risk. Examples and FAQ: multiple use cases and quickstart examples, but no FAQ. Known limitations: SECURITY.md mentions threat model, but not all limitations listed. License: Apache-2.0 full text present, declared in pyproject.toml. Versioning/changelog: CHANGELOG.md exists, but no detailed version history. Maintenance responsibility: SECURITY.md provides security contact email, but no explicit maintainers or contribution guide.
Evidence shows: output usability: API response examples and Markdown file descriptions provided, but no full output format documentation. Marginal value: project offers unique Markdown-first memory layer, differentiated from other libraries, but no performance benchmarks. Cost-benefit: requires multiple API keys (OpenRouter, DeepInfra), potentially increasing usage cost, but no cost estimates.
Evidence shows: claim traceability: feature claims in README lack specific implementation details or test evidence. Cross-source corroboration: README references multiple external projects, but no independent verification. Fact-inference separation: docs distinguish facts (e.g., feature descriptions) from inferences (e.g., 'self-evolving'), but not explicitly labeled.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Server defaults to loopback, but if user binds to 0.0.0.0, it may be exposed to untrusted networks; configure carefully.
- Memory stored as plaintext Markdown; sensitive data requires additional encryption.
- lancedb dependency has known issues; monitor version updates.
- API v1 is legacy and may be removed; new code should use v2.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.5.1 EverOS 1.5.1
Release notes excerpt
Hybrid and vector search keep up with 10 requests a second out of the box. Each of those searches embeds its query first, and the slots reserved for those calls were the limit: with 4 of them and a remote embedding endpoint answering in about 0.45 s, search topped out near 9 requests a second and a steady 10 queued without bound. The default is now 16, which held the same load at a p50 of 0.42 s and a p95 of 1.45 s. Changed - [embedding].query_max_concurrent defaults to 16 instead of 4. Every hybrid or vector search makes one query embedding call, and the budget …View on GitHub ↗ -
v1.5.0 EverOS 1.5.0
Release notes excerpt
**/add no longer has to wait for extraction, and an index can no longer be wrong without saying so.** A client can hand a batch to /add with async_mode and get a 202 back in milliseconds, while a durable in-process queue runs extraction in session order; the field, the response body and the task-status paths match EverOS Cloud, so one client works against both. Vector columns now follow [embedding] dim instead of a hardcoded 1024, startup refuses an index the configured model cannot have produced instead of accepting writes that are truncated or searches that quietly return nothing, …View on GitHub ↗ -
v1.4.2 EverOS 1.4.2
Release notes excerpt
A server that stays healthy for days, not hours. Three faults in this release compounded on exactly the deployments that ran longest: a long-lived index leaked file descriptors until searches took seconds, interactive searches queued behind the cascade's background embedding, and a memory root holding more than one project had each project's index rows overwrite the other's. All three are fixed, and a LanceDB root that the last fault already damaged repairs itself on the first start after upgrading. Changed - [embedding].max_concurrent defaults to 10 instead of 5. The …View on GitHub ↗