Billing

Hosted workstations are billed under the plans below. The plans are configured and proposed while launch gates are still pending.

plans

Standard is $20 per month. Pro is $50 per month. Both are subscriptions with a metered overage for hours past the included allowance.

Standard: up to 8 parallel sandboxes sharing the workstation, 200 included active hours per month, $0.06 per extra active hour, default spend cap $40 per month, 40 GB workspace storage budget across sandboxes.

Pro: up to 20 parallel sandboxes sharing the workstation, 300 included active hours per month, $0.12 per extra active hour, default spend cap $100 per month, 60 GB workspace storage budget across sandboxes.

An active hour is any hour in which the workstation is running. Stopped time is free. Overage counts completed hours only: a partial hour at the end of a period is never charged and never carried forward.

Parallel sandboxes share the workstation. The documented count is a ceiling, not a reservation of resources for each sandbox. Storage is a shared managed budget, not a kernel-enforced quota: bytes your sandboxes hold on disk count toward it, including stopped sandboxes, and new work may pause at the budget.

These numbers are the currently configured terms, shown in your account and at checkout when you subscribe; the checkout offer at purchase time is the agreed terms for that subscription. Nothing here reserves compute per sandbox or promises latency.

trial

The trial is 7 days with 10 active hours on Standard. A card is required, and the trial is once per account: anything that ever reached a trial or a payment pays up front next time.

Membership approval is necessary before any trial, and it is not sufficient on its own: the server controls whether checkout and trials are currently available to your account, and this site cannot enable them. When checkout is available to you, it starts from your authenticated client — pipod billing checkout --trial in the CLI for a trial request when the server allows it (omitting the flag is paid checkout), or the Start trial / Subscribe / Manage billing actions in the native apps, which remain account/server gated — which opens Stripe-hosted pages in the browser and returns here afterwards. Public trials and activation remain closed until the launch gates pass. Membership application review is unchanged: apply here.

checkout and portal

Authenticated clients call POST /v1/billing/checkout-session for a Stripe checkout link and POST /v1/billing/portal-session for a Stripe billing-portal link (plan changes, cancel, card update; a downgrade takes effect at period end). After either Stripe page, the browser returns to this site:

checkout return · checkout cancel return · portal return

Those pages confirm nothing by themselves. A subscription or change takes effect when Stripe tells the server (webhook); the client then re-reads the account with POST /v1/billing/refresh or its next status read. Anything after the ? in a return address is for Stripe's reference only and changes nothing on this site.

The spend cap is the answer to bill shock: it is user-set, refuses new machine starts past the ceiling, refuses new pod work on an already-running workstation (launches, reuses, co-located runs, and wakes), and also stops the overage meter there. Every terminal billing state — an expired or exhausted trial, a failed payment past its grace period, a reached cap, or a missing subscription where one is required — blocks new starts and new work the same way. A reached cap additionally steers a running box to sleep through the ordinary stop path. New work is refused at the limit. Existing work may pause after the remaining grace/TTL window; workspace files are retained.

Billing itself does not block stopping a running workstation or reading files on a running eligible host, so a billing state can never trap you inside your own box — while normal authorization and safety checks still apply. Fetching from a stopped workstation first needs a wake, and wakes require current eligibility, so a cold file fetch may have to wait until the account is in good standing. Self-hosted servers have no billing surface at all: under that edition the API serves no /v1/billing/* routes and carries no workstation billing block.