Comment installer Anneal Memory ?

Copiez sur cette page la configuration stdio pour Cursor, Claude Desktop, Claude Code ou VS Code. Elle utilise l'installation de l'éditeur, pas un proxy PlugMCP.

Anneal Memory nécessite-t-il une clé API ?

Aucune variable d'environnement requise n'est indiquée sur cette fiche.

Quel transport Anneal Memory utilise-t-il ?

Anneal Memory s'exécute en local via stdio.

Quand Anneal Memory a-t-il été vérifié pour la dernière fois ?

Dernière vérification : 2026-11-10. Two-layer memory for AI agents with an immune system. Zero dependencies.

Serveur MCP Anneal Memory | PlugMCP

Alimenter votre agent

Ajouter ce serveur

La commande propre à l'éditeur. Ce n'est pas un endpoint PlugMCP.

Ajouter à Cursor Ajouter à VS Code Exécuter sur PlugMCP

Host a copy with our keys and logs.

Commande locale

uvx anneal-memory==0.1.1

Claude Code n'a pas de lien d'installation pour une commande locale. Copiez la commande ci-dessous et exécutez-la dans un terminal.

shClaude Code

1claude mcp add io.github.phillipclapham-anneal-memory -- uvx anneal-memory==0.1.1

À exécuter dans un terminal.

jsonClaude Desktop

1{2  "mcpServers": {3    "io.github.phillipclapham-anneal-memory": {4      "command": "uvx",5      "args": [6        "anneal-memory==0.1.1"7      ]8    }9  }10}

claude_desktop_config.json

Local · pypiInstallation de l'éditeurPas à pas : ajoutez-le dans Claude

URL distante ou commande sur votre machine ? Ce qui distingue les deux installations

Exécuter sur PlugMCP

Host a copy with our keys and logs.

A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.

Lancer

Infos sur le serveur

Local

Transport: stdio
Version: 0.1.1
Dernière vérification

De l'éditeur

Documentation

anneal-memory

Living memory for AI agents. Episodes compress into identity.

Memory without grounding is amplification infrastructure.

Persistent user memory profiles increase agent sycophancy 16–45% across models (Gemini 2.5 Pro at 45%, others lower). Production deployments accumulate 97.8% junk entries within weeks. Clinical research documents memory . The failure mode here isn't memory. It's memory with nothing checking what gets kept.

pip install anneal-memory

from anneal_memory import Store, EpisodeType, prepare_wrap, validated_save_continuity

# Initialize (creates DB + continuity file automatically)
store = Store("./memory.db", project_name="MyAgent")

# Record episodes during work
store.record("Connection pool is the real bottleneck", EpisodeType.OBSERVATION)
store.record("Chose PostgreSQL as the database because ACID outweighs speed", EpisodeType.DECISION)

# Recall before decisions
result = store.recall(episode_type=EpisodeType.DECISION, keyword="database")
for ep in result.episodes:
    print(f"[{ep.type}] {ep.content}")

# Compress at session end — this is where the cognition happens
wrap = prepare_wrap(store)  # fetches episodes, marks wrap in progress
if wrap["status"] == "ready":
    # Feed wrap["package"] to your LLM. Compression IS the cognition —
    # patterns emerge from the act of compressing, not from storage.
    compressed = your_llm.compress(wrap["package"])
    validated_save_continuity(store, compressed)  # full immune system pipeline
# "empty" status means no new episodes to wrap — skip

store.close()

# Point the demo at its own store. Without --db or ANNEAL_MEMORY_DB every
# command uses ~/.anneal-memory/memory.db, your default store.
export ANNEAL_MEMORY_DB=./demo.db

# Initialize. Global flags such as --db and --project-name go before the
# subcommand. --project-name names the memory in the continuity header and is
# not stored: pass it on each command (the default is "Agent").
anneal-memory --project-name MyAgent init

# Record and recall
anneal-memory record "Chose PostgreSQL as the database for ACID" --type decision
anneal-memory search "database"

