Memory vault

The memory vault is a set of markdown notes on an account, and a key can bind to it. Once bound, the models stop starting from nothing: the service recalls what it knows before a request and lets the model write back what it learns. Memory belongs to the account: a key with memory on can search, read and write the vault, and the toggles below are the key's own.

The vault#

• Markdown notes with YAML frontmatter, [[wikilinks]], #tags and folders by path.
• Full-text search over the first 256 KiB of each note, ranked by relevance, recency and links.
• Version history, the last 50 versions of each note.
• Import and export of an Obsidian vault as a zip, from the dashboard.
• Editing in the dashboard: a markdown editor with preview, search and backlinks.

An import adds and updates; it never deletes. A note whose path is absent from the archive is left where it is, a note that the archive carries takes a new version, and one whose markdown is unchanged is not touched. An import is all or nothing: a file that is not a zip, a path outside the vault, two files at one path, a note over 1 MB, or more notes or bytes than the vault can hold is refused and the vault stays as it was.

Toggles on the key#

The toggles are per key, so a coding key can carry recall while a key pasted into a shared script carries neither. Recall works with or without the tools, and both work with every API format.

A tool of your client with the same name as a memory tool is never taken over: that request goes without the memory tools, recall stays, and x-token-notice says memory tools unavailable: tool name collision.

Memory that is on but cannot run says why in the same header rather than answering as though it had worked: memory unavailable: no vault is bound to this key, memory unavailable: the vault could not be read, or memory recall unavailable: the vault could not be read when only recall failed.

How the tool rounds work#

With tools on, the model sees memory_search, memory_read, memory_write, memory_append, memory_link and memory_list. When a turn ends with only memory tool calls, the service runs them and continues the same response, up to four rounds. The loop can end sooner when the next round would not fit in what the request reserved.

A single round runs at most eight calls: a round that asks for more is refused before any of them runs, and the request fails with 400 memory_tool_call_ceiling. Writes are bounded in size too: at most 4 MB of note writes over the whole request, summed over the rounds. Writes and searches also count against the account's vault budgets: 120 a minute each, in bursts of up to 60, shared with the dashboard and MCP, so switching surface does not multiply them. A call refused for a budget is answered with a message the model can read, and the request goes on.

A mixed turn is handled differently: memory writes run, memory reads are dropped, and the client's own tool calls are returned as usual. Memory tool calls are never streamed: the model's deltas for them are buffered and only the final answer reaches the client.

Writes are screened before anything is saved: text that matches an unambiguous instruction-override heuristic is refused, not written, because a saved one would come back inside the recall block of every later request. The refusal is the tool result, so the model can rephrase and try again.

Costs#

Recall and memory rounds are ordinary tokens, billed like any other input or output. Each round sends the conversation again, so a request with the memory tools reserves room on the balance for the prompt five times, the first send and up to four rounds; what it does not use is released when it ends.

What is stored#

Notes are stored on the platform. Notes are yours: they are not used to train models, and a request's usage record never carries note content.