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.