Recall

Recall is a governed knowledge layer that gives your models memory and your own documents in one place. It learns durable facts about each of your end-users from every conversation, lets you ground answers in documents you add, and keeps both in a single knowledge graph so a request can recall the relevant facts and passages together, automatically. You do not resend context on every call and you do not wire up a separate retrieval step: send a user id, add your documents once, and Recall does the rest.

You will find Recall under Services > Recall.

Turning Recall on

Use the Enabled switch in the top right of the page. It takes effect the moment you flip it, so there is no separate save step. While it is off, nothing is stored and nothing is recalled, even if a request carries a user field or names a collection.

The page has four tabs: Memory (facts and the knowledge graph, per end-user), Documents (your collections), Settings (extraction, thread and retrieval configuration), and Activity (the audit log).

When you disable Recall and there is stored data (facts or collections), you are asked whether to keep or delete everything. Keeping it leaves all data in place so retrieval works again the moment you re-enable the service; deleting clears every fact, thread, and document, and cannot be undone.

Identifying the end-user

Long-term memory is scoped to your end-users, not to your workspace as a whole. To associate a request with a specific end-user, include "user": "<your-end-user-id>" in the chat-completions body, the same field OpenAI uses:

{
  "model": "mistral/mistral-small-2603",
  "user": "usr_abc123",
  "messages": [{ "role": "user", "content": "Book me a window seat on tomorrow's flight." }]
}

Without a user, the platform has no identity to attach facts to: nothing is learned or recalled for that end-user, though a request can still be grounded in your workspace's documents (see below).

How retrieval works

On every request, Recall runs one blended search across the caller's personal memory (when a user is supplied), the workspace's shared knowledge, and every collection in it, and injects the most relevant facts and passages as context before the model runs. There is nothing to flag and no collection to name: the blend covers all of it in a single pass.

Retrieval runs whenever there is something to consult: a user was supplied, or the workspace holds at least one ready document. A request with neither triggers no retrieval and is not augmented.

The rag field is still accepted on chat completions for backward compatibility, but it is deprecated and ignored: retrieval no longer scopes to a single named collection, it always blends everything the caller is entitled to see.

Every response carries an additive sources array (empty when nothing was retrieved) naming what was recalled, grouped and ordered by relevance: one entry per source document or collection, plus one grouped entry for memory facts. Use it to show your users what grounded an answer.

If a request opts into retrieval (by supplying a user, or by the workspace having ready documents) and the knowledge graph is unavailable, the platform returns an error rather than quietly answering without the context you expected.

How facts are learned

After each exchange, an EU-sovereign model extracts durable facts from the end-user's message in the background: stated preferences, roles, constraints, or decisions that are unlikely to expire. New facts are reconciled against what is already known for that end-user: changed ones update, contradicted ones are retired. This runs after the response is returned, so it adds no latency to the call your user is waiting on.

How much capability that extraction spends is configurable on the Settings tab under Extraction tier: Balanced uses a lighter model for fewer credits, Precise uses a stronger model that is more reliable on complex, changing knowledge. The tier affects extraction only, never retrieval.

Managing facts

