Skip to Content
DocsCloud OSMolly Memory

Molly Memory

Molly, the assistant bundled with Quazzar, shares the same memory store that external AI clients write to through the Memory MCP. The difference: Molly runs in-process, so there is no HTTP round-trip, no bearer auth, and no API key. Molly synthesises a full-scope caller identity bound to the operator’s user id and reads / writes memories directly.

All of Molly’s memory features are free on every plan.

How Molly uses memory

Every Molly turn runs through a three-stage pipeline:

  1. Pre-injection. Before your message hits the LLM, Molly asks the Memory service for the top-N relevant memories (hybrid ranked) and inserts them as system-role messages after the baseline prompt. The injector is soft-fail: a misbehaving embedding backend never breaks chat.
  2. Conversation. The LLM sees the enriched prompt and responds normally. Tool calls, streaming, and token counting work exactly as without memory.
  3. Remember / recall. You pin memories explicitly via the /remember and /recall slash commands (see below).

Because Molly’s memories live in the same notes table as everything else, you can browse, edit, tag, and delete them in the Notes UI under the Molly namespace filter.

Namespace and stamping

Molly writes under the molly namespace. Each write carries:

ColumnValue
sourcemcp
mcp_namespacemolly
mcp_client_namemolly
Auto-tags#molly, #memory, #ns/molly plus user-supplied and inline #tags

Other MCP clients (Claude Desktop, ChatGPT, …) can see Molly’s memories if they pass namespace=molly to memory_search or memory_recent. The store is shared by design.

Slash commands

The chat UI intercepts two commands before sending to the LLM — neither touches your conversation’s token budget.

/remember <text>

Persists <text> as a memory. The first line becomes the title; the full text becomes the body. Auto-tags apply.

/remember Deployed v0.6.35 to node-01. Rollback via `quazzar rollback --to=0.6.34`.

/recall <query>

Displays up to 5 hybrid-ranked hits inline. Clicking a hit copies its title into the input so you can reference it in a follow-up message.

/recall deploy v0.6.35

Settings

Settings -> Molly -> Memory (MCP) exposes three controls:

SettingRangeDefaultEffect
Enable memoryon / offonWhen off, the pre-injection pipeline is a no-op. Stored memories are untouched.
Max recalled memories per turn1..105Cap on the number of system messages Molly injects per turn.
Max chars per memory200..2000400Per-memory body budget. Long bodies are truncated with an ellipsis.

Two actions sit alongside the toggles:

  • View Molly’s memory notes — jumps to the Notes UI filtered to source:molly.
  • Clear all Molly memories — soft-deletes every memory in the namespace behind a confirm dialog.

Settings persist to localStorage under molly.memory.settings. The injector reads them on construction, so a toggle change takes effect on the next turn.

What the LLM sees

Molly pre-injects relevant memories into the context as system-role messages before your user message. The format looks like:

<system>
Relevant memories for this turn:

[memory 1: "Incident 2026-04-19"]
Deployed v0.6.29 to node-01. Rollback instructions in the runbook.

[memory 2: "Q2 OKR: reliability"]
Target is 99.95% availability. Measured via synthetic probes...
</system>

If Molly seems confidently wrong about something, check the Notes graph for recently-written source:molly memories — a stale or incorrect memory is the single biggest cause of “why did it say that?” behaviour. The Settings UI has a one-click Clear all Molly memories action behind a confirm.

HTTP endpoints

These live at /api/molly/memory/* and share the JWT / session auth with the rest of /api/molly. They are not MCP endpoints — external clients keep using the bearer-authenticated /mcp surface.

EndpointPurpose
POST /api/molly/memory/rememberPersist a new memory (body: content, title?, tags?, importance?)
POST /api/molly/memory/recallHybrid search bound to the user and Molly namespace
GET /api/molly/memory/recent?limit=NList the N most recently referenced Molly memories
POST /api/molly/memory/clearSoft-delete every memory in the namespace
DELETE /api/molly/memory/mcp/:idSoft (default) or hard (?hard=true) delete a single memory

All return 503 Service Unavailable when the MCP Memory service is not wired (air-gap builds).

Legacy molly_memory store

Pre-Phase-4 Molly used a dedicated molly_memory SQLite table. That store remains in place alongside the new MCP-backed memories — the migration does not delete its rows. You can inspect legacy entries under Settings -> Legacy Memory and delete them individually. The old entries no longer influence Molly’s responses because the system prompt no longer enumerates them into the context.

Troubleshooting

Molly does not seem to remember anything

Check Settings -> Molly -> Memory (MCP) -> Enable memory. If it is off, pre-injection is a no-op. Toggle it on.

Molly injected an obviously wrong memory

Open the Notes UI, filter source:molly, and delete the offending row. Or click Clear all Molly memories to purge the namespace behind a confirm dialog.

Embedding backend is offline

Molly’s injector is soft-fail. When Ollama is unreachable, recall degrades to lexical-only scoring and chat still works. Restart Ollama and the next turn’s recall switches back to hybrid.

AI HubOrbit Docs