Getting More From ChatGPT With Projects

For the first year of using ChatGPT seriously, I treated it as a stateless tool — open a conversation, get an answer, close it. Projects changed that. They are the first feature that made ChatGPT feel like something I maintain rather than something I visit.

If you are still using ChatGPT as a series of one-off conversations, this is worth reading.

What Projects actually do

A Project is a persistent workspace with three things that carry across every conversation inside it:

1. Custom instructions specific to that project.
2. Uploaded files that remain in context.
3. Conversation history that the model can reference.

The instructions are the biggest win. Instead of re-explaining your context in every conversation — "I'm working in TypeScript, using Next.js 15, the database is PostgreSQL, we use Zod for validation" — you write it once and it applies automatically to everything in that project.

How I structure my projects

I keep one project per context I regularly switch between:

• Client work — one project per active client, with their stack, conventions, and any docs I have uploaded.
• Personal projects — one project per codebase, with the README and architecture notes uploaded.
• Writing — one project with my style preferences and a note about what I am working on.
• Research — a catch-all for exploratory conversations I want to be able to find later.

The separation matters more than it sounds. Without it, ChatGPT has no way to know that "the API" means one thing in client A's project and something completely different in client B's. With Projects, that context is always present and always right.

What to put in the custom instructions

The instructions field is not a place for long documents — it is a place for the highest-leverage context that applies to every conversation in the project. For a development project, mine typically include:

Stack: TypeScript, Next.js 15 App Router, Prisma, PostgreSQL, Tailwind.
Conventions: prefer named exports, no default exports. All API responses use
the shape { data, error, meta }. Tests use Vitest.
What to skip: I do not need explanations of basic concepts. Lead with code,
explain after if needed.
Always check: am I importing from the right path? Does this pattern match
the existing code?

Short, opinionated, specific. The "what to skip" line alone saves three paragraphs per conversation.

Uploading files that actually help

Projects allow file uploads that persist as context. The files worth uploading:

• README or architecture doc. A well-written README is dense context. The model can reference it for every follow-up question.
• Type definitions or schemas. For a TypeScript project, the main types file tells the model about the shape of your data without you having to paste it repeatedly.
• API documentation for external services you integrate with frequently.
• Style guides or decision logs. If your team has documented why certain decisions were made, the model stops suggesting alternatives you already rejected.

What not to upload: entire codebases. The model degrades when the context is too large and unfocused. Upload the maps, not the territory.

The conversation history feature

Within a Project, the model has access to previous conversations. This is useful in two specific ways:

Continuity on long tasks. "Continue where we left off on the auth refactor" works, and the model actually can. You do not have to re-paste the context from last session.

Finding old answers. "In our earlier conversation you wrote a migration for X — can you adapt that for Y?" is now a real question with a real answer. Previously, finding that conversation was your problem.

The history is not magic — the model cannot access all your past conversations without limit — but it extends the effective memory of a working session meaningfully.

The habit change this enabled

Before Projects, I would either start a fresh conversation every time (and re-explain everything) or maintain one enormous conversation that became unwieldy. Projects gave me a third option: persistent context without conversational debt.

The test is whether the tool feels different after a week of use versus on day one. For Projects, it does — the friction of starting a new conversation about something I am actively working on dropped to nearly zero.