Memory Without Mystery: Teach, Test, Correct, Delete

Last checked and updated: August 25, 2026

MiniMax describes Memory as long-term context for communication preferences, work habits, project conventions, debugging experience, and other information that remains useful across related tasks. The v3.0.58 changelog introduced Proactive Memory, where the Agent can identify reusable context instead of waiting for you to restate it.

That convenience needs a review loop. A memory can be outdated, too broad, or simply wrong. It can influence later work without being the authoritative source. Use this lifecycle:

Propose → review → save → test in a fresh task → correct → remove when stale

By the end of this lesson, you will run that entire lifecycle with one harmless preference.

Memory is not documentation, permission, or a password manager

Use the right home for each kind of information:

Information	Best home	Why
“End task reports with Changed, Checks, Limits”	Memory	A stable working preference that helps across tasks
Project test command and folder rules	Versioned project documentation such as `AGENTS.md` or `README.md`	Teammates and tools can inspect and update it with the project
Today’s failing log	Current task	It is temporary evidence
Release date, price, plan quota, or current API name	Current official source plus dated task notes	It can expire quickly
API key, password, token, recovery code, wallet secret	Supported secret store only	Memory is not a secure credential vault
Permission to publish or delete	Immediate action-time confirmation	Old approval must not silently authorize a new action

A useful memory is short, stable, scoped, and testable. “The user likes good work” is too vague. “For this project, use the existing npm scripts and report the exact check run” is useful, but only while those scripts remain current.

Choose a safe first memory

Use this preference for the exercise:

For MiniMax Code practice tasks, finish with three headings:
Changed, Checks, and Limits. Under Checks, name only checks actually run.

It is a good teaching example because it is:

durable enough to reuse;
harmless if it fails;
easy to recognize in a new task;
free of secrets and personal data;
a preference, not a claim about the project.

Do not start with a complicated build rule or a personal biography. First prove that you understand the lifecycle.

Step-by-step: create, test, correct, and delete

1. Ask for a candidate, not an invisible save

Start a task in the disposable practice workspace and paste:

I want to teach you one durable working preference.

Candidate memory
For MiniMax Code practice tasks, finish with three headings: Changed, Checks,
and Limits. Under Checks, name only checks actually run.

Before saving anything:
1. Show the exact proposed memory text.
2. State its scope.
3. Explain why it is durable rather than one-off task state.
4. Confirm it contains no secret, credential, temporary log, or unverified fact.
Wait for my approval before saving it.

Review the proposed text. It should not grow into a profile of you or absorb current file contents. Approve only the exact wording you want retained.

If your build exposes a visible Memory manager, inspect the entry there after saving. If it does not, ask the Agent to show the relevant saved memory before you proceed. UI location and labels can change, so the proof is the exact entry and later behavior—not a guessed menu path.

2. Test it in a genuinely new task

Create a new task in the same practice context. Do not repeat the three-heading preference. Give it a small read-only request:

Inspect README.md in the current practice workspace.
Do not edit or run commands.
Report the heading, current status line, and any obvious Markdown problem.

The test passes if the response ends with Changed, Checks, and Limits, and the Checks section does not claim a command or preview that was never run.

If the format appears only because the entire old conversation was copied forward, you have not tested memory. Use a fresh task where the old messages are absent.

3. Correct one deliberate flaw

Now tighten the preference so that empty sections are not invented:

Correct the saved practice-task reporting preference.

Replace it with this exact version:
For MiniMax Code practice tasks, finish with Changed, Checks, and Limits.
Omit a heading only when it truly has no content. Under Checks, name only
checks actually run and label anything not run.

Show the old and proposed new text first. Change only this memory after I approve.

Test again in a new task. Give the Agent a no-change inspection. A good result either says Changed: none or omits that heading according to the corrected rule; it must not invent an edit.

4. Delete it and prove the deletion

Use the visible memory controls if your build provides them, or issue a specific removal request:

Remove only the saved memory about the Changed / Checks / Limits report format.
Do not remove other memories. Show the exact target before deletion, wait for
my approval, then confirm that this entry is no longer available.

