How Perplexity Memory Works: Settings, History, and Limits

Perplexity Memory personalizes answers using information retained across conversations. It is distinct from the text in your current chat and from memory infrastructure you would build into your own application. When a remembered detail is wrong, inspect both saved memories and the earlier search history that may be influencing the answer.

Product controls change, so start from the settings available in your account and the current help documentation. Account type and organization settings can affect the available controls.

What can influence an answer?

Perplexity's Memory documentation distinguishes saved information from past searches. Settings → Memory exposes controls for search history, notes, and managing saved records. Referenced memories can appear among an answer's sources. Turning off consumer memory stops its use but does not itself clear existing saved entries; deletion is a separate action.

The same documentation distinguishes Search memory from Brain in Computer. Treat them as different product surfaces when investigating a result. A setting on one surface should not be assumed to describe every other surface.

Check a remembered fact with a controlled example

Use harmless fictional information, such as a demo project's code name. Record where you supplied it, whether it appears in the saved-memory interface, and what evidence a fresh conversation cites when you ask about it.

Then change the detail and ask a related question. If the older answer persists, check whether it comes from a saved record, a previous thread, or text already present in the new conversation. Those are different routes and may need different corrections.

Do not turn one successful answer into a recall percentage. A useful test includes both questions where the information should be used and questions where it should be ignored. Repeat the same cases under the same settings if you want to compare behavior over time.

Manage saved memories and search history

Perplexity says cleared-memory logs may remain for up to 30 days for operational purposes. That statement does not promise that users can restore deleted memories. Its consumer documentation also describes Incognito as excluding memory and past-search use. Review the current controls before using deletion or Incognito for a specific workflow. Memory controls and deletion.

For an unwanted recurring answer, removing a saved note and removing its source conversation are separate checks. Verify the next answer instead of assuming that changing one visible toggle removed every source of personalization.

Enterprise behavior needs its own check

The Enterprise memory guide describes organization-level controls, organization ownership of memories, and different data-handling commitments. It also describes deletion when memory is disabled in Enterprise contexts. Do not generalize the consumer toggle behavior to a managed workspace.

Record the account type and organization settings when troubleshooting. If personal and shared project context are involved, establish which context the session is permitted to use before interpreting the answer as a memory failure.

Does memory carry across models?

Perplexity's product announcement describes memory working across its models and search modes. That is continuity inside Perplexity. It is not a claim that a saved Perplexity memory automatically appears in the standalone ChatGPT or Claude applications.

For a cross-client workflow, use an explicitly configured shared service and verify its save and retrieval path. The MCP context-sharing guide explains that separate setup.

What should builders take from this?

The transferable design questions are about control and evidence: can a user inspect a remembered detail, understand where it came from, correct it, and predict when it will be used? Those questions apply whether your app stores preferences in a database or uses a memory API.

Consumer personalization settings do not configure memory for your own API application. For that, define stable user identity, retrieval scope, correction behavior, and failure handling. Start with the user-preference workflow and the long-term memory guide.

A practical next step is to test one preference across two sessions and inspect its evidence. Record the account settings and source of the remembered preference so you can troubleshoot an unexpected result.

Building this behavior into your own app? Start with Supermemory and test the same preference across two application sessions. This is a separate integration from Perplexity’s built-in memory; define your own identity, correction, and deletion behavior.