If I became a memory: how AI tools design memory

Lately I’ve been feeling one thing more and more clearly:

different AI tools have very different senses of memory.

ChatGPT sometimes feels like someone who has known me for a long time. It knows how I like things phrased, knows I dislike vague platitudes, and knows what projects I’m working on lately.

Claude feels more like a restrained collaborator. It can pick up context, but usually doesn’t come across as overly personal.

Codex and Claude Code are something else again. They don’t seem to remember “me as a person”; they remember a project, a repo, the scene of a task.

At first I thought this was the different models having different “personalities.”

But then I realized it isn’t only the models’ personalities. What matters more is:

their memory systems were never designed for the same purpose in the first place.

First, to be clear: AI memory usually isn’t the model itself remembering you

Most of the time, the model isn’t really keeping you in its head.

The model itself is more like a very smart person. But every time before it answers, someone has to hand it the relevant material.

The process goes roughly like this:

The user asks a question → the system retrieves relevant history / memories / project files / tool results → puts that information into the current context → the model answers based on this context

So a lot of the time, “the AI remembers me” really means:

before answering, it was handed a briefing note about you, the project and the task.

Where the real differences arise is:

different products have made different choices about “what to remember.”

ChatGPT: more like remembering the person

ChatGPT’s memory system, overall, is closer to a personal assistant.

Its memory has roughly a few layers.

The first layer is Custom Instructions / personalization settings.

This kind of information is more like global rules. For example:

• you want answers to be concise;
• you want the conclusion first;
• you dislike AI tone;
• you want it to answer in a certain tone and structure.

This belongs in settings, because it isn’t a requirement of any one project but how you want AI to work with you in the long run.

The second layer is Saved Memories / the memory summary.

This is more like the AI’s long-term understanding of you. For example:

• who you are;
• what industry you’re in;
• what direction you’ve been pursuing long term;
• what stable preferences you have;
• what long-term goals you keep pushing on.

This information doesn’t need to be written into every prompt. The system brings it into the current context when appropriate.

But there’s a risk here too.

If it remembers “stable preferences,” great. If it mistakes a passing state for a long-term trait, that’s a problem.

For example, if one day you say “I’ve been feeling down lately,” it shouldn’t remember long term that “you’re a down person.”

If you’re job hunting for a month, it shouldn’t forever assume “finding a job is the most important goal in your life.”

So this person-centered memory of ChatGPT feels very smooth, but it’s also the one that most needs pruning.

The third layer is Reference Chat History.

This isn’t memory you explicitly saved; it’s the system possibly finding relevant content in past chats and bringing it into the current answer.

That’s also why ChatGPT sometimes suddenly picks up context from long ago. It doesn’t permanently remember every sentence; it recalls possibly relevant information from history.

The fourth layer is Projects / project memory.

ChatGPT’s Projects are key.

In normal mode, ChatGPT’s global memory and history may influence answers inside a project. But with project-only memory turned on, the project becomes more like an independent space:

• chats inside the project can reference each other;
• the project can use its own files and instructions;
• but it won’t reference chats or saved memories outside the project;
• and what’s in the project won’t be carried outside it.

This design is very important.

Because not all long-term context should be mixed together.

For example:

a job-search project; an indie product; content creation; a fitness plan; reflecting on your feelings.

If all of this is mixed into one big memory pool, AI easily gets its wires crossed.

You ask about the job search and it brings up your feelings. You ask about the product and it brings up a relationship. You ask about content and it brings up the bank.

That’s not just “inaccurate”; it’s a bit of a disaster.

So ChatGPT is better used like this:

• Global settings: stable communication preferences and long-term background about who you are.
• Saved memory: information you want it to remember long term that’s useful across settings.
• Project instructions: goals, style, constraints and output format that belong only to this project.
• Project files / sources: this project’s materials, documents and summaries of past work.
• Project-only memory: good for sensitive projects, long-term projects, and projects where boundaries matter a lot.

In a sentence:

ChatGPT remembers the person, and Projects are there to stop it stirring every version of you into one pot.

Claude: more like remembering the working relationship

Claude’s sense of memory is different.

It has personalization too, but overall it’s more restrained.

Claude has a few layers:

The first is Profile Instructions.

This is more like your global requirements for working with Claude. For example, how you want it to answer, what to call you, what tone and structure you prefer.

The second is Project Instructions.

Claude’s project instructions only apply within that project. That matters.

If you create a project in Claude, say “AI content writing,” its instructions only serve that project. They won’t automatically affect another project, like “fitness plan” or “job-search prep.”

The third is the Project Knowledge Base.

Claude’s project space puts more emphasis on being “self-contained.”

You can put materials, project descriptions and documents in it, and Claude will use them within that project. But if information hasn’t been added to the project knowledge base, different chats in the project don’t naturally share all their context.

That runs against many people’s intuition.

You might think: “I talked about it in the same Claude project, so Claude should know.”

More accurately: it needs the project knowledge base, a project summary or a memory mechanism to build continuity. Not every chat naturally shares all the original context.

The fourth is the Memory Summary.

