Architecture

How Memrith actually works.

Memrith is local-first by architecture, not just by marketing. This page walks the actual data flow: what lives on your disk, what touches the network, and what doesn't.

The data flow, end-to-end

The chat payload goes directly from your machine to the AI provider you chose. memrith.com sees only your license activation and update-check pings — never your entries, memories, or conversations.

What lives where on disk

~/Library/Application Support/Memrith/ (Mac)
%APPDATA%\Memrith\ (Windows)

All of your data. Entries, memories, conversations, uploads, embeddings, backups, config. Plain JSON + markdown. You can open these in any text editor.

OS Keychain (Mac: Keychain; Windows: Credential Manager)

Your AI provider API key, stored in the OS's secure credential store. Memrith reads it at chat time and never logs or transmits it anywhere except to the provider's API endpoint.

OS Memrith log (Mac: ~/Library/Logs/Memrith.log)

Diagnostic events: app launches, update checks, errors. No entry content, no memory content, no API keys. Auto-scrubbed for known secret prefixes before any Sentry submission.

What does and doesn't touch the network

Outbound traffic that DOES happen

Direct API calls to your AI provider — your chosen provider's endpoint (Anthropic, OpenAI, OpenRouter), only when you send a chat or Memrith processes an entry. Carries chat payload + the relevant memory context. Authenticated with your key.
License activation — one-time on first launch. Your license key is validated with Polar (our payments provider, api.polar.sh), and memrith.com issues a signed entitlement that then lives on your disk. Carries your license key + a SHA256 hash of "Memrith on <hostname>" (not the raw hostname) — never your entries, memory, or conversations.
Update manifest check — ~daily, to memrith.com/releases/latest.json. Carries nothing identifying. Used to decide whether a new version is available.
Crash report — only if you opt in to crash reporting (off by default). Carries scrubbed exception + stack trace. Never carries your entries, memories, conversations, or API keys.
First-run model download — once, the first time on-device search runs, Memrith downloads the embedding model (~130 MB) from Hugging Face. A one-time download to your machine; like any download it exposes your IP to their servers. No entries, memory, or keys are sent.

Traffic that DOESN'T happen

Your entries never leave your machine — except as part of a chat payload you initiate, sent directly to your AI provider.
Your memory database never syncs anywhere — there is no Memrith cloud sync. It lives only on your local disk (and any backups you make yourself).
Your conversations are not stored by Memrith.com — they go through your machine to your provider, and the response comes back the same way. Memrith.com is not in the loop.
No analytics, no tracking, no cookies on the marketing site — verified in the footer of every page on memrith.com.

How signing + verification work

The license activation and the auto-update channel both use Ed25519 signatures. The public key for each is baked into the shipped binary; the private key lives only on the release-signing machine. This means the Memrith app refuses to accept a license or an update that wasn't signed by us, and won't downgrade silently if a manifest is tampered with in transit.

Why this matters for trust: the failure mode of a compromised CDN or a MITM attack on the update channel is "the app refuses the update + tells you why," not "the app silently installs whatever signed payload it received." The verifier distinguishes a real signature mismatch (security signal) from a transient network/corruption issue (benign), and the API surface tags the failure kind so the UI can route them differently.

Editability + traceability

Every memory in Memrith has a provenance trail: which entry or conversation it came from, when it was extracted, what version of the schema it's stored under. The Memory Health view shows the trail; the Memory editor lets you correct, lock, or merge any entry by hand. Nothing the AI extracts is treated as read-only — you can always override it.

The reason this matters: a long-term continuity layer is only trustworthy if you can fix what it gets wrong. A read-only memory is just a black box that compounds errors silently.

If you want to verify any of this yourself

The Python backend (the brainbox/ package) is the canonical source for every claim on this page. Network calls live in a small set of files: brainbox/license.py (license activation + entitlement refresh), brainbox/updater.py (update-manifest fetch), brainbox/crash_reporter.py (opt-in Sentry submit with PII scrubbing). Everything else is local-only — including the AI provider calls, which go through brainbox/api_mixins/chat.py using your stored API key.

Prefer to verify without reading code? How your data flows walks through the same thing from the outside — running a network monitor and cross-checking your own AI provider's dashboard.

Buy Memrith — $9.99 Why BYOK matters → If Memrith shuts down →