Pricing and limits

Plans

Prices are in US dollars per month. Allowances reset with each billing period on a paid plan. The signup trial counts its allowances over its 7 days.

Retained state is sized for one workspace per customer, with suspended workspaces kept for as long as you want them. The workspace counts assume 2 GiB each, which is generous for most work: on the default template with 2 GiB of memory, a new workspace keeps under 0.1 GiB, one with a cloned Node.js repository and its dependencies about 0.2 GiB, and one with a Python environment, 40 MB of data and a report about 0.4 GiB. A checkpoint also holds the memory the workspace has used, so one that has filled its memory can keep close to its memory size on top of its disk.

Opt-in idle retention removes workspaces you no longer use so you stay inside your Retained state allowance.

Retained state sets how many workspaces you keep: the workspace counts above are what it holds at 2 GiB each. Only working workspaces count toward workspaces working at once, so on Developer you keep about 50 workspaces and up to 10 of them work at the same moment.

GPU: on Startup and Scale, workspaces render on a GPU through Shardflux's own Vulkan driver, with the CUDA Driver API (libcuda.so.1), NVENC (API 13.1) and NVDEC (libnvcuvid.so.1) on the same GPU, and Vulkan, CUDA, NVENC, NVDEC and VA-API apps use them unchanged. CUDA applications call the Driver API, as NVENC and FFmpeg do; programs built on the CUDA Runtime API (libcudart) use the Driver API instead. Blender's Cycles renders on CUDA devices; it is offered no OptiX device. Render on the GPU has each engine's launch settings. GPU-hours measure what your apps use.

GPU video: a workspace holds up to 32 Vulkan Video sessions, 64 NVDEC decoders and 64 NVDEC parsers at once. A session or decoder past those, or while the GPU's own are all in use, waits a short time for one to free up and is then refused (GPU video sessions).

Enterprise: contact shardflux@shardflux.dev. Write there too when you outgrow Scale. With its largest overage Scale covers 67,933 RAM GiB-hours a month (48,000 included plus $299 of overage at $0.015); past that, no plan fits yet.

There is no automatic overage. Reaching an allowance adds charges only after you turn on overage with a spend cap. Upgrade, change or cancel a plan under Usage & billing in the console, or from a terminal with the CLI (0.5.0+): shard billing upgrade <plan> prints the Stripe Checkout URL where a person pays, and shard billing portal prints the link for plan changes and cancellation (Billing).

Card on file

Compute runs on organizations with a card on file and an active trial or paid plan. The organization's creator saves a non-prepaid credit or debit card directly on the console's Usage & billing page, a Stripe page in setup mode, and approves it with their bank (3-D Secure; wallet tokens and prepaid cards are not accepted): nothing is charged. A paid plan's card counts, and so does a plan arranged with Shardflux (a custom or design-partner plan). Accounts, organizations, projects and API keys need no card. Until a card is saved, opening, resuming or forking a workspace and building a template answer 402 card_required with the page that saves it. Running workspaces keep running.

Signup trial

New accounts can register automatically via the console, CLI (shard signup) or HTTP API, and create organizations, projects and API keys right away. Before starting workspace compute, verify an established GitHub account (at least 30 days old) or non-disposable work domain (registered at least 30 days ago with active MX records), and complete the $0 Stripe card check on the console’s Usage & billing page or with shard billing trial --wait. Enter a credit or debit card number directly and approve it with your bank (3-D Secure); wallet tokens and prepaid cards are not accepted. Nothing is charged. This starts 7 days of Pro’s allowances and limits. Subscribing to a paid plan ($9/mo Developer and up) enables compute immediately without the trial checks.

