What ChatGPT Sites is, and the three limits we still hit.

What you get, and what it costs

No separate bill. The documentation says Sites "is in public beta and is available with ChatGPT Plus, Pro, Business, Enterprise and Edu plans", so if you already pay for one of those, you already have it. Free and Go are not on the list, and availability is still hedged on "your plan, region, and workspace settings". You describe what you want in the Work surface, ChatGPT builds it, and you get a live URL on a ChatGPT-hosted chatgpt.site address (OpenAI's own Sites sit at {name}.openai.chatgpt.site; ours sat under our account name, see the London test below), or, where custom domains are available, an apex domain or subdomain you already own, connected by updating DNS records. Custom domains are not in Enterprise workspaces at launch.

What comes with it, all documented: built-in analytics (unique visitors and page views, plus both over time, though not for Enterprise-owned Sites), a D1 relational database with 10 GB of storage and R2 object storage with no fixed limit, both declared in a .openai/hosting.json file, and two-stage publishing. You save a version, which is a reviewable deployment candidate, then deploy it to the production URL. Updates keep the same address, which makes this genuine replace-in-place rather than a new link per revision. You can also rename the ChatGPT-hosted address: at least five characters, a lowercase first letter, only lowercase letters, numbers and single hyphens.

Who sees it is a five-way choice in the docs: owner and workspace admins, selected active users or groups, invited external viewers, anyone in the workspace, or anyone on the internet. Read that list once and the shape becomes obvious. Four of the five are identity checks against a ChatGPT account, and the fifth is the whole internet. The Sites docs describe nothing in between, which is the first of the three limits below.

It is a build, not a file upload, and it takes real time. Our own probe of two near-empty pages took 7 minutes 50 seconds: Sites scaffolds a Next.js application, patches it, spawns a deployment-monitoring subagent and creates a checkpoint before handing back a URL. The launch release note excluded the UK, the EEA and Switzerland from public publishing and the wider beta rollout. Our London test on 22 August ran on a personal account, so Sites had reached the UK by then, but we have found no OpenAI note dating the change.

The three limits

All of the above is the part that works, and it works well. These three are what we keep running into, and each one rules out a different job.

• No gate a viewer can pass without a ChatGPT account. Private sharing arrived in September 2026 and is still rolling out: you can invite named people by email without publishing to the internet. They still have to "sign in with the account that received access". The Sites docs don't offer a passcode, an email-domain gate or link expiry, so the only documented way to reach a client with no ChatGPT account is to make the Site public.
• No public API or MCP surface. A Site is created and managed inside ChatGPT, on the web or in the desktop app, where Codex can also deploy a compatible local project. The docs describe no public API or MCP surface for publishing or updating one from outside ChatGPT, and Sites has no standalone Codex CLI management view. If your publisher is an agent pipeline outside ChatGPT, the docs give it nothing to call.
• Beta usage limits with no published numbers. "Plan-specific usage limits apply across all Sites during the beta." ChatGPT shows the current limits inside Sites and warns you as you approach one, and reaching one "can prevent you from creating a Site, adding storage, or keeping a high-usage Site public". The most-liked reply to the September announcement was someone asking to pay for more after a 50% warning. D1 storage is capped at 10 GB per Site; R2 has no fixed limit.

Two smaller gaps are worth knowing before you commit a deliverable to Sites. Export is not documented, despite community reports at launch of receiving a Wrangler project for self-hosting on your own Cloudflare account. And search-engine indexing behaviour is not documented either, which matters if the page is meant to be found rather than sent.

29 September: the DevDay 2026 update

Sites had its own session at OpenAI DevDay on 29 September 2026. Simon Willison's live blog carried the headline number: Sites "is already hosting 8m sites, and 70% of OpenAI employees are making their own sites". That is up from the 5M @ChatGPT posted on 11 September, and it comes from the session, not from an OpenAI doc. Here is the rest of the update, checked against the Sites docs and the Help Center on 30 September.

• A database and file storage. Simon's note from the session: "Sites get a SQLite database!" That part was already in the docs before DevDay: they describe D1 as "a relational database for durable structured data" and R2 as "object storage for files", with D1 capped at 10 GB per Site and no fixed limit on R2. Sites doesn't support data residency at launch, and that includes D1 and R2 data.
• Sign in with ChatGPT. A public Site can stay open to everyone and offer optional Sign in with ChatGPT for saved progress, personal views or records that belong to one person. The signed-in visitor's email reaches the Site's server in a request header. The docs treat this and the Site's audience setting as separate controls.
• Plugins, for workspace-private Sites only. Simon reported Plugins in Sites launching that day. A Site can load data from each visitor's own connected apps, but "using plugins in Sites requires a workspace where the feature is enabled and a Site that is private to that workspace", and visitors must be members of that workspace. The Help Center adds that an external-viewer invitation "does not independently authorize connected-app access". This one is for colleagues, not clients.
• Scheduled tasks and Edit site. Simon reported scheduled tasks for Sites launching that day, and the Help Center says you can link a cloud schedule to a published Site "when Site automations are available", if you own both. Releasebot's 29 September entry adds that owners and editors on Plus and Pro can select Edit site from a published Site in a desktop browser to carry on editing in ChatGPT.
• Usage limits, still unpublished. They are plan-specific, apply across all your Sites and may change during the beta. No official page gives the numbers, so the figures passed around for Plus are user reports, not documentation.
• Custom domains, where available. You connect an apex domain or subdomain you already own through DNS. Sites doesn't register domains for you, and custom domains aren't in Enterprise workspaces at launch.
• External invitations, still with a sign-in. From the keynote, Simon wrote: "You can also build ChatGPT Sites and share them with specific other people. (I admit I thought they had that feature already.)" He had reason to: the Help Center release note for it is dated 3 September. The docs say external invitations are "rolling out to Sites users on Plus, Pro, Business, and Enterprise plans", invited viewers can't edit or publish, and they must "sign in with the account that received access".

So DevDay made Sites more capable for people who already have ChatGPT accounts and left the signed-out viewer where it was: the Sites docs still describe no passcode, no email-domain gate and no way for a signed-out person to open a Site that isn't public. If your viewer is a client without ChatGPT, Stacktree gives them a private link they open with no account, with a passcode on any plan.

Is it the same as Codex Sites?

Same lineage, two things changed. Availability: Codex Sites was a beta for team plans; the June signal that individual plans were coming "ASAP" took five weeks to land. Visibility: Codex Sites could not be viewed outside your authenticated workspace, which was its defining limitation. ChatGPT Sites flips that: with public publishing enabled, a site is on the open web. If you found our "can you make a Codex site public?" status post first, the answer there was no; for ChatGPT Sites it is yes, and that post now says so.

Collaboration, and what it did not change

On 20 August 2026 Sites gained collaborative editing. OpenAI's developer account put it plainly: "Add teammates as editors to your ChatGPT Sites so you can build and publish together. Collaborators can push changes to the same project while Codex handles git management and CI behind the scenes." URL renaming landed in the same drop. The docs now define three roles: owner (audience settings, editor management, analytics, versioning, first publish), editor (open, change, save versions, publish updates once the owner has published), and visitor (read-only on the live site). Sites shared with you appear in a "Shared with you" section.

Read the qualifying line carefully, because it decides who this is for: collaborators must be "active members of the same workspace". This is multiplayer building, not multiplayer viewing. The audience model was untouched at the time, still the same four options it was in July, and it moved three weeks later (see the next section). At the collaboration launch, the gap people were already naming in public had not moved. Two days before the collaboration launch: "ability to more than one more user using chatgpt Sites in Plus Plan. I only see option for Private or anyone with link" (@zshansyd, 12 August). The day after: "why are these the only options for sharing chatgpt sites?" (@bee_human_, 13 August). And a month earlier, the request the launch did answer: "ChatGPT sites are a great way to share and present work (as opposed to ppt or docs) but it still doesn't solve the collaboration aspect for me" (@anukshi13, 31 July).

So the shape was clear. Sites is very good at a team building something together and then showing it to the world or to their own colleagues. As of August it had no answer for the third audience: one named person outside your company who should see this and nobody else, without signing up for anything. Since September it has half an answer, which is the next section, and the other half is still a separate question with a separate answer.

11 September: 5M sites, private sharing, database inspection

Two months after launch, @ChatGPT announced that "people have created over 5M sites" and listed five updates: invite teammates to edit, save and publish a shared Site; "invite specific people to a private Site without making it public"; prompt to deployment in half the time; ask ChatGPT to inspect a Site's database, which editors can view too; and custom domains. Two of the five were already documented in August. Private sharing is the one that changes this post.

The Help Center release notes had already dated the feature to 3 September; this was the announcement. The Help Center lists the second access option as "Selected active users or groups, and named external viewers", and describes the flow: enter an email address, save, then "ask them to open the Site while signed in with the account that received access". So the seat is gone and the sign-in is not. A client can be invited without joining your workspace, and per the docs still has to sign in with a ChatGPT account to open the link. The mechanism, the replies, and what is still missing are in ChatGPT Sites private sharing, explained.

The replies told a second story. The most-liked one asked to pay for more usage after a 50% warning, and a dozen others echoed it; the Help Center says limits apply across all Sites on the account, may change during the beta, and are shown inside Sites rather than published. Three developers described Codex publishing every local experiment to Sites unless told not to. Both are covered in the usage limits post and the AGENTS.md fix. OpenAI featured six Sites in the thread while the product lead collected forty more for an awesome list; we catalogued them, and almost none are client work.

The Cloudflare underneath

The launch thread confirmed Sites is "a collaboration between OpenAI and Cloudflare", and community digging identified Cloudflare Workers with SQLite and Durable Objects. Notably, Sites can reportedly export a Wrangler project of your site for hosting on your own Cloudflare account: a real portability story if it holds, though still absent from the docs. It is also a second consecutive datapoint (after Cloudflare Drop, launched the day before) that the biggest players are converging on the same shape: AI makes HTML, it needs a URL instantly, and Cloudflare is becoming the substrate either way.

Tested from London: the new URL editing

Sites reaching the UK made a first-person test possible, so on 22 August we ran one from London on a personal account: asked ChatGPT Work to build a deliberately minimal two-page probe site, published it, renamed it, and watched what the redirect actually does. What we found, in the order we found it:

• The build took 7 minutes 50 seconds for two near-empty pages. Sites scaffolds a Next.js application, patches it, spawns a deployment-monitoring subagent, and creates a checkpoint before handing back a URL. It is a real pipeline, not a file upload.
• Sites only exists in the Work surface. Asked in a plain chat, ChatGPT states the Sites capability is not exposed there and declines. The Chat-mode assistant in our test then volunteered that it did have publishing access to Stacktree via the installed connector, but would not substitute it for a test aimed at Sites, which is both correct and a neat illustration of where each product lives.
• Our URL was namespaced to our account. Our probe published at redirect-probe.stevysmith.chatgpt.site, a per-account subdomain. OpenAI's own Sites sit at {name}.openai.chatgpt.site, which looks like the same pattern with openai in the account position, but the docs don't document the format.
• Publishing defaulted to private, and in August a personal plan had exactly two modes: "Only you" and "Anyone with the link". No passcode, no email gate, no invited viewers outside a workspace, confirmed in one dropdown. The docs now describe a third mode, inviting named people by email from a personal account (September 2026, sign-in required); we have not re-run the test since.
• The new URL change works as documented, with one caveat. We renamed the site and requested the old address with a deep route and a query string: /about?q=carried came back as a redirect to the new host with both the route and the parameter intact. The caveat: it is an HTTP 307 temporary redirect. For a permanent rename, a 301 or 308 is what tells crawlers and caches the move is real; a 307 keeps old links working for humans while leaving search engines pointed at the old address indefinitely.
• The settings page shows more than the docs do: custom domains offered on a personal account, an environment-variables panel ("Add API keys and other environment variables your site needs"), an analytics tab, and site deletion. Still nowhere to be found: any API, MCP, or export surface.

Sites or a publish primitive

For a paid ChatGPT subscriber who wants a live app from a conversation, Sites is now the shortest path there has ever been, and public publishing removes its old dealbreaker. The choice that remains is sharper than it was at launch, because custom domains no longer separate the two. What does: who the viewer is, and who the publisher is. Sites viewers are either the whole internet or invited accounts, and the Sites docs describe no gate a client can pass without one. And the publisher is a chat session, not an API. If the thing you are publishing is a deliverable to share with a client without a login, needs an expiry or a password, or gets published and revised by an agent over an API rather than a conversation, that is the other half of the category: pages as deliverables, private by default, with a read on how they landed. That is the half Stacktree covers: publish over MCP or the API, unguessable by default, passcode and email-domain gates a client passes without an account, and revisions that keep the same URL. Both halves just got very real.