# Consolidation is the operator's act: a new store wraps only under a session
# you have claimed the baton for. Claim once (init --no-baton opts out).
anneal-memory baton claim me

# Agent-driven compression (same workflow as library and MCP)
anneal-memory --project-name MyAgent prepare-wrap --session-id me    # Get compression package
# Agent compresses...
anneal-memory --project-name MyAgent save-continuity out.md \
    --session-id me --wrap-token "$WRAP_TOKEN"                        # the 'Wrap token:' line

# Operator commands (things MCP can't do)
anneal-memory stats                  # Detailed analytics
anneal-memory graph --format dot     # Graph of links formed before 1.0.2 (Graphviz)
anneal-memory diff --wraps 5         # Wrap metric progression
anneal-memory audit --since 7d       # Read audit trail
anneal-memory audit-repair           # Rebuild a quarantined audit manifest, or set aside a corrupt sealed week (--set-aside-unreadable: one that only fails to read)
anneal-memory export --format json   # Full store export

# Done with the demo: return the CLI to your default store
unset ANNEAL_MEMORY_DB

{
  "mcpServers": {
    "anneal_memory": {
      "command": "uvx",
      "args": ["anneal-memory", "--project-name", "MyProject", "serve", "--session-id", "claude-code"]
    }
  }
}

[mcp_servers.anneal_memory]
command = "uvx"
args = ["anneal-memory", "--project-name", "MyProject", "serve", "--session-id", "codex"]

{
  "mcpServers": {
    "anneal_memory": {
      "command": "uvx",
      "args": ["anneal-memory", "--project-name", "MyProject", "serve", "--session-id", "gemini"]
    }
  }
}

	Library	CLI	MCP
Install	`pip install anneal-memory`	Same	`uvx anneal-memory` or same
Record	`store.record(content, type)`	`anneal-memory record "..." --type T`	`record` tool
Recall	`store.recall(keyword=...)`	`anneal-memory search "..."`	`recall` tool
Compress	`prepare_wrap(store)` → agent → `validated_save_continuity(store, text)`	`prepare-wrap` → agent → `save-continuity`	`prepare_wrap` → agent → `save_continuity`
Best for	Framework integration, custom agents	Agents with shell access, operators	MCP-enabled editors

Framework	Integration Point	Guide
LangGraph / LangChain	`AgentMiddleware` (before/after agent + model)	docs/integrations/langgraph.md
CrewAI	`BaseEventListener` (event bus)	docs/integrations/crewai.md
OpenAI Agents SDK	`RunHooks` (agent lifecycle)	docs/integrations/openai-agents.md
Anthropic Agents SDK	agent-instructions snippet + `Stop` hook	docs/integrations/anthropic-agents.md
Google ADK	Callbacks + custom `MemoryService`	docs/integrations/google-adk.md
Pydantic AI	`AbstractCapability` with `Hooks`	docs/integrations/pydantic-ai.md
smolagents	`step_callbacks` dict	docs/integrations/smolagents.md
LlamaIndex	Instrumentation `BaseEventHandler`	docs/integrations/llamaindex.md
Haystack	Custom `Tracer`	docs/integrations/haystack.md
CAMEL-AI	`WorkforceCallback`	docs/integrations/camel-ai.md
AutoGen / AG2	`register_hook()`	docs/integrations/autogen.md
DSPy	`BaseCallback`	docs/integrations/dspy.md

