* fix(knowledge): contain original-file write path (CWE-22) The multipart upload filename was joined into ``_original/`` verbatim. An attacker-controlled filename such as ``/tmp/pwned`` or ``../../.bashrc`` would let ``POST /knowledge/documents`` write outside the document directory (the ``/`` operator discards the left operand for absolute paths; ``..`` walks upward). The read side had the symmetric issue. Fix, mirroring the sender_id containment shipped in 1.0.1 (GHSA-c795-2g9c-j48m): - Add ``_safe_original_filename`` reducing the untrusted filename to a single POSIX/Windows-basename component; reject degenerate residuals (``""``, ``"."``, ``".."``) with PathTraversalError. - ``_write_original_file`` asserts ``target.resolve()`` stays inside ``original_dir.resolve()`` before any filesystem touch (mkdir/write). - ``_resolve_original_file_path`` sanitises symmetrically so a stored provenance label can never resolve to an out-of-directory file. Four SEC regression tests cover: absolute filename, ``..`` traversal, degenerate filename rejection, and read-side sanitisation. Backport from GitLab release/v1.1.4 (commit 40f19de) — 1.1.4 shipped this fix; the GitLab -> GitHub sync stopped at 1.1.3, so 1.2.0 regressed the containment. This commit alone restores the fix; the 1.2.1 release PR ships it to PyPI. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cascade): retry classification, budget, and reconcile races Backport the cascade reliability work that shipped in GitLab 1.1.4 (MR !49 / commit 95db2f5) — six interlocking changes the reviewer should read in order: 1. Worker retry classification uses ExternalServiceError (embedding / LLM / rerank transient failures) as the "retry inline" signal. The legacy RecoverableError hierarchy under cascade/errors.py is removed; the retry contract now lives in the domain error tree (core/errors.py). Docstrings in handlers/base.py and sqlite/tables/md_change_state.py updated to match. 2. Cross-cycle retry budget: _MAX_TOTAL_RETRIES = 12. Once total attempts across scanner cycles exhaust the budget, the worker marks retryable=False in place instead of looping forever on a sustained upstream outage. 3. md_change_state upsert preserves retry_count on scanner re-enqueue when mtime is unchanged (previously reset to 0 every sweep, defeating the budget). mtime change (user edit) still resets the counter. 4. Reconciler no longer re-enqueues pending / processing rows on stable mtime — that was overwriting the worker's mark_done. It also skips failed rows with retryable=False on stable mtime so the entry-check demote path is stable. 5. mtime tolerance (10 ms, MTIME_TOLERANCE_SECONDS) absorbs the SQLite REAL float precision loss that previously flapped the reconcile decision when the same md was rewritten without a real content change. The constant is defined once in the sqlite repo and imported by the reconciler so both sides use the same tol. 6. Worker _run_rebuild_once carries an explicit `state.task is not asyncio.current_task()` guard before awaiting the optimize task — the previous contextlib.suppress was silently swallowing self-await RuntimeError. Kept intact from the GitHub 1.2.0 baseline: - The `except FileNotFoundError → handle_deleted` branch in the worker (delete/modify race — see test_modified_event_for_vanished_file_is_processed_as_delete). Test coverage added: - test_retry_budget_exhausted_marks_unrecoverable - test_external_service_error_at_budget_edge_demotes_in_place - test_upsert_preserves_retry_count_for_failed_stable_mtime - test_upsert_resets_retry_count_on_mtime_change - test_optimize_fallback_rebuild_on_sustained_failure - reconciler mtime-tolerance / stable-mtime skip suite Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(embedding): raise on empty API data; forward MRL dimensions Backport from GitLab 1.1.4 (MR !49 / commit 95db2f5). Two behavioural changes on ``OpenAIEmbeddingProvider._embed_chunk``: 1. ``response.data == []`` now raises ``EmbeddingServiceError`` instead of returning an empty list. Some upstream providers (observed on DeepInfra under load) return HTTP 200 with an empty ``data`` array; the silent zero-vector path was corrupting search indexes without any signal. 2. When ``[embedding] dimensions = N`` is set in ``everos.toml``, the parameter is forwarded to the API so MRL-capable models (OpenAI text-embedding-3-*, Qwen3-Embedding, ...) do server-side truncation with proper re-normalization. Client-side truncation to ``dim`` remains as a fallback for backends that ignore the param. ``openai.NOT_GIVEN`` is used as the sentinel so the request omits the field when the setting is left at the default ``None``. Config plumbing: - ``EmbeddingSettings.dimensions: int | None = None`` - factory forwards ``dimensions=settings.dimensions`` to the provider The provider stays inside the existing ``memory_span`` OTel wrapper and continues to report input-only tokens via ``set_generation_usage`` - both are GitHub 1.2.0 native tracing behaviours preserved intact. Test coverage: - test_empty_response_data_raises_embedding_error (new) - test_usage_span._FakeEmbeddings.create signature updated to accept ``dimensions`` kwarg so the OTel token-recording tests still exercise the same call path Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(extract): retry episode extraction on malformed LLM output Backport from GitLab 1.1.4 (MR !49 / commit 95db2f5). The ``/flush`` synchronous path called ``EpisodeExtractor.aextract`` exactly once. everalgo raises ``ValueError`` when the LLM returns malformed JSON (observed with OpenRouter partial responses where finish_reason=stop but the body is truncated) — the caller was surfaced a 500 for a transient upstream hiccup. ``_extract_with_retry`` wraps the call with two extra attempts at 1s and 2s backoff (final attempt propagates untouched), typed as ``AlgoEpisode`` so the caller path stays annotated. Retry stays inside the existing GitHub 1.2.0 ``memory_span("everos.extract", ...)`` OTel wrapper — the OTel token capture and the retry loop are orthogonal. TODO in the code notes we should catch a typed everalgo ``ExtractionError`` once that type is introduced (currently ValueError is broad). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: log non-stop finish_reason; bump everalgo-user-memory 0.3.2 Two loosely coupled changes from GitLab 1.1.4 (MR !49 / commit 95db2f5) that arrive together as a housekeeping commit. 1. ``_LoggingLLMClient`` diagnostic wrapper (new, file-private). Wraps the raw everalgo LLM client and, on every ``chat()``, warns when ``resp.finish_reason != "stop"`` — logging the reason, ``content_len``, the last 200 chars of ``content``, and ``model``. Aims at OpenRouter/DeepSeek truncation triage where the provider silently caps output length and returns finish_reason=length / filter / etc. Non-invasive: one branch per call, no config gate. Wrapper stack in ``get_llm_client``: LoggingLLMClient(UsageRecordingClient(build_client(...))) LoggingLLMClient(build_client(...)) # observability off ``UsageRecordingClient`` (GitHub 1.2.0 native OTel token capture) stays gated by ``settings.observability.enabled`` — this commit preserves that. LoggingLLMClient is always outermost so the reason it observes is exactly the reason the underlying provider reported. 2. ``everalgo-user-memory`` 0.3.1 -> 0.3.2 (pyproject + uv.lock). Same bump the GitLab 1.1.4 release lane took; unblocks the episode-extract retry work in commit 4 seeing the upstream improvements. Verified via ``uv sync``. No functional API changes. Test coverage: - test_returns_singleton_when_configured now asserts the outer LoggingLLMClient wrapper. - test_wraps_client_when_observability_enabled asserts the two-layer Logging(UsageRecording(...)) stack. - test_does_not_wrap_client_when_observability_disabled asserts Logging still wraps when tracing is off. - test_logging_wrapper_warns_on_non_stop_finish_reason (new). - test_logging_wrapper_silent_on_stop_finish_reason (new). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(changelog): restore [1.1.4] section to match published sdist The 1.1.4 changelog entry on this branch previously listed three items (Langfuse example, delete/modify race, live-server telemetry). The 1.1.4 sdist on PyPI, however, was built from the internal release lane and includes the CWE-22 containment, the cascade retry-budget / mtime-tolerance / reconcile-guard work, the embedding empty-data raise, the episode-extract retry, MRL dimensions, and the LLM finish_reason diagnostic — none of which were represented here when the tag was cut. Rewrite the [1.1.4] section so it matches the wheel a user actually installs from PyPI: - Add a header note explaining the retroactive restoration. - Fixed: CWE-22, cascade reliability bundle, delete/modify race (unchanged wording), embedding empty-data, episode extract retry, Langfuse live-server telemetry (unchanged wording). - Added: MRL dimensions, LLM finish_reason diagnostic, Langfuse example (unchanged wording). - Changed: everalgo-user-memory 0.3.1 -> 0.3.2. The GitLab-side `.gitlab-ci.yml` in-house-runner entry is dropped — open-source CI runs on GitHub Actions and the internal runner switch is not visible to public users. Date stays 2026-07-20 (the GitHub v1.1.4 tag date / PyPI upload timestamp) rather than the internal 2026-07-23 code-freeze date, so the timeline of what shipped where remains internally consistent. The corresponding code fixes are all backported by earlier commits in this PR; this commit only aligns the changelog surface. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .claude | ||
| .github | ||
| benchmarks | ||
| data | ||
| docs | ||
| examples/langfuse | ||
| scripts | ||
| src/everos | ||
| tests | ||
| use-cases | ||
| .env.example | ||
| .gitignore | ||
| .gitlint | ||
| .pre-commit-config.yaml | ||
| ACKNOWLEDGMENTS.md | ||
| CHANGELOG.md | ||
| CITATION.md | ||
| CLAUDE.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| Makefile | ||
| NOTICE | ||
| QUICKSTART.md | ||
| README.md | ||
| README.zh-CN.md | ||
| SECURITY.md | ||
| config.example.toml | ||
| pyproject.toml | ||
| uv.lock | ||
README.md
Why Ever OS
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 |
Quick Start
Goal: play with the memory visualizer first, then start EverOS, write one real memory, and search it back.
0. Prerequisites
- Python 3.12+
- No API keys are needed for
everos demo. - To run the real server-backed memory flow, create two provider keys before
everos init:
| Capability | Provider | Used for | Fill these .env slots |
|---|---|---|---|
| Chat + multimodal | OpenRouter | LLM / MULTIMODAL |
EVEROS_LLM__API_KEY, EVEROS_MULTIMODAL__API_KEY |
| Embedding + rerank | DeepInfra | EMBEDDING / RERANK |
EVEROS_EMBEDDING__API_KEY, EVEROS_RERANK__API_KEY |
You can use other OpenAI-compatible providers by changing the matching
*__BASE_URL fields in .env.
1. Install
uv pip install everos
# or: pip install everos
2. Play With The Demo
Run this before configuring API keys or starting the server:
everos demo
The command asks for one memory and one recall question, then opens a full-screen terminal UI. This is an educational visualizer: it is hardcoded, local to the CLI, and does not connect to the EverOS server. Its job is to make the memory lifecycle visible: conversation -> memory sphere -> recall -> source proof -> confetti. See docs/everos-demo.md for the demo scope and TUI source layout.
The sphere moves through ingest, extraction, indexing, recall, source reveal,
and a confetti burst after the first memory lands. Press r to replay and q
to quit.
For the looping showroom view used in README media, run:
everos demo --cinematic
If your shell is not interactive, or you want a copyable preview, use:
everos demo --plain
3. Configure
Generate a starter .env file, then fill the four API key slots shown in the
generated comments. With the default setup, paste your OpenRouter key into the
LLM / MULTIMODAL slots and your DeepInfra key into the EMBEDDING /
RERANK slots.
everos init
# or, from a source checkout:
cp .env.example .env
everos init writes ./.env by default. Use everos init --xdg to
write ${XDG_CONFIG_HOME:-~/.config}/everos/.env instead.
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
Expected response:
{"status":"ok"}
everos server start searches for .env in this order: --env-file <path> →
./.env (cwd) → ${XDG_CONFIG_HOME:-~/.config}/everos/.env → ~/.everos/.env.
The endpoint stack is OpenAI-protocol compatible (OpenAI / OpenRouter / vLLM /
Ollama / DeepInfra) - override *__BASE_URL in the generated .env to point
at any of them.
Now make the demo real. In the second terminal, run:
everos demo --live
Live demo mode connects to the running server and performs the real
/health -> /api/v1/memory/add -> /api/v1/memory/flush ->
/api/v1/memory/search flow before opening the same memory sphere UI. Use
--server-url <url> if your server is not on http://127.0.0.1:8000.
5. Try Your First Memory
Add a tiny conversation:
TS=$(($(date +%s)*1000))
curl -X POST http://127.0.0.1:8000/api/v1/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.\"}
]
}"
Force extraction for the local demo:
curl -X POST http://127.0.0.1:8000/api/v1/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/v1/memory/search \
-H 'Content-Type: application/json' \
-d '{
"user_id": "alice",
"app_id": "default",
"project_id": "default",
"query": "Where do I like to climb?",
"top_k": 5
}'
You should see the Yosemite memory in the response. If the result is empty on the first try, wait a moment and retry; Markdown is written synchronously, while the local index catches up in the background.
[!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
~/.everosand inspect the generated Markdown files.
For annotated responses and the Markdown files EverOS creates, see QUICKSTART.md.
Optional: Ingest Multimodal Files
To ingest non-text content (image / pdf / audio / office documents)
through /api/v1/memory/add content items, install the optional
extra:
uv pip install 'everos[multimodal]' # or: pip install 'everos[multimodal]'
This pulls in everalgo-parser (with the [svg] bundle for SVG
support via cairosvg) and wires up the multimodal LLM client
(EVEROS_MULTIMODAL__* fields in .env, defaults to
google/gemini-3-flash-preview via OpenRouter).
Office document support requires LibreOffice as a system dependency.
The parser shells out to soffice (LibreOffice's headless renderer) to
convert .doc / .docx / .ppt / .pptx / .xls / .xlsx to PDF
before feeding the result into the multimodal LLM. Without LibreOffice,
office uploads return HTTP 415 with a clear error message; PDF / image
/ audio / HTML / email parsing is unaffected.
Install on the host before serving office documents:
brew install --cask libreoffice # macOS
sudo apt-get install -y libreoffice # Debian / Ubuntu
For Contributors
git clone https://github.com/EverMind-AI/EverOS.git
cd EverOS
uv sync # creates ./.venv and installs deps
source .venv/bin/activate # or prefix commands with `uv run`
everos demo --plain # try the local educational demo; no API keys needed
everos init # paste OpenRouter + DeepInfra keys into .env
everos --help
make test
Use Cases
Now that you have had your first successful EverOS moment, explore what people are building with persistent memory across agents, apps, and community integrations.
Use cases show what persistent memory makes possible in real products and workflows. Some examples are packaged in this repository; others point to external demos or integrations you can study and adapt.
Reunite - Find With EverOSParents describe what they remember. Children describe what they recall. Reunite uses semantic memory to surface the connections. |
Hive OrchestratorBrowser-native hive-mind for CLI coding agents - Claude Code, Codex, Gemini, and OpenCode collaborate as real PTY processes via a team protocol. |
AI Coding Assistants With EverOSUniversal long-term memory layer for AI coding assistants, powered by EverOS. |
AI Data TechnicianAn agentic AI system that learns from scientist interaction to inspect, analyze, and classify high-dimensional time series data - with persistent memory that improves across sessions. |
Rokid AI Assistant With EverOSConnect to EverOS within Rokid Glasses enabling long-term memory for all of your smart activities. Coming soon |
Creative Assistant With MemoryCreative assistant with long-term memory, so your creative context stays available across sessions. Coming soon |
|
|
|
Earth Online Memory GameEarth Online is a memory-aware productivity game that turns everyday planning into a living quest log. |
Multi-Agent Orchestration PlatformGolutra presents a multi-agent workforce for engineering teams, extending the IDE model from a single assistant to coordinated agents. |
Your Personal Tasting UniverseRecord, visualize, and explore your tasting journey through an immersive 3D star map. |
EverOS Open HerBuild AI that feels. Open-source persona engine - personality emerges from neural drives, not prompts. Inspired by Her. |
Browser Agent For Personal MemoryRuminer brings persistent memory to a browser agent so it can carry personal context across web tasks. |
EverMem Sync With EverOSOne command to connect any AI coding CLI to EverMemOS long-term memory. |
|
|
|
MCO - Orchestrate AI Coding AgentsMCO equips your primary agent with an agent team that can work together to solve complex tasks. |
Study Buddy With Self-Evolving MemoryStudy proactively with an agent that has self-evolving memory. |
Alzheimer's Memory AssistantEmpowering individuals with advanced memory support and daily assistance. |
Memory-Driven Multi-Agent NPC ExperienceAn iOS sci-fi mystery game where players explore and uncover the truth. |
Mobi CompanionAn iOS app where users create, nurture, and live with a personalized AI companion called Mobi. |
AI Wearable With MemoryA context-native AI wearable that listens to everyday life and converts conversations into memory. |
|
|
|
Legacy OpenClaw Agent MemoryArchived pre-1.0.0 plugin reference. New integrations should use the current EverOS API. |
Live2D Character With MemoryAdd long-term memory to a real-time Live2D character, powered by TEN Framework. |
Computer-Use With MemoryRun screenshot-based analysis with computer-use and store the results in memory. |
Game Of Thrones MemoriesA demonstration of AI memory infrastructure through an interactive Q&A experience with A Game of Thrones. |
Claude Code PluginPersistent memory for Claude Code. Automatically saves and recalls context from past coding sessions. |
Memory Graph VisualizationExplore stored entities and relationships in a graph interface. Frontend demo; backend integration is in progress. |
Documentation
- docs/everos-demo.md — Demo scope and TUI source layout
- docs/how-memory-works.md — Markdown, SQLite, LanceDB, and recall flow
- docs/use-cases.md — Full use-case gallery and integration examples
- docs/engineering.md — Contributor engineering reference: build, test, CI, conventions
- docs/migration-to-1.0.0.md — Legacy API migration notes
- CHANGELOG.md — Release notes
- CONTRIBUTING.md — How to contribute
EverMind Ecosystems
EverMind is an open-source ecosystem for long-term memory, self-evolving agents, AI-native interfaces, and memory evaluation.
| EverMind Open-Source Ecosystem | |
|---|---|
| Memory Runtime | EverOS - the local memory operating system and research-backed runtime for agent and user memory. |
| Self-Improving Agent Harness | Raven - the self-improving agent harness that brings memory, proactivity, context control, and skill evolution into terminal-native agents. |
| Algorithm Engine | EverAlgo - stateless extraction, ranking, parsing, and memory operators that power EverOS. |
| Hypergraph Memory | HyperMem - hypergraph memory for long-term conversations, with its own benchmark-backed topic -> episode -> fact retrieval method. |
| Benchmarks | EverMemBench · EvoAgentBench - evaluation suites for conversational memory and agent self-evolution. |
| Long-Context Research | MSA - Memory Sparse Attention for scalable latent memory and 100M-token contexts. |
| Personal Memory Layer | EverMe - CLI and agent plugin suite for cross-device, cross-agent personal memory. |
| Developer Integrations | evermem-claude-code · everos-plugins - plugins, skills, and migration tooling for AI coding agents. |
Together, these repositories form EverMind's research-to-runtime stack: new memory methods, reusable algorithms, benchmark evidence, and practical agent integrations.
Contributing
Contributions are welcome across the whole repository: memory methods, benchmark coverage, use-case examples, documentation, and bug fixes. Browse Issues to find a good entry point, then open a PR when you are ready.
[!TIP]
Welcome all kinds of contributions 🎉
Help make EverOS better. Code, documentation, benchmark reports, use-case write-ups, and integration examples are all valuable. Share your projects on social media to inspire others.
Connect with one of the EverOS maintainers @elliotchen200 on 𝕏 or @cyfyifanchen on GitHub for project updates, discussions, and collaboration opportunities.
Code Contributors
License
Apache License 2.0 — see NOTICE for third-party attributions.
Citation
If you use EverOS in research, see CITATION.md.