How to Use ChatGPT Projects (and Where They Fall Short)

ChatGPT Projects are the closest thing OpenAI ships to an actual workspace. One container in the sidebar that holds your chats, your reference files, and a set of standing instructions, so the model stops meeting you as a stranger every morning.

They work. Worth saying plainly up front, because most of this post is about the ceiling, and a ceiling is not the same thing as a flaw.

How to use ChatGPT Projects

A project holds three things: the chats you start inside it, the files you upload to it, and the project instructions that apply to every conversation in it. Anything you open inside that project can see all three without being told. Projects are available on every plan, including Free, and you can create as many as you like. What changes by plan is how much fits in one — five files per project on Free, twenty-five on Go and Plus, and forty on Pro, Business, Enterprise, and Edu, per OpenAI's documented limits.

Setup takes about twenty minutes, and the order matters more than the contents.

Write the instructions first, before a single file goes in. Project instructions are standing direction: who you are, what this project is for, how you want answers shaped, what to never do. Files are reference. Instructions are intent. Nearly everyone uploads first and then wonders why the output still reads like it was written for a stranger.

Keep the file list short on purpose. The per-project cap sounds generous right up until you start treating a project as storage. Four documents that each earn their place beat twenty-five that mostly overlap, because every extra file hands the model one more thing to be confidently vague about.

Name files the way you'd describe them out loud. deck-v4-final.pdf tells ChatGPT nothing about when to reach for it. Q3 pricing objections from sales calls tells it exactly when to reach and when to leave the file alone.

Then decide what the project should remember. ChatGPT lets you set a project to project-only memory: chats inside it can reference the other chats in that project, but not your conversations outside it, and nothing outside can see in. For client work, or anything you want walled off from the rest of your account, turn it on. For a project that should benefit from what ChatGPT already knows about you, leave it off.

And put in the documents that make it sound like you. Most projects get filled with company material, which is a large part of why so much AI output reads like a department wrote it. The files that make writing feel human are the files about the human.

Projects, memory, and custom instructions are three different things

They get used interchangeably. They behave nothing alike.

	ChatGPT memory	ChatGPT Projects	Portable context anchors
What it holds	Impressions saved automatically as you chat	Files, instructions, and chats you put there deliberately	Documents you wrote and own
Where it applies	Across your whole ChatGPT account	Inside that one project	Anywhere you paste them
Who decides what's in it	Mostly the model	You	You
If you switch tools	Stays behind	Stays behind	Comes with you
When it's wrong	Hard to find, hard to correct	Replace the file	Edit the source

Memory is passive and account-wide. A project is deliberate and walled. Custom instructions sit between them: deliberate, account-wide, and small. We put all of them next to each other in every way to give AI context, compared, and the honest summary is that each is good at a different job, and none of them is the durable layer.

Where ChatGPT Projects fall short

The context is scoped to the project. That's the design, not a defect, and it's exactly why projects work as well as they do. It also means the knowledge lives inside four walls. Start a new project and ChatGPT arrives blank again. Your background, your voice, your standing preferences: uploaded once per project, forever. Change your job title and you don't update it in one place. You update it in every project that mentions it, assuming you remember which ones do.

And it doesn't leave ChatGPT. Project knowledge is an OpenAI feature. It doesn't travel to Claude. It doesn't travel to Gemini. It isn't available to anything you build on an API, or to the AI features quietly showing up inside tools you already pay for. Claude Projects have the identical ceiling from the other side, and Gemini Gems make it unanimous, which is the tell. The problem isn't the vendor. The better the workspace, the more expensive it is to leave, and the same trap sits inside every tool's memory system, which is why we compared them rather than crowning one.

Nothing tells you the files have gone stale. A project built in March will answer in September using March's numbers, March's org chart, and positioning you abandoned in June. It won't hedge, because it has no way to know. That's the quiet version of context drift: not the model wandering, but the material underneath it aging while you keep trusting it. The output looks identical on the day it goes wrong.

And an empty project is harder than it looks. "Upload relevant files" reads like an instruction. It's really a decision about what actually matters, and it's where most people stall, upload whatever's on the desktop, and end up with a project that knows their filenames instead of their work. Knowing what belongs in there is its own skill, context mining, and it's the one part of this an upload button can't do for you.

What to keep outside the project

So the fix isn't to abandon projects. It's to stop treating one as the place your context lives.

Write it down once, as plain markdown you own: who you are and what you're optimizing for, how you sound, the stories you already tell, what's true this quarter. There are six anchors in all, and together they cover most of it. Keep them somewhere that isn't a product. Then paste them into whatever needs them — this project, the next project, your custom instructions, a Claude project, the app your team is building on the API.

The project becomes a place you deploy context instead of the only place it exists. Nothing about the setup changes. What changes is where the original lives, and whether losing access to one product costs you an afternoon or a year.

That distinction is worth being exact about. A context anchor is a file you own. A project is a place you put files. One survives the tool. The other is the tool.

Set one up anyway

Projects are good. Write the instructions before you upload, keep the file list short, name things like a human, and choose the memory setting on purpose. You'll end up with a workspace that beats a cold chat window, and you'll have it by lunch.

Just keep the originals somewhere you can reach them. Because there will be a second project, and a fifth, and eventually a different tool entirely. On the morning you're staring at another empty instructions box, the difference between twenty minutes and a lost afternoon is whether those files already exist.