Spinneryalways readyThe Organization keeps the CLI entry point, Project checkout, Workspace metadata, Git, tmux, editors, Claude, Codex, logs, repo storage, and signed dev link state available before the Runtime wakes.
Docs / Pricing and usage
Usage billing starts after the shell is ready.
Spinnery separates the always-ready shell baseline from awake-only runtime work. Teams can attach with spin up, choose a runtime size for service work, let auto-sleep stop the meter, and keep live cost visibility while agents, tests, and dev sessions run.
usage modelawake runtime
shell: ready baseline
runtime: bills only while awake
size: Small / Medium / Large
sleep: idle auto-sleep stops meter
visibility: live estimate + cap state
Billing boundary
The shell baseline and runtime meter are different layers.
The baseline keeps the collaboration surface ready. Runtime usage starts only when service processes need CPU and memory for dev URL traffic, tests, jobs, or explicit service commands.
retained asleepThe branch checkout, declared artifacts, Resource references, and Workspace identity remain available while Service CPU and memory are not running.
awake onlyWeb, API, workers, tests, database proxy, cache, mail, storage helpers, and other Service/Resource work bill only while the selected Runtime is awake.
Product language
Use Shell for the baseline and Runtime for awake billing.
Pricing copy should use the same nouns the product uses: Organization, Project, Workspace, Service, Resource, Shell, Runtime, Access Policy, signed dev link, and CLI. That keeps invoices, docs, and support handoffs aligned.
included baselineThe Shell is the always-ready terminal surface opened by the CLI. It belongs to the Organization and Workspace, and it does not start awake Runtime billing by itself.
awake meterThe Runtime is the Service capacity for web, /api, workers, checks, and Resource helpers. It bills only while awake and stops billing after idle sleep or spinnery sleep.
billing-neutralAccess Policy, root posture, and signed dev link scope stay enforced whether the Runtime is asleep, waking, or awake.
Launch pricing
Use concrete amounts when modeling a first workspace.
The first-release pricing docs name the launch amounts beside the billing boundary: shell baseline, retained storage, and awake runtime sizes are separate lines.
Includes CLI and dashboard access, the always-ready shell handoff, Git/tmux/editor tooling, logs, workspace metadata, signed-link state, and 20 GB of retained workspace storage.
Covers branch checkouts, declared artifacts, retained logs, and workspace state while the runtime is asleep or awake.
1 vCPU reserved; 4 GB RAM reserved; up to 2 shared vCPU / 8 GB burst. Bills only while web, API, workers, tests, jobs, or signed dev traffic keep the runtime awake.
2 vCPU reserved; 8 GB RAM reserved; up to 4 shared vCPU / 16 GB burst. Bills only while web, API, workers, tests, jobs, or signed dev traffic keep the runtime awake.
4 vCPU reserved; 16 GB RAM reserved; up to 8 shared vCPU / 32 GB burst. Bills only while web, API, workers, tests, jobs, or signed dev traffic keep the runtime awake.
spin up + Git + editor work = 0 runtime minutes$0 runtime chargeThe shell baseline covers the handoff while no service CPU or memory is awake.
37 awake minutes / 60 x $0.36 = $0.22$0.22 runtime chargeA signed dev request wakes Medium for review; asleep time before and after adds no runtime cost.
Usage handoff
A usage receipt should explain the active meter without exposing infrastructure.
Before an agent run, long test suite, or reviewer session is left running, the pricing docs should tell teams what to check: runtime state, cap posture, separate customer-cloud costs, and the receipt Spinnery keeps after sleep.
workspace usagesafe billing view
$spinnery workspace usage signed-links
runtime: Medium awake for 37m
wake trigger: signed dev request from web
cap: warn at 80%; stop disabled
customer-cloud: postgres, storage, egress billed separately
sleep receipt: retained after idle sleep
- Runtime state
asleep / waking / awakeName what is running now.
A usage handoff should show whether the runtime is asleep, waking, or awake, which size is selected, and which trigger started the session.
- Cap posture
none / warn / stopShow what happens near the limit.
Caps should be visible before work starts, then record when the product warned, blocked new runtime work, or let the session continue.
- Separate cost
customer-cloud resourcesDo not hide provider spend.
The usage handoff should call out resource modes and provider-owned costs that are not part of Spinnery runtime minutes.
- Sleep receipt
wake + sleep timestampsLeave evidence after the meter stops.
After idle sleep or spinnery sleep, keep the runtime size, awake window, cap events, and wake trigger available for review.
Security and billing boundary
The meter can sleep, but the organization boundary does not.
Pricing should not imply that sleep, wake, or runtime size changes the trust model. The included shell, signed dev links, root policy, and one-org-per-VM placement remain governed by the same organization boundary.
- VM tenancy
one-org-per-VMEach shell/runtime VM is assigned to exactly one customer organization. Awake or asleep runtime state never places another organization on that VM.
- Root policy
org-governed rootRoot stays disabled, approved break-glass, or workspace elevation by organization policy. Runtime wake, sleep, or billing state does not grant root.
- Signed dev links
app boundary onlySigned dev URLs can wake web, same-origin /api, assets, and realtime traffic for one service/workspace/org session; they do not expose SSH, secrets, logs, private consoles, or runtime admin.
- Billing state
shell included / runtime awakespin up and shell collaboration stay included while idle. Runtime minutes start only when service work, tests, jobs, or signed dev traffic wake the selected capacity.
Runtime guardrails
Billing rules should be obvious before a workspace wakes.
The pricing docs should give teams a plain-language contract for which actions stay in the included shell baseline, which actions wake paid runtime capacity, and what evidence appears when caps or auto-sleep change a session.
- Does not wake
shell / git / docsOpening the shell, editing files, reading logs already captured in the workspace, or reviewing repo metadata should not start runtime billing by itself.
- Does wake
dev URL / tests / servicesA signed dev URL request, service command, worker run, test suite, or agent task that needs web, API, database, cache, mail, or storage processes wakes the selected runtime.
- Stops or warns
cap / idle policyWorkspace caps warn before stopping more runtime work, and idle policy stops the meter after service traffic and background jobs go quiet.
- Leaves a record
wake / sleep / capThe usage trail records who or what woke the runtime, which size ran, when sleep stopped the meter, and whether a cap changed the session.
Runtime sleep contract
spinnery sleep stops runtime billing without deleting the workspace.
Use spinnery sleep when the service runtime should stop billing now, but the workspace should remain available for shell work, later signed-link review, and usage history.
runtime sleepbilling off
$spinnery sleep
runtime billing: stopped
shell: still available
workspace data: persisted
signed dev URL: can wake later
usage history: wake + sleep recorded
- Stop metered runtime
spinnery sleepStop paid service capacity on command.
spinnery sleep shuts down the service runtime and stops runtime billing for web, API, workers, tests, and resource helpers.
- Keep shell access
shell remainsKeep the terminal handoff alive.
Sleeping the runtime does not close the workspace shell, tmux session, Git checkout, editors, Claude, Codex, logs, or workspace metadata.
- Retain workspace data
state persistsSleep is not cleanup.
The repo checkout, declared artifacts, metadata, and signed-link state persist until an explicit cleanup action removes the workspace.
- Wake from signed links
dev URL wakeReview links remain useful after sleep.
A valid signed dev URL can wake the runtime later for app, same-origin /api, asset, or realtime traffic without exposing shell access.
- Record the lifecycle
wake + sleepUsage history keeps the billing trail.
Runtime usage history records who or what woke the runtime and when spinnery sleep stopped billing for the awake session.
Runtime sizes
Pick the capacity for the work that wakes.
Size changes affect the awake runtime window, not whether the shell baseline exists. Start smaller for normal branch work and increase only when tests, workers, or agent loops need more reserved headroom.
1 vCPU / 4 GB reserved
$0.18 / awake hourBursts to 2 shared vCPU / 8 GB when the host has room.
45 awake minutes on Small = $0.14 runtime.
Default branch workspaces, light web/API dev routes, and smoke checks.2 vCPU / 8 GB reserved
$0.36 / awake hourBursts to 4 shared vCPU / 16 GB for heavier test loops.
37 awake minutes on Medium = $0.22 runtime.
Full-stack branches with workers, background jobs, or larger fixtures.4 vCPU / 16 GB reserved
$0.72 / awake hourBursts to 8 shared vCPU / 32 GB for short compile-heavy windows.
2 awake hours on Large = $1.44 runtime.
Busy agent runs, large monorepos, and integration suites that need headroom.Auto-sleep and visibility
Every awake session should show what it costs.
Spinnery should make runtime state visible while work is happening: when the meter started, which size is awake, what the session has accumulated, and whether a cap is close to stopping more service work.
- Open shell
spin upThe user or agent lands in the workspace shell first. Runtime billing has not started just because the shell is open.
- Wake services
dev URL / tests / jobsSigned dev traffic, service commands, smoke checks, or agent jobs wake the Small, Medium, or Large runtime.
- Watch usage
live cost panelThe product shows runtime size, awake/asleep state, current session minutes, estimated spend, and cap status while work runs.
- Sleep idle
auto-sleepWhen service work goes quiet, Spinnery stops the runtime meter and keeps the shell baseline ready for the next wake.
awake minutes + estimateDevelopers can see what the active runtime session is accumulating before leaving a dev session, test run, or agent job unattended.
warn before stopUsage caps should be visible before a runtime wakes and again when the session approaches the configured limit.
wake / sleep eventsThe billing trail records when a workspace runtime woke, which size it used, and when auto-sleep stopped the meter.