ChatGPT Sites usage limits, explained from the replies.

What the help center says

OpenAI's help center article on creating and managing ChatGPT Sites has a short section titled "Public Beta Limits". Quoted in full, because it is the only official text:

"During the public beta, Sites usage is included up to plan-specific limits. ChatGPT will notify you as you approach a limit. If you reach a beta limit, you may be unable to create a new Site, add storage, or keep a high-usage Site publicly available until usage is reduced. You can still edit and manage existing Sites. Limits apply across all Sites on the account and may change during the public beta. Check the Sites experience for the limits currently shown for your plan or workspace. Enterprise and Edu limits may vary by workspace."

Three things follow. The limit is per account, not per Site. It is not a fixed number, and the text reserves the right to change it. And the consequence is a freeze rather than a deletion: existing Sites keep working and stay editable, but you cannot add a new one, add storage, or (for a busy public Site) keep it public.

What counts toward it

The help center does not say. A user in the product lead's feedback thread posted the notice OpenAI sent when their account hit the cap, which does: "While ChatGPT Sites is in beta, the amount of hosting usage (a combination of number of sites, storage, and site visits) is limited. You can still edit existing sites, but you can't create new ones for now. Options to upgrade or purchase additional usage will be available after beta."

So the meter has three inputs: how many Sites you have, how much they store, and how many visits they serve. That is why a single Site can show 50% used. A Plus user asked the obvious question under the announcement: "I have 1 site. Got a message saying you've used 50% of your usage. So I can have 2 sites?" Not necessarily. Two small quiet Sites might fit; one popular Site with a lot of images might not.

The docs add one number: the D1 database is capped at 10 GB per Site, and R2 file storage has "no fixed storage limit". Both are per-Site technical ceilings, separate from the account-level beta cap, which can stop you adding storage long before you approach them.

What people are reporting

• Wanting to pay. The most-liked reply to the announcement: "Any plans to allow us to pay for more usage? Just got a 50% usage warning. If my site scales or I continue building, I'm happy to pay more. But doesn't seem to be an option." Another: "Please add optional upgrades of capacity. I am already using 100%."
• Limits moving. From the feedback thread: "I get random emails changing my limit even when I don't do anything. I understand it's currently beta, but I can't really rely on Sites if I have no idea if or when I'll get cut off."
• Versions eating space. "Please add a way to prune/delete prior versions of a Site. There is no way to do this currently, and after many changes the versions take up all the space for nothing."
• Pricing clarity for serious use. "Love ChatGPT Sites, but we need to know what your future plans and pricing are for this feature before we can use it for any serious projects." And, from someone already hosting five or six Sites: "You need to be clear on usage for each plan."
• Enterprise deletion. A separate reliability worry from an Enterprise admin: when an employee leaves, "all of their ChatGPT sites are automatically deleted, and we have no visibility on what those sites are."

None of these are complaints about the product being bad. They are complaints about not being able to plan around it, which is the specific thing a beta cannot yet offer.

Two meters, not one

Building a Site and hosting a Site draw from different allowances, and the replies mix them up. Building runs through Codex, so it spends your plan's agentic or weekly usage: "I would have hosted it on chatgpt sites but I ran out of usage 24 hours after the last reset. Pro 20x here." That meter resets on a schedule. Hosting draws from the beta Sites cap described above, which does not reset; it only goes down when you delete things. A 50% Sites warning and a 0% weekly usage screen are two different problems, and the fixes are different.

How to reduce usage

1. Delete Sites you do not need. Open Sites from the sidebar, choose Delete site, and type the slug to confirm. The help center is blunt: "you cannot restore deleted sites." Export anything you want to keep first, and note that export is not documented, so "keep" may mean copying the source out of the chat. One caveat before you delete in bulk: a user who removed a dozen Sites on a warning reported staying blocked, and the docs do not say how quickly the meter moves. The deletion how-to covers what deleting does and does not free.
2. Stop Codex publishing experiments. Several developers found Codex reaching for Sites whenever a task produced something viewable ("I had to add 'Never use ChatGPT Sites' to my AGENTS.md because Codex was putting every tiny local experience up on there"). Each stray publish is a Site with versions. The AGENTS.md line that stops it is one sentence.
3. Move big files to R2. A community report describes a 256 MB per-Site ceiling and recommends storing images in R2 and referencing them from the database rather than bundling them into the Site. Unverified against the docs, but consistent with the "no fixed storage limit" line for R2.
4. Move finished static pages off Sites. This is the one most people miss, and it is the subject of the next section.

What does not need to be a Site

ChatGPT Sites scaffolds a full application behind every deployment: a framework, server logic, a database, a deployment pipeline, saved versions. That is the right shape for a game, a tracker, a dashboard with live data. It is the wrong shape for a finished document, and a lot of what gets published is a finished document: a report, a proposal, a one-pager, a prototype the client needs to look at once, a deck rendered as a page. Those are a single HTML file. Hosting one on Sites spends the same account-level quota as hosting an app, keeps accruing versions every time you tweak a heading, and puts the reader behind either a public URL or a ChatGPT sign-in.

Publishing that file to Stacktree costs none of your Sites allowance, and the caps there are the kind you can plan around: a number of pages and a storage size per page, printed on the pricing page and returned by the API. Three pages free with a seven-day life, then 25 pages on Solo at $19 a month, unlimited on Studio. Visits are not metered against a quota, so a page does not go dark because it got popular. Each revision replaces the page in place on the same URL rather than stacking a version you cannot delete. And the link is private by default, opened by a client with no account, with a passcode or expiry when you want one. Keep the app on Sites. Put the document where documents belong.