One rung per wrap, measured against what the store last saved. Every check above reads the line the agent wrote, so on its own it would trust the line's date, level and tag shape. The last check reads the store's own record of the level each pattern held when it was last saved: each line is cut to that level, or one rung above it if the line validated this wrap. A pattern new to the store enters at 1x. A pattern dropped from the file and added back returns to the level it was saved at, never to a high-water mark it was later demoted from. The continuity file can lower a level (an operator's hand demotion stands) but never raise one, and a line added to the file outside a save counts as new. So a back-dated line, a bare line, a line whose [evidence:] tag isn't adjacent to its marker, and a line that jumps several rungs on one citation all land where the record entitles them, and a carried-forward hold never lifts a line above it either. A cut line is marked (level-capped) (the mark clears once the line stands at a level it is entitled to), and the cut is reported: level_capped on the save result, the MCP reply and the CLI output, a UserWarning, and the audit chain. Before this check, a brand-new claim | 9x (yesterday) was saved at 9x. Lines are keyed by operator name, and a name's level is its highest line across the graduating sections, as every reader takes it; a renamed pattern is a new one, and a freeform line is keyed by its text, so rewording it makes it new. Only a line's own marker earns its rung: evidence on a second marker later in the line does not. A store's first save under this check takes the file as its prior. A crystal's level is never a prior: a pattern crystallized out of the file before then re-enters as new and re-earns its rungs (its crystal is untouched). Every | Nx marker on a line in a graduating section is governed, dated or not; a line's identity is the text before its first marker, and a line with none (- | 9x) is always new, every marker on it at 1x. The save dates the wrap by the day prepare_wrap gave the composer, so a wrap saved after midnight keeps the graduations it stamped. The check governs what a canonical save writes: a continuity written by the raw Store.save_continuity() or by an older anneal is outside it until the next canonical save, which bounds it against the record again. Schema generation 2, which 1.0 introduces, arms the anneal_writer_schema() write triggers, so an older anneal refuses a store that 1.x has migrated, and anything pinned to one refuses it until upgraded (docs/stability.md, On-disk format).

Hash-chained audit trail. Every memory mutation appends to a SHA-256 hash-chained JSONL audit log. AuditTrail.verify walks the chain and detects post-hoc tampering at the exact entry where the chain breaks. What it does not detect, stated plainly: the append is best-effort after the mutation is durable — a sink failure (disk full, permissions, a failed rotation) is recorded and warned, never raised, because failing the caller would report a completed operation as failed. verify therefore proves the integrity of the entries that were written; it cannot see one that was never written, and will return valid=True over such a gap. The loss is not silent: the count of dropped writes rides into the next entry that lands as dropped_before (so it is itself hash-chained), is surfaced by Store.status() as audit_write_failures / audit_last_failure, and is logged on the anneal-memory logger. audit_write_failures is durable and lifetime-scoped — persisted in the store's SQLite metadata (a different I/O path from the failing sink) and seeded at open, so anneal-memory status --json from a cron job reports losses caused by a process that has already exited, and the number never resets: a trail that lost an entry is permanently incomplete. Poll it rather than relying on having caught the warning. Bounded, not absolute — the guarantee is that a loss recorded here survives the process, not that every loss is recorded: the metadata write is itself best-effort and issued after the mutation committed, so a full volume can fail it too; and a failure raised inside a caller's open transaction cannot commit there, so its delta is written at the end of that batch or, failing that, at close() — a process killed before either loses that last delta. (The dropped_before marker is the narrower of the two: it pins where the gap is in the chain, and it reaches the chain only if a later write lands in the same process. And it can over-report, in one measured case: if you register an on_event callback and that callback raises a terminal exception — KeyboardInterrupt, SystemExit — it escapes the append, which by then has already succeeded and fsynced. The caller cannot distinguish that from a failed write, records a drop, and the next entry carries dropped_before naming an entry that is sitting on disk. Ordinary exceptions from the callback are caught and logged and do not do this. So the marker's honest reading is "a write was reported lost here", not "a write is missing here".) One Store per thread — Store is documented as not thread-safe, not task-safe, not reentrant. Separate processes, each with its own Store, may record into one database: audit appends are serialized by a cross-process lock on POSIX (see "One database is one entity's memory" below), and on Windows the trail needs one writer at a time.

Single-consolidator gate (structural; on by default for new stores). Consolidation is the operator's act. A store created by init or by the MCP server requires the consolidate baton; init --no-baton creates an open one, and an existing store keeps whatever policy it has. The operator claims the baton for a session id once (anneal-memory baton claim NAME); a CLI wrap names it with --session-id, and the MCP server takes it from its launch config (serve --session-id NAME or ANNEAL_MEMORY_SESSION_ID), never from a tool argument. This holds against an agent consolidating through the protocol on its own initiative; it is not a lock against an agent with a shell that runs baton claim itself, which is the operator's to manage. Recording episodes is afferent — append-only, parallel-safe, every session does it. Consolidating — recomposing the compressed identity layer — is efferent: it rewrites shared state, so it's gated to human authority. When several sessions run in parallel over one store (the real operating mode of a multi-conversation operator), each could independently recompose the felt/identity layer from its own narrow slice of context, and the identity memory thrashes. The gate makes the discipline structural: a consolidation proceeds only if this session holds the consolidate baton — otherwise it auto-downgrades to capture-only and surfaces a flag. The operator designates one session as the consolidate seat by claiming the baton, and taking it from another session requires an explicit take=True, so automation cannot take it by accident. (Before 0.9.13 a session that was the only live one was authorized without the baton; that rule is now an explicit allow_sole_live=True opt-in, because "only live session" is judged from a registry snapshot a resumed session can race.) The policy, Store.set_consolidate_requires_baton(True) (on by default for a store init or the MCP server creates, written in the transaction that creates the schema; a Store() opened from Python keeps it off unless set, or unless it creates the store with consolidate_requires_baton_on_create=True), extends the gate to callers that pass no session_id: they downgrade, and a save must name the baton holder (session_id) as well as carry the prepare wrap_token. A wrap prepared with a session_id on any store is committed only by that same session_id (a save that omits it, or names another session even if it now holds the baton, is refused, since the token identifies the wrap, not who may commit it); a gated wrap that cannot be finished is abandoned with wrap-cancel, which for a gated wrap needs its --wrap-token, the preparing --session-id, or an explicit --force (MCP: wrap_token, session_id, force). Because the baton is a file outside the store's transaction, a take landing in the milliseconds between a save's final check and its commit is not seen; the take then applies to the next wrap. The layer engages when a caller passes a session_id or the store carries that policy, and lives in coordination sidecars next to the store, never in the store's single-writer DB. Drift becomes a safe downgrade, not a silent identity-thrash.

Lexical-overlap exploits. An agent who can read episode content can craft an explanation that shares ≥2 meaningful words with the episode while making a claim the episode does not actually support. The explanation-grounding check is anti-fabrication, not anti-misinterpretation.
Rotated-pair citation pumping. Five patterns each citing a distinct pair of episodes from a pool of ten — citation_reuse_max=1, the per-ID gaming detector cannot trip. The shape bypasses gaming detection cleanly. What it cannot bypass is the operator's worklist: probe status lists every pattern a save graduated at 2x and up with a validated citation, whatever the detector said. Run on 2026-10-07, five absurd claims built this way all graduated and all five were on the worklist. Whether a grounded claim is true is the operator's call, as above; the per-ID detector is a hint, not the check.
Deliberately-divergent-vocabulary drift. A pattern whose explanation uses entirely new words each session passes the lexical check and rides up ungrounded. (The library does catch the easier variant — a re-grounding that merely rephrases prior words demotes on a per-prior overlap of ≥3 meaningful words.) Reaching the divergent case needs the contradiction scan plus the operator-review pass below.
Semantic contradiction with existing graduated patterns. No semantic comparison runs between a candidate graduation and existing Proven-tier patterns inside the library — and structurally cannot, under the no-LLM-as-judge rule that keeps the library zero-dependency. The library ships the substrate for catching it: prepare_wrap lists the existing Proven and renders a contradiction-scan step directly into the compression package, recognizes per-pattern [contradicts: name] / [no-contradicts] declarations, and records any new Proven that lands without a stance into the hash-chained audit log — so the discipline travels with the wrap instead of depending on an external doc an adopter has to keep in sync. Turning that substrate into semantic closure is the operator's review, on their own cadence and outside the zero-dep library; drift probes and the audit are its instruments. The library records whether the discipline was followed; it doesn't catch the contradictions itself.
One database is one entity's memory. There is no tenant scoping inside a database: two agents that must not see each other's memory need two stores. Several processes of one entity can record into one store: SQLite serializes the episodes, and each audit append holds a cross-process lock and re-reads the chain's tip from disk first, so the hash chain stays valid. Measured 2026-10-07: before the lock, three processes writing 200 episodes each broke the chain (verify invalid while status counted no audit failure); with it, six processes writing 250 each left one valid chain of 1,500 entries, and four processes appending across a week rotation left one valid chain of 800. Every writer must run a version that takes the lock: an older anneal-memory writing alongside breaks the chain as before. On Windows, or a filesystem without flock, the lock is not held and the audit trail needs one writer at a time.
What a consolidation leaves out does not come back by itself. An episode the composer did not keep is not brought back into the always-loaded continuity automatically. Measured 2026-10-23 over eight nightly consolidations of my own store: of 86 episodes cited in a later save, 85 had already been kept by the first consolidation after they were recorded. The episode is not lost: it stays in the episodic store, and recall and search still find it. The limit is on the always-loaded file, not the store.

  Episodes (fast)              Continuity (compressed)
  ┌─────────────┐             ┌──────────────────────┐
  │ observation  │             │ ## State             │
  │ decision     │── wrap ───→│ ## Patterns (1x→Nx)  │
  │ tension      │  compress  │ ## Decisions          │
  │ question     │      │      │ ## Context            │
  │ outcome      │      │      └──────────────────────┘
  │ context      │      │        always loaded, bounded
  └─────────────┘      │        human-readable markdown
   SQLite, indexed     │
                       │      Crystallized tier
                       └────→┌──────────────────────┐
                              │ proven patterns       │
                              │ recalled on cue       │
                              └──────────────────────┘
                               held out of always-loaded context

  Immune system, at the wrap: citations verified against real episodes,
  ungrounded graduations demoted, reuse flagged, every change audit-logged.

Type	Purpose	Example
`observation`	Pattern or insight	"Connection pool is the real bottleneck"
`decision`	Committed choice	"Chose Postgres because ACID > raw speed"
`tension`	Tradeoff identified	"Latency vs consistency — can't optimize both"
`question`	Needs resolution	"Should we shard or add read replicas?"
`outcome`	Result of action	"Migration done, 3x improvement on hot path"
`context`	Environmental state	"Production DB at 80% capacity, growing 5%/week"

from anneal_memory import Store, FLOW_SCHEMA

# A partnership entity: gains the felt layer + the shrink gate.
store = Store("./memory.db", project_name="flow", section_schema=FLOW_SCHEMA)
# An existing store stays on DEFAULT_SCHEMA untouched — or migrate in place:
store.set_section_schema(FLOW_SCHEMA)   # validated; frozen during an active wrap

Durable facts. One fact per bullet line (- , * or 1. ; an indented line right under it continues it) under ## Durable Facts: things that would change a future answer, or that the user would be upset or harmed to have forgotten (health, allergies, constraints, commitments, preferences, relationships, identity facts, system facts a future action depends on). A line may end with cue words for the situations where it matters: - tree nut allergy — cues: restaurant, dinner, recipe, food, menu (– cues:, -- cues: and | cues: work too); parse_durable_facts(text, schema) returns them as DurableFact(line, fact, cues). At save, every line of the prior section must be in the new one, compared by its fact part, so changing only the cues is an update: a line the wrap left out is re-inserted verbatim (the section is re-created if it is gone) and a warning names it. That is never a refusal. The only way to remove a line is a marker line in the section, [drop-durable: <exact line text>]; the save removes the marker and records the drop in the audit chain (durable_dropped on continuity_saved). A reworded fact is a drop plus an add, and a reword without the marker draws a near-duplicate warning; a re-inserted line that shares cue words or identifier-like tokens with a new one is flagged as possibly superseded. Every durable warning is also on the save result as durable_warnings. The section has its own budget, 15% of the schema's default size target (default_max_chars(schema)) on top of it; a max_chars passed to prepare_wrap does not change it. The wrap package shows it as Durable Facts: <current> / <budget> chars, and over it the save warns and keeps every line. When a value will change on a future event, the line states the current value and the pending change, so a reader does not take the newest code path as today's: - The nightly bank export calls fmt_row52; it switches to fmt_row64 only at the bank cutover, which has not happened. The wrap package lists such pending lines for the composer to re-check.

	anneal-memory	Anthropic Memory MCP	Mem0	Ori-Mnemos	BrainBox
Architecture	Episodic + continuity + crystallized tier	JSONL flat file (graph-shaped)	Vector + graph	Retrieval + Hebbian	Memory + Hebbian
Attention management	Working-set / crystallized split — graduated wisdom recalled on cue, not always loaded	None	None	None	None
Compression	Session-boundary rewrite	None	One-pass extraction	None	None
Quality mechanism	Structural citation-layer primitives (cited episode IDs verified + lexical-overlap explanation check + ungrounded-citation demotion + per-ID gaming flag + audit chain)	None	LLM update step (add / update / delete)	NPMI normalization	None
Audit trail	Hash-chained JSONL	None	None	None	None
Access patterns	Library + CLI + MCP	MCP only	REST API	Python only	MCP only
Dependencies	Zero (Python stdlib)	Node.js	Docker + cloud	Embeddings model	Not specified

System	Quality gate	Gate judged by an LLM?
anneal-memory	Structural citation evidence (agent cites episode IDs; server verifies)	No for promotion (a lexical check); the compression itself is written by the agent's LLM
OpenClaw Dreaming	LLM reflection + six weighted signals: Relevance 0.30, Frequency 0.24, Query diversity 0.15, Recency 0.15, Consolidation 0.10, Conceptual richness 0.06	Yes — Relevance and Conceptual richness are LLM-judged
KAIROS / autoDream	LLM consolidation (merge, remove contradictions, promote tentative observations to absolute facts)	Yes — promotion gate is model-reliant
Letta sleep-time agents (paper)	A background agent rewrites memory; with MemFS every edit is a git commit	Yes — the rewrite is model-judged

Anneal Memory

io.github.phillipclaphamRevendiquer ce serveur

Two-layer memory for AI agents with an immune system. Zero dependencies.

Knowledge Memory

Ajouter à Cursor Ajouter à VS Code Exécuter sur PlugMCPRevendiquer ce serveur

Ajouter à Cursor Ajouter à VS Code Exécuter sur PlugMCP

1{2  "mcpServers": {3    "io.github.phillipclapham-anneal-memory": {4      "command": "uvx",5      "args": [6        "anneal-memory==0.1.1"7      ]8    }9  }10}

.cursor/mcp.jsonServeur MCP

Transport: stdio
État: Local

Ajouter ce serveur

Host a copy with our keys and logs.

Infos sur le serveur

Documentation

anneal-memory

Quick Start

Windows

Python Library

CLI

MCP Server

All Three Paths, Same Cognitive Loop

Framework Integrations

Claude Code / agent-harness adopters (Skill + snippet)

Why This Exists

The Immune System

Structural immune-system primitives at the citation layer

Wrap-package integrity — two checks that guard what the agent is asked to do

Honest scope — what these primitives do NOT catch

Associations: a history

Architecture

Configurable continuity structure

Comparison

The Memory Architecture (Complementary Learning Systems)

Does a recalled memory help? (report-only)

Updated facts: supersession

Prospective memory — spores

The Consolidation Landscape (2026)

On LOCOMO

Session Hygiene

Anneal Memory

Outils

Questions

Comment installer Anneal Memory ?

Anneal Memory nécessite-t-il une clé API ?

Quel transport Anneal Memory utilise-t-il ?

Quand Anneal Memory a-t-il été vérifié pour la dernière fois ?