Delete a ChatGPT Site. Then check whether it helped.

The steps, from the help center

1. In ChatGPT on the web or in the desktop app, open Sites from the sidebar and select the Site.
2. Copy out anything you want to keep. Export is not documented, so the conversation that built the Site is your source of record: ask ChatGPT for the files or content you need before you go further.
3. Select Delete site and follow the prompt.
4. Type the Site slug in the dialog, then select Permanently delete.

The help center's warning is worth quoting in full: "Deleting a site permanently removes it, and you cannot restore deleted sites." It also notes a gentler option in the same section: if what you want is the Site gone from an audience rather than gone entirely, use Share settings to restrict access to a select set of people, or to yourself. That is the "take down" path, and it matters for the usage question below.

Does deleting free up usage?

Partly, and not on a documented schedule. The help center says that when you reach a beta limit you may be unable to create a Site, add storage, or keep a busy Site public "until usage is reduced". Usage, per the notice OpenAI sends when you approach the cap, is "a combination of number of sites, storage, and site visits". Deleting a Site reduces the first two directly. Nothing in the docs says how quickly the account's meter reflects that, or what happens to the visits component, which is a history rather than a quantity you can delete.

One report from 4 September suggests the meter does not move the way people expect: "I deleted a bunch of sites after getting email warnings of Sites usage almost full, thinking it would free up space but now I'm totally blocked? I used to have almost 20 sites but now only 8." Another, from mid-August, got the 50% email, "chatted with them a few times about the issue, but it didn't get resolved so I gave up."

So the honest advice is: delete what you genuinely do not need, then open the Sites experience and read the limits it shows for your plan. If it still reports you at the cap, do not keep deleting. OpenAI staff in the 11 September announcement replies pointed people to the in-product /feedback command so the team can debug an account; that is the route for a stuck meter.

Why usage does not reset weekly

Two different allowances get called "usage", and the replies to every Sites announcement mix them up.

• Build usage resets. Building and editing a Site runs through Codex, so it spends your plan's agentic allowance, the five-hour and weekly limits you can see under Usage and limits in the app. "I ran out of usage 24 hours after the last reset" is this meter. Waiting fixes it.
• Hosting usage does not. The Sites cap is a running total across all Sites on the account: how many, how much they store, how much traffic they serve. It has no reset day. It goes down only when you remove things, and the docs say it "may change during the public beta". "You've now used 50% of your allocated ChatGPT Sites usage" is this meter. Waiting does nothing.

People are asking for the two to be shown side by side ("could we add a way to see the GPT sites usage limit as well within that same usage limits section in the iOS app?"). Until they are, the tell is the wording: agentic limits talk about resets, Sites limits talk about allocation.

What you cannot delete

• Individual versions. Every save adds a version; the docs describe listing and inspecting them but not removing them. Users report versions "take up all the space for nothing". Deleting the Site is the only version-level cleanup.
• Anything from the CLI or an agent. Sites can be created from a Codex session but the docs are clear that management lives in ChatGPT web or the desktop app. "You can make claude artifacts and chatgpt sites from cli but cannot delete them using the same," as one developer put it. Another wanted Sites off entirely and found "agents can create the sites but not delete them, that can only be done in the UI".
• A Site whose settings are stuck. One user with a broken custom domain reported being unable to delete or change it for days. If Delete site fails, that is a support case, not a retry.

Three levers that reduce usage

1. Delete the Sites you do not need. The steps above. Permanent, so start with the throwaways: the experiments Codex published on its own, the duplicates from a workspace hiccup, the demo you already showed.
2. Take busy Sites private. If a public Site is drawing traffic you do not need, switching "Who has access" to "Only you" or an invited list stops the visits that count toward the cap, without deleting anything. The help center describes this as the way to restrict access; a high-usage public Site is also the one thing a limit can take offline on its own.
3. Stop new usage arriving. Most surprise Sites are Codex publishing local work; one line in AGENTS.md stops that. And a finished static page (a report, a proposal, a one-pager) does not need a database, a server, and a stack of versions. Hosting it on Sites spends the same account-level quota as an app. Hosting it on Stacktree spends none, and the caps there are page counts and storage you can read on the pricing page. The usage limits post has the full breakdown.

Before you delete a page someone has the link to

Deletion is instant and the URL dies with it. If a client, a colleague or a reader has that link, republish first and delete second. For a static page that is one step: publish the same HTML to Stacktree and send the new private link. The client opens it with no ChatGPT account, you can add a passcode or an expiry, and revisions replace the page at the same address rather than stacking versions.

Deletion works differently there, and it is worth saying because it is the opposite of the ChatGPT model. Taking a Stacktree page down kills the link immediately for everyone holding it, but the content is kept for 30 days and a single call restores it at the same URL, with the same id, slug and read history. You can delete without losing the option to change your mind. On ChatGPT Sites, the slug you type into that dialog is the last time you will see the Site.