Claude Projects vs Custom GPTs

A Claude Project and a custom GPT both let you give an AI assistant files and standing instructions, which is why they get compared. They are built for different jobs. A Claude Project is a workspace: you, and on Team and Enterprise plans your colleagues, hold many conversations inside it, all starting from the same knowledge and instructions. A custom GPT is a product you configure: a named version of ChatGPT with its own instructions, knowledge and optional actions, which other people open and use without seeing how it was set up. If you want a place to do ongoing work, the project is the closer fit. If you want to package a repeatable job for others to run, the GPT is. One more thing now shapes the choice: OpenAI is moving custom GPT workflows to plugins, covered below.

If you are comparing the workspace features of the two products, that is a different question, answered in Claude Projects vs ChatGPT Projects. This piece compares a Claude Project with the thing ChatGPT users build for others.

At a glance

• What it is for. Claude Project: ongoing work on one body of material. Custom GPT: one repeatable task or workflow, packaged for reuse.
• Who configures it. Project: its owner and anyone with Can edit. GPT: its builder.
• Who uses it. Project: its members, each in their own chats. GPT: whoever it is shared with, in their own conversations.
• Knowledge. Both take uploaded files.
• Instructions. Both have standing instructions; a project’s shape every chat in it, a GPT’s define how the GPT behaves for everyone who uses it.
• Reaching other systems. Project: connectors, including custom connectors to MCP servers. GPT: built-in capabilities, connected apps and custom actions that call an API.
• Sharing. Project: inside an organisation on Team and Enterprise. GPT: controlled by the builder and, in managed workspaces, by admins.

What a Claude Project is

Anthropic’s help centre describes projects↗ (opens in a new tab) as self-contained workspaces with their own chat histories and knowledge bases. You upload documents, write project instructions, and every chat in the project starts from both. Projects are on every plan, including free accounts with a cap on how many. When knowledge grows large on a paid plan, Claude switches to retrieval so the project can hold more than one chat could.

The work happens in chats, and those chats belong to the person who started them. On Team and Enterprise plans a project can be shared with colleagues as Can view or Can edit, but each member’s chats stay private unless they share them one by one. So a shared project is a shared briefing, not a shared conversation. What that covers is set out in can Claude Projects be shared, and running one well in Claude Projects best practices.

What a custom GPT is

OpenAI Academy’s page on custom GPTs↗ (opens in a new tab) calls them custom versions of ChatGPT for repeatable work, such as writing in a format or style or analysing common data sets. It lists four parts the builder sets: instructions for how the GPT should behave, knowledge files such as policies and FAQs, capabilities such as image generation, data analysis, web search and canvas (since retired in favour of writing and code blocks in the chat), and custom actions that call third-party APIs.

The builder and the user are usually different people. Someone designs the GPT once; colleagues or customers open it and start a conversation, getting its instructions, knowledge and tools without having to set anything up. That is the structural difference from a project, where the people using it are the people shaping it.

Knowledge files

Both accept uploaded documents as knowledge, and both are best with a small set of current, clearly named files. The difference is who maintains them. In a project, anyone with edit access updates the knowledge as the work moves on, and the next chat sees the change. In a GPT, the knowledge is part of the build: the builder replaces files on behalf of everyone who uses it. That suits stable reference material, such as a policy or a product catalogue, better than notes that change daily.

Instructions

Project instructions are written for the people in the project and apply to every chat in it: tone, audience, what the house rules are. A GPT’s instructions are closer to a job description for a tool: what it does, how it should respond, what it must avoid. Because a GPT’s users did not write its instructions, those instructions carry more of the load. They have to cope with requests the builder never imagined, from people who do not know what rules they are working inside.

Reaching other systems: connectors and actions

On the Claude side, connectors↗ (opens in a new tab) let Claude read from and act in other apps. The help centre notes that connectors are only available in private projects, that each user authenticates with the third-party service separately, and that custom connectors reach a remote MCP server from Anthropic’s cloud, so the server has to be reachable over the public internet. Because every person signs in for themselves, what Claude can see through a connector is what that person can see.

On the GPT side, OpenAI’s developer documentation on GPT actions↗ (opens in a new tab) describes them as a way for ChatGPT users to call external applications through REST APIs in natural language. The builder describes the API call, configures authentication and adds instructions to the GPT. Actions can run with no authentication, with an API key the builder stores, or with OAuth so each user signs in. The choice matters: with a single stored key, every user’s calls go out under the same credential; with OAuth, each user’s own token is sent.

Sharing, and who can use them

A Claude Project is shared inside an organisation, on Team and Enterprise plans, and admins can switch project sharing off. It is a collaboration feature: members see the same knowledge and instructions and bring their own conversations.

A custom GPT is shared as a finished tool. In managed workspaces, OpenAI’s admin guide to GPTs and sharing↗ (opens in a new tab) says admins control who can create GPTs and whether they can be shared with specific people, groups or the entire workspace. The people it is shared with use it in their own conversations; the configuration stays with the builder.

The retirement of custom GPTs

OpenAI has announced that it is retiring custom GPTs and moving their workflows to plugins, bundles that can include skills and MCP servers. Its guide to migrating custom GPTs to plugins↗ (opens in a new tab) describes what carries across: the GPT’s instructions become a skill, its knowledge becomes reference files, and connected apps remain part of the plugin. Custom actions do not transfer, the selected model does not carry forward, and sharing settings are not copied in bulk. The original GPT remains usable until retirement; at retirement, custom GPTs stop running and leave the GPT directory. OpenAI’s help centre gives 11 December 2026, later for Enterprise workspaces with an approved deferral, so check the date that applies to you before building anything new on a GPT.

That changes the comparison more than any single feature. A GPT built on custom actions will need a replacement for those actions. And the destination, a skill plus connected apps, looks structurally like Claude’s own split between skills and connectors, covered in Claude Projects vs Skills vs Artifacts.

Which fits which need

• An analyst returning to the same research over weeks, with colleagues who need the same briefing: a Claude Project.
• A support lead who wants every agent to draft replies the same way from the same policy, without each setting anything up: a packaged assistant, which today means a GPT or, going forward, a ChatGPT plugin, or a Claude skill shared across the organisation.
• A tool that has to call your own API: either, but decide first whether it should act with one shared credential or as each user. Per-user sign-in is the safer default.
• Work several people and assistants carry forward together: neither on its own. Both keep conversations per person.

Where the work itself goes

Projects and GPTs both shape how an assistant answers. Neither records what is being worked on, who has it, or who changed what. When conversations start producing “fix this” and “check that”, the list needs a home that people and assistants from both vendors can read and write. On fenbs that is a board: each task is a feature, enhancement or bug in To Do, Next Up, In Progress or Completed. Claude and ChatGPT both connect over MCP, sign in as a person, and act under that person’s role, with every change recorded in the history. Standing rules live once as AI context, which every connected assistant reads with fenbs_get_context, so they are not copied into a project in one product and a GPT in the other.