A year ago, "it's just a ChatGPT wrapper" was a dismissal. You'd hear it about a startup and know what it meant: an LLM API call, a little RAG, file upload, a chat box on top. Thin. Replaceable. Probably dead the next time the base model shipped a feature.

I keep coming back to that phrase, because it stopped being true in a way I didn't notice happening. The thing you'd be wrapping is no longer a model with a chat UI. It's a fast, stateful web application with its own agent loop, its own sandbox, its own artifact system. The wrapper didn't get easier to build as the models got better. It got heavier.

The simple interface hides the hard part. A ChatGPT-shaped product is not just an API call with a chat box around it; it's the accumulation of many product and infrastructure decisions that make execution feel safe, stateful, and immediate. The model is the part you can buy. The surrounding runtime is the part people had to design.

What gets me is the timescale. It's been roughly a year, and the question actually worth arguing about has moved out from under us — from "is this just a wrapper?" to "where does the sandbox even run?" The pace is faster than I can comfortably track. And the part I keep finding fun is that it all bends toward the practical, not away from it: every one of these shifts makes the tools more usable, more real, closer to something you'd actually ship. Surprising and, honestly, a good time to be building.

This isn't a "wrappers are over" argument, and it isn't advice. It's me writing down where my thinking has drifted while trying to build these things myself — partly so I can find out where it's wrong. Read it as one person's notes.

What "wrapper" used to mean

The old shape was honestly small. Roughly:

prompt → LLM API → (RAG retrieval) → response
        + file parsing on the side

The whole game was prompt design, a retrieval index, and some glue. You could stand it up in a weekend. The reason "wrapper" was an insult is that the surface area was tiny — the model did the hard part, and you did the part anyone could redo.

The leverage point was the prompt and the context you stuffed into it. I've written before that token spend only becomes an asset when you redesign the work around it. Back then, "the work" was mostly the prompt. There wasn't much else in the box.

Two things that are easy to blur

Before going further, it's worth separating two things, because the rest of this post depends on not mixing them up.

The first is the consumer surface: ChatGPT's Data Analysis, Canvas, and Agent mode; Claude's artifacts and browser agents. These are managed sandboxes the platform owns end to end. You can't bring your own; you can only observe their shape.

The second is the developer engine: Codex's CLI / app-server / SDK, and Claude Code's headless mode and Agent SDK. These expose the agent loop as something you can drive from your own code.

They're the same product family seen from two sides. The lesson you take from each is different:

The consumer products reveal the shape of the architecture — sandboxed analysis, artifact surfaces, browser/terminal agents.
The developer tools reveal the build strategy — don't rebuild the agent loop; drive the existing engine and own the boundary, the policy, and the domain compiler around it.

Keep those two lines in mind. The first half of what follows is about the shape. The second half is about the strategy.

The sandbox is the actual product surface

The clearest way I've found to see the shape is to stop looking at ChatGPT as "a model" and look at it as a set of execution environments, each with a network boundary around it. Strip the marketing and the consumer surface decomposes into tiers:

What strikes me, laid out like this: none of these is only a model feature. Each is a product/runtime feature that depends on model behavior but is mostly a managed sandbox with a deliberate trust boundary — what can run, what it can reach, when a human has to confirm. The design center isn't "a better prompt." It's managed sandbox + network boundary + user confirmation + tool isolation.

And notably, it is not "trust a user-supplied container as your production sandbox." There's no devcontainer.json you hand in and have it boot as your runtime. The isolation is the point, and the isolation is theirs, hand-built per surface. That's the part a thin wrapper can't fake — and the part that's now the bulk of the work.

So the leverage point moved. It used to be the prompt. The model call used to be the product; now it's the commodity-shaped component inside a much heavier runtime.

Runtime choice is really a state-gravity decision

The moment you decide your wrapper needs to run something — execute the code it wrote, render the component, hold work state between turns — you've inherited an infrastructure decision you can't shortcut. And the heart of it isn't "which platform is fastest." It's where the state lives.

It helps to notice that "state" here isn't one thing. An agentic product juggles at least four, with different gravity:

1. conversation state        — turns, plan, tool-call history
2. workspace filesystem state — the repo/files the agent edits
3. artifact / render state    — the live canvas, the preview
4. connector / auth state     — credentials, permissions, approvals

