#Usage & limits

Your plan gives you a weekly amount of compute and a few limits on how many chatspaces you can have. This page explains exactly what counts, what happens when you hit a limit, and how to keep usage low.

#The machine you get

Every chatspace runs on a real cloud machine with the same shape on every plan:

What changes between plans isn't the machine — it's how much total compute you can use each week (your budget) and how many chatspaces you can run (limits).

#How usage is measured

Usage is metered by the compute your chatspace actually uses — its CPU and memory — not by wall-clock time. A chatspace sitting idle costs almost nothing; one running builds, tests, and dev servers costs more.

We measure two things, across everything running on the machine — not just the agent, but also your dev server, your build steps, and anything they spawn:

• CPU — counted while work is actually happening. Builds, tests, installs, and serving web requests all burn CPU; a process that's just sitting there burns almost none.
• Memory (RAM) — counted for as long as it's held. A process that's up but doing nothing still occupies memory, so a dev server you left running keeps costing a little even when nothing is hitting it.

Your weekly budget covers both, and whichever you lean on harder is what counts against it. In practice memory is usually the one to watch — leaving things running is what quietly adds up.

Because of this, the "active hours" you see on each plan are estimates based on typical usage. Your real mileage depends on what you run: light editing stretches far, compile-heavy work uses more.

#How web requests to your apps count

Your live preview links run on the same machine, so serving web traffic uses your budget too:

• Every request costs a little CPU to handle — and the heavier the response (rendering, database queries, big payloads), the more. A busy app costs more than a quiet one.
• Your app holds memory the entire time it's running, whether or not anyone is hitting it.
• A preview URL is public — anyone with the link can reach it. Crawlers, bots, a teammate refreshing, or a load test all spend your budget.

There are guardrails: a request that stalls with no data flowing for a few minutes is dropped (so a stuck app can't pin the machine awake), and a flood of simultaneous connections is shed. It's the same CPU/memory meter as everything else — no separate per-request charge.

#Your weekly budget

Each plan includes a weekly budget of compute. You can see how much you've used (as a percentage) in the app.

The budget resets every week on your own schedule (tied to when you signed up), so everyone's reset is staggered rather than all at midnight. When it resets, you're back to a full budget.

Under the hood, the budget is two numbers per week — CPU-hours and memory GB-hours:

In everyday use memory is the dimension that runs out first — CPU almost never binds before it. That's why the plans are advertised in active hours: it's these budgets translated into roughly how long a typical chatspace runs (we reckon ~2 GB of memory per active hour, so e.g. Pro's 100 GB-hours ≈ 50 active hours).

#Idle stop

To keep you from spending budget on a machine that's doing nothing, Chatspaces auto-stops a chatspace after a stretch of inactivity — about 10 minutes by default.

• It's activity-aware: as long as the agent is working (or you're interacting), the timer doesn't fire. It only stops when things have genuinely gone quiet.
• It's safe: stopping preserves your repo, branch, uncommitted changes, and installed tools. Resume picks up where you left off.
• It's adjustable per chatspace: change the timeout, or turn idle stop off for a chatspace.

To resume a stopped chatspace, tap Resume (or Open in Claude / Codex). It wakes in about a second.

#Concurrency & total limits

Two separate limits, by plan:

• Running at once — how many chatspaces can be on simultaneously.
• Total — how many chatspaces you can have at all (running or stopped).

* Estimated. Usage is metered by CPU & memory, not wall-clock — your actual hours depend on what you run.

The machine itself is the same on every plan — plans differ by how much weekly compute you get and how many chatspaces you can run, not by how powerful each box is.

#What happens when you hit a limit

Chatspaces never yanks a machine out from under you:

• A running chatspace keeps running even if you cross your weekly budget mid-session.
• What gets blocked is starting new work — resuming a stopped chatspace, reconnecting, or creating a new one. You'll see a clear message with your reset time.
• Creating a new chatspace while over budget still saves your setup; it just starts in the off state until you have budget (or upgrade).
• Hitting the total limit means you can't create another until you delete one. Hitting the running-at-once limit means you must stop one before starting another.

#Staying under budget

• Let idle stop do its job — don't leave chatspaces running when you're done.
• Stop a chatspace yourself when you switch tasks.
• Avoid leaving heavy processes (watchers, dev servers) running longer than you need.
• For a public preview you're done with — especially one that might attract bot traffic — delete the chatspace rather than just stopping it, so inbound requests can't wake it.
• Delete chatspaces you're finished with so they don't count toward your total.

#Need more?

If you're hitting your budget or limits, upgrade — a higher plan takes effect immediately, so you can get back to work right away. Or wait for your weekly reset.

Next: plans & billing.