Brainllm

BrainLLM

Give Claude a memory that survives the session.

Self-hosted memory for LLMs in TriliumNext Notes, structured by the server and editable by you, served over the Model Context Protocol.

Site · Connect to Claude · How it works · Quick start · Privacy

---

What is BrainLLM?

LLMs forget. Every session starts from zero: who you are, what you're working on, what was decided yesterday, what went wrong last week. BrainLLM fixes that.

BrainLLM is an MCP server that gives an LLM a real, persistent memory — stored in TriliumNext Notes, a mature open-source knowledge base you self-host and own. The model opens each session by loading who you are and what's live, writes durable facts the moment they surface, wires knowledge together as a typed graph, and closes each session with a log, a diary entry, and a database backup. The next session picks up exactly where the last one ended.

It's a single Bun/TypeScript service with two dependencies (the MCP SDK and Zod), speaking to Trilium exclusively through its public ETAPI. Your memory lives in *your* Trilium instance — inspectable, editable, and portable, never locked inside a vendor's black box.

Who it's for

Anyone running an LLM as a long-running collaborator, not a one-shot Q&A tool — across coding, research, personal knowledge management, or day-to-day operational tracking — who wants that collaborator to actually remember: who you are, what's in flight, what was decided, without you re-explaining it every session. If you're comfortable self-hosting one small service and a Trilium instance, BrainLLM turns "the model forgot everything again" into a solved problem. It works with any MCP-capable client (Claude Desktop, Claude Code, or anything else speaking MCP), not just one product.

From experiment to open source

BrainLLM began in February 2026 as a personal experiment: could an LLM operate a real, self-hosted memory reliably enough to be trusted as its own memory — orienting, writing, connecting, and closing sessions without a human doing the filing? Through sustained daily, production use the answer held. The design has settled, the failure modes have been found and fixed, and the project has graduated from experiment to something efficient and stable enough to share — so it's now open source. It still runs the author's own sessions every day; what you're reading is the same code, not a demo. It also still carries the shape of one person's daily use — see Adapting to your environment for exactly what that means and what to change.

The core principle

The model supplies content. The server owns form.

Placement, naming, labels, deduplication, relation bookkeeping, lifecycle aging, archival, date stamping, HTML sanitization, backups — and structure itself — are all deterministic server policy, never delegated to the LLM. The model never chooses a parent note, never sets a label, never checks for duplicates, never stamps a date. That division is what makes the memory *reliable*: every guarantee is enforced at the tool layer, not requested via prompt.

Design highlights

