# cass-memory: Cross-Agent Procedural Memory for AI Coding Agents > cass-memory is a CLI tool that transforms scattered AI coding agent session logs into a persistent, cross-agent memory playbook. It runs locally, distils raw session history into confidence-tracked procedural rules, and makes those rules available to every agent before it starts a new task. **Dicklesworthstone/cass_memory_system** — Procedural memory for AI coding agents: transforms scattered session history into persistent, cross-agent memory so every agent learns from every other - Repository: https://github.com/Dicklesworthstone/cass_memory_system - Stars: 443 · Forks: 50 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/dicklesworthstone-cass-memory-system ## The Cross-Session Memory Problem cass-memory Addresses AI coding agents accumulate useful knowledge during sessions: debugging strategies, project-specific patterns, workarounds for known issues. But each session ends and the context is gone. Claude Code does not know what Cursor learned the previous day. Cursor does not know that the same authentication bug has been solved three times this month by different agents. The README frames the problem in four parts: knowledge is trapped in sessions (each session ends, context is lost), agent-specific (different tools do not share what they learned), unstructured (raw conversation logs are not actionable guidance), and subject to collapse when naively summarised. cass-memory addresses this by maintaining three layers of memory. Episodic memory holds raw session logs from all agents as the ground truth. Working memory holds structured session summaries as diary entries. Procedural memory holds distilled rules with confidence tracking as playbook bullets. Together, these mirror how human expertise develops: raw experiences become structured memories, which eventually become automatic procedural knowledge. The tool is designed as a first-class concern for AI coding agents, not an afterthought. The README's section header for agent usage describes it as the most important section of the documentation. ## The ACE Pipeline: How Raw Logs Become Playbook Rules The memory system is built around what the README calls the ACE pipeline. Session logs from any supported agent feed the episodic memory layer via the cass search engine. The tool processes those logs through structured diary entries in the working memory layer. Finally, the playbook layer distils the diary entries into specific, actionable rules. Rules are not accepted blindly. Before a rule joins the playbook, the system validates it against the cass history. The README gives an example: a proposed rule about checking token expiry before authentication debugging is evaluated against sessions where that rule would have applied. If five sessions are found with four successful outcomes, the rule is accepted. Rules without historical evidence are flagged as candidates. Rules in the playbook are not permanent. The confidence decay system applies a 90-day half-life: confidence halves every 90 days without revalidation. The README also documents a 4x harmful multiplier: one mistake counts four times as much as one success when calculating a rule's confidence. Rules progress through maturity stages from candidate to established to proven. When a rule accumulates three harmful marks, it is inverted into an anti-pattern warning rather than deleted. The example in the README shows a caching rule becoming a warning: the stored failure becomes guidance for future agents to avoid the same mistake. ## Installing cass-memory and Running the Agent Quickstart The README provides a one-liner install for Linux and macOS: ```bash curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/cass_memory_system/main/install.sh?$(date +%s)" \ | bash -s -- --easy-mode --verify ``` Alternatively, install via package managers: ```bash brew install dicklesworthstone/tap/cm ``` For Windows via Scoop: ```bash scoop bucket add dicklesworthstone https://github.com/Dicklesworthstone/scoop-bucket scoop install dicklesworthstone/cm ``` The binary is named cm (short for cass-memory). The README recommends always using --json in agent contexts, because stdout carries data and stderr carries diagnostics, with exit code 0 indicating success. The agent quickstart sequence from the README: ```bash cm context "implement auth rate limiting" --json cm quickstart --json cm onboard status --json cm onboard sample --fill-gaps --json cm onboard read /path/to/session.jsonl --template --json cm onboard mark-done /path/to/session.jsonl ``` The first command retrieves task-specific memory before starting work. The onboard commands build the playbook from existing session logs. The tool is built with Bun and compiles to a self-contained binary, so it runs without a Node.js or Bun runtime installed on the target machine. ## Cross-Agent Learning: Unified Memory Across Claude Code, Cursor, and Others The central feature that distinguishes cass-memory from simple context files is cross-agent learning. Session logs from Claude Code, Cursor, Codex, Aider, PI, Gemini, and ChatGPT all feed the same unified knowledge base. A debugging technique discovered in a Cursor session is immediately available to Claude Code in the next session without any manual transfer. The README describes the flow visually: multiple agent sessions feed into a unified playbook, and every agent benefits from that shared output. The episodic memory layer (the cass search engine) serves as the shared ground truth, and the playbook distils the actionable conclusions from it. This cross-agent architecture has a practical prerequisite: the tool must be able to access session logs from each agent in a processable format. The onboard commands read session logs from files in JSONL format. Whether a given agent's session history is available in a compatible format depends on how that agent stores its logs, which is outside cass-memory's control. The system also works in degraded conditions. The README documents graceful degradation across four failure modes: no cass (playbook-only scoring, no history snippets), no playbook (commands still work but return empty playbook), no LLM (deterministic reflection without semantic enhancement), and offline (cached playbook plus local diary). ## Limitations: LLM Dependency, Onboarding Cost, and Licence Uncertainty Full cass-memory value requires an LLM connection for semantic rule enhancement. Without an LLM, the tool falls back to deterministic reflection, which is described as a degraded mode in the README. Teams running fully air-gapped systems without LLM access get reduced functionality. The onboarding pipeline is the entry point for all memory value. Teams with no existing session logs in a compatible format get an empty playbook until they accumulate and process sessions. The ACE pipeline requires running through the onboard sequence to seed the playbook, which is not a one-time action; it requires ongoing session processing to keep the playbook current. All data is local. Session logs, diary entries, and playbook rules are stored in local files (the README references .cass/ and .beads/ directories in the repository structure). This is a privacy advantage for teams that cannot send session data to an external service, but it also means the memory does not follow the developer to a new machine without explicit copying. The repository's detected licence is listed as unknown, though the package.json declares MIT. Teams that require a confirmed open-source licence should check the LICENSE file directly before adopting the tool in a commercial context. ## cass-memory vs. Mem0 Mem0 (mem0ai/mem0) is a managed memory layer for AI applications that stores user and session memories as structured data in a hosted service. Both cass-memory and Mem0 address the problem of giving AI systems persistent memory, but they take fundamentally different approaches. Mem0 operates as an external API service. Integrating Mem0 requires changing agent code to call the Mem0 API to store and retrieve memories. Memory lives in Mem0's infrastructure, is accessible across devices, and can be shared across team members with appropriate access. The hosted service means no local infrastructure to maintain, but it also means data leaves the local machine. cass-memory runs entirely locally as a CLI tool. It reads existing session log files from whatever format the coding agent produces, requires no code changes to the agent itself, and keeps all data local. The tradeoff is that team sharing requires explicit synchronisation of the local data, and there is no managed service to handle persistence across machines. For individual developers who want local-first memory that works with existing agent session logs without changing their tooling, cass-memory is the more practical choice. For teams that want shared memory infrastructure accessible to all members without managing local data, Mem0's hosted model is the more appropriate architecture. ## Conclusion cass-memory is useful for developers who use multiple AI coding agents (Claude Code, Cursor, Codex, Aider) on the same codebase and want the patterns discovered in one agent's sessions to carry over to another without manual knowledge transfer. It is the wrong choice for teams that want a simple, stateless system prompt: cass-memory requires onboarding existing session logs, running the ACE pipeline to build a playbook, and feeding the playbook context to each agent before tasks. The v0.3.0 release was published on 2026-09-28. The package.json lists the licence as MIT, though the repository's detected licence is listed as unknown. Before adopting it, verify that you have session logs in the format cass-memory can process, since the onboarding pipeline is the entry point for all memory. ## FAQ ### What does cass-memory do? cass-memory reads session logs from AI coding agents, distils recurring patterns into a confidence-tracked playbook of procedural rules, and makes those rules available to any agent before it starts a task. It supports Claude Code, Cursor, Codex, Aider, Gemini, and others from a single shared knowledge base. ### How do I install cass-memory? On macOS and Linux, the one-liner installer uses the install.sh script with --easy-mode --verify flags, or brew install dicklesworthstone/tap/cm via Homebrew. On Windows, use Scoop after adding the dicklesworthstone bucket. The binary is named cm. ### Does cass-memory require a connection to an LLM service? An LLM connection is needed for semantic rule enhancement but is not required to run the tool. Without an LLM, cass-memory falls back to deterministic reflection. The README describes this as a degraded but functional mode, alongside other graceful degradation scenarios for offline use or missing session history. ## Sources - [Dicklesworthstone/cass_memory_system on GitHub](https://github.com/Dicklesworthstone/cass_memory_system) - [Issues](https://github.com/Dicklesworthstone/cass_memory_system/issues) - [README](https://github.com/Dicklesworthstone/cass_memory_system/blob/main/README.md) - [Releases](https://github.com/Dicklesworthstone/cass_memory_system/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dicklesworthstone-cass-memory-system