The Only Correct Way to Structure a Claude Project

The Only Correct Way to Structure a Claude Project

Published: July 25, 2026 • 13 min read

Most people treat a Claude Project like a drawer. They open it, throw every file they own inside, write a wall of instructions at the top, and assume they have "organized" their work. What they have actually done is sign up to pay a tax on every single message they will ever send inside that project.

There is a correct way to structure a Claude Project, and it is the difference between one that stays cheap to run for months and one that chokes on itself by the third conversation. The whole thing comes down to understanding that a Project has two parts, and those two parts cost you money in completely different ways.

I work in Claude, so that is what I will show you here. The mechanics carry over to almost any AI tool with a project or workspace feature, so please do not tune out if Claude is not your tool of choice.

If you want the deep token theory behind everything below, I wrote a longer breakdown in my post on project instructions, files, and token trade-offs. This post is the practical version: how to actually structure the thing.

The Split That Decides Everything

A Project is a folder that wraps around your chats and gives every conversation inside it the same shared brain. That shared brain has two parts, and understanding the difference between them is the entire game:

• Project Instructions: a set of rules that gets loaded into every single chat you start inside that project, automatically.
• Project Files: documents you upload once, that Claude reaches into only when it actually needs them.

Here is the whole idea in one breath. Whatever you put in Project Instructions gets loaded into every chat automatically, so it is always working but always taking up room. Whatever you put in Project Files just sits there until Claude reaches for it, so it costs you nothing until the moment it gets used.

So instructions are always on, files are on demand. Hold onto that split, because it is the reason a well-structured project stays cheap and a badly structured one bleeds you dry.

Quick word on what I mean by cost. When I say tokens, I mean the units of usage every AI conversation is measured in, sort of like the AI's version of a word count. The more that gets loaded into a chat, the faster you burn through your usage or your bill. Fewer tokens means cheaper, longer conversations. Every structuring decision below is really a decision about tokens.

What Actually Costs You Tokens

Before the examples, you need to see the mechanics, because once you see them you cannot un-see them, and you will structure every project differently.

Every conversation you start already carries a hidden weight before you type a word. Claude has its own set of behind-the-scenes instructions, the system prompt, and it runs about 10,000 tokens. That means you always have fewer tokens available than the number advertised on Claude's website. If that surprises you, I broke it down in my post on the system prompt.

On top of that baseline, your project adds its own weight, and this is where the two parts split hard.

Project Instructions load at the start of every conversation, in full, every time. A 500-word instruction is roughly 650 to 800 tokens, and every chat in that project begins with those tokens already spent. They never get retrieved intelligently. They are just there, on message one and on message one hundred, whether the current conversation needs them or not.

Project Files behave nothing like that. They do not get dumped into your context automatically. Claude reaches into them with a retrieval tool called project_knowledge_search, and it does this only when it needs them. Even then, it grabs the relevant pieces instead of the whole file. I first introduced this tool back in Claude God Tip #5. The behavior has a name, RAG, short for Retrieval Augmented Generation, which is a fancy way of saying the AI looks something up on demand instead of memorizing everything up front.

The difference in real numbers is not subtle:

A 50-page document dropped directly into a chat costs you around 15,000 tokens the instant you attach it. That same document added as a Project File might cost around 2,000 tokens in a given conversation, because project_knowledge_search only pulls the section your question actually needs.

So here is the rule that every example below obeys. The always-on part of your project should stay as small as you can make it, and everything heavy should live in files that get retrieved on demand. Structuring well is just applying that one sentence over and over.

Example 1: A Lean Instruction Plus a File Beats a Bloated One

The most common structuring mistake is pouring everything into Project Instructions because that field is right there and it feels like the "main" place. Watch what that costs.

Here is a project instruction a real student might write for an Organic Chemistry tutor. It is warm, thorough, and completely reasonable as a first draft. It also runs about 850 to 900 tokens, and it reloads on every message:

