A GPT wrapper is a software product whose intelligence comes from a large language model it rents through an API, while its own code supplies the interface, the prompts, the billing and the plumbing around that model. That is the whole definition. The argument is over what the label implies: that a product built this way has no value of its own, and that anyone could rebuild it in a weekend.
I assess AI products for investors and acquirers, and "is this just a wrapper" is one of the questions I hear most, from founders who have just been accused of it and from buyers who suspect it. The honest answer is rarely a clean yes or no. Read architecturally, nearly every AI product on the market is a wrapper, because nearly every AI company buys its model rather than training one. The label tells you how a product is built. It tells you nothing, on its own, about whether the business is real. That depends on what sits around the model, and most of it can be read from the outside.
“The label tells you how a product is built. It tells you nothing, on its own, about whether the business is real.”
Why the label is nearly always technically true
The term comes from the first wave of products built on the GPT model family: a prompt, a text box, a logo and a payment page in front of someone else's model. Some of those products vanished the moment the model provider shipped the same capability natively, and the insult has carried that memory ever since.
The architecture the insult describes, though, is now the default way to build AI products. Training a competitive foundation model costs more than almost any application company will ever raise, so buying the model is the correct engineering decision for nearly all of them. The model arrives as an API call, off the shelf, on the same terms it arrives for every competitor. "They didn't train their own model" describes the whole market and disqualifies nobody.
Used in its narrow, useful sense, the label means something more specific: a product where the prompt is the only thing its builders own. The interface, the sign-up flow, the payments and the polish are all things a competent team rebuilds in days. That product exists in large numbers, and from the outside it can look identical to a product with ten times the substance underneath. Which is why the tests matter more than the definition.
How to tell, from the outside
The question underneath most wrapper arguments is practical. You are looking at an AI product, you cannot read its code, and you want to know how much is behind the curtain. You can get a long way with tests that need no technical background.
The swap test. Take a real task the product performs and give the same input to a general-purpose chatbot with a paragraph of careful instruction. If the outputs are interchangeable, the product is the paragraph. Output from a system with its own layer resists this: it draws on records the public models have never seen, or it follows a process longer than one response can hold and catches the model's errors along the way.
The knowledge test. Ask what the product knows that the base model does not. Your own data, a licensed corpus, live prices, case histories, outcomes accumulated from earlier users. A thin wrapper knows nothing the model doesn't. In a substantial product, much of the value is in what gets assembled and fed to the model before anything is asked of it.
The improvement test. Is the product better in month six than it was on day one, for reasons other than the underlying model being upgraded? A system that learns from use, from corrections and accumulated outcomes, has a layer no model provider sells.
The release-day test. Watch what happens when the frontier labs ship a major release. If the product's changelog reads "now powered by the latest model" and little else, the value you are paying for lives upstream, and it just improved for every competitor at the same moment.
The pricing test. Pricing that tracks tokens, with tight usage caps and tiers that map onto model costs, is a supplier bill being passed through. That alone proves little, though it does tell you where the margin goes, and margin tends to sit where the value sits.
No single test settles it. Run four or five and the pattern is usually unambiguous.
The wrapper spectrum
"Wrapper or not" is the wrong shape for the question, because products do not divide into two bins. They sit on a spectrum, and the line that matters runs through the architecture, layer by layer, rather than around the whole product.
Thin passthrough
A prompt, an interface and a billing page. Input goes in, gets wrapped in an instruction, goes to the model, comes back. The product is the model plus manners. This can be useful software and it can make money, but it has no defence: the proprietary layer is a paragraph of text, and what doesn't leak gets guessed or simply equalled.
Workflow product
The model is one component in a process the product owns: multi-step pipelines, state, integrations into the systems where the work happens, validation that catches the model's failures before a user sees them, and handling for the exceptions that make up half of any real job. None of this is exotic, and a funded competitor could rebuild it, but not in a weekend, and knowing where the exceptions live took contact with real users to earn. Most good AI application companies sit here.
Data and judgement product
The layers no model provider can ship. Data no vendor sells: proprietary records and accumulated outcomes, or a corpus with the rights attached. Retrieval built for one domain, where deciding what "relevant" means is itself a judgement rather than a setting. And expert knowledge encoded into the system. The tell for that last layer, when you can get in the room, is to ask the domain expert why the system works the way it does, then watch the answer arrive. If it comes back instant and crisp, you are hearing a codifiable fact, one some vendor has already shipped. A pause, a reach, an answer that turns out to be judgement built over years: that is the layer no model can guess and no competitor can copy from a specification.
“An instant answer is a codifiable fact a vendor has probably shipped. The pause is accumulated judgement, and no model can guess it.”
When a wrapper is a fine business
The hot takes get this wrong in both directions. A thin wrapper can be a very good business. It costs little to build, reaches revenue in weeks, and when the founder owns distribution (an audience, a search position, a community, a sales motion into a niche the big players ignore) the wrapper is simply how that distribution monetises. Plenty of durable small companies are architecturally thin and honestly priced. If the channel is the moat, the product does not need to be.
The trouble starts when the claim outgrows the architecture.
“A wrapper is a fine business at the price of a wrapper. It becomes a problem at the price of a platform.”
A wrapper is a fine business at the price of a wrapper. It becomes a problem at the price of a platform: when a valuation or an acquisition assumes durable margins and a defended position that the architecture does not contain. Four structural pressures do the damage, usually within 12 to 18 months.
- Gross margin is set by a supplier. Every transaction pays the model provider, at a price the product does not control, so the margin story belongs to someone else.
- The frontier moves underneath the product. A capability that is the entire company today can ship as a default setting of next year's models, at which point the product competes with a free version of itself.
- Replication is priced at a weekend. Same model, same API, a prompt that can be approximated from the outputs. Nothing slows a copycat except the layers the wrapper doesn't have.
- The supplier is also a competitor. The model providers sell a consumer product of their own, and every thin wrapper is a feature suggestion delivered with usage data attached.
None of these kills a modest, honest business. All four together are what an inflated valuation quietly assumes away.
What moves a product along the spectrum
Four things reliably convert a wrapper into something harder to dismiss, and the model is not one of them.
Data. Proprietary, accumulating, rights-cleared. Data the product generates by being used is the strongest form, because it compounds and cannot be licensed by a competitor. It is also model-agnostic: whichever lab wins, the data gets more valuable.
Retrieval. The unglamorous layer that decides what the model sees. Domain-specific structure, tagging, metadata, a working definition of relevance for one narrow field. This layer is chronically under-built, because the model layer pays off in a single afternoon and feels like the AI part, while retrieval feels like plumbing. Attention flows to the visible layer and starves the one where defensibility sits.
Distribution. Orthogonal to architecture and routinely underrated by technical critics. Owning the audience, the integration point, or the place where the work already happens can outlast any product advantage. It defends the channel rather than the product, which is fine as long as the price reflects which one is defended.
Encoded judgement. The tacit expertise of people who have done the work for years, built into how the system retrieves, ranks, checks and decides. It resists being written down, which makes it slow and expensive to build, and that same resistance is what stops a competitor extracting it from a spec. The deepest moats are the ones their own builders struggle to fully explain.
For founders, and for investors
If you are building: the accusation costs a stranger nothing, so ignore the insult and keep the question. Which layer of your product will be yours in 18 months? If the honest answer is the prompt, the work in front of you is the unglamorous kind: data, retrieval, workflow depth, encoded judgement. The model layer will keep feeling like progress, and it is the one layer that improves without you.
If you are investing: the label is a starting point for a different exercise, run layer by layer against the price. I have written that method up separately, in how to run the wrapper question inside a live deal, and the AI due diligence checklist sets it alongside the full question set a technical read should answer. The short version fits in a sentence: what did they build around the model that you could not buy elsewhere, and does the price assume more than that?