mirror of EverMind-AI/EverOS - portable memory layer for AI agents
Go to file
Kendrick-Song 42629dfd4d
fix: backfill missing 1.1.4 fixes into main (#366)
* 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>
2026-07-28 14:57:53 +08:00
.claude feat(observability): OTel tracing chassis + request-id propagation 2026-07-23 20:47:39 +08:00
.github ci(docs): run docs check on every PR so its required check reports 2026-07-24 16:12:59 +08:00
benchmarks chore(release): update EverOS to 1.1.1 (#327) 2026-07-07 18:30:03 +08:00
data chore: initialize EverOS 1.0.0 2026-06-06 07:33:17 +08:00
docs chore(release): update EverOS to 1.2.0 2026-07-24 16:32:16 +08:00
examples/langfuse docs(examples): replace Langfuse wrapper with native tracing example 2026-07-24 16:26:22 +08:00
scripts docs: align config and github workflow (#314) 2026-06-29 07:31:31 +08:00
src/everos fix: backfill missing 1.1.4 fixes into main (#366) 2026-07-28 14:57:53 +08:00
tests fix: backfill missing 1.1.4 fixes into main (#366) 2026-07-28 14:57:53 +08:00
use-cases fix(docs): repair dead xrefs in api.md, runbook, skill (#269) 2026-06-08 07:10:56 +08:00
.env.example chore(release): update EverOS to 1.1.1 (#327) 2026-07-07 18:30:03 +08:00
.gitignore chore(release): update EverOS to 1.1.1 (#327) 2026-07-07 18:30:03 +08:00
.gitlint chore: initialize EverOS 1.0.0 2026-06-06 07:33:17 +08:00
.pre-commit-config.yaml chore(release): update EverOS to 1.1.0 (#307) 2026-06-24 23:17:23 +08:00
ACKNOWLEDGMENTS.md docs: fix Discord community links (#294) 2026-06-17 17:16:13 +08:00
CHANGELOG.md fix: backfill missing 1.1.4 fixes into main (#366) 2026-07-28 14:57:53 +08:00
CITATION.md chore(release): update EverOS to 1.1.4 (#348) 2026-07-23 13:18:19 +08:00
CLAUDE.md docs: align config and github workflow (#314) 2026-06-29 07:31:31 +08:00
CODE_OF_CONDUCT.md chore: initialize EverOS 1.0.0 2026-06-06 07:33:17 +08:00
CONTRIBUTING.md docs: align config and github workflow (#314) 2026-06-29 07:31:31 +08:00
LICENSE chore: initialize EverOS 1.0.0 2026-06-06 07:33:17 +08:00
Makefile docs: align config and github workflow (#314) 2026-06-29 07:31:31 +08:00
NOTICE chore: initialize EverOS 1.0.0 2026-06-06 07:33:17 +08:00
QUICKSTART.md chore(release): update EverOS to 1.1.1 (#327) 2026-07-07 18:30:03 +08:00
README.md docs(readme): remove Star us section (#363) 2026-07-27 17:07:20 +08:00
README.zh-CN.md docs(readme): remove Star us section (#363) 2026-07-27 17:07:20 +08:00
SECURITY.md chore(release): update EverOS to 1.1.1 (#327) 2026-07-07 18:30:03 +08:00
config.example.toml chore(release): update EverOS to 1.1.0 (#307) 2026-06-24 23:17:23 +08:00
pyproject.toml fix: backfill missing 1.1.4 fixes into main (#366) 2026-07-28 14:57:53 +08:00
uv.lock fix: backfill missing 1.1.4 fixes into main (#366) 2026-07-28 14:57:53 +08:00

README.md


Table of Contents

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.

Animated EverOS demo preview showing the memory sphere moving through recall and confetti states

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 ~/.everos and 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.

banner-gif

Reunite - Find With EverOS

Parents describe what they remember. Children describe what they recall. Reunite uses semantic memory to surface the connections.

Learn more

banner-gif

Hive Orchestrator

Browser-native hive-mind for CLI coding agents - Claude Code, Codex, Gemini, and OpenCode collaborate as real PTY processes via a team protocol.

Code

banner-gif

AI Coding Assistants With EverOS

Universal long-term memory layer for AI coding assistants, powered by EverOS.

Code

banner-gif

AI Data Technician

An 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.

Code

banner-gif

Rokid AI Assistant With EverOS

Connect to EverOS within Rokid Glasses enabling long-term memory for all of your smart activities.

Coming soon

banner-gif

Creative Assistant With Memory

Creative assistant with long-term memory, so your creative context stays available across sessions.

Coming soon

Back to top

banner-gif

Earth Online Memory Game

Earth Online is a memory-aware productivity game that turns everyday planning into a living quest log.

Code

banner-gif

Multi-Agent Orchestration Platform

Golutra presents a multi-agent workforce for engineering teams, extending the IDE model from a single assistant to coordinated agents.

Code

banner-gif

Your Personal Tasting Universe

Record, visualize, and explore your tasting journey through an immersive 3D star map.

Code

banner-gif

EverOS Open Her

Build AI that feels. Open-source persona engine - personality emerges from neural drives, not prompts. Inspired by Her.

Code

banner-gif

Browser Agent For Personal Memory

Ruminer brings persistent memory to a browser agent so it can carry personal context across web tasks.

Plugin

banner-gif

EverMem Sync With EverOS

One command to connect any AI coding CLI to EverMemOS long-term memory.

Code

Back to top

banner-gif

MCO - Orchestrate AI Coding Agents

MCO equips your primary agent with an agent team that can work together to solve complex tasks.

Code

banner-gif

Study Buddy With Self-Evolving Memory

Study proactively with an agent that has self-evolving memory.

Code

banner-gif

Alzheimer's Memory Assistant

Empowering individuals with advanced memory support and daily assistance.

Code

banner-gif

Memory-Driven Multi-Agent NPC Experience

An iOS sci-fi mystery game where players explore and uncover the truth.

Code

banner-gif

Mobi Companion

An iOS app where users create, nurture, and live with a personalized AI companion called Mobi.

Code

banner-gif

AI Wearable With Memory

A context-native AI wearable that listens to everyday life and converts conversations into memory.

Code

Back to top

banner-gif

Legacy OpenClaw Agent Memory

Archived pre-1.0.0 plugin reference. New integrations should use the current EverOS API.

Learn more

banner-gif

Live2D Character With Memory

Add long-term memory to a real-time Live2D character, powered by TEN Framework.

Code

banner-gif

Computer-Use With Memory

Run screenshot-based analysis with computer-use and store the results in memory.

Live Demo

banner-gif

Game Of Thrones Memories

A demonstration of AI memory infrastructure through an interactive Q&A experience with A Game of Thrones.

Code

banner-gif

Claude Code Plugin

Persistent memory for Claude Code. Automatically saves and recalls context from past coding sessions.

Code

banner-gif

Memory Graph Visualization

Explore stored entities and relationships in a graph interface. Frontend demo; backend integration is in progress.

Live Demo


Documentation


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.

divider divider

Code Contributors

EverOS Contributors

divider divider

License

Apache License 2.0 — see NOTICE for third-party attributions.

Citation

If you use EverOS in research, see CITATION.md.