ChatGPT Plugins – ecosystem analysis
Technical scope Major labs & flagship models, openai, vendor-analysis
When OpenAI opened ChatGPT Plugins to all Plus subscribers in May 2023, it framed them as an app store moment for conversational AI: third-party services would plug into the model, and ChatGPT would become a hub that could book flights, run code, pull live data and shop on your behalf. Less than a year later, that architecture was gone. OpenAI deprecated Plugins in favour of Custom GPTs and Actions, and the Plugin store closed. If you have arrived here looking for "ChatGPT plugins," the honest answer is that they no longer exist as a product – the capability lives on, reshaped, inside GPTs and the GPT Store. This piece traces what changed, how the current system actually works, and whether any of it has delivered on the original promise.
The plugins-to-GPTs evolution
The original ChatGPT plugin system worked by exposing an OpenAPI specification and a manifest file to the model. A developer described their API in a machine-readable schema, ChatGPT read that schema, and the model decided when to call an endpoint based on the user's request. Early launch partners included Expedia, Instacart, Klarna, OpenTable, Wolfram and Zapier. A browsing plugin and a code interpreter rounded out the first wave. The mechanism was clever, but the experience was clumsy. Users had to manually enable up to three plugins per conversation, remember which plugin did what, and hope the model chose to invoke the right one.
OpenAI announced the successor stack at its first DevDay in November 2023. Custom GPTs – configurable versions of ChatGPT that bundle instructions, knowledge files and tool access – replaced the flat plugin list. The GPT Store opened to the public in January 2024. Plugins were formally sunset over the first half of 2024, with the plugin store shutting down and existing plugins migrated, where developers chose to do so, into Actions inside GPTs. The architectural lineage is direct: an Action is essentially the old plugin mechanism (an OpenAPI schema plus authentication) relocated inside a single GPT rather than floating in a shared global catalogue.
The reframing mattered. Plugins treated external tools as the unit of distribution. GPTs treat the whole packaged assistant – persona, instructions, files and tools together – as the unit. That shift tells you how OpenAI reinterpreted the opportunity: not a marketplace of capabilities, but a marketplace of pre-configured agents.
Custom GPTs in 2026
A Custom GPT, as OpenAI documents it, is a version of ChatGPT that a creator has tailored for a specific purpose without writing code. In practice it is a configuration layer on top of the underlying model. A GPT carries four main ingredients: a system instruction that shapes its behaviour and tone, optional knowledge files it can retrieve from, a set of enabled built-in capabilities (web browsing, the Python code interpreter, DALL·E image generation), and optional Actions that reach out to external APIs.
You build one through the GPT editor, available to paid ChatGPT tiers. The editor offers two paths. The conversational "Create" tab lets you describe what you want and have the system draft the configuration for you, including a name and profile image. The "Configure" tab exposes the raw fields – instructions, conversation starters, knowledge uploads, capability toggles and the Actions panel – for anyone who wants precise control. Verify the exact tier requirements and feature availability against OpenAI's own GPTs documentation, since access rules and the base model powering GPTs have shifted repeatedly since launch and will keep moving.
The honest distinction between a Custom GPT and plain ChatGPT is narrower than the marketing implies. A well-written prompt plus a couple of uploaded documents reproduces much of what most published GPTs do. The genuine value sits in three places: persistence (you do not re-paste the same instructions every session), knowledge retrieval over files you supply, and Actions that give the model live reach into systems ChatGPT cannot otherwise touch. For a fuller account of what the base product can and cannot do, see our analysis of ChatGPT as a product, its capabilities and limits.
Actions – connecting GPTs to the outside world
Actions are where a Custom GPT stops being a clever prompt and becomes something closer to an agent. An Action is defined by an OpenAPI schema describing the endpoints of an external service, an authentication method (none, API key, or OAuth), and a privacy policy URL that the Store requires before a GPT with Actions can be published.
The runtime behaviour mirrors the old plugin flow. When a user's request implies a call – "what's the status of order 4821?" – the model matches intent against the operations described in the schema, constructs the request, sends it, receives JSON back, and composes a natural-language reply. The descriptions in the schema are load-bearing: the model relies on the summary and description fields to decide whether and how to call each endpoint, so vague documentation produces unreliable invocation. This is the single most common failure mode builders report, and it is the same lesson the plugin era taught – the model is only as good at tool use as the tool's self-description allows.
Authentication is the practical bottleneck. OAuth flows let a GPT act on a user's behalf against their own account in an external service, but they demand a correctly configured authorization and token endpoint, and the setup is unforgiving. For simpler read-only data sources, an API key passed in the header is enough. Builders who want to understand how these primitives compose into larger systems should read our walkthrough of the OpenAI Agents SDK and building with OpenAI primitives, which covers the programmatic equivalent of what Actions do inside a no-code GPT.
The GPT Store reality
The GPT Store launched in January 2024 with the promise of discovery and, eventually, money. OpenAI announced a US builder revenue programme in which creators would be paid based on user engagement with their GPTs. The programme ran as a pilot; the exact payout formula was never published in detail, and OpenAI has said little publicly about its scale since. Anyone weighing the Store as a revenue channel should check OpenAI's current GPT Store and builder policies directly, because the terms and the very existence of the payment programme are the sort of thing that changes without fanfare.
The reality has fallen well short of the app-store framing. OpenAI reported that users had created roughly three million GPTs within two months of the editor's release – a figure that itself signals the problem. The overwhelming majority of those GPTs are near-duplicates: writing assistants, logo makers, PDF summarisers, "humanizers" and SEO helpers that wrap the same handful of prompts. Top positions in categories like writing, productivity and research tend to be held by a small set of well-known names and a few genuinely differentiated tools, while the long tail is effectively undiscoverable.
Several structural factors explain the muted trajectory. There is no meaningful moat: a GPT's instructions are often trivially extractable, and a competitor can clone a popular one in minutes. Discovery is weak, as discussed below. And the base capability has commoditised – as ChatGPT itself gained better file handling, browsing and reasoning, the marginal value of a wrapper GPT shrank. Interest in building for the Store, measured by developer discussion and new high-quality entries, cooled noticeably through 2024 and 2025. The Store did not fail, but it never became the platform economy that the DevDay framing suggested.
For builders – GPT or API?
The decision is mostly about control, distribution and scale. A Custom GPT is the right choice when your users are already inside ChatGPT, when you need no custom interface, when the logic fits in instructions plus a few Actions, and when you can tolerate OpenAI owning the runtime, the model version and the rate limits. It is fast to build and requires no hosting. It suits internal team tools, lightweight customer-facing assistants, and experiments.
The API – whether raw chat completions, the Assistants API, or the Agents SDK – is the right choice when you need a bespoke interface, deterministic control over the model and prompts, your own authentication and data boundaries, integration into an existing product, or scale beyond what a shared consumer surface allows. You also take on hosting, error handling and the operational realities that come with it, including rate-limit errors like HTTP 429 under load. A rough rule: if the thing you are building is itself a product, use the API; if it is a convenience layer for people who already live in ChatGPT, build a GPT. For broader context on where agent tooling is heading, our ongoing coverage of AI agents news and developments tracks the shifting line between the two.
For users – finding anything useful
Discovery is the Store's weakest link. The in-product interface surfaces featured picks, category leaders and a search box, but search rewards exact-name matches and popular terms, which entrenches incumbents and buries specialised tools. With millions of GPTs and heavy duplication, a keyword search for a common task returns a wall of near-identical results with little signal to separate them.
The practical approach is to treat the Store as a directory of starting points rather than a curated catalogue. Favour GPTs from recognisable organisations or named creators, check whether a GPT uses Actions (which usually signals genuine added capability over a prompt wrapper), and read the description for specificity. For any task that a well-briefed base ChatGPT session handles, the GPT buys you persistence and convenience, not new power. Readers mapping the wider assistant space may find our survey of AI assistants and AI companions in 2026 a useful companion.
The competitive picture
OpenAI's reframing now sits alongside parallel systems from its rivals, and the direction of travel across the industry is toward interoperable tool use rather than walled catalogues.
Anthropic's approach centres on Skills – packaged folders of instructions, scripts and resources that Claude loads on demand – and, more consequentially, on the Model Context Protocol (MCP), an open standard for connecting models to external tools and data. MCP is the most significant divergence from the GPT model: it is vendor-neutral by design, so a single MCP server can serve any client that speaks the protocol, rather than a GPT Action bound to OpenAI's runtime. Our explainer on Claude Skills, Anthropic's tool framework covers the mechanics in detail.
Google's Gems are the closest analogue to Custom GPTs – configurable, instruction-driven versions of Gemini – and occupy the same no-code niche. Notably, OpenAI itself has adopted MCP support, a tacit acknowledgement that the proprietary-Action model is not the industry's endpoint. The trajectory is clear enough: the specific product called ChatGPT Plugins is a historical artefact, but the problem it tried to solve – letting a language model reliably act on the outside world – is now the central contest in applied AI, and it is being fought on open standards as much as on private stores.