Price Your Weekend Agent's Overnight Run

You close the laptop, and the agent keeps working. Before you let it, price the night: compute, model spend, maximum runtime, and the stop condition that ends it. Most side projects stay side projects, and that is fine. The ones that become businesses usually have a boring answer to the cost question.

The sandbox price is the first stop condition

Docker introduced Cloud Sandboxes on September 24 at the WeAreDevelopers conference, extending its local sandbox product to Docker-managed compute so coding agents can keep working after the laptop goes to sleep. Docker's cloud sandbox billing is pay-as-you-go and measured by the second, with hourly rates from $0.07 for a 1 vCPU/2 GB Micro shape to $1.12 for a 16 vCPU/32 GB XL shape. The default Small shape has 2 vCPUs and 4 GiB of memory and costs $0.14 per hour.

A paused sandbox costs nothing. A waiting agent should not run the meter. Sessions default to one hour, can be configured for up to 24 hours, and Docker stops or deletes them after the configured runtime expires. New accounts receive $250 in limited-period free credit, enough to run the default sandbox size for more than 1,000 hours. The credit makes the first experiment cheap, but it is not a business model.

You can use a custom model key and an existing provider; Docker bills model inference through that provider, while volumes, egress, public images, and Docker Kits are free. The sandbox needs sbx 0.45.1 or later and a pay-as-you-go plan on a Docker Personal or Pro account.

The sandbox is the part you can price before the agent starts. The model bill can surprise you. Runtime can turn a test into a month of small charges. Name each one, and you stop guessing. Treat an overnight run as compute, model calls, and a deadline. The price should be a stop condition, not a hope.

Choose the size that finishes the job without leaving the machine idle for most of the night. The spread is wide enough to change the answer. If the agent waits for a step, a human, or a queue, pause the sandbox and stop the charge.

The checklist turns an overnight run into a price

The go/no-go test stays short. Compute is the easy number. Token spend is the one that can outgrow it, especially when the agent retries, explains, or loops. Answer each item, or the agent does not get the night.

Compute cost: Multiply the hourly rate by the longest run you will allow, and confirm the number fits your weekend budget.
Token cost: Put a cap on model tokens or spend, and check that the provider bill will not outgrow the sandbox bill.
Maximum runtime: Set a hard stop before the session can run all night, and confirm the stop actually fires.
Pause/stop behavior: Confirm pause and stop behavior in your provider settings before a run.
Maintenance burden: Name the person who will fix a broken run, and make sure that person is you on a weekend.
Value: Write the customer or user benefit in a short line, and decide whether it pays for the recurring run.

If any answer is vague, the run stays a test. The next question is whether the continuing cost is worth the value.

The recurring cost is the real business test

A weekend build can stay a weekend build. Once you can name the cost, the stop, and the value, it can become a business without becoming a bill. Cheap runs with vague benefits stay toys. Real benefits with solo maintenance turn into jobs. Clear cost and clear value create a small business with a known cost. Start small and keep the runtime short. Increase only when the value is proven. The agent should earn the next night, not inherit it.

Before a paid night, write the price down. Include compute, model spend, and the time you will spend watching it. If a number makes you flinch, shrink the run. When the number is small, ask what the output is worth. Businesses need a repeatable answer, not a surprise.

Answer the checklist quickly, or do not let the agent run overnight.