Projects vs conversations
Working with Claude on Projects
There's a fundamental difference between chatting with Claude and working with Claude. A chat is a one-off exchange. Working with Claude — on a codebase, a course, a research project, a business workflow — benefits from something more structured: a Project. This chapter explains what Projects are, what they change, and what Claude actually remembers across sessions (and what it doesn't).
Conversations vs. Projects — The Core Difference
- Exists for the duration of one session
- No memory carries over when you start a new chat
- You re-explain context every time: your stack, your goals, your preferences
- Claude treats you as a stranger at the start of each new message thread
- Great for one-off questions, quick lookups, exploratory chats
- A persistent workspace that spans many sessions over days, weeks, or months
- Has a system prompt (instructions) that Claude reads at the start of every session
- Supports a memory system — files that Claude can read and update across sessions
- Can include uploaded files, documents, and code as persistent context
- Claude behaves like a long-term collaborator who knows your project
The practical effect: in a Project, you invest in context once and it compounds. Every session starts from a shared foundation rather than a blank slate.
What Claude Actually Remembers — and What It Doesn't
This is the most important thing to understand about working with Claude long-term. The word "memory" is used loosely — the reality is more precise and more useful once you understand it.
What's in Claude's Context Window During a Project Session
Every time you send a message in a Project, Claude reads all of this before generating a response:
The total context window is 200,000 tokens — enormous for most projects. The key insight is that the persistent layers (instructions, memory, files) are loaded fresh each session, so they don't accumulate session-by-session. Only the conversation history grows within a session, and it resets when you start a new one.
What Persists Between Sessions — Full Table
| What | Persists? | How |
|---|---|---|
| Project instructions (system prompt) | Always | Written in Project settings; loaded automatically every session |
| Memory files (user, feedback, project, reference) | Always | Written by Claude or you; read by Claude at session start |
| Uploaded documents and files | Always | Attached to the Project; available every session |
| Preferences you stated in a conversation | Never | Unless Claude wrote them to a memory file — tell Claude to remember them |
| Decisions made mid-session | Never | Ask Claude to save important decisions to the project memory file |
| Code Claude wrote in a session | Only if saved | Code in the filesystem persists; code only in the chat does not |
| The conversation thread itself | Viewable, not loaded | You can scroll back and read it; Claude does not re-read past sessions |
| Claude's "learning" from interactions | Never | Claude does not update its model weights from conversations |
When to Use a Project vs. a Conversation
Building an app, writing a course, maintaining a server. You'll have many sessions and context accumulates — a Project makes every session smarter than the last.
Editor shortcuts, code style, preferred tools, tone for writing. Write these into memory once and never re-explain them again.
A database schema, API docs, a style guide, a project spec. Upload once to the Project; Claude can read it any session.
Same response style, same assumptions, same constraints. The system prompt enforces this automatically — you don't have to re-state it.
"What does this error mean?" "How do I do X in Python?" No context needed across sessions — a conversation is lighter and faster.
If you want Claude without any context shaping its answer — no prior decisions, no project framing — a new conversation gives you a clean slate.
The Mental Model: Claude as a Long-Term Collaborator
The most useful way to think about a Project is as working with a colleague who reads a briefing document before every meeting. That briefing contains everything they need to know about you and the project — but they don't remember the actual conversation from last week unless someone took notes.
Your job as the project owner is:
- Write the briefing — the system prompt: who you are, what the project is, how you like to work
- Keep the notes — the memory files: decisions made, preferences discovered, important facts
- Maintain the filing cabinet — uploaded files: reference material Claude should always have access to
When those three layers are well-maintained, every new session feels like continuing a conversation — because Claude walks in already knowing the context.