Claude can also generate a memory summary. You can view and edit it in settings. It can also form a summary of you and how you work based on your chat history.

But Claude’s project memory is kept separate. Each project has its own memory space and project summary.

That means:

context learned in one project isn’t automatically carried into another.

So Claude feels more like:

“I’ve carefully recorded how we work together in this project.” Rather than: “I have a long-term, cross-context profile of you as a person.”

That’s a big difference from ChatGPT.

ChatGPT more easily becomes a long-term personal assistant. Claude is more like a partner with clear boundaries.

It isn’t necessarily as close-fitting. But it’s less likely to get its wires crossed.

Claude is better used like this:

• Profile instructions: global preferences for working together.
• Project instructions: this project’s goals, output style and way of working.
• Project knowledge base: project materials, reference documents, fixed background.
• Memory summary: longer-term working preferences and important background, but you need to review and correct it regularly.
• Incognito / temporary chats: for content you don’t want to enter memory or history-based personalization.

In a sentence:

Claude doesn’t remember a “personalized you”; it remembers “you as a collaborator.”

Codex: more like remembering the scene of the task

Codex’s memory logic is completely different again.

It isn’t there to keep you company. It’s there to work, especially on code.

So what it cares about most isn’t:

• who you are;
• how you’re feeling today;
• how you like things phrased.

It cares more about:

• how this repo runs;
• how to test it;
• what the code style is;
• which directories not to touch;
• what pitfalls this project has;
• where the last debugging session got to;
• which workflows are already stable.

A key thing in Codex is AGENTS.md.

You can think of it as the coding agent’s project handbook.

It’s a good place to write:

project structure; how to start it; test commands; code conventions; PR check requirements; files not to modify; common pitfalls; what must be verified before a task is done

Codex reads these project instructions before it starts work. And it supports instructions at different levels: global, project and subdirectory.

That’s very different from ChatGPT’s saved memory.

Saved memory is more like a “user profile.” AGENTS.md is more like “project rules.”

Codex has memories too, but they’re better for remembering:

• stable preferences;
• repeated workflows;
• the tech stack;
• project conventions;
• known pitfalls.

But OpenAI also stresses: team rules that must be followed shouldn’t live only in memory; they should be written into AGENTS.md or project docs.

That’s very important.

Because memory helps recall; it isn’t a hard rule.

If you really don’t want the agent to run wild, you can’t rely on a single “please remember not to change this file.” You should write the rules into project docs, config, permissions and sandboxes.

Codex can also use Skills to turn repeated tasks into reusable workflows. For example:

• writing release notes;
• checking CI failures;
• scanning for common bugs;
• generating standup summaries;
• doing a certain kind of routine code migration.

So Codex’s “memory” is more like a system for an engineering site:

• AGENTS.md: stable project rules.
• Memories: stable preferences, tech stack, past pitfalls.
• Skills: reusable workflows.
• Automations: scheduled runs of stable workflows.
• Config / permissions: what really controls whether it can read, write, go online and execute.

In a sentence:

Codex doesn’t remember your life; it remembers how to move this project forward safely.

Claude Code: more like remembering engineering work notes

Claude Code is a lot like Codex, but its memory design is more like an engineer’s local work notes.

It has two core mechanisms:

The first is CLAUDE.md.

This is the handbook you write for Claude Code. It can exist at different levels:

A global CLAUDE.md: good for your personal development preferences, like always using pnpm, disliking certain testing approaches, wanting it to write tests first.

A project CLAUDE.md: good for project architecture, how to start it, test commands and code conventions.

A subdirectory CLAUDE.md: good for special rules for a particular module.

The second is Auto Memory.

You don’t write this; Claude Code accumulates the notes itself from your corrections and how you use it.

It’s good for recording:

build commands; debugging experience; clues about the architecture; code style; pitfalls Claude itself has run into; preferences you keep correcting it on.

But one thing is key:

Claude Code loads these memories as context at the start of a session. They aren’t enforced configuration.

That is, after Claude Code sees these rules it will usually follow them better. But if you truly want to forbid some action, you should use hard constraints like hooks, permissions and sandboxes.

It’s a lot like people.

If you write a colleague an onboarding note, they’ll most likely follow it. But if something absolutely must not happen, you can’t rely on a note alone; you need a permission system.

So the right way to use Claude Code is roughly:

• CLAUDE.md: the project description and ways of working you want it to follow long term.
• Auto memory: let it automatically build up debugging experience and usage habits.
• Rules / hooks / permissions: for real boundary control.
• Prompt: only this task’s goal and specific requirements.

In a sentence:

Claude Code isn’t remembering who you are; it’s building an engineering memory for each repo.

So why are they designed differently?

Because they solve different problems.

ChatGPT’s core problem is:

users don’t want to reintroduce themselves every time.

So it’s more person-centered. It wants to know your long-term background, preferences, goals and communication style.

Claude’s core problem is:

complex collaboration needs continuity, but without being too intrusive.

So it’s centered more on projects and the working relationship. It tries to keep each project within its own context boundary.

