When you open a new session, Claude doesn't just "wake up." There's a precise loading sequence. Things arrive in a specific order, and that order matters because it creates a priority stack: earlier = more foundational, later = more immediately relevant.
Understanding this order is practical, not theoretical. It tells you where to put different kinds of instructions, why some things "stick" better than others, and why your Team Claude architecture works the way it does.
Click each step to see exactly what loads and who controls it.
Before you say a word, Anthropic has already given Claude its baseline instructions. This includes safety guidelines, formatting rules, how to use tools, the knowledge cutoff date, and behavioral guidance.
In Cowork specifically, this also includes: your user preferences (the ones you set in settings), your name and email, the list of available skills, instructions for how to handle files, and how to use computer-use tools.
What you can't change: Safety behavior, core personality, tool schemas.
What you CAN influence: Your user preferences setting ("Use quick and clever humor," "don't use em dashes," etc.) gets injected into the system prompt. This is why those preferences work across sessions without being in CLAUDE.md.
Your CLAUDE.md file is read automatically. It typically sets identity ("You are [role], working for [company]"), defines the organization, links to a knowledge map, lists connected tools, and establishes session rules.
Critically, CLAUDE.md also contains @-import references that pull in additional files.
Why this matters: CLAUDE.md is the ONLY file that loads automatically. Everything else requires either an @-import or an explicit read action. This is why CLAUDE.md is the most important file in your entire setup. If it's wrong, everything downstream is wrong.
Token trade-off: Every line in CLAUDE.md costs you on every single message. A 50-line CLAUDE.md vs. a 500-line CLAUDE.md is the difference between ~500 tokens/turn overhead and ~5,000 tokens/turn overhead. Yours is lean by design. The knowledge map alone saves thousands of tokens by pointing to files instead of including their content.
The four @.claude/rules/ files referenced in CLAUDE.md load as part of the boot context:
Why separate files instead of one big CLAUDE.md? Three reasons:
1. Maintenance: Update marketing rules without touching core identity.
2. Reusability: hard-rules.md could be shared across sessions (same rules, different roles).
3. Clarity: When Claude violates a rule, you know exactly which file to check.
The downside? They ALL load at boot, so modularity doesn't save tokens. It saves your sanity.
Now Claude has its foundation (system prompt + CLAUDE.md + rules) and receives your first message. At this point, Claude "wakes up" — it can see everything loaded so far and your request.
What Claude knows at this exact moment:
What Claude does NOT know yet:
This is exactly why the session startup protocol exists — to fill in these gaps in a deliberate order.
This is Claude following the startup protocol from session-protocol.md. Each step is a tool call, and each tool result lands in the context window. A typical startup might look like:
The token cost: A thorough startup sequence consumes 8,000-15,000 tokens. That's the price of Claude being properly informed. Without it, Claude would be flying blind on current state. With it, Claude starts every session knowing what matters right now.
Key design choice: Good startup protocols use on-demand retrieval (pull from KB) rather than loading entire files into CLAUDE.md. Each query returns a small, targeted result. Loading the same docs into boot context would cost 10x more tokens on every turn for the rest of the session.
At this point, Claude has consumed roughly 20,000 tokens (10% of the 200K window) just getting oriented. The remaining 180,000 tokens are available for actual work.
This is the most productive moment of the session. Claude has full context, maximum thinking room, and strong attention on all loaded instructions.
The takeaway: The boot sequence is an investment. You're spending ~20K tokens to make the remaining ~180K tokens count. A session without this startup would have 200K tokens available but produce worse results because Claude wouldn't know the current state of anything.
This simulates what happens when a Cowork session starts. Watch the context window fill up in real time.
Claude starts differently depending on which interface you're using. Click each to compare.
Where something appears in the boot sequence affects how much "weight" Claude gives it. This isn't a bug — it's how attention works in transformer models.
| Priority Level | What Goes Here | Example |
|---|---|---|
| Highest: System Prompt | Core behavioral rules that should never be overridden | Safety rules, tool schemas, user formatting preferences |
| High: CLAUDE.md + Rules | Identity and operational rules you want followed consistently | "You are [role]," response rules, scope boundaries, knowledge map |
| Medium: Supplements | Product context that frames the work but doesn't need constant enforcement | Product feature list, current sprint state, pricing details |
| Active: Recent Messages | The current conversation — highest attention, highest recency | "Fix the login bug" or "Write a blog post about X" |
Quick comparison so you start building a mental model of the landscape.
| Concept | Claude | ChatGPT | Gemini |
|---|---|---|---|
| Boot context file | CLAUDE.md — automatic, file-based, version-controlled |
"Custom Instructions" or "GPT Instructions" — entered in a form, limited to 1,500 chars | "Gems" — similar to Custom GPTs, less mature |
| Rules files | @-import any .md file from .claude/rules/ | Not supported natively | Not supported natively |
| Tool connections | MCP — open protocol, any tool can plug in | Actions (OpenAPI-based), more restricted | Extensions (Google ecosystem mostly) |
| Multi-session | Independent sessions share nothing by default — you build the bridges (KB, messages, handoffs) | Single conversation memory — "remembers" across chats but you can't control what it keeps | Limited memory, tied to Google account |
| Your control | Maximum. You control the files that control behavior. | Moderate. Form fields, no file system. | Minimal. Google controls the integration points. |