verify-everos
Skill14k starsChanged 16 days agoApache-2.0View on GitHub
Verify an EverOS change on a real server - start your own instance, drive it over HTTP or through Claude Code with everos-mcp, read the outcome from the layer that owns it (markdown, SQLite, LanceDB, metrics), and tear it down. Use before saying a memory feature works end to end.
- Reads credentials
1 other project uses a version of this.
Trending
More talk lately.about the whole repository
Most recently taken up by
- EverMind-AI/EverMemOSword for word, first seen Nov 8, 2026
Who's talking about EverMind-AI/EverOS
- BACKFIRED X“EverOS: One Portable Memory Layer Across Your AI Tools”YouTube · Jul 3, 2026 · 396 views
- GitHub Trending Digest“EverOS - GitHub Trending Today”YouTube · Jul 17, 2026 · 355 views
- Dann Paker AI“EverOS: Long-Term Memory for AI Agents”YouTube · May 19, 2026 · 342 views
- Dann Paker AI“EverOS: Long-Term Memory for AI Agents”YouTube · May 22, 2026 · 141 views
- Dann Paker AI“EverOS: Self-Evolving Memory for AI Agents”YouTube · Jun 8, 2026 · 132 views
The biggest 5 of 48 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 48
Talked about on GitHub, YouTube, Bluesky and the web (48 times).
On GitHub · 39
- Nov 8, 2026agent-skills.github.evermind-ai.everos: init at 1.5.1 — sudosubin/agents.nix0 reactions
- Nov 7, 2026fix(cascade): stop reporting a failed index write as extracted — JunjianS/EverMemOS0 reactions
- Nov 3, 2026Add ever-opencode — local-first persistent memory plugin (automatic capture + recall, EverOS-backed) — awesome-opencode/awesome-opencode0 reactions · 1 comment
- Oct 18, 2026deps: bump everos from 1.2.3 to 1.4.2 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Oct 13, 2026[Benchmark][Comparators] Expand real same-harness market cohort beyond Mem0, with per-profile peer coverage — MythologIQ-Labs-LLC/agent-memorysays it tested it0 reactions · 9 comments
34 more on GitHub
- Oct 9, 2026deps: bump everos from 1.2.3 to 1.4.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Oct 5, 2026deps: bump everos from 1.2.3 to 1.4.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Oct 1, 20261.4.1 hybrid search times out while cascade backlog shares the embedding semaphore — RyderFreeman4Logos/EverOS0 reactions · 1 comment
- Sep 29, 2026[Request] EverMe integration: persistent cross-device, cross-agent personal memory via MCP — lobehub/lobehub0 reactions · 4 comments
- Sep 28, 2026deps: bump everos from 1.2.3 to 1.4.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Sep 24, 2026deps: bump everos from 1.2.3 to 1.3.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Sep 21, 2026deps: bump everos from 1.2.3 to 1.3.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Sep 20, 2026Consider Engram, Caura, TencentDB Agent Memory, memU, and EverOS in comparison docs — akitaonrails/ai-memory0 reactions · 1 comment
- Sep 17, 2026deps: bump everos from 1.2.3 to 1.3.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Sep 16, 2026docs: point EverOS links at the right destinations — EverMind-AI/EverOS-Convex0 reactions
- Sep 15, 2026deps: bump everos from 1.2.3 to 1.3.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Sep 11, 2026deps: bump everos from 1.2.3 to 1.3.1 — RonsenbergVI/agent-memory-benchmarks0 reactions
- Sep 7, 2026Weekly discovery: new DeepSeek Harness ecosystem candidates — fendouai/awesome-deepseek-harness0 reactions · 1 comment
- Sep 3, 2026feat(llm): add aimlapi.com as an LLM endpoint with partner attribution — aimlapi/EverOS-aimlapi0 reactions
- Aug 31, 2026Weekly discovery: new DeepSeek Harness ecosystem candidates — fendouai/awesome-deepseek-harness0 reactions · 2 comments
- Aug 29, 2026[repo] EverMind-AI/EverOS — lucas-albers-lz4/sre-ai-llm-work0 reactions · 2 comments
- Aug 28, 2026[Feature Request] Explore EverOS as an optional AgentMemory backend — camel-ai/camel0 reactions
- Aug 28, 2026Feature: optional EverOS long-term memory integration — deepset-ai/haystack0 reactions · 3 comments
- Aug 24, 2026Weekly discovery: new DeepSeek Harness ecosystem candidates — fendouai/awesome-deepseek-harness0 reactions · 1 comment
- Aug 21, 2026[new system]: EverOS (EverMind) — RonsenbergVI/agent-memory-benchmarks0 reactions
- Aug 9, 2026Estudos de referência: repositórios e soluções externas (guarda-chuva) — renatobardi/kubo0 reactions
- Jul 24, 2026[Feature Request] Optional EverOS long-term memory extension for Langflow — langflow-ai/langflow0 reactions · 2 comments
- Jul 23, 2026[Feature Request] Optional EverOS LearningStore + cookbook for local-first user and agent memory — agno-agi/agno0 reactions · 1 comment
- Jul 22, 2026Python: [Feature]: Explore EverOS as an optional Python long-term memory ContextProvider — microsoft/agent-framework0 reactions · 4 comments
- Jul 21, 2026[Feature Request] EverOS as an optional local-first long-term memory backend — google/adk-python0 reactions · 2 comments
- Jul 20, 2026feat(core): MemCell foresight/validity-window on ExperienceRecord + MemScene thematic clustering port (EverOS pattern) — hleserg/atman0 reactions · 1 comment
- Jul 8, 2026AI Agent 上下文/记忆/知识管理的开源竞品调研 — Pines-Cheng/blog0 reactions
- Jul 3, 2026Create Memory Agents system — ANFAIA/MalariaSentinel0 reactions
- Jun 18, 2026RFC: EverOS-inspired roadmap for local-first mempal memory — RyderFreeman4Logos/mempal0 reactions · 2 comments
- Jun 5, 2026No information on where the md files sit, assuming it's still md files, given this link was provided from https://github.com/EverMind-AI/EverOS — tt-a1i/everos-mcp0 reactions
- May 24, 2026research(evermembench): harness investigation + adapter skeleton — totobusnello/memoria-nox0 reactions
- May 22, 2026【开源自荐】EverOS:一个让 AI Agent 拥有长期记忆的开源系统,内置大量真实 Use Cases — ruanyf/weekly0 reactions
- May 13, 2026[TEST] [Security Track] CWE-798: security tracker smoke test — Fearvox/EverOS0 reactions · 3 comments
- May 13, 2026[TEST] [PR Track] #196: webhook smoke test — Fearvox/EverOS0 reactions · 2 comments
On YouTube · 6
- Jul 3, 2026EverOS: One Portable Memory Layer Across Your AI Tools — BACKFIRED X396 views · 3 comments
- Jul 17, 2026EverOS - GitHub Trending Today — GitHub Trending Digest355 views
- May 19, 2026EverOS: Long-Term Memory for AI Agents — Dann Paker AI342 views
- May 22, 2026EverOS: Long-Term Memory for AI Agents — Dann Paker AI141 views
- Jun 8, 2026EverOS: Self-Evolving Memory for AI Agents — Dann Paker AI132 views
1 more on YouTube
- Oct 16, 2026Module 13: A Memory Operating System | Context & Agent Memory in LLMs — Omar Kamal28 views
On Bluesky · 2
- Sep 8, 2026No storage migration or index rebuild required. Multi-round retrieval is opt-in. github.com/EverMind-AI... — @evermind-ai.bsky.social1 likes and repost
- Jun 11, 2026EverOS Build, evaluate, and integrate long-term memory for self-evolving agents. https://github.com/EverMind-AI/EverOS — @pythonhub.dev1 likes and repost
On the web · 1
- Apr 13, 2026EverMind Introduces EverOS, a Long-Term Memory ... — pr.dailyastorian.com
Other versions1 project uses a version of this.
Word for word · 1
- EverMind-AI/EverMemOS★ 14k100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- add-memory-kindSkill
- commitSkill
- new-branchSkill
- prSkill
- releaseSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 14
Never use ~/.everos or a server someone else started.
- Very specific: line 38
Before reading the index, poll it once a second until it reads 0 on two consecutive samples (docs/api.md, and wait_converged in …
- Very specific: line 51
Claude Code, the way users do it: run everos-mcp against your port and start Claude Code with only that server, in a tmux socket of your …
- Distinctive: line 88
Stop the pid you started, after checking it is yours, then wait for the port:
- Very specific: line 97
Never pkill by pattern: other sessions on the machine run their own servers.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/verify-everos - check a change on a real server
Unit and integration tests run the code with stand-ins; this is how to see
the real everos server do it. Grown one task at a time: each task adds the
features it actually walked (see the feature map at the end), nothing more.
1. Start your own instance
Never use ~/.everos or a server someone else started. Give every check its
own root and port.
ROOT=$(mktemp -d)/root; PORT=18611
lsof -nP -iTCP:$PORT -sTCP:LISTEN # must print nothing
uv run everos init --root "$ROOT"
EVEROS_LLM__API_KEY=$OPENROUTER_API_KEY \
EVEROS_EMBEDDING__API_KEY=$DEEPINFRA_API_KEY \
EVEROS_RERANK__API_KEY= \
uv run everos server start --root "$ROOT" --port $PORT > "$ROOT.log" 2>&1 &
echo $! > "$ROOT.pid"The shipped defaults point the LLM at OpenRouter and the embedding at
DeepInfra, so those two keys are all it needs. Reflection is off by default
(docs/reflection.md); to turn it on, replace the $ROOT/ome.toml that
init scaffolds with [strategies.reflect_episodes]\nenabled = true before
starting, as the acceptance tests do.
2. Is it ready?
curl -s http://127.0.0.1:$PORT/health answers 200 within a few seconds.
Its cascade.pending is the number of markdown changes not yet in the index.
Before reading the index, poll it once a second until it reads 0 on two
consecutive samples (docs/api.md, and wait_converged in
tests/acceptance/memory_delete/observe.py): a single 0 can come between a
markdown write and its projection being queued. A server that exits instead: the last
lines of $ROOT.log (usually a missing key).
3. Drive it
- HTTP:
POST /api/v2/memory/add,/flush,/delete(user_id/agent_id/session_id),/delete_by_ids({"memory_type": "episode", "memory_ids": ["<owner>_<entry_id>"]}),/memory/search,/memory/get. Run Reflection now withPOST /api/v2/ome/trigger {"name": "reflect_episodes", "force": true}. Claude Code, the way users do it: run everos-mcp against your port and start Claude Code with only that server, in a tmux socket of your own (
tmux -L <name>), sending keys and reading the pane:{"mcpServers": {"everos": {"command": "uv", "args": ["run", "--no-project", "--with", "everos-mcp==0.1.1", "python", "-m", "everos_mcp.server"], "env": {"EVEROS_BASE_URL": "http://127.0.0.1:18611", "EVEROS_USER_ID": "me", "EVEROS_SESSION_ID": "walk-1"}}}}claude --mcp-config <that file> --strict-mcp-config. A turn is finished when the pane shows its completion line (... for Ns · done), not when somefor Nsappears (the thinking line has one too).- Racing a background task:
make acceptance(needs the two keys; the Milvus cases need docker) starts servers behind a local proxy that can hold one model call (tests/acceptance/memory_delete/proxy.py), so a deletion can land while an extraction or a Reflection merge is in flight. Check that the held call is still the only one of its kind when the deletion answers: a model call that times out retries past the hold.
4. Read the outcome where it lives
| Fact | Read it from |
| A memory exists | the markdown: $ROOT/<app>/<project>/users/<id>/episodes/episode-<day>.md, .atomic_facts/, .foresights/, user.md; agents under agents/<id>/ (tests/acceptance/memory_delete/observe.py md_entries parses them) |
| Session, cluster, queue state | $ROOT/.index/sqlite/system.db (memcell, cluster, cluster_member, memorize_inbox, ...); OME runs in ome.db beside it |
| Index rows | LanceDB under $ROOT/.index/lancedb/ (observe.py lance_ids); on Milvus read with consistency_level="Strong", or you may see rows from before a deletion |
| Lock waits and holds | GET /metrics: everos_lock_wait_seconds, everos_lock_hold_seconds (label kind: session, owner, partition:<strategy>); compare before/after deltas |
| What the server complained about | $ROOT.log; it is coloured, so strip ANSI codes before grepping (perl -pe 's/\e\[[0-9;]*m//g'), or [error matches nothing |
A search that finds nothing is not proof of a deletion: read the markdown and the index directly.
5. Tear down
Stop the pid you started, after checking it is yours, then wait for the port:
ps -o args= -p $(cat "$ROOT.pid") # must show `everos server start`
kill $(cat "$ROOT.pid")
for i in $(seq 1 50); do lsof -nP -iTCP:$PORT -sTCP:LISTEN >/dev/null || break; sleep 0.2; done
tmux -L <name> kill-server # if you drove Claude CodeNever pkill by pattern: other sessions on the machine run their own
servers.
Feature map
One row per feature a task has walked on a real server.
| Feature | Reach it | Drive it | End state that proves it works |
| Forget a conversation from Claude Code | everos-mcp forget_session (Section 3) | ask the model to remember a sentence (add_memory, wait true), then "forget this conversation" | no entry with that session_id in the markdown, no .md file contains the sentence, search_memory finds nothing |
Delete a session (session_id only) | POST /api/v2/memory/delete {"session_id": ...} | while its episode extraction is held at the proxy | 200; the session's memcell rows gone; no entry of the session appears in the markdown after the hold is released |
| Delete a whole user / agent | POST /api/v2/memory/delete {"user_id": ...} | after seeding several kinds | 200 with count; only today's empty day files remain (they keep the id counters), user.md gone, the owner's cluster rows and index rows gone; .. and a/../b answer 422 |
| Delete episodes by id with Reflection on | POST /api/v2/memory/delete_by_ids | while the Reflection merge call is held | no merged episode (parent_type: cluster) appears; the deleted source and its atomic facts are gone, the other source stays |
| Deletion latency | tests/acceptance/memory_delete/test_t18_1_tb11_1_perf.py, alone on the machine | a year of day files per user | each deletion <= 1 s; owner-lock holds of all session deletions p99 <= 20 ms, none over 100 ms |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

