OpenAI let other services plug into ChatGPT, then moved on

A feature that gave the chat window hands and eyes

OpenAI's own plugins announcement describes plugins as tools that act as “eyes and ears” for a language model, letting ChatGPT reach past its training data to browse the current web, run calculations, or call a third-party service on a person's behalf. The document names early partners including Expedia, Instacart, Kayak, OpenTable, Shopify, Slack, Wolfram and Zapier, alongside OpenAI's own browsing and code-execution plugins. Browsing was restricted to retrieval requests rather than actions that change something on the web, and code execution ran in a sandbox without internet access, both framed as safety limits on a system OpenAI describes as still under study.

Who it was for, and what using it meant

Access rolled out first to ChatGPT Plus subscribers, explicitly so OpenAI could study the plugin system's effects before wider release, rather than to every user at once. For a person using it, a plugin turned a single general-purpose chat into something closer to a directory: instead of a model guessing at a restaurant based on old training data, a connected plugin could call OpenTable directly. The same announcement records that OpenAI's own red-teaming had already surfaced risks specific to this design, including prompt injection and the potential for a plugin to be used to send unwanted messages, risks that come from letting a model take real-world action rather than only produce text.

What replaced it, and what that implies

OpenAI's later announcement of GPTs states that a GPT's “actions” build on lessons from the plugins beta and that an existing plugin manifest can be reused to define a GPT's actions, and OpenAI's own plugins-quickstart repository now states plainly that “plugins have been superseded by GPTs.” Neither document gives a fixed date for when plugin access inside ChatGPT itself was withdrawn; that specific closure is covered in this Atlas's separate record of the retirement. What is verifiable here is the shape of the change: a feature built by outside companies for a specific interface was folded into a successor system on the platform owner's timeline, not the integrators'.

Questions to ask before you adopt it

• If you build against a platform's extension system, what is your plan for when that system is restructured?
• Does the vendor's own repositories or documentation show a migration path, or only a deprecation notice?
• How much of your workflow depends on a feature that a single company can retire without your agreement?

The plugins episode is a plain example of platform risk: the integration was real and functioning, and it was still replaced within the same product line inside roughly a year. Building on a rented feature is different from owning the tool outright, and that difference only becomes visible at the moment the feature changes under you.