How We Made Cloud Coding Agents Start in Milliseconds

Starting a coding agent in the cloud shouldn't mean waiting for a VM to boot, repositories to clone, and integrations to initialize. With Tembo, a prepared environment is already waiting, so the agent starts the moment you press Enter.

We started by speeding up snapshot restores, then moved the rest of the setup ahead of the request. Here's the result next to other cloud agents.

Tembo vs. other cloud agents

We gave Tembo, Devin, and Cursor the same prompt and timed each from the moment we pressed Enter.

Tembo

Agent started0.00s

First reply1.67s

App running2.20s

Devin

Agent started0.00s

First reply4.25s

App running26.88s

Cursor

Agent started0.00s

First reply5.83s

App running61.25s

Every agent replies within a few seconds. The difference is what comes next: the app still has to start. That took about 20 more seconds in Devin and nearly a minute in Cursor. In Tembo, it was already running, because the environment was prepared before we pressed Enter. A responding agent isn't a ready environment.

Here's how that works.

A running VM isn't a ready agent

Project snapshots already handle much of the expensive setup. We pre-clone repositories, install dependencies and skills, and run project setup scripts before capturing the environment, so restoring a snapshot doesn't repeat that work.

But a snapshot only captures what was true when it was built. Before the agent can start, there's still work left:

Fetch new commitsAnything pushed since the snapshot was built

Refresh credentialsGit and integration tokens expire

Configure MCP serversTo match today's selection, not build time

Start the agent runtimeFor the harness and model you picked

That work has a variable cost. One project needs a quick fetch for a single repository; another has several repositories to refresh, integrations to authenticate, and MCP servers to configure. Making restores faster only shortens one part of that sequence.

Snapshot restore time and environment readiness time are two different measurements.

A sub-second restore followed by seconds of setup is still a several-second wait.

Move the work ahead of the request

Most of that setup is predictable before you send a message. If we know the project, we already know which repositories to prepare, which snapshot to use, how large the sandbox should be, and which integrations, MCP servers, and skills to configure.

Your next instruction is unknown. The environment the agent will handle it in usually isn't.

So instead of racing to initialize everything after a request arrives, we do that work ahead of time:

ProjectDescribes the repos, setup, and sizes you need

SnapshotMakes that environment cheap to reproduce

Warm poolBoots and fully prepares it before you ask

Your sessionClaims it and starts in milliseconds

A prepared warm-pool VM isn't just running. Its repositories, integrations, and agent runtime are already initialized. When a matching environment is ready, Tembo reserves it for your session and hands your instruction to the agent already waiting inside. Nothing boots and nothing installs, which is why the handoff takes milliseconds. Projects define what gets prepared.

Keeping the pool ready

Preparing an environment early only helps if it's still ready when someone needs it. A session can take the last available machine, and repositories, credentials, or project settings can change underneath a waiting environment.

ClaimA session takes a ready environment

ReplenishA replacement starts preparing in the background

ReconcileOut-of-date environments are replaced when the project changes

Tembo keeps one ready environment per configured size, subject to capacity.

Changes trigger reconciliation, and periodic checks catch missed events or unhealthy machines. Before handing an environment to a session, Tembo checks that its preparation still matches the request. Repository updates are batched to avoid constantly rebuilding the pool, so a brand-new commit may take a moment to reach a waiting environment.

You never wait for the replacement. If a burst empties the pool before replacements are ready, sessions fall back to the ordinary startup path.

The fastest initialization is the one you don't wait for

We started with a seemingly simple question: how quickly can we restore a VM? That work mattered, but looking at the whole path to a ready agent changed the question:

How much of this work needs to happen after you arrive at all?

For a prepared session, almost none. Projects tell us what to prepare, snapshots give us a reusable starting point, warm pools do the work before demand arrives, and reconciliation keeps that capacity fresh.

Try warm pools in Tembo

Warm pools are available on Max plans. Enable warm pools in your project settings, and Tembo will prepare environments ahead of your next sessions.

Get Started · Read the Docs