sage-mem · file-based memory for DeepSeek Harness (sage-mem)

中文版见 README.zh.md

Cross-session memory for DeepSeek Harness — plain markdown files, no database, no worker.

Current release: 2.0.0 — the npm badge above is the dynamic source of truth. Contract baseline: 1.0.0 — the first stable release, whose public commitments, the capability boundaries and the list of things it explicitly cannot do are frozen in the frozen contract.

If it is useful to you, a Star is the most direct feedback.

Table of Contents

• What This Is
• Why Files, Not a Database
• Core Features
• Quick Start
• UI Preview
• Memory File Format
• Retrieval and Injection
• Write Safety
• Autodream
• Migrating from Claude Code
• Configuration Reference
• Stability and Versioning Policy
• Permissions and Privacy
• Compatibility
• Architecture
• Contributing
• FAQ
• Uninstall
• Maintainer
• Credits
• Related Projects
• Legacy
• License

What This Is

DSH has no native memory system. Every new session is a blank sheet: it does not remember who you are, where you got to yesterday, or what stage the project is at, so you have to brief it again every time.

sage-mem adds that layer, like this: write down the things worth remembering as cards, and store them on your own computer. Before DSH hands the question to the model, the plugin picks out the few most relevant cards and puts them in front of the model.

So the accurate statement is not "the model remembers you", but "before it opens its mouth, somebody has handed it the relevant slips of paper". Take the slips away and it is that amnesiac colleague again.

A memory takes the form of one .md file per memory (YAML frontmatter + body): openable, editable and deletable in an editor, and manageable with git directly. This memory stays in your own hands the whole time, not in some database.

Why Files, Not a Database

Most memory schemes take the "SQLite + a long-running worker" route: once memories are written into a database they are opaque (to see what is stored you have to go query tables), capturing every event inflates the store (even "the user said hello" counts as a row), and you have to keep an extra process and an extra port alive.

	File-based (sage-mem)	Database + worker
Seeing what is stored	Open the directory	Query tables / write a script
Editing one by hand	Edit it in an editor	Go through an API or SQL
Migration / backup	Copy the directory (travels with git)	Export tooling
Extra process and port	None	Usually yes
Who decides what gets stored	The agent judges by rules	Commonly indiscriminate capture of everything

Core Features

…