Time to feedback: the delay that matters for coding agents

What one step of the loop is#

A coding agent works in steps. The model reads the code and decides on a change, the agent applies it, and then it runs a check to learn whether the change worked. The check is whatever your project uses to tell right from wrong: a type-check, a build, a test file or a linter. Its output goes back to the model, which plans the next edit.

Reading and deciding belong to the model. Applying the edit and running the check happen in the environment, and that half is what your infrastructure decides. Promigence's own site states the belief behind this post plainly: time to feedback is the delay that matters in an agent loop, and cold start is a small part of it.

The arithmetic#

Here is a worked example. The step count and the slow check time are example inputs, so put in your own; the other figures are measured numbers from the Promigence home page.

One task, 40 edit-then-check steps (example count)

Measured step, warm repository:   40 × 0.66 s  = 26.4 s
Example slow check:               40 × 30 s    = 1,200 s, or 20 minutes
Sandbox ready, paid once:         8 ms         = 0.008 s

The measured step is an edit followed by a type-check on a warm repository, with 4 vCPU: 0.66 s at the median, 0.80 s under load (n = 30). The ready time is from create to first command at 2 vCPU / 4 GiB: 8 ms at the median, unloaded (n = 100).

Put those side by side. At the measured step time, 40 steps spend 26.4 seconds in the environment, and the start is about 0.03% of that. At 30 seconds a check, the same task waits 20 minutes on checks. No start time gets that back.

The model's own thinking time comes on top in both cases. It does not change with the environment, which is why the environment's half of the step is the part worth working on.

The home page also times a whole task: 20 steps on a 3 GB repository, 43.7 s at the median, 58.0 s under load (n = 30).

Why the loop gets slow#

From where you sit, a slow check usually has one of a few causes.

Setup is inside the loop. If the environment does not already have the project installed and built, the first check pays for the install and the build. If every step gets a fresh environment, every check pays it.

The check runs somewhere else. An agent that pushes a branch and waits for a CI run, or copies the repository to another machine to test it, pays the queue and the transfer on every step.

The check does more than the step needs. Running the whole suite after a one-line change is slower than running the tests that cover it, and that part is yours to tune whatever environment you use.

What keeps the loop short#

Start the agent on a project that is already installed and checked. Build a snapshot once: your repository at a pinned commit, the install and the build as setup steps, and your own test command as the verify step. A snapshot whose verify command fails is never stored, so an agent never starts on a broken environment. Every sandbox started from a good snapshot opens with that work done, and the agent's first check runs against a project that is ready.

Run the check where the code is. The agent edits files in the sandbox and runs the check in the same sandbox, on the same files, with no push and no queue in between. From the command line that is promigence exec --sandbox <id> -- <your check command>, and the SDKs have the same call.

Keep one sandbox for the whole task. A fresh environment per step brings setup back into the loop. If the task waits on a person between sessions, pause the sandbox: paused time is not billed, and waking a paused sandbox took 104 ms at the median from resume to the first database query (n = 100), 127 ms under load.

Size it for the check. The measured step above ran on 4 vCPU, and a new account can use sizes up to large, with 8 vCPU.

How to measure your own#

Time the edit-then-check step where the agent runs it, enough times to get a median:

# in the environment your agent uses: one small edit, then your check, 20 times
TIMEFORMAT=%R
for i in $(seq 1 20); do
  { time sh -c '<apply one small edit> && <your check command>' >/dev/null 2>&1 ; } 2>&1
done | sort -n

With 20 sorted times, the median sits between the 10th and the 11th line. Then do three more things with it.

Measure the first check apart from the rest. A first check far slower than the others means setup is leaking into the loop.

If your agent drives the environment over the network, time the step from the agent's side too. Each call adds your network's round trip, and the agent feels that as part of the step.

Count the steps in a real task from your agent's logs and multiply. That product is your time to feedback per task. Put the start time you were worried about next to it.

To try the same loop on Promigence, build a snapshot of your project, start one sandbox from it, and run the loop above inside it with promigence exec. The quickstart covers the snapshot, and running a coding agent in a sandbox covers the agent. To get started, leave your work email on www.promigence.ai or write to support@promigence.ai.

Sources#

Every page below was read on 19 Oct 2026. The 40 steps and the 30-second check are example inputs chosen for the arithmetic, not measurements.

Updated 2026-10-19