No, by default. Sandra is self-hosted. The graph lives in your database, on your machine or your server.
That includes meaning-based search, which used to be the exception and is not one any more. Turning it on used to send everything you memorised to OpenAI to be turned into a numeric representation; since Phase 7 the thing that does that conversion is another container in your own stack, so the text never leaves your machine.
There is no longer any advice here about leaving a feature off if you handle confidential material. That advice existed because the design needed it. The design changed instead.
The software is free and MIT-licensed. You provide a container and a database, which on a small server is a rounding error.
If you enable meaning-based search, you run one more container and it uses your own CPU rather than anyone's invoice. It is not free in the sense of costing nothing: the model wants a couple of gigabytes of memory and takes a fraction of a second per item it processes. Nothing is billed per word.
Yes — that is the main use. One instance, everyone connects to it, everyone sees the same memory.
Each person gets their own token, so access can be revoked individually rather than by rotating a shared password.
Yes. One instance can hold several independent memories that cannot see each other — one per client, or per project. Alternatively, run a container per project with its own database. Both are supported.
The controls are there: every request requires a token, tokens carry read-only or read-write permissions, they can be revoked or given an expiry, and requests are rate-limited.
Two things are your responsibility. Do not store secrets in it — it is a memory store, not a vault. And do not expose it to the internet without a token; if you use the tunnel for claude.ai, set one first.
Worth knowing if you used the original Sandra: an unset token used to mean "no authentication required". It now means the server refuses requests. That is a deliberate change — the old default was one forgotten environment variable away from an open, writable memory store.
You lose the memory. It is the only copy, so back it up — the same way you would any database holding something you cannot reconstruct.
This is worth stating plainly because the memory accumulates invisibly, as a side effect of working, and it is easy to forget it exists until it is gone.
Comfortably more than a team will generate by hand — hundreds of thousands of facts.
One caveat: below a few thousand memories, meaning-based search compares against every stored item, which is exact and takes a fraction of a second. Above that it switches to an index that is fast but approximate, and it tells you when it has — an answer that skipped something never pretends otherwise. Text search and following connections stay fast regardless.
No. Looking something up is a fast local query. Saving something is a fast local write — the optional meaning-based processing happens in the background, so it never delays you. The trade is that something saved a moment ago may take a few seconds to become findable by meaning; it is findable by text and by its connections immediately.
Your assistant carries on without it, exactly as it did before. It just cannot remember anything for the duration, and cannot recall. Nothing is lost — writes simply do not happen.
No. Types are created by using them: the first decision you record creates the decision type.
The one thing worth being deliberate about from day one is the vocabulary — the verbs connecting facts. That is not structure exactly, but it is the thing that decides whether the memory stays useful. Why naming matters is one page.
Yes. It is your database, and you can query it directly. A portable export format existed in the original Sandra and is planned to return — see the ported / not ported table for current status.