Skip to main content

conflicts

List pending contradictions: the new memory and the existing ones it clashes with. A conflict appears when a save contradicts something already stored; both memories stay active until resolved. Resolving by hand lives where a human is: the viewer’s Conflicts tab, or an MCP client relaying your choice via resolve_conflict. The four actions are keep new, keep existing, keep both, and merge; every resolution is reversible.

conflicts auto

Re-judges every pending conflict with an LLM, one call per conflict. The dedup classifier that filed each conflict only ever saw two isolated pieces of text; the auto-resolver adds what it couldn’t see, when each memory was recorded, and, for memories that came from import sessions, the transcript excerpt it was distilled from. A later session recording a state change against an older fact usually resolves the way a human skimming both would resolve it.
Only a decisive verdict resolves anything. The model is instructed to answer unsure rather than guess, and an unsure conflict stays in the queue exactly as it was. A resolved one lands in the same revertable history as a resolution made by hand, so conflicts auto is safe to run repeatedly over a growing queue.
Auto-resolution needs the LLM, so it’s unavailable in offline mode (no OPENROUTER_API_KEY).
How contradiction detection works, and what each resolution does to the version chain, is covered in Conflicts.