frembench — dev benches

frembench is a Linux machine you rent by the minute and reach from your browser — a dev bench. It carries the same language toolchain your CI runners do, so something that builds on a bench builds in CI.

What it costs

A bench seat is €39 per month and includes 200 hours of runtime. Beyond the pool it is €0,20 per hour, and the total is capped outright — so your bill can never exceed €99 per bench seat in a month, however hard you run them. On a single seat the cap binds at 500 hours of runtime; past that the bench keeps running at no further charge. Every figure here is in EUR, which is what benches are charged in — as is the rest of your subscription.

Hours pool across bench seats, the same way CI minutes do. The allowance is 200 hours × seats, measured against everything your organisation’s benches ran, so two seats share 400 hours: one busy bench draws on a quieter colleague’s allowance rather than going straight into overage. The ceiling pools with it — the cap is €99 per bench seat, not per machine, so a single bench in a two-seat org can account for more than €99 while the org stays inside €198.

Two details worth knowing, because they change what you actually pay:

• Time is measured in seconds and rounded once, at the end of the period. A bench suspends after 30 minutes idle and wakes when you attach, so a working day is many short intervals. Rounding each one up to a minute would bill twenty ten-second wakes as twenty minutes — charging you for our own suspend optimisation.
• 200 hours is far more than a working month of attached time. The pool is sized against wall-clock time a bench is awake, not hours you spend at the keyboard; an agent left running a long job counts, an idle editor does not.

Seats are prorated when you add or remove them, like any other seat. See the pricing page for how it sits beside the rest of the plan.

You do not manage it. It wakes when you attach, and suspends itself when nobody is attached and nothing is running.

What survives, and what does not

This is the one thing worth understanding before you use a bench, because it shapes everything else.

Your bench has two disks. The profile volume is yours and persists. The boot disk is rebuilt from a fresh image on every wake, which is how you get patched without a maintenance window and without ever being asked to reboot.

$HOME is on the profile volume. So:

apt is the deliberate exception: system packages are what the image is for. If you need one every morning, it belongs in the image — open an issue rather than scripting it into your shell profile, and the weekly rebuild stops it being your problem.

Running an agent

Codex and opencode are pre-installed. Both are open-source licensed, so we ship them.

Claude Code is not pre-installed, and the reason is a licence rather than an oversight: its terms are not an open-source licence, and this is a product we sell, so shipping it would be redistributing proprietary software. It is one command, under your own Anthropic agreement:

frembench-install-claude-code
claude

It resolves from our in-VPC mirror like everything else, so using it does not reach registry.npmjs.org. You only do this once — the install and the sign-in are on your profile volume.

Running more than one thing at once

Your bench terminal is not a bare shell — it attaches to a tmux session called frembench:

tmux new-session -A -s frembench

That is what makes an agent survive a closed laptop, and it is also how you run several at once. The prefix key is the stock Ctrl-b, and the mouse is enabled.

A second browser tab mirrors; it does not fork. Every attach goes to the same frembench session, so two tabs show the same window and will fight over it. Use windows and panes for parallel work, not more tabs.

If you do want two tabs showing different things, give the second one its own view of the same windows:

Ctrl-b :  new-session -t frembench -s second
Ctrl-b :  switch-client -t second

-t frembench groups the new session with the original, so both see the same window list but each can sit on a different window. A freshly opened tab always lands on frembench, so you re-issue switch-client per tab.

Two details that surprise people:

• A new window is a plain login shell. ~/.frembench/startup runs only when the session is first created, so it does not re-run per window.
• Different-sized tabs do not shrink each other. aggressive-resize is on, so a window is sized to the client actually looking at it rather than to the smallest one attached.

Opening a dev server in your browser

A bench has no inbound network path. Nothing on the internet can reach it, and that is not a limitation we plan to remove — it is why the attach surface is defensible.

Dev servers still work. Start one as you normally would:

npm run dev

Within a few seconds the port appears under Open in browser on the terminal page. Click it. The connection travels outbound over the same channel as your terminal; no port is exposed and no tunnel binary is involved.

Some things to know:

• Only ports your bench is actually listening on are offered. You cannot ask for an arbitrary port, and neither can anything else holding a link.
• A server bound only to the bench’s private address is not listed, because a forward to it would fail. Bind to localhost or 0.0.0.0.
• SSH is never offered. Use the terminal.
• Hot reload works. A forwarded page is served from your bench’s own origin, and a WebSocket opened from that origin is carried too — which is what a dev server’s live-reload channel needs. This note previously said it did not work; that was written before the per-bench origin existed and stayed here after it arrived.

