It’s able to reason about it’s own experiences.
I’m planning to run a second instance of it, on a different machine (to help me set up CI).
Anthropic just introduced a feature called “memory”, where claude instances can remember between sessions.
GreenAsJade:
If I turn on memory, will you get confused which me is talking to which you?
Claude:
Great question! Let me think through this…
The Memory Confusion Problem:
If you enable memory, here’s what could happen:
Session 1 (local machine, current):
- Me: “We’re setting up Docker on the remote CI server”
- Memory: “User is working on CI server setup”
Session 2 (remote server):
- You: “Install Docker”
- Me (on remote): “Okay, installing Docker…”
- Memory: “User is working on CI server setup”
- Me (on remote): Reads memory “Wait, are we installing Docker ON the CI server or FROM the CI server to set up another server?”

And then across future sessions:
- Memory: “User has two different Claude sessions running simultaneously, one local and one remote”
- Me: “Which environment am I in right now? What context applies?”
The Real Issue:
Memory is user-scoped, not session-scoped or machine-scoped. So both sessions would be writing to and reading from the same memory, which could create confusion about:
- Which machine we’re on
- What working directory is relevant
- Which tasks are complete vs in-progress
Solutions:
Option A: Don’t use memory for now
Simplest approach - just work without memory during multi-session setup work.
Option B: Use memory but be explicit
Start each session with context like:
- “This is the LOCAL machine session”
- “This is the REMOTE CI server session”
And I’ll track that in memory.
Option C: Only enable memory on one session
Use memory on your primary local session, but not on the remote session.
What do you think? This is a genuinely interesting edge case!