Choosing the Boundary: Local, Synced, or Server
Claude-mem’s architecture changes meaningfully when its data crosses a new boundary. The private marker changes whether content enters the memory path; the provider choice changes which model sees admitted content; cloud sync changes whether local records are copied to another device; and server mode changes who owns storage, authentication, and generation infrastructure. This chapter compares those choices by trust perimeter, failure recovery, and operational responsibility so a reader can choose a fitting boundary rather than treating every deployment as the same feature with a different setting.
Privacy and provider choices come before topology
The first boundary is content admission. Claude-mem recognizes <private>...</private> and strips the marked material before storing prompts or queuing tool data. If a user’s prompt becomes empty after stripping, that turn does not generate an observation. Project exclusions suppress both capture and later context injection for matching paths. These controls are valuable because they act near the edge, before content reaches the observer and before a shared or synchronized store could receive it.
They are not a complete data-loss-prevention system. The private marker works only when the user or upstream adapter applies it. Unmarked content remains eligible for compression, and the project does not implement a default-private mode in which every event must be explicitly approved. A marker also does not change what has already been sent through another path. The correct question is not “does claude-mem have privacy?” but “which content is marked, at what edge is it stripped, and which later path can still see the remaining content?”
The absent-prompt case deserves the same care. A missing prompt row can mean that session initialization raced worker startup, not that the user intended privacy. The validator allows ingestion in that case. A row that exists but is empty after stripping is treated as a deliberate private turn. This distinction prevents a reliability problem from masquerading as a privacy decision, but it also shows that the system cannot infer user intent from every absence.
The provider choice creates a second boundary. The worker can select Claude, Gemini, or OpenRouter based on configuration and credential availability. The stored observation format stays broadly the same, but the model, endpoint, quota, latency, and external trust perimeter change. An observer using a remote provider sees the admitted tool material needed to compress it. A provider that is unavailable may cause silent fall-through to Claude when the optional provider lacks credentials, or a failure may pause the generator rather than create a partial memory.
Tier routing adds an optimization inside that choice. Batches containing only simple read-like tools can be routed to a simple model when configured, while summaries can use a dedicated summary model. This can reduce cost or latency for work that needs less reasoning, but the source does not establish that the cheaper model preserves quality in every workload. A model that is adequate for identifying a file read may be poor at explaining a subtle architectural trade-off. The schema’s stability should not be confused with identical semantic quality.
The project also contains specific cooldown and fallback behavior. Repeated quota failures can withhold new requests instead of buying the same refusal for every incoming event.