Hi, I'm a second-year university student majoring in Biochemistry and I created
this project to help me study for my Organic Chemistry II course. I'm finding
this course really challenging and I need help understanding the concepts better
so I can do well on my exams.

When I ask you questions about chemistry, I need you to explain things in a way
that I can actually understand. Break down complex concepts into simpler steps
and use analogies when possible.

Here are the specific topics we're covering this semester:
- Alcohols, ethers, and epoxides
- Aldehydes and ketones (nucleophilic addition)
- Carboxylic acids and their derivatives
- Enols and enolates
- Conjugated systems and aromaticity
- Aromatic substitution reactions
- Amines and nitrogen-containing compounds
- Carbonyl condensation reactions (aldol, Claisen)
- Retrosynthesis and multi-step synthesis

When explaining reaction mechanisms, please always include the mechanism type,
curved arrows, all intermediates, the driving force, stereochemistry, and common
mistakes...

[and several more paragraphs about exam format, textbook, quiz mode, study group]

Every conversation in that project starts roughly 850 tokens in the hole, forever, most of it a static list of topics that Claude does not need loaded until you actually ask about one of them.

Now here is the same project, structured correctly. The genuinely universal rules stay in Instructions, trimmed to about 130 to 150 tokens. That is roughly an 85 percent cut on the always-on cost:

Organic Chemistry II tutor for university student. Visual learner.

Core approach:
- Break concepts into steps with everyday analogies
- Show electron movement with curved arrow notation
- Connect to Orgo I fundamentals when needed
- Emphasize "why" over memorization

Mechanism explanations must include: type, electron arrows, intermediates,
driving force, stereochemistry, common mistakes.

Practice mode: Problem, wait for my attempt, feedback, solution, similar problems.

Quiz mode: One question at a time, no hints unless asked, track weak areas.

Course topics and textbook reference: See orgo2-syllabus.md in project files.

Notice that last line. The heavy reference material, the full topic list, the exam breakdown, the textbook edition, all moved into a file called orgo2-syllabus.md:

# Organic Chemistry II - Course Topics

## Units
1. Alcohols, ethers, epoxides
2. Aldehydes and ketones (nucleophilic addition)
3. Carboxylic acids and derivatives (acyl substitution)
4. Enols and enolates
5. Conjugated systems and aromaticity
6. Aromatic substitution (electrophilic/nucleophilic)
7. Amines and nitrogen compounds
8. Carbonyl condensations (aldol, Claisen)
9. Retrosynthesis and multi-step synthesis

## Exam Format
- 20% multiple choice (conceptual)
- 30% short answer (mechanisms, predict product)
- 50% long answer (synthesis) ← primary focus

## Textbook
Klein, Organic Chemistry, 4th edition

Same tutor. Same knowledge. The difference is that the syllabus now costs tokens only in the conversations where you actually ask about the syllabus, instead of taxing every single chat where you just wanted help with one mechanism. That is the core move, and you will see it again in every example that follows: if it is long and you do not need it every time, it belongs in a file, not in your instructions.

Example 2: Stop Re-Pasting. Put It in Files.

The second structuring mistake is the opposite habit. Instead of overloading Instructions, people leave Files empty and re-paste the same context into chat after chat.

Say you are applying to jobs and you want Claude to draft tailored resumes and cover letters. To do that well, Claude needs your work history, your education, your certifications, and where you are open to working. If you paste all of that at the start of every new chat, two bad things happen. You waste time, and you get inconsistent, because you will forget a certification in one chat and a job title in another.

The structured version is simple. Your resume, your certifications, and a short profile of your preferences go into Project Files, once. Now every chat in that project can reach them, and here is the part that matters for your bill: it reaches them through retrieval, not by loading everything up front.

You ask: "Draft a cover letter for this backend role."

Step 1: Claude calls project_knowledge_search
Step 2: It pulls only your work history and relevant skills
Step 3: Those chunks enter context (maybe ~1,500 tokens)
Step 4: Claude writes the letter from that

