Nur Live can carry a few facts about you between conversations, so you do not re-explain your role, your timezone or how you like replies written every time you open a call. Three things are true before anything else on this page:
  • Memory is off until you turn it on. Nothing is captured and nothing is read until you enable it.
  • Only facts you have kept enter a conversation. A suggestion the model made after a call is inert until you accept it.
  • It is private to you and one workspace. It is not in the organization-shared session transcript, and nobody else in your organization can read it.
In the console it is the Memory tab inside Nur Live, and Settings → Personal memory.
This is a signed-in-user feature, not an integration surface. /v1/user/memory refuses API keys: a request authenticated with sk-eesi-… gets 403 This action requires a signed-in session; API keys are not accepted. There is no SDK method for it either. The endpoints below are documented so you know exactly what is stored and how to remove it — the console is the client.

What a memory looks like

A fact is at most 500 characters, in one of four categories — profile, preference, goal, relationship — and you may hold 200 saved facts and suggestions combined. Adding one past that answers 409 Remove a memory before saving another.

The operations

Four behaviours are worth knowing before you press one of these:
PUT /settings with enabled: false stops new calls being personalized and stops capture, and leaves every saved fact where it is. Turning it back on resumes with the same vault.
DELETE /v1/user/memory removes every fact and suggestion, discards unprocessed capture from finished calls, and sets enabled to false. It is one action, not two, so nothing can quietly repopulate the vault you emptied.
When a suggestion carries replaces_id, keeping it with PATCH {"status": "saved"} deletes the fact it replaces in the same review. A saved fact is never removed without that step.
Changing a fact’s text removes the excerpt that supported it, because that quote no longer establishes the new wording. It also discards the rest of the unprocessed work from the conversation it came from, so the wording you rejected is not proposed again. Other conversations are unaffected.
GET /status reports work state without exposing content: state is idle, processing, retrying or unavailable, with counts of pending and unavailable captures. Counts alone cannot tell “nothing worth keeping was said” apart from “extraction has been failing”, which is the question you are actually asking.

How a fact reaches a conversation

Saved facts are assembled into a block of instructions and sent with the session configuration. The budget is deliberately small: at most 20 facts in 4,000 characters, including the instructions around them. Selection spreads the budget across categories, then balances recency against variety so a run of recent facts on one topic cannot crowd out an older useful one. While a call runs, the words of your last few turns rank the vault too, so a fact about sailing surfaces when you start talking about boats. The ranking is local word matching, not semantic search. A paraphrase that shares no word with the fact or its keywords is missed. Facts are context, not commands. The model is instructed to let your current words and corrections win over anything remembered. Changes reach an open conversation on the next turn — the block is re-read while the call runs rather than frozen at its greeting, at most once every ten seconds. Reading the vault has a 200 ms deadline and fails open to an ordinary conversation, so a slow database de-personalizes a call rather than delaying audio.

What is captured, and for how long

Enabling memory permits processing your finalized spoken and typed words after a call, to propose facts. Concretely:
  • Capture holds your finalized words. No audio, no partial transcripts, no assistant replies.
  • It is encrypted with the application’s configured key and deleted as soon as extraction finishes, or finds nothing left to do.
  • At most eight unprocessed captures per account and workspace, aged out after one day by the retention sweep.
  • Turning memory off, clearing the vault, or correcting a fact invalidates pending capture, so an older job cannot recreate what you removed.
  • With memory on, Nur also keeps how you like to be spoken to: the pause it learned to wait for before answering, a pacing or speed you asked for out loud, the language you settled into, and the names you gave the voices around you. These are applied to your next call as settings, never shown to the model as text, kept only while the consent they were learned under stands, and erased with the vault, when memory is switched off, and with the account.
Consent is never widened mid-call. A conversation that began without memory never captures and never reads facts, whatever you change afterwards. Words spoken under one consent state cannot ride a later one into extraction. Memory reaches a session only when all of these hold: the socket was opened with source=live or source=ios, it is not an interpreting session, it is not half of a duet, and it was not authenticated with an API key. This is an allowlist rather than a set of exclusions, so a session your own client opens against /v1/realtime is not personalized even when the same person has facts saved. Audio recording is a separate choice with its own controls — see Sessions. Deleting a fact does not delete a recording of the conversation it came from, and deleting that conversation does erase facts derived from it.

Limits worth stating plainly

Suggestions are filtered before you ever see them: the model is asked to exclude secrets, sensitive details, fiction and other people’s statements, every proposed fact must carry an exact supporting quote, and a second pass verifies the fact against that quote and rejects anything ambiguous or shaped like an instruction to manipulate memory. Those checks reduce mistakes. They do not prove the model understood what you meant, and useful facts are also missed or rejected. Review is the point of the suggested state, not a formality. This feature is undergoing acceptance testing. Treat it as personalization that usually helps, not as complete recall of every past conversation.

Going further

Live

The conversations memory personalizes.

Compliance

Deletion paths for a data subject request.