TL;DR: Deploy as many cells as you like. Idle cells sleep and cost nothing for compute. You pay consumed vCPU-seconds and requests on the apps people actually open — so a team holding twenty tools, three used daily, gets a bill reflecting the three. No per-seat, no per-app fee, no infrastructure subscription. Three costs survive sleep (storage, custom domains, warm capacity) and are priced or capped explicitly.
The bill mental model
The unit economics this must satisfy, stated as a test:
A team holds twenty cells, three used daily, seventeen asleep. The bill reflects the three. If that is not true, the “deploy freely” promise is a lie, people prune, and the accumulation the whole product depends on dies.
Small software only compounds if the tenth and twentieth tool cost nothing to leave running. Consumption billing is the on-ramp and the floor: it lets people be careless in the right direction.
Why the architecture matters: the 10–30× gap
Serving a published app out of an ephemeral sandbox session costs roughly $36–72/mo per app (1 vCPU at sandbox-vendor rates) — against ≈$0 incremental on isolate-style Active-CPU billing past a small account floor. A 10–30× gap.
| Option (95%-idle app) | Cost per app-month |
|---|---|
| Deno Deploy free tier (JS/TS only, ≤20 apps) | $0 under 1M req/mo combined |
| Cloudflare Workers + DO style isolates | ≈$0 incremental past the ~$5/mo floor |
| Fly.io shared micro-VM always-on | ~$2/mo + storage + IP |
| E2B / Daytona / Modal session run continuously | ~$36–72/mo |
Sandbox vendors are priced for ephemeral agent execution, not for serving the finished app. So a cell has two states: an ephemeral build/edit environment for the agent’s loop, and a cheap always-addressable serving state for the published app colleagues occasionally visit. Getting that second state near-free is what makes “keep twenty tools alive without thinking” possible at all. Python idle cost (much agent-built small software is Streamlit/FastAPI, and the cheapest tiers are JS/WASM-only) is measured before any pricing is published — the design goal, not a shipped number, and stated as such.
What counts, what sleeps, what survives
- Counts: vCPU-seconds actually executed + requests served.
- Sleeps free: idle compute. No requests, no CPU, no charge.
- Survives sleep (priced or capped explicitly): stored images and volumes, custom domains and certificates, any warm capacity held to avoid cold starts.
The wake-latency honesty box
Sleep-to-zero and instant first click are in direct tension. Render’s free tier (sleeps at 15 min, 30–60s cold starts, widely complained about) is the failure mode to avoid. Our acceptable p95 wake time for a colleague clicking a link — one second, three, ten — is set by measurement before launch, and a paid “always warm” tier likely exists for tools where the first click must be instant. We will publish the measured numbers rather than promise them.
Why consumption alone can’t carry revenue (stated openly)
Small software is by definition low-consumption: twenty internal tools together may burn less compute than one modest production service. Metering the dimension where the workload is smallest is right for adoption and probably cannot carry revenue alone. The working hypothesis: consumption is the floor; the org plan — SSO, groups, access logs, custom environments, private networking — carries the revenue. If teams won’t pay a flat org fee for identity and environment, this is a small business, and no metering fixes that. That question is what design partnerships test.
Abuse controls are launch requirements
“Unlimited free deploys of arbitrary code, publicly reachable” is the most abusable product shape in hosting — miners, phishing, spam relays. Every provider that offered it retreated (Fly 2024, Heroku 2022, Streamlit caps, PythonAnywhere consolidation). Designed in from day one: verified identity before public exposure, egress restrictions by default on free cells, per-account cell and CPU ceilings, outbound-domain reputation checks, rapid takedown tooling.
FAQ
Is there a per-app or per-seat fee? No. Unlimited cells; no seat count anywhere in the model.
What will twenty idle tools cost? ~Nothing for compute. Storage and any custom domains attached are the only surviving costs, capped and visible.
How is this different from serverless? Same metering spirit, different packaging: per-cell bills, per-cell share lists, per-cell logs and caps — one mental object per tool, not a cloud console of services to assemble.
When is pricing final? After storage/warmth decisions land and Python idle numbers are measured. Illustrative usage on the homepage (not final pricing) shows the shape until then.
Want twenty tools alive without doing arithmetic? Deploy now.