TL;DR
Claude Projects give you a persistent workspace: shared files (Project Knowledge), custom Instructions, and a chat history that all stay in one place. The trap is treating it like a folder and dumping everything in. As of June 2026, chatting with Opus 4.7 or Sonnet 4.6 on Claude.ai gives you a 500K-token context window, and Projects layer retrieval (RAG) on top to scale past that — but retrieval gets noisier as you add files. The winning pattern is the opposite of “upload everything”: 3 to 7 curated files, tight Instructions, and a rolling decisions.md you re-upload after every real conclusion.
What this tutorial solves
Most teams burn their context by stuffing every draft into a Project and hoping retrieval sorts it out. The result is vague answers, drifting tone, and chats that confidently quote a file you deleted three weeks ago. This walkthrough swaps the “folder” model for a curated-workspace pattern that survives months of use and model upgrades.
Who this is for
Claude Pro ($20/mo), Max ($100 or $200/mo), Team, or Enterprise users running multi-week work: research, long-form writing, codebase analysis, recurring client engagements, or repeat product reviews. If you open a new chat once a week and re-explain the same five facts each time, this is for you. Free accounts cap at five Projects total, so this pattern assumes a paid plan where Projects are unlimited.
What you actually get in a Project (June 2026)
A Project bundles three things that persist across every chat inside it:
| Component | What it does | Practical limit |
|---|---|---|
| Project Knowledge | Shared files Claude can reference in any chat | 30 MB per file; unlimited files, but only relevant sections load per query |
| Custom Instructions | A system prompt applied to every chat in the Project | Bounded only by the context window, not a fixed character cap |
| Chat history | All conversations grouped under the Project | Shared within the Project; not auto-injected as context |
Two facts shape the whole workflow. First, Claude.ai’s chat context window with Opus 4.7 and Sonnet 4.6 is 500K tokens on paid plans (Enterprise can go higher; Claude Code reaches 1M with usage credits enabled). Second, when your Project Knowledge grows past what fits, Claude switches to retrieval-augmented generation (RAG), which Anthropic describes as expanding capacity by up to 10x — but RAG only pulls the chunks it judges relevant, so it can miss things and never guarantees full-document recall in a single reply.
That second point is why “more files” backfires. Past roughly ten files, retrieval picks the wrong chunk more often and scores noise as signal.
When to reach for a Project — and when not to
| Use a Project when… | Use a plain chat when… |
|---|---|
| The task needs persistent context across many chats | It’s a one-off question |
| You can name 3 files that should load into every chat | You don’t yet know the shape of the output |
| You need a stable role and tone over weeks | Setup time would exceed the time saved |
| Multiple people work the same deliverable (Team/Enterprise sharing) | You’re just exploring |
The clearest signal you need a Project: you can name three files that should be loaded into every chat about this topic.
Step by step
- Name the Project after the outcome, not the topic. “Q3 product launch plan,” not “marketing.” Outcome names force a done state.
- Write Instructions in under 1,000 words. Cover role, audience, voice, what to skip, and two or three success criteria. Read it back and cut anything generic about “being helpful.” Instructions apply to every chat in the Project, so keep them strict but not absolute (a hard “respond only in formal English” rule will fire on casual side questions too).
- Upload only the 3 to 7 files that ground every chat. Outdated drafts and tangential references stay out. Name files explicitly —
spec.md,voice.md,decisions.md— so Claude quotes them by name instead of saying “the document you uploaded.” Project Knowledge accepts PDF, DOCX, CSV, TXT, XLSX, HTML, and images up to 30 MB each. - Lead each new chat with the sub-goal. “Today: rewrite the launch email using
voice.md. Output one 180-word version plus three subject-line variants.” - Write conclusions back to
decisions.mdand re-upload. This is the single highest-leverage habit. Project files are snapshots — local edits silently desync until you replace the uploaded copy. - Prune every two weeks. Swap stale files, delete chats that produced nothing, and refine Instructions based on what actually worked.
A first run to calibrate the setup
- Pick a low-stakes deliverable — one email, one chapter section, one bug ticket.
- Run the Project once end-to-end without changing the prompt, files, or model halfway through. Resist the urge to tune mid-run.
- Mark each output “ship as-is,” “needs editing,” or “wrong,” and note which Instructions correlated with the wrong outputs.
- For the second run, change exactly one variable — usually Instructions. Same Knowledge, new Instructions tells you whether the bottleneck is the system prompt or the source material.
Quality check before you ship
- Run the output against the success criteria in your Instructions, not “does it look polished.”
- Verify facts, page numbers, file paths, and commands independently. Claude paraphrases your files confidently even when accuracy slips, and RAG may have pulled the wrong section.
- Flag the human-judgment risks RAG can’t catch: client confidentiality, copyright on uploaded materials, the cost of a wrong direction, and the production impact of a code change.
Make the workflow reusable
- Save your Instructions as a snippet so you can clone the structure in 60 seconds for a new client or book.
- Keep a starter file set per Project type: writing always includes
voice.mdandoutline.md; consulting always includesbrand.mdandprior-deliverables.md. - Keep a
lessons.mdper Project — every time Claude misread a file, drifted in tone, or invented a fact. Patterns surface after three or four entries and feed back into Instructions. - Rerun a smoke test monthly. Model versions, file handling, and the UI change often.
- For coding Projects, include a
conventions.mdwith naming, error handling, and “never do this” rules. It’s more useful than uploading the entire repo, and it keeps RAG focused.
A worked example: a client-deliverable Project
Instructions describe the client, audience, and tone. Knowledge holds brand guidelines, two prior deliverables, and a rolling decisions.md. Each chat handles exactly one section — never two — and ends by appending one paragraph to decisions.md, which you re-upload. On a Team plan you share the Project read-only (“Can use”) with reviewers and edit access (“Can edit”) with the two people actually writing, so feedback lands in one place instead of scattered chats.
Common mistakes
- Uploading 30 files because storage is cheap. Past ten files, RAG retrieves the wrong chunks more often and confidence-scores noise as signal.
- Forgetting Instructions apply to every chat, including unrelated tangents.
- Treating Project files as live documents. They’re snapshots until you re-upload; local edits silently desync.
- Mixing project work with personal experiments. Voice drifts fast, and so does your trust in the output.
- Skipping the
decisions.mdhabit. Without it, every new chat re-litigates settled questions. - Never pruning. Two-month-old Projects accumulate dead files that drag retrieval quality down.
FAQ
- Does a Project remember chat history across sessions?: Projects share files and Instructions, not chat history. Each chat starts fresh on context. Re-upload summaries (the
decisions.mdhabit) if you want continuity. - How big can a Project get?: Files can be up to 30 MB each and Projects accept an unlimited number, but Claude only loads relevant sections via RAG. Past roughly 100K tokens of files, retrieval gets sloppier and replies slow down. Keep it lean.
- What’s the real context window when I chat in a Project?: 500K tokens with Opus 4.7 or Sonnet 4.6 on paid Claude.ai plans as of June 2026; Enterprise can be higher. Project Knowledge that exceeds the window is served through RAG rather than loaded whole.
- Can I share a Project with my team?: Yes, on Team and Enterprise plans, with “Can use” (view and chat) or “Can edit” (modify Knowledge and Instructions) permissions. Personal Pro and Max Projects stay private to your account.
- Should I split big work into multiple Projects?: Yes, when the deliverables are distinct. One Project per deliverable beats one Project per client — it prunes cleaner and keeps retrieval tight.
- How often should I refresh Knowledge files?: Every two weeks at minimum, or right after any decision that changes the source of truth.