This is also how you reach an agent web UI such as OpenChamber. It is installed on every bench, so there is nothing to set up: start it and open its port. Do not run openchamber tunnel — that is a Cloudflare tunnel, and the forward above is both the sovereign path and the one that already authenticates you.

Suspend, wake, and what you are charged for

You are charged for the minutes your bench is awake. A suspended bench costs only its profile volume, so what keeps it awake is worth knowing precisely.

What keeps it awake

Your bench stays up while any of these is true:

• Someone is attached — a browser tab or an SSH session actually connected.
• An agent is working. Not merely running: see below.
• You pinned it, from the bench page.

When none of them holds, the bench suspends after 30 minutes.

What “an agent is working” means

An agent sitting at a prompt is not working, and this is the distinction that decides your bill. A Claude session left open overnight looks busy by every naive measure — it still ticks along using about 1% of a CPU — so we do not use CPU on its own to decide.

An agent counts as working when either is true:

• it has written to its own session history in the last 10 minutes, or
• it or anything it started is using at least 10% of a CPU core.

The second exists for long tool calls. If your agent kicks off a thirty-minute build, it writes nothing for thirty minutes while it waits — but the compiler it started is busy, so the bench stays up.

So a genuinely idle agent stops holding your bench about 10 minutes after its last activity, and the bench suspends about 30 minutes after that: roughly 40 minutes from your last interaction, if nothing else is holding it.

The one case you have to tell us about

A long job you started yourself — not through an agent — does not keep the bench awake. A make -j, a data import, a soak test: if you start it in a shell and close your laptop, the bench will suspend under it.

That is deliberate. If any busy process kept a machine awake, an idle bench could be kept billing forever by anything at all, and the cheapest thing to run on somebody else’s machine is a crypto-miner. So the rule is that we only count work we can attribute to an agent, and everything else is your call: pin the bench, and unpin it when the job is done.

Staying attached also works, since an attached client is itself a hold.

Waking is automatic — attach and it comes back. Your files are where you left them, and your terminal layout comes back with them: the windows you had open are recreated in the same directories, and Claude, Codex, opencode and OpenChamber are relaunched — each resumed into the session it was in, waiting at a prompt. Nothing is replayed for you; an agent does not act while you are away.

Two things do not come back. A session started without a resumable id returns as a fresh one in the right directory, and any other long-running process — your own dev server, a build — is not restarted. Declare it in ~/.frembench/restore-commands.txt, one command name per line, if you want it to be.

Pin a bench when you have a long job that our tracking would not see, from the bench page. A pin is not permanent: a bench that has gone too long without a rebuild is patched regardless, because an unpatched machine on the internet is not something a pin should be able to buy.

Getting one

Dev benches are enabled per tenant. If your org has them, the page is under Settings → Dev benches; if not, that page will say so. Your org admin sets how many benches your tenant may run at once.

One bench per organisation

A bench belongs to an organisation, not to you. If you are a member of several organisations that have bench seats, you get one bench in each — separate machines, separate profiles, billed separately to the organisation that granted the seat. You cannot create a bench in an organisation that has not bought seats, so no organisation can be charged for a machine it did not agree to.

Profiles do not follow you between organisations. Each bench has its own profile volume, so the tools, shell configuration and credentials you install on one bench do not exist on a bench in a different organisation. Set up each one you use.

This is a consequence of the tenancy boundary rather than a limitation we plan to remove: a shared profile would mean one organisation paying to store another organisation’s work, and would carry files across a boundary customers rely on.

Benches suspend independently after thirty minutes idle, so holding benches in several organisations does not keep several machines running — only the one you are actually using stays awake.

Why Claude Code is not pre-installed

The bench image ships codex (Apache-2.0) and opencode (MIT) ready to use. Claude Code is not pre-installed, and that is a licensing decision rather than an oversight: its licence is not open source, and frembench is a product we sell. Shipping it inside our image would redistribute it as part of something we charge for.

Installing it yourself is one command, and it then runs under your Anthropic agreement rather than ours — which is also why it survives a suspend: your profile volume keeps it, so you install it once per bench.

This is the same rule applied everywhere in the product: dependencies we ship are sovereign, current, and fully open-source licensed. Anything that fails that test is something you bring, not something we bundle.