Documentation

Everything, in the
order you'll need it.

One binary, two places the memories can live, three ways an agent reaches them. Start at install. Read the memory model once, because every refusal in the tool follows from it. Keep the CLI reference open.

Start here

Install and the first hour

Get the binary, create a brain, prove the hooks actually fired and seed the store from a project that already has months of history behind it.

Read →
The model

How memory works here

Types, decay tiers, the six-term score, scopes, confidence and trust, supersession, provenance stamps and review dates. The one page worth reading end to end.

Read →
Reference

Every command, every flag

All 67, grouped by how often you touch them, with the flags that carry weight and what each refusal is protecting. Generated against the binary, not from memory.

Read →
Surface

MCP, stdio and HTTP

Every command as a tool. Client configs that work, the three inputs no CLI flag corresponds to and the one setting that stops your memories landing under another project's name.

Read →
Surface

The brain from your phone

Your brain in the Claude app, over your own Tailscale Funnel, with the authorization the app requires served by the binary itself. What it costs and what has to be awake.

Read →
Surface

The web UI in the binary

ns-brain ui. No Node, nothing to install and no SQL of its own: every route builds an argv and runs the ordinary dispatch, so ranking and scoping cannot drift from the CLI.

Read →
Many projects

One store, several projects

A file each or one shared file, the per-project opt-out, cross-project notes, axioms and house standards and why nothing arriving through any of them carries authority.

Read →
Beyond memories

Tasks, measures, the user model

What is owed and when, numbers that only mean something as a series and the opt-in domains that stay invisible until you use them.

Read →
Server

Hive

Sign in, move a project onto a server, what happens to a write when the server is unreachable, the HTTP API and running your own.

Read →
Server

The HTTP API

All forty-eight routes, what credential each takes and which ones need owner. Including the export the refusals point you at.

Read →
Server

Away from home

A brain on a machine at home, reached from a laptop on mobile data, with no inbound port and no VPN. What it costs in latency and what happens the day a machine is stolen.

Read →
When it is wrong

Troubleshooting

The brief did not appear. Recall returns nothing. Memories under the wrong project name. doctor, map, review and reading a refusal for what it is protecting.

Read →
Pick by situation

What to read,
for what.

One machine and one developer is the whole product for most people and the CLI page is all of it. Everything else here exists because one of two things changed: a second machine, or a second person.

SituationWhat you runPage
One machine, one developerThe CLI, wired to session hooksInstall
An agent that cannot run shell commandsMCP over stdioMCP
The Claude app on your phone, away from the deskThe same server published on your own tailnetPhone
A laptop and a desktopOne brain, the other machines enrolled against itRemote
Six projects and one set of habitsA shared store, with per-project opt-outSharing
A second person on the brainA Hive serverHive setup
A security review to answerNothing. Send them the page.Security
For the agent, not for you

Two documents ship
inside the binary.

ns-brain init writes both into your project, so an agent working there already holds them without fetching anything. They are also served here.

HOWTO.md is the mechanics: which command to reach for, what each flag does to the store and the shapes of the output. BEST-PRACTICES.md is the judgment: what is worth storing at all, what is derivable from code or git and therefore noise and how to write a title that will still be findable in March.

For an agent that landed here because somebody said install https://brain.fightclub.pro/, the short version is llms.txt and the full procedure is install.md. Neither needs the HTML.