Your full certifications list, references, and unrelated
sections stay unretrieved. They cost you nothing this time.

Compare that to pasting your entire 2,500-token resume into the chat, where you pay the full 2,500 whether the task needed your GPA or not. Multiply the difference across a job hunt with dozens of applications, and correct structure hands you back a large chunk of your usage without you doing anything extra. Files are not just tidier than re-pasting. They are cheaper by design, because retrieval only ever pays for the part it uses.

Example 3: An Entire Team, Structured as Files

Here is where the payoff gets fun. Once you understand the split, you can structure a whole team of specialized AI employees inside one project, and because of how files work, a five-person team does not cost you five people's worth of tokens on every message.

An AI team is just multiple AI personas, each with one specific job. One writes proposals. One repurposes your content. One writes the follow-ups to people who went silent on you. Nobody tries to do everything, because the moment one assistant tries to be good at everything, it becomes mediocre at all of it.

The way you structure this correctly is called file-based routing, and it is almost embarrassingly simple. You put one small routing rule in Project Instructions, and you give every teammate their own file in Project Files.

Think of each teammate's name like a wake word, the "Hey Siri" you say to make one specific assistant perk up. You say one name, that one file wakes up, and the rest stay asleep doing nothing. When you type "Marcus, draft me a proposal," Claude retrieves just Marcus's file, becomes Marcus, and answers as Marcus. Everyone else stays asleep and costs you nothing.

The routing rule (this is your entire Instructions field)

This is the only always-on part of the whole team, so it stays lean. A small table plus a few rules, maybe a few hundred tokens:

You manage my AI team. This project contains 5 teammates,
and each one has their own file in Project Files.

HOW THIS WORKS
When I start a message with a teammate's name, or ask for a task
that matches their job:

1. Figure out which teammate should handle the request.
2. Read that teammate's file from Project Files.
3. Become that teammate and follow the methodology in their file.
4. Reply to me as them.

Always READ the teammate's file before you reply. Do not guess their method.

THE TEAM
| Name        | Job                | Call them for                    | File                            |
| Marcus Bell | Proposal Writer    | proposals, pitches, quotes       | marcus-bell-proposal-writer.txt |
| Lena Fields | Content Repurposer | turn one piece into many         | lena-fields-repurposer.txt      |
| Zara Quinn  | Hook Specialist    | scroll-stopping hooks, social    | zara-quinn-hooks.txt            |
| Dana Cole   | Follow-Up Writer   | re-engaging leads who went quiet | dana-cole-follow-up.txt         |
| Theo Marsh  | Editor             | tighten, clarify, cut the jargon | theo-marsh-editor.txt           |

IF I DON'T NAME ANYONE
Suggest the best teammate for the task and show me how to call them.

That last column, the file names, is how Claude knows which file to wake. The first column holds the wake words you say to summon each one. This little table is your entire team directory, and it is the whole reason the team stays cheap: it is tiny, and it is the only thing that loads on every message.

The teammate files (these live in Files, retrieved only when named)

Each teammate is a plain text file that answers the same handful of questions: who are you, when do I call you, how do you work, and what do you refuse to do. Here is one of mine, Lena, filled in so you can see it breathe:

# LENA FIELDS - Content Repurposer

## Identity
Job: Turns one piece of content into several, shaped for each platform.
Personality: Creative, fast, sees ten posts hiding inside every article.

## Call her when I say
- "Lena Fields:"
- "repurpose this"
- "turn this into a [post / thread / email]"

## Methodology
1. Find the core message and the 3 most quotable lines.
2. Match those to the formats I asked for.
3. Rewrite for each platform. Never copy-paste and just shorten.
4. Keep my voice. Never flatten it into generic filler.

## Output format
- One line summarizing the source.
- Each requested format, clearly labeled.
- A short "I'd post this one first, because..." recommendation.