The core problem for Codex / Claude Code is:

AI can’t start a new job from scratch every day, and can’t make careless changes to real projects.

So they’re centered more on the engineering site. They need to remember project structure, test commands, code conventions and past pitfalls.

Behind this there’s a bigger pattern:

ChatGPT: person-centered memory

Claude: collaboration-centered memory

Codex / Claude Code: memory centered on the project and the scene of execution

None of these is more or less advanced than the others. They serve different tasks.

One remembers the person. One remembers the collaboration. One remembers the site.

The real difference isn’t “whether there’s memory,” but:

what the memory is organized around.

If you want AI to understand you better, what should go where?

Here’s how I sort it now.

1. Things for global settings

Long-term, stable information that holds across all projects.

For example:

• you want concise answers;
• you want the conclusion first;
• you prefer clear logic and little filler;
• you want it to challenge your assumptions.

These don’t belong to any one project. They belong to “how AI works with you.”

So they go in global settings.

2. Things for saved memory / the memory summary

Information that’s useful long term but isn’t necessarily about answer style.

For example:

• your career background;
• your long-term direction;
• the tools you use often;
• the topics you follow long term.

But be careful not to put passing emotions in there.

Don’t let AI permanently remember:

that you were dejected one day; how you reacted once in some relationship; that you were especially pessimistic about your career one week; a temporary travel arrangement.

These can live in the current chat or project; they shouldn’t become part of a global profile.

3. Things for project instructions

Goals, voice and output rules specific to this project.

For example:

• this project is for writing RedNote posts;
• who the target audience is;
• what the writing style is;
• which expressions not to use;
• how each post is structured;
• whether the output should include a title, tags, cover suggestions.

These belong only to this project. Don’t let them pollute other projects.

4. Things for project files / the knowledge base

Project materials.

For example:

past posts; product descriptions; user feedback; competitor analysis; data records; brand documents; project retrospectives.

These aren’t “preferences”; they’re “materials.”

AI needs to read them within the current project, but they don’t necessarily need to become long-term personality memory.

5. Things for AGENTS.md / CLAUDE.md

For coding agents.

For example:

• how to start the project;
• how to run tests;
• code conventions;
• directory structure;
• tech stack;
• which files not to modify;
• which checks must run before a task is done.

Don’t rely on repeating these in chat. Write them into the project docs so the agent can read them every time it comes in.

6. Things for the prompt

One-off tasks.

For example:

• just three titles this time;
• don’t go into detail this time;
• use a sharper tone this time;
• don’t write the body yet, just give the structure;
• only check for bugs this time, no refactoring.

What’s in the prompt is a temporary instruction. It isn’t necessarily worth remembering.

A very simple rule of thumb:

Holds across all projects → settings

Useful to you long term → memory

Belongs only to one project → project context

Belongs only to one repo → AGENTS.md / CLAUDE.md

Belongs only to this one time → prompt

This rule is very useful for everyday users. And for people building AI products too.

Lessons for indie developers

If you’re building an AI product, the memory system isn’t a minor feature.

It nearly determines the product’s “personality.”

Many AI products start by thinking:

• Should I add memory?
• How should I store user information?
• Should I do RAG?

But the more fundamental question should be:

what exactly should my product remember?

If you’re building a personal assistant, you need to remember the user’s long-term preferences, background and goals.

If you’re building a writing tool, you need to remember the user’s style, audience, content direction and banned expressions.

If you’re building a fitness tool, you need to remember training goals, physical limits, feedback at each stage and how exercises are performed.

If you’re building a coding agent, you need to remember project rules, tech stack, testing approach and past pitfalls.

If you’re building something financial or legal, you should actually be very restrained. Many things shouldn’t be remembered long term by default, but should be explicitly confirmed by the user.

So a memory system can’t just ask:

“How do we remember more?”

It has to ask:

What should be remembered? Where should it be stored? For how long? When should it be brought out? Can users see it? Can users change it? How is outdated information handled? When old and new information conflict, which wins? What should only be temporary context? What needs a hard constraint rather than soft memory?

That’s what’s truly hard about a memory system.

A crude AI memory makes users feel:

you didn’t understand me. Or worse: you misunderstood me, and you’re confident about it.

A good AI memory should make users feel:

you remembered what should be remembered. You forgot what should be forgotten. You know which information belongs only to this project. You won’t hold the present me hostage to the past me.

That’s closer to the real product experience than “the model is smart.”

Finally

It’s no accident that different AI tools feel different in how they remember.

ChatGPT feels like it knows you because it organizes memory more around “the person.”

Claude feels like a collaborator because it organizes memory more around “the project and the working relationship.”

Codex / Claude Code feel like engineering colleagues because they organize memory more around “the scene of execution.”

So the core question behind all this isn’t:

does AI have memory?

It’s:

when AI is going to help a person over the long term, what exactly should it remember?

The truly valuable AI products of the future won’t just answer beautifully. They’ll also work alongside people over time.

And the hardest part of long-term work has never been remembering everything.

It’s knowing which parts of the past are still worth bringing into the present.