The real design question is which of these lives inside the sandbox, close to the actor, and which gets pushed back to a durable store (a DB, object storage, Git). This is the same state gravity model I keep running into: high-churn work state wants to be close to whatever reads and writes it most; the durable record stays central. (It's telling that Codex exposes SQLite-backed state for agent jobs and exported results via sqlite_home — the workbench is local, the ledger is elsewhere. The pattern keeps reappearing.)

Choosing a platform is choosing that gravity, and none of the options hands it to you for free:

• Vercel — Fluid Compute killed the "too short-lived for agents" complaint (300s default, up to 800s, 30-min beta), but it still isn't a stateful repo-workspace sandbox out of the box, so a code-running agent needs extra design on top.
• Cloudflare — Durable Objects are great for per-entity conversation state (SQLite-backed, one writer each); less of a fit, alone, as an arbitrary-code sandbox or a cloned repo.
• AWS — Fargate gives real per-task isolation. Beyond that you're assembling: the pattern I'd reach for is a session-scoped, disposable VM per agent run — something you build on the primitives rather than buy off the shelf. Maximum control, maximum assembly.
• Roll your own — gVisor / Firecracker, your own warm pools and snapshots. The most control, the deepest hole.

Whichever you pick, you spend real days on cold-start latency, warm pools, and the network policy before a single user-visible feature ships. The wrapper used to be the prompt. Now part of the wrapper is a sandbox you have to operate — and the network boundary is not a checkbox. A good concrete example: Codex cloud runs a two-phase model — the setup phase has network access to install dependencies, then the agent phase runs offline by default, and secrets are removed before the agent phase even starts. That separation of setup egress from agent egress, with secrets scoped to setup, is exactly the kind of boundary you end up rebuilding yourself if you roll your own runtime.

Don't rebuild Codex or Claude Code — drive them

Chat-with-a-sandbox is heavy but reachable. The coding agents — Claude Code, Codex — are a different tier, and this is where the build strategy from earlier pays off. The honest move is to stand on the engines that already exist rather than reimplement the loop.

Codex is the clear example because the engine is exposed. codex exec runs the agent non-interactively — single session to completion, events streamed as JSONL via --json, a built-in sandbox (read-only by default, workspace-write when you opt in), approval gating you can set to never for unattended runs. codex app-server runs the same core as a server over stdio / WebSocket / Unix socket, which is how IDEs and SDK clients drive it — the Python SDK, for instance, controls the local app-server over JSON-RPC, while codex exec --json is the simpler non-interactive path. Claude Code has its own headless mode (claude -p) and Agent SDK in the same spirit.

One caveat I'd flag honestly: you can speak the app-server protocol, but treat it as a fast-moving integration surface, not yet a boring, stable production ABI — the docs mark it as primarily for development/debugging, and the WebSocket transport is still hardening. Build on it, but expect it to move.

The lesson I take from this: the agent loop, the tool orchestration, the apply-patch system, the sandbox enforcement — that's a frontier-grade engine, and the leverage is in driving it, not rebuilding it. Trying to hand-roll the equivalent loop is the new version of trying to hand-roll dominators in a static analyzer: technically possible, almost always the wrong place to spend your rigor.

The part worth owning — and how thin the moat really is

So where's the defensible work, if the model is a commodity and the agent loop is borrowed?

Honestly, I'm not sure "defensible" is the right word, and I want to resist making my own work sound safer than it is. Here's the most honest version I have.

The durable idea — more durable, I think, than any tooling that implements it — is an epistemology: typing the facts you hand an agent by how you know them. Is a claim verified (it follows from a model you built, with evidence) or estimated (a pattern guessed it)? What's its provenance? I care about this because an agent handed grounded, labeled facts has to guess less, and a fact that carries its own confidence is worth more than a longer context window.

The tooling I've built around that — an SDK and compiler aimed at Codex and Claude Code, turning messy domain data into typed, sourced facts — is just my current implementation of the idea, not a moat. And I should take my own earlier objection seriously: if platforms absorb the commodity layer, why wouldn't they absorb this too? They might — a generic facts-grounding layer is exactly the kind of thing that gets commoditized next. There's a second pressure cutting the same way: as models get better at deriving global facts unaided, the need for hand-built verified/estimated scaffolding could shrink, not grow.

So I won't claim a moat. The narrower thing I will claim — more defensible for being narrow — is that the facts that matter most are tied to your domain: your invariants, your private data, the specific thing that's dangerous in your system. That's the part a general platform doesn't have and a smarter model can't infer from nothing. Owning the pipeline that produces those facts buys trustworthy agent output now, on your actual problem. Whether that's a lasting edge or a temporary one, I don't know. The honest reason to build it isn't defensibility — it's that it makes the agent's answers true today.

Objections I'd raise myself

• "Wrappers are still easy — most apps don't need a sandbox." True, and plenty of good products are still a chat box over an API. My claim only covers the frontier-shaped slice — runs code, renders artifacts, holds work state, feels instant. Outside it, "just wrap it" is still accurate, and I don't want to inflate the rest into something heavier than it is just to dignify the work.
• "This is build-vs-buy, nothing new." Partly. What's new is that the buy side moved. You used to buy the model and build the app. Now you also buy the agent engine and the sandbox platform, and the build is the orchestration, the boundary, and the facts pipeline between them.
• "Won't the platforms just absorb all of this?" Probably some of it. Managed agent sandboxes will get boring the way managed Postgres did, and a generic facts-grounding layer is a plausible next thing to be commoditized. I don't have a clean rebuttal — only that the specific facts tied to your domain and private data are the slowest part to absorb. That's a thinner claim than "I have a moat," and I'd rather state the thin true one.
• "You're building on a borrowed engine and a rented sandbox." Yes, and it makes the strategy less stable than I'd like. The app-server isn't a frozen ABI; the platform sets the gravity, not me. I'm not standing on bedrock — I'm standing on a fast-moving layer and trying to stay close to it. The wager is that staying close beats trying to own the whole stack. It's a wager, not a fortress.

Where this is going

The best developers at OpenAI and Anthropic are improving the consumer product relentlessly, and you can't out-ship them on their own surface — the chat, the sandbox, the artifacts, the latency move every few weeks. Matching that head-on is a losing race.

So the move is two-handed, and I'll admit it isn't a stable one. One hand keeps up: drive codex exec and app-server, Claude Code's headless mode, whichever sandbox platform's gravity fits — ride the improvements instead of fighting them. The other hand grounds the facts your agent runs on. Neither hand is holding bedrock; both sit on layers that move, one rented and one possibly temporary. The wager is only that staying close to the frontier while owning your domain's facts beats the alternatives — not that it's safe.

The phrase aged in an interesting direction. "Just a wrapper" used to mean thin, replaceable, not really engineering. For the frontier-shaped slice, it now means a state-gravity decision and an orchestration layer over a borrowed engine. (For everything else, "just wrap it" is still true, and that's fine.) The model call used to be the product. Now it's the commodity inside the product — and the easy part is the part you no longer build.

That's the pull I keep feeling: stop trying to reproduce the giants, stay close to the layer that keeps moving, and stay honest about how much of the advantage is real versus borrowed.