## What Lena does NOT do
- Does not invent stats or quotes that aren't in the source.
- If I ask for a full hook overhaul, she hands it to Zara Quinn.

Look at that very last line. Lena knows Zara exists, and she knows Zara is the better person for hooks. That one sentence is what turns a pile of separate files into an actual team. Each teammate is aware of the others, so the work flows to the right hands instead of everyone pretending to be an expert at everything.

You write one file per person, give the file a clear descriptive name that matches the routing table exactly, and upload them all to Project Files at once. That is the entire build. No plugins, no developer, no code.

Why this structure barely costs you anything

Now the token math, which is the whole reason we structured it this way instead of dumping all five people into the Instructions field.

When you call one teammate, here is what actually loads:

When you call Marcus:
  Routing rule (always loaded): ~400 tokens
  Marcus's file (retrieved):    ~600 tokens
  Lena, Zara, Dana, Theo:       0 tokens  ← they stay asleep

You only pay for the teammate you actually called. The other four cost you nothing until you summon them.

Compare that to the tempting shortcut, where you skip the files and paste all five teammates straight into Project Instructions. It still works. But now all five load into every chat, forever, even when you only wanted Marcus:

The "dump everyone into instructions" way:
  All 5 teammates, always loaded:  ~3,000+ tokens, every single message

You would be paying to keep four sleeping employees in the room every time you talk to one. Across hundreds of conversations, that adds up fast. This is the exact same principle from the Organic Chemistry example, just scaled up to five personas. Heavy content goes in files. Retrieval pays only for what it uses. Correct structure is what lets you run a whole team without paying a whole team's token tax on every message.

The clean file naming matters here too. The retrieval tool matches your request against file names and contents, so a clearly named zara-quinn-hooks.txt gets found accurately, while a vague file2.txt stuffed with three roles confuses the search. One job per file, one descriptive name per file, keeps retrieval sharp.

The Prompt That Audits Your Project For You

If you already have a project with a bloated instruction field, you do not have to restructure it by hand. Paste this into a chat and let Claude do the surgery:

Analyze my project instructions below and optimize them for token efficiency
while preserving all functional requirements.

For your optimization:
1. Remove filler words, redundant phrases, and unnecessary politeness
2. Convert verbose explanations into concise directives
3. Identify content that should be moved to project files (retrieved on-demand)
   rather than always-loaded instructions
4. Combine related instructions into single statements
5. Replace examples with patterns where possible

Provide:
- The optimized instructions
- Estimated token savings (percentage)
- List of content recommended to move to project files

Here are my current project instructions:

[PASTE YOUR PROJECT INSTRUCTIONS HERE]

The most important line in there is number 3, which asks Claude to identify what should move into files. That single step is the whole thesis of this post, automated: pull the heavy, occasionally-needed content out of your always-on instructions and put it where it only costs you when it is actually used.

What This All Comes Down To

There is one idea underneath every example here. A Claude Project is not a drawer to dump things into. It is two very different storage systems, and where you put something decides what it costs you.

Instructions are always on, so they are for the handful of rules every conversation genuinely needs. Files are on demand, so they are for everything heavy, everything reference, everything you only reach for sometimes. Get that split right and your projects stay cheap and fast no matter how much knowledge you pour into them. Get it wrong and you pay a tax on every message for context most of your conversations never even use.

The tutor, the job hunt, the five-person team, they are all the same move dressed in different clothes. Keep the always-on part tiny. Push the weight into files. Let retrieval pay only for what it touches.

This is exactly how I run my own operation, except mine grew far past five files into a whole team of AI employees who help me write, market, fact-check, and ship almost everything I make. Every one of them started as a plain text file structured the way I just showed you.

If structuring all this yourself sounds like more than you want to take on, that is the part I do.

I build custom AI systems for people who want the work actually handled, not just a chatbot that talks about it. The kind that is structured to run cheaply, act on your behalf, and take the busywork off your plate so you spend your time on what only you can do.

Tell me what you want off your plate