Claude Projects

In a standard Claude conversation, you start from zero context every time. If you need the model to understand your tech stack, coding standards, or project background, you must explain it again — or copy-paste from a previous conversation. Projects solve this by allowing you to upload documents and set custom instructions that persist across every conversation within that workspace.

The uploaded documents become part of Claude's context for every new chat in the project. This means you can upload your architecture docs, style guides, API specifications, or any reference material once, and every subsequent conversation starts with that knowledge already loaded. The model can reference specific details from your documents without you needing to quote them — it has already read them.

This persistence also enables meaningful cross-session context. While each conversation within a Project still has its own thread, the shared document base ensures continuity of understanding. You can start a new conversation on Monday about a feature design, and on Wednesday start another conversation about testing that feature — both conversations share the same understanding of your system architecture.

The cost saving is significant over time. A team that references the same architecture document in ten conversations per week no longer pays for ten copies of that context in their token usage. The document is loaded once per conversation, but the time saved on context-setting and the quality improvement from consistent understanding compound across every interaction.

Start with the documents the model needs most frequently. For a software project, this typically means the README, architecture overview, and coding standards. For a business context, it might be the brand guidelines, product strategy document, and key metrics definitions. The goal is to eliminate the context-setting that currently consumes the first few messages of every conversation.

Custom instructions — functioning like system prompts — in the project configuration set the model's default behaviour for every conversation in that workspace. Rather than repeating 'respond in British English' or 'format code examples in TypeScript' in every prompt, set these once in the project instructions. This is equivalent to onboarding a new team member — you explain the norms once, not every morning.

Avoid uploading everything. The model's context window is large but finite, and irrelevant documents dilute the attention available for relevant ones. Curate the knowledge base to include reference material that is frequently needed across conversations, not every document the project has ever produced. A focused knowledge base of five to ten key documents typically outperforms an exhaustive upload of fifty documents.

Structure uploaded documents with clear headings and sections. The model processes structured documents more effectively than unformatted text, because the structure helps it locate relevant information when answering questions. A well-organised architecture document with named sections is easier for the model to reference than a stream-of-consciousness design discussion.

Development teams often create a Project per codebase, uploading architecture docs, type definitions, and API contracts. When any team member starts a new conversation about the codebase, Claude already knows the stack, naming conventions, and architectural decisions — producing recommendations that align with existing patterns rather than generic best practices. This shared context ensures consistency across team members who use the tool independently — see inside AISA's assessment architecture for a real-world example of persistent AI context in action.

Content teams use Projects to maintain brand consistency. By uploading the brand voice guide, approved messaging examples, and past content that exemplifies the desired quality standard, every conversation about content creation starts from the same baseline. This is particularly valuable when multiple team members use Claude independently — the Project ensures consistency that would otherwise require editorial review of every AI-generated draft.

Consulting and professional services teams create per-client Projects containing engagement history, client preferences, industry context, and past deliverables. This accumulated context means that follow-up work references previous decisions and maintains continuity, even when different team members handle different phases of an engagement.

The pattern extends to any domain where accumulated context matters. Research teams create per-topic Projects that accumulate papers, notes, and evolving hypotheses. Product teams create per-feature Projects that hold requirements, design decisions, and user feedback. The common thread is replacing repeated context-setting with persistent, shared knowledge that improves every interaction within the workspace.

Documents in a Project should be treated as living references, not static uploads. When your architecture changes, update the architecture document in the Project. When coding standards evolve, update the standards file. Stale documents are worse than no documents — they cause the model to give confidently wrong advice based on outdated information.

A practical cadence is to review Project documents quarterly or whenever a major decision changes the project's direction. Remove documents that are no longer relevant, update documents that have drifted from current practice, and add new documents that reflect recently established patterns or decisions.

Project instructions should also evolve. As you learn which instructions the model follows well and which need refinement, update the project configuration. If you find yourself repeating the same correction across multiple conversations — 'remember, we use snake_case not camelCase' — that correction belongs in the project instructions, not in individual prompts.

Consider archiving Projects that are no longer active rather than deleting them. The accumulated context in a completed client engagement or a shipped feature may be valuable months later when similar work arises. An archived Project can be cloned and updated rather than rebuilt from scratch.

Custom GPTs from OpenAI offer a similar concept — persistent instructions and uploaded knowledge files — but differ in structure. Custom GPTs are designed as shareable, public-facing tools with a defined persona, while Projects are private workspaces optimised for ongoing team or individual use. The Claude Projects model centres on the workspace metaphor: you work within a Project, and every conversation inherits the workspace context. Custom GPTs centre on the assistant metaphor: you talk to a specialised assistant that always behaves in a defined way.

For teams that need both tools, the practical distinction is about use case. Projects are stronger for ongoing work where context evolves — a codebase that changes, a client engagement that develops over months, a research programme where new documents are added regularly. Custom GPTs are stronger for standardised, repeatable tasks where the instructions and knowledge base are stable — brand-compliant content generation, standard analysis templates, or onboarding assistants that answer the same questions for every new hire.