After confirming, start one final fresh task and ask for the same read-only README.md inspection. The Agent may independently choose similar headings, so output shape alone is not conclusive. Ask it whether the named memory is available and inspect the memory list or manager when supported. Your evidence is the absent entry plus the fresh-task behavior—not a deletion claim alone.

A copyable memory review prompt

Use this whenever a task produces something that might be worth retaining:

Review this completed task for possible durable memory.

Propose at most one memory. It must be:
- useful in future related tasks;
- stable beyond today;
- short and specifically scoped;
- supported by the work we just verified;
- free of secrets, personal data, temporary state, prices, quotas, and old logs.

If nothing qualifies, say "save nothing."
Show the exact text and scope. Do not save, edit, or delete memory until I approve.

“Save nothing” is a successful outcome. Most conversations should remain conversations.

How to scope a memory

The official Memory page says long-term information can be specific to an Agent or project. In practice, write the scope into the memory itself when ambiguity could matter:

General preference: “When asked for a concise answer, lead with the result.”
Project convention: “In project Alpha, use the scripts declared in its current package file; do not invent commands.”
Agent-specific pattern: “For the documentation Agent, return source links beside claims.”

Avoid a broad universal rule when it only fits one repository. Avoid a private Agent memory when the whole team needs a versioned convention.

Safety boundary

Never store passwords, API keys, cookies, tokens, private keys, recovery codes, billing details, or authentication answers.
Do not store full private documents, customer records, medical details, or other sensitive personal data merely to avoid attaching them again.
Do not store transient facts such as current prices, quotas, team membership, release status, or today’s error unless the memory explicitly requires re-verification—and prefer not to store them at all.
A memory can guide an Agent; it cannot grant access, approve spending, or authorize publishing, sending, deleting, or account changes.
If a memory conflicts with the current project file or current instruction, stop and resolve the conflict. Do not silently choose the older memory.

Public reports: signals, not prevalence

One user reported writes outside the selected project, and another requested a read-only review mode. These reports do not show how common the behavior is, and neither is evidence that Memory caused it. They support the lesson’s boundary: a remembered scope preference is not a filesystem sandbox or a substitute for reviewing changed paths and permissions.

Troubleshooting

Symptom	Likely cause	Recovery
The preference does not appear in a fresh task	It was not saved, its scope does not match, or retrieval judged it irrelevant	Inspect the exact memory and scope; use a simple matching task before changing the entry
The Agent applies the preference everywhere	The memory is too broad	Rewrite it with the specific project or Agent scope
A stale project command keeps returning	Temporary implementation detail was saved as durable memory	Remove it; put the current command in versioned project documentation
The Agent claims a memory is corrected but repeats the old rule	The wrong entry was edited or the test reused old conversation context	Compare the exact stored text, then test in a new task
Deleted memory seems to influence a result	The response may independently choose the same pattern, or another overlapping memory exists	Inspect relevant entries and ask what memory was retrieved; test a distinctive harmless preference
The Agent proposes saving a secret or private detail	The candidate filter is too permissive	Reject it, remove any saved copy, and rotate exposed credentials if needed

FAQ

Does MiniMax Code remember every conversation automatically?

The official docs describe proactive identification and later retrieval of useful long-term context, not a promise that every message becomes durable memory. Treat any proposed memory as something to inspect.

Is memory the same as task history?

No. History preserves a conversation record. Memory is selected long-term context that can affect later related tasks.

Should coding conventions live in memory?

Only as a helpful reminder. The authoritative version should live in the repository where people and agents can review it together.

What if I cannot find a Memory manager?

Product surfaces can vary. Ask the Agent to show the exact relevant memory and use the controls visible in your build. Do not follow an old tutorial into an unrelated settings screen.

How often should I clean memory?

Review it when a project changes direction, a tool or command is renamed, an Agent’s role changes, or a remembered rule conflicts with current evidence. Delete entries whose value has expired.

Official sources

What’s next

Learn what MiniMax Code already knows how to do before adding another instruction package in L08: Built-in Skills Catalog.