The Memory tab lists every stored fact, with a graph view (the entities and relationships a selected end-user's facts form) and a list view (search by end-user or text, sortable and filterable). Each row shows the fact's content, the end-user it belongs to, and when it was added. Use Delete on any row to remove a fact immediately.

Each fact also has a Promote to collection action. Promoting moves the fact into one or more of your document collections: the fact's text is ingested as a document in each collection you pick, and the fact is then removed from personal memory. Once promoted, the content is retrieved as part of the workspace's shared knowledge for any request, regardless of which end-user sent it. Use this when a fact should be available to everyone rather than scoped to a single end-user. The action is disabled until you have at least one collection.

Conversation threads

Threads let the platform track conversation history server-side. Instead of resending the full transcript on every call, you send a thread id alongside your new messages and the platform replays the recent history automatically, then appends the new turn before passing the conversation to the model.

Threads are opt-in and effective only when Recall is enabled.

Opting in

Include "thread": "<your-conversation-id>" in the chat-completions body, alongside user or any other field you already send:

{
  "model": "mistral/mistral-small-2603",
  "user": "usr_abc123",
  "thread": "conv_session_42",
  "messages": [{ "role": "user", "content": "What did we agree on last time?" }]
}

The thread is created on first use and scoped to your workspace. You choose the id: any string that uniquely identifies the conversation in your app.

The sliding window

Only the most recent N messages are replayed into each request. N defaults to 50 and is set on the Settings tab under Messages kept per conversation. Messages that fall outside the window are dropped from replay, but any durable facts already extracted from them remain in long-term memory for as long as the end-user's facts are retained.

Managing threads

The /v1/recall/threads API lets you manage threads directly:

Threads are also created implicitly the first time a request carries a thread id you have not created manually.

Collections and documents

Your workspace keeps documents in one or more named collections: separate, walled-off knowledge bases. You add documents to a collection; the platform reads them into the same knowledge graph as memory facts. A document belongs to exactly one collection, and every collection is included in the blended retrieval on every request.

You will find collections under the Documents tab.

• Create a collection with New collection and give it a name. The platform derives a URL-safe slug from the name ("Support docs" becomes support-docs). Your plan sets how many collections you can have: the Free plan includes one, paid plans are unlimited. At the limit, New collection is disabled with an upgrade prompt.
• Rename a collection from its row; the name and its slug update together.
• Merge a collection into another with its Merge action: every document moves into the destination collection and the now-empty source collection is deleted. This cannot be undone.
• Delete a collection from its row; its documents and their chunks are removed with it.
• Open a collection to manage the documents inside it.

Open a collection to add documents. Paste text (with a title), upload files, or both in one go.

• Upload files. Drop or choose one or more PDF, text (.txt), or markdown (.md) files, up to 20 MB each. Each file becomes its own document, so this doubles as a bulk import. PDFs are read for their embedded text (a scanned, image-only PDF has no text to extract and is marked failed).
• Paste text. Give a title, an optional source label, and the body text.

Processing happens in the background: a document appears as Processing, then becomes Ready once it has been parsed, chunked, and written into the graph, or Failed with the reason if its text could not be read. Rename, Move (to another collection), and Delete are available on each document's row.

Documents are scoped to your workspace and to the collection they belong to. Retrieval only ever draws from your own workspace's documents, never another workspace's or another tenant's.

Erasing an end-user's memory (GDPR)

To remove all long-term facts and threads for a specific end-user, for example when they delete their account in your app, call:

DELETE /v1/recall?user=<your-end-user-id>

This removes every stored fact and conversation thread for that end-user, scoped to your workspace. The deletion is permanent and runs synchronously. Wire it into your user-deletion flow so Recall does not outlive the account it belongs to.

Exporting an end-user's data (GDPR)

To hand an end-user a copy of everything Recall holds about them (GDPR Article 15), call:

GET /v1/recall/export?user_ref=<your-end-user-id>

The response returns the end-user's facts, then their conversation threads and messages, cursor-paginated with next_cursor so you can page through everything. Documents are your workspace's shared knowledge base rather than that end-user's personal data, so they are not included in the export.

Metering and records

Recall meters each part of the lifecycle separately:

• Extraction is metered once per learned turn, at a rate that depends on the configured extraction tier.
• Ingest is metered once per document, scaled to how much of it there was to read into the graph.
• Retrieval is metered once per request that triggers a blended search, whether or not it found anything relevant.
• Threads are metered per turn appended to a conversation thread.
• Storage is a recurring meter on the tokens your collections hold, measured per month. Your plan includes a free allowance; usage beyond it is metered on top.

Every extraction, ingestion, retrieval, promotion, configuration change, and deletion also writes an entry to the audit log, visible on the Activity tab and under Platform > Audit logs. Those entries record counts and item ids only, never the content of your facts, documents, or prompts.

Good to know

Personal memory needs a user; document retrieval does not. A request without a user is never augmented from personal memory and never triggers extraction, but it can still be grounded in your workspace's documents if any are ready.

Extraction and embedding stay in the EU. The models that read conversations, derive facts, and embed documents run on EU-sovereign endpoints, and the graph lives in an EU-resident store.

Facts are per end-user, not per workspace. Each end-user's memory is isolated from every other user's, within your workspace and across tenants. Promoting a fact to a collection is the one deliberate way to make its content workspace-wide.