• Structure is enforced, not requested — every content kind has a canonical structure, served by template() and held on write: a new thread requires its goal, thread/diary/session entries open with an identification line (which LLM, which environment, which session type), threads carry exactly one Resolution (owned by resolve()), duplicate section headings are detected, and Last updated stamps are server-maintained.
• Domains born complete — creating a knowledge domain creates its book *and* its canonical Sources note (marker legend, stamp, grouped source list, revision table), so every claim has a sourcing home from the first write.
• A visible graph — graph() renders the whole relation graph (or any note's neighborhood) as a Mermaid flowchart, maintained as a native Trilium note.
• Byte-preserving artifacts — text is UTF-8, while binary content uses strict standard base64 in the tool contract and raw bytes on the wire; binary reads return an explicit MIME/base64 envelope instead of replacement characters.
• One-call day orientation — day() serves the previous session, its change log and everything touched since in a single call.
• Two thread shapes — a thread is a dated journal (one child per active day) or a titled collection (one maintained note per item, e.g. an ideas list), chosen once with shape= at creation.
• Timeless notes, dated records — knowledge, information and thread books hold no state or history (only a domain's *Current State* does); maintain(deep=true) flags dated prose that creeps in. Every note except a log carries an icon, set by kind and backfilled by the sweep.
• Resilient plumbing — every backend call is timeout-bounded with retry on idempotent reads; routine core writes are idempotent or duplicate-guarded, while full-mode raw overwrites remain explicit; content surgery survives the editor's own HTML rewriting; renaming a domain cascades to everything inside it; the maintenance sweep heals drift it finds.
• Multi-agent by default — all write-classified tools serialize behind a process-wide FIFO lock, so two agents (an interactive session and an automated run, say) writing through one hosted instance queue in arrival order instead of racing; reads stay fully parallel. Deletion catch-up in the daily log keeps a note deleted after its day's close from vanishing without a trace — and its window is configurable (deletionCatchupDays in the lifecycle policy), defaulting to Trilium's 7-day retention.
• Ask in prose, split on a seam — consistency(subject="…") finds every note asserting about a fact however it is phrased, no regex guessing; consistency(pattern, staleAfterDays=N) surfaces figures held in exactly one untouched note, the ones that rot silently because nothing disagrees with them, and skips sessions and diaries, which are history rather than claims; diff(since="today") reviews every note a session changed in one call; revise(find="Phase 2", within="tr") edits, inserts or removes a table row named by a few words inside it; read(ids=[…]) batches a multi-note orientation into one round trip — each note's size up front, or a single section= across them; and split(noteId, sections=[…], into="…") is the write half of the oversized-note problem — it lifts whole sections into a new note and leaves a pointer back. Information notes can carry a #mandate marker so a scoped session finds the one note it must obey without reading every note's prose.
• A distinct connector identity — hosted instances advertise BrainLLM and their own origin, with same-origin PNG/SVG icons, explicit page favicon links and a real multi-size ICO. The canonical mark is shared across the connector, consent pages and public assets.
• Preview changes and measure coverage — revise(noteId, edits=[…], dryRun=true) shows sequential match counts and sanitized before/after content with no revision, labels or gate writes. Revision failures stop content overwrites. consistency() reports read failures and scan coverage; case-insensitive comparisons retain spelling variants without false conflicts. Incomplete scans cannot establish absence or unanimity.
• Registers close in one call — revise(find, within="tr", mode="remove", closure={thread, body}) removes a register row and records its closure in that thread's entry for the day, closure={note, table?, row?} moves a row into an explicitly selected register table; destination cells must match the table's shape. Destination-first ordering preserves recoverability, and moves=[{find, row?}] batches closures with preflight and per-row progress, and append={table, row} adds a row with no anchor to find; within= also accepts a row as a reader sees it ("Phase 2 | Claude | Open"), and a table row whose cells disagree with its header is flagged at write time and by maintain(deep).
• Bulk edits and lighter receipts — revise(find, within="tr", mode="remove", all=true) removes every row an anchor sits in, in one write and previewable with dryRun=true; remember(kind="sources", revision=[{source, from}]) renames a Sources key when a source moves instead of adding a second row; a dated-thread append returns previousRun, its author's previous block and run number; read(ids, sizes=true) plans a bulk read from sizes and section sizes alone; and diff(since="today", summaryOnly=true) lists what changed without the lines.
• Records you can prove — sessions, diary entries and dated thread entries are append-only, and now verifiably so: every close() seals its day's records into a digest chained to the previous day's, and maintain(deep) reports any sealed record that was rewritten afterwards. Appends stay legal; edits to history do not go unnoticed.

---

How it works

At bootstrap, BrainLLM builds a five-area tree in Trilium. Every note the tools create is typed, labeled, dated, and placed by server policy:

BrainLLM  (#brainLlmRoot)

├── 👤 Master Biography · Goals · Preferences (the user — maintained singletons) ├── 🤖 LLM Responsibilities · Protocols · Self-correction · Diary/ (the assistant's self-model + daily diary) ├── 🗂️ Memory Sessions/ · Threads/ (daily session logs + multi-session work) ├── 📚 Knowledge Master/ · Domains/ /{ Sources, info } (learned facts beyond/contra training) └── 💡 Insights Logs/ · Graph · Claims (the brain's record of itself)

A session follows an enforced protocol: start() orients (who you are, live threads, what changed since last time) → the model works, writing durable facts *as they surface* → session() → addendum() → maintain() → remarks() → diary() → close() commits the log, regenerates the daily change log, and triggers a DB backup. The pre-close gate is enforced in code: close() refuses unti