Save a durable memory. UPSERTS: a memory of the same type with the same (whitespace/case-normalized) title is updated in place instead of duplicated, so re-remembering a fact refines it rather than cluttering.

Worth remembering: decisions and their reasons, conventions, gotchas that cost time, the user's preferences and how they like to work, facts about the environment (paths, commands, accounts) you had to discover. Not worth it: anything derivable from the code, or a transcript of what you did. Remember it when you learn it, not at the end of the session.

Memories of type project/feedback/reference are tagged with the current project automatically (proj:<name>, from CLAUDE_PROJECT_DIR) unless you pass a proj: tag yourself; user memories are about the person and stay global.

Args: type: one of "user", "feedback", "project", "reference". title: a short label; also the dedup key within a type. body: the fact. For feedback/project, a "Why:" / "How to apply:" line helps. tags: optional comma-separated tags. links: optional list of related memory ids. Merged (union) into any links already on the memory, never replaces them - omitting this on a refine call preserves links set earlier. crystallizes: optional list of source memory ids this memory abstracts; links it over them as a crystallized principle (needs TETHER_CRYSTALLIZE).

Returns {"id", "action"} where action is "created", "updated", or (with TETHER_CONSOLIDATE on) "consolidated" - a near-duplicate was superseded.

Search memories by keyword and semantic similarity, then follow the usage graph to related memories, most relevant first.

Ask in plain language, the way you would ask a colleague ("how do we run the integration tests?", "what did the user decide about the auth library?") - a memory matching some of the words is a hit, and the best match ranks first. Recall BEFORE starting a task, not only when stuck: the index you were given at session start is titles only. Memories from the current project rank slightly ahead of equally-good ones from elsewhere.

Each hit carries {id, type, title, body, tags, updated_at} and a via receipt explaining why it surfaced (a direct match, or the edge it was reached through). Use updated_at to judge staleness (an old fact may no longer hold; verify before relying on it) and id to cite what you update via remember/link.

body is an EXCERPT centered on your query, not the whole memory. When a memory was longer than the excerpt, the hit also carries truncated: true and body_chars (the full length). To read one in full, call recall(id=N) - that returns just that memory, whole.

Args: query: free text; punctuation is safe. May be omitted if tags is given. type: optional filter ("user"/"feedback"/"project"/"reference"). limit: max results (default 20). budget: how far to follow associations (0 = direct matches only). session: optional id grouping related recalls so they prime each other. tags: optional comma-separated tags; exact-match filter (a memory must carry every listed tag). Combine with query to filter its ranked hits, or use alone (query omitted) to list every current memory with those tags, newest first, deterministic rather than ranked - raise limit to fetch beyond the default page size. id: fetch this one memory in full instead of searching. Use it after a search returns a truncated hit you want to read completely. full: return complete bodies for every hit instead of excerpts. Costs the whole payload - prefer id= for the one memory you actually need.

Create a bidirectional link between two memories by id.

Soft-delete a memory by id: marks it no longer current (excluded from recall/the boot index) but keeps the row, reversibly, like consolidation and the forgetting sweep already do. Returns {"forgotten", "existed"}. (Permanent purge is an admin-only CLI operation, not available here.)