• Who gets it. One signup trial per person, per card and per GitHub account, across all accounts, ever. Either a linked GitHub account at least 30 days old or a verified work email or organization domain registered at least 30 days ago with active MX records is required alongside a non-prepaid, non-wallet Stripe card check that the card's bank approves (3-D Secure). Consumer webmail addresses (such as Gmail, Outlook, Yahoo, iCloud or Proton) need a linked GitHub account or a verified organization domain to qualify for the trial, or can start directly on a paid plan. The trial applies to the organization where you start it; additional organizations need a paid plan. Trials are limited each month.
• Capacity. Trial workspaces start on capacity that is already running, so at busy times a start may wait for it (until the start's deadline, then capacity_unavailable). Paid plans add capacity when they need it. A trial organization's running workspaces share 8 vCPU, and on a busy host trial workspaces run on the CPU that paid plans leave free.
• The end. When the RAM GiB-hours or CPU hours are used up, or after 7 days, workspace compute pauses until you choose a paid plan ($9/mo Developer and up). Up to 10 GiB of retained workspace storage is kept and nothing is deleted. Every owner and billing member gets an email 3 days before the end and one when it ends.
• Upgrading. Upgrade to a paid plan at any time. The plan replaces the trial at once; Pro ($29) has the same allowances and workspace limits, without the shared 8 vCPU, every month, with overage.

What each allowance measures

Shared volume storage is measured and shown separately; no allowance includes it and it never blocks anything.

shard usage, cloud.usage (TypeScript) and Usage in the console show what you have used, with the time the numbers were measured through.

GPU-hours

A GPU app counts every second at the larger of two shares of one GPU: the GPU memory its scene holds, over 16 GiB, and the fraction of that second the GPU spends on its own work. An hour at a full share is one GPU-hour, so a light scene uses a fraction of one:

• Only your own work counts: time spent waiting for the GPU and the driver's own memory never do.
• A scene's GPU memory counts while it is on the GPU. A Vulkan scene waiting between frames leaves the GPU a fraction of a second after its last frame and comes back with the next request (Frames on request), so an app that renders on request counts its GPU memory only around its frames.
• 16 GiB is 2^34 bytes. Usage is measured per app, summed for the organization, and counted per UTC hour like the other allowances.
• Startup includes 25 GPU-hours a period and Scale 100. With overage on, more cost $1.00 per GPU-hour under the same spend cap as RAM and CPU.
• Usage in the console and the usage summary (gpu: used, included and overage GPU-hours) show what you have used.

What an agent session costs

Because a parked workspace uses little or no RAM, what you pay follows how long your agent works, not how long the workspace stays open. The figures below are the average of 1,345 recorded agent sessions, each 55.7 minutes from the first tool call to the last with 11.2 minutes of tool calls, replayed on the production idle policy with a workspace holding 2 GiB while it works. A session uses 0.573 RAM GiB-hours: the full 2 GiB for 15.1 minutes and 256 MiB for 16.8 minutes. A workspace that a background process keeps busy never parks, so it uses its full 2 GiB for 63.1 minutes (2.102 GiB-hours), or 55.6 minutes (1.854 GiB-hours) when your harness suspends it as the turn ends.

• The dollar columns are the cost per end customer a month at the overage rate. Inside a plan's allowance the sessions cost nothing extra: Developer's 800 RAM GiB-hours cover about 1,396 of them a month, Pro's 4,000 about 6,980, Startup's 12,000 about 20,941 and Scale's 48,000 about 83,763.
• 124 sessions is one workspace's month in the replay, with modelled breaks between the sessions.
• The replay assumes the workspace parks whenever the agent is idle. One whose processes keep using CPU or the network while idle stays resident: count it as kept busy.
• Past Scale with its largest overage, 67,933 RAM GiB-hours a month or about 118,550 of these sessions, no plan fits yet: contact shardflux@shardflux.dev.
• CPU hours are not included. They count only the CPU time your processes use.
• The calculator in the pricing section works this out for your number of customers and sessions and your workspace size.

With elastic memory. The table counts 2 GiB held while the workspace works. With elastic memory a workspace is billed for what it holds, not for its maximum. Replayed on 1,885 recorded agent sessions, the median session of a workspace with a 1 GiB floor and the 8 GiB maximum of python-node-browser was billed for 0.55 GiB on average over its running time, less than a workspace holding 2 GiB (0.71 GiB), with up to 8 GiB there whenever its commands need it.

What happens at a limit

Every owner and billing member gets an email at 80 % and 100 % of an allowance. With overage on, they also get one at 50 %, 80 % and 100 % of the spend cap. Compute limits are enforced with short budget leases, so usage can run slightly past an allowance or the spend cap before running workspaces are suspended; the organization's spend view reports that bound.

Billing states. If a payment fails, you have 7 days of grace. Nothing changes during it, except that overage is paused until the invoice is paid. After that, new opens, resumes and forks are refused with 402 entitlement_required (details.reason: payment_past_due or unpaid); running workspaces and your data are untouched. A cancellation takes effect at the end of the period, after which new workspace starts require a paid plan while up to 10 GiB of retained workspace storage is kept.

Data is never deleted by billing or inactivity. Workspaces are deleted only when you delete them, with one exception: a session workspace is deleted when its session ends.

Overage (opt-in)

Overage keeps your workspaces opening and running past the CPU-hours and RAM GiB-hours allowances, keeps them rendering past GPU-hours on Startup and Scale, and lets retained storage and workspace disks grow past the plan, up to a spend cap you set. It is off by default; trials have no overage.

Turning it on. An owner or billing member turns overage on under Usage & billing in the console and sets a spend cap in dollars per billing period. The cap is at least $1 and at most the plan price: $9 on Developer, $29 on Pro, $79 on Startup, $299 on Scale. A period's bill is therefore at most twice the plan price. The cap never exceeds the current plan's price, so moving to a cheaper plan lowers it.

Rates. RAM, CPU and storage rates are the same on every paid plan.

With overage on, a workspace disk can also grow past the plan's disk maximum, up to 2,048 GiB. Shared volumes are never charged. Outbound transfer has no overage: outbound traffic is blocked at 100 % of the transfer allowance.

Billing. Charges come from the same usage measurements as the allowances, counted per UTC hour. They go on your next monthly invoice and are charged to the card that pays the plan. There are no prepaid credits. Upgrading during a period does not refund overage already charged.

At the cap. New opens, resumes and forks are refused with 402 allowance_exhausted (details.reason: spend_cap_reached; see Errors). Running workspaces are suspended, keeping their files, memory and processes. Nothing is deleted. Work can start again when the next billing period begins, when you raise the cap (up to the plan price), or when you upgrade. Usage can run slightly past the cap before workspaces are suspended, but you are never charged more than the cap. Past the GPU-hours allowance, the cap stops only the GPU; workspaces keep running.

Past-due payments. While a plan payment is past due, overage is paused and the allowances apply as if it were off. Past an allowance, starts are refused with 402 allowance_exhausted (details.reason: overage_paused) and running workspaces are suspended. Overage resumes when the invoice is paid.

Emails. Every owner and billing member gets an email at 50 %, 80 % and 100 % of the cap, and when someone turns overage on or off or changes the cap.

Workspace sizes

A workspace's CPU, memory and disk are the smallest of three maximums: the plan's (above), the template's, and the caps you pass to open (caps: { cpu_millis, memory_mib, disk_gib }; 1,000 cpu_millis is one vCPU). Memory is elastic: the workspace sees that maximum from boot and holds what its processes use, at least memory_mib_held, 1,024 MiB by default and at least 512. A floor within 512 MiB of the maximum is lowered to leave that room, and a maximum below 1,024 MiB is held in full. A workspace boots with the vCPUs of its plan's or template's maximum; cpu_millis is the CPU time it may use.

• A new workspace starts with its template's default disk, 20 GiB on the platform templates, and its disk grows on its own as it fills, up to the plan's and the template's maximum. An explicit caps.disk_gib at open sets the size it starts at, within those maximums; reopening it without a disk cap keeps its disk. Retained state counts the bytes kept, not the disk's size.
• python-node-browser allows up to 4 vCPU and 8 GiB of memory. Its workspaces have up to 8 GiB of memory, or the caps.memory_mib you set.
• Resize: memory changes live, both ways; CPU changes live up to the vCPUs the workspace booted with (its plan's or template's maximum) and above them at its next start; a disk grows online and never shrinks (a smaller disk_gib is 422 validation_failed, shrink_not_supported). A resize above the plan's or the template's maximum is lowered to it (limit_reason), and at_maximum says the resource is there.
• Disk is the space for the workspace's own changes; the template's files do not count against it.

See Workspace size.

Region

Workspaces and the API run in AWS us-west-2 (Oregon, United States). The API is https://api.shardflux.dev and the console https://app.shardflux.dev.

Starts and waits

Inbound ports

Port URLs of processful workspaces:

Templates

A version's immutable paths are stored as one image. Each version's image counts toward your organization's template storage, and so toward retained state.

Computer use

The desktop's control port, 61001, is reserved and cannot be exposed (422, port_reserved). The viewer is served through the workspace's inbound ports 61002 (view only) and 61003 (interactive), which stream() exposes for you.

API rate limits

Over a limit, the API answers 429 rate_limited with a Retry-After header. The SDKs retry 429 for safe and idempotent requests (maxRetries / max_retries, default 2), waiting the full Retry-After (TypeScript 0.22.0+, Python 0.18.0+), then raise the error with retryAfterSeconds (TypeScript) or retry_after (Python). A wait that would outlast the request's timeout raises the error at once.

File and command limits

Search, patches and revisions

See Search and edit files.

File-first workspaces

See File-first workspaces.

Shared volumes

The plan's shared-volume size is an account-wide total: the sum of quota_gib across every customer-managed shared volume in the organization. Developer has 10 GiB, Pro 50 GiB, Startup 100 GiB and Scale 1,000 GiB. Count limits are unchanged; the trial has Pro's 50 GiB total. Shared-volume storage is reported and has no storage charge. An open by name defaults to 1 GiB only when creating; supply quota_gib within the remaining allowance (TypeScript SDK 0.18.0+, Python 0.14.0+, CLI 0.13.2+, MCP 0.12.0+).

Shared volumes store data outside workspace snapshots and forks; attached agents can read or write them according to the mount mode. A workspace takes up to eight shared-volume mounts; detach a volume before adding another. See Volumes.

Website sign-ins

See the HTTP reference for store metadata and the sign-in protocol.

Secrets

Project secrets are stored encrypted with AWS KMS; only the project's workspaces can load them, and every load is logged. Browser sessions are stored and loaded the same way.

Secret values are redacted before exec/PTY output and logs are persisted, including base64/URL forms across chunks. Tool-call capture sanitizes bound secret values. Both cover values of 8 or more characters, and values that are only letters or only digits from 16; shorter or plain values, such as true, 1, 8080 or production, appear as written, so output that contains them stays intact.