01
Machine per session
Create on the first turn, sleep on the last, delete when the session closes. The simplest mapping and the right default for agent products.
MANSSINO / Use cases
Four workloads that stop fighting their sandbox.
The pattern repeats across every team we talk to. The work is long, it is stateful, it needs root, and it comes back to the same environment over and over. The sandbox was built on the opposite set of assumptions, so teams spend their time working around it. Here is what changes when the machine simply stays.
Common thread
- Environments that take minutes to build and seconds to lose
- Jobs that outlive a single request by hours
- Code written by a model, run without a human reading it first
- Idle time that costs money on every other platform
01 Code generation agents
Give the agent a computer, not a transcript.
A coding agent that cannot run what it writes is guessing. Give it a machine and the loop closes: it installs the dependency, runs the failing test, reads the stack trace, and fixes the line. Because the machine persists, turn two starts where turn one ended, with the virtual environment built, the repository cloned, and the language server already warm.
- Install once per session, not once per turn. A dependency tree that takes two minutes to resolve is paid for a single time and then slept on.
- Real test runs. Databases, browsers, and services run alongside the code, because root and a real kernel let them.
- Safe by construction. Model-written commands run inside a boundary the processor enforces, so a destructive command destroys only that machine.
- Cheap between turns. A session that waits three minutes for a human reply costs nothing while it waits.
execute
test
iterate
resume
manssino resume m-4b19
running in 0.22s · venv intact · repo at HEAD
pytest tests/test_invoice.py -x
1 failed, 42 passed in 3.1s
git apply fix.patch && pytest -x
43 passed in 3.4s
manssino sleep m-4b19
state kept · meter stopped
Shape
Two to four cores, four to eight gigabytes, twenty gigabytes of disk for most repositories.
Mapping
One machine per agent session, resumed on the first tool call of a turn and slept on the last.
Why it wins
The environment becomes part of the session state rather than something rebuilt from the transcript.
manssino create --vcpu 8 --memory 32 --disk 500 --gpu
m-9c1b live in 0.24s · gpu attached
nohup python train.py --ckpt /data/ckpt &
epoch 4/40 · loss 1.284 · 2h11m elapsed
manssino sleep m-9c1b
snapshot taken mid-epoch
manssino resume m-9c1b
epoch 4/40 continues · dataset still local
Dataset locality
A corpus staged on local disk stays staged. There is no repeated transfer at the start of every run.
Checkpoint safety
Checkpoints live on the persistent disk, so a sleep, a resume, or a restart never costs you an epoch.
02 ML training and fine-tuning
Long runs that survive the night.
Training is the workload sandboxes were never built for. It wants a GPU, a large disk, a compiled CUDA environment, and hours of uninterrupted time. On MANSSINO you request that shape once, build the environment once, and keep it. Sleep between sessions, resume in a quarter second, and find the dataset, the driver, and the process table exactly where you left them.
- Accelerated shapes. GPU and CUDA available from first boot, with drivers already loaded.
- Big local storage. Up to a terabyte of persistent disk for datasets, checkpoints, and compiled wheels.
- No rebuild tax. The slowest part of a training setup is the setup, and it happens once.
- Idle hours are free. A machine that sleeps between experiments is not billed for the gap.
gpu
cuda
large disk
checkpoints
03 Browser automation and scraping
Crawls that resume where they paused.
Headless browsers are heavy, stateful, and unhappy inside thin runtimes. A machine gives them what they want: a real network stack, a real filesystem for profiles and caches, and enough memory to keep a browser pool alive. Pause a crawl mid-flight, sleep the machine, and resume to find the same sessions, the same cookies, and the same queue position.
- Browsers install normally. Playwright, Chromium, and their system dependencies install once with apt and stay installed.
- Session continuity. Cookies, local storage, and logged-in profiles persist across runs instead of being rebuilt each batch.
- No warm-up per batch. The browser pool comes back with the memory snapshot rather than starting cold.
- Isolation per target. One machine per job keeps a messy page from touching anything else you run.
playwright
profiles
queues
resume
npx playwright install --with-deps chromium
chromium and system deps installed
node crawl.js --resume --profile ~/.profiles/acct-7
queue 14,208 remaining · session restored
manssino sleep m-21d8
manssino resume m-21d8
queue 14,208 remaining · same session
Shape
Four cores and eight gigabytes handles a browser pool comfortably.
Mapping
One machine per account, per region, or per target site, labelled so the fleet stays readable.
Why it wins
Browser state is the expensive part of scraping, and it is the part everything else throws away.
Pipeline economics
active onlyQueue time
A resume is faster than a scheduler decision, so runners stop being the bottleneck.
Cache
Package caches, build artefacts, and Docker layers live on the disk and survive between commits.
Idle runners
Sleeping between commits costs nothing, which removes the reason to hold warm capacity.
Isolation
Each job gets a dedicated kernel, so one pipeline cannot poison another.
250ms
Runner start
$0idle
Between commits
04 Pipelines and build farms
A clean machine per job, in milliseconds.
Continuous integration has always traded isolation against speed. Shared runners are fast and dirty, fresh containers are clean and slow, and both of them reinstall the world on every run. A persistent machine with a sub-250ms resume gives you the clean boundary and the warm cache at the same time.
- Root in every job. Install system packages, mount loop devices, and run the daemon your build actually needs.
- Warm caches, cold boundary. The disk keeps your caches, the kernel keeps jobs apart.
- Burst without pre-warming. Wake fifty sleeping machines at once instead of keeping fifty idle runners paid for.
- Reproducible by machine. Pin a machine per branch or per release train so a failure is reproducible on the box that produced it.
isolated
fast boot
warm cache
05 Fleet patterns
Four shapes of fleet that keep showing up.
Machines are cheap to create and free to keep asleep, which changes how you map work onto them. These are the patterns teams settle into after the first week.
02
Warm pool
Keep a set of sleeping machines in the shapes you use. Allocation becomes a resume, and the pool costs nothing while it waits.
03
Machine per tenant
Pin a machine to a customer, a branch, or a dataset. State accumulates where it belongs and never leaks sideways.
04
Fan out and collect
Wake many machines for a parallel sweep, pull the results back, and sleep them all. Concurrency is a loop, not a capacity plan.
06 Is it a fit
An honest read on where this belongs.
A persistent machine is the right tool for stateful, privileged, long-running work. It is not the right tool for everything, and pretending otherwise would waste your time.
| If your workload | Then |
|---|---|
| Rebuilds the same environment on every call | A strong fit. The rebuild becomes a one-time cost. |
| Runs code written by a model | A strong fit. Hardware isolation is the boundary you want. |
| Needs root, devices, GPUs, or Docker | A strong fit. These are ordinary on a real machine. |
| Runs for hours and checkpoints to disk | A strong fit. Sleep and resume cost nothing in between. |
| Is a stateless function returning in milliseconds | A serverless function is simpler and probably cheaper. |
| Is a public web service under constant load | A conventional autoscaled deployment fits better than a fleet of machines. |
Waitlist open
Tell us which one you are building.
Describe the workload and the concurrency you expect. We will match a shape to it and get a machine into your hands.
- Shapes sized per machine, including GPU-backed boxes.
- Resume in under 250ms, however large the fleet.
- Root inside, hardware isolation outside.
- Nothing billed while a machine sleeps.