Agent autonomy is a timeout setting, not a capability

GitHub put a 59-minute ceiling on one coding-agent session. Replit advertised runs of up to 200 minutes. Vercel made a sandbox that can stay alive for 24 hours. Put those three numbers in a comparison table and Vercel appears to have built an agent roughly seven times more autonomous than Replit’s.

It has not. One number limits a GitHub Actions job, one packages an agent with its own testing loop, and one rents isolated compute. The advertised autonomy number is a product envelope, not a capability score. Longer runtime can mean more useful work. It can just as easily mean a larger change arriving later, when the evidence is colder and the review is harder.

Fifty-nine minutes measures a GitHub session

GitHub’s coding-agent documentation, in its August 13 version, set a hard 59-minute maximum. The task stays inside one repository, works on one branch and can open one pull request. A workflow can choose a shorter timeout, but not a longer one.

The accounting makes the boundary clearer. GitHub’s July 2025 pricing change made one session consume one premium request, while GitHub Actions minutes still varied with execution time. “Session” is therefore an orchestration and billing unit as well as a user experience. Nothing about 59 minutes establishes how much planning, correction or verified change the model can produce inside it.

This is not a criticism of the cap. A forced stop can be useful. It bounds spend and the amount of work that returns for review. The mistake is putting that boundary in a model-capability column.

Two hundred minutes includes a verification design

Replit’s Agent 3 launch made the stronger product claim: the agent could operate for up to 200 minutes, building, testing and fixing its own work. The important part is not the extra 141 minutes. It is the test loop.

Replit later described an automated self-testing system that separates testing from the main build context and combines programmatic checks with interaction through the running application. That is a substantive attempt to prevent a long session from merely compounding plausible-looking errors. It is also vendor-reported architecture, not an independent benchmark showing that a 200-minute run produces more accepted software than a 59-minute run.

I would still rather evaluate the verification design than the stopwatch. A forty-minute agent that gives me a small diff, passing checks and a precise failure report may be more autonomous in practice than a three-hour agent that hands me a working-looking application and an afternoon of reconstruction.

Twenty-four hours measures the room, not the worker

Vercel’s June release let Pro and Enterprise customers run a Sandbox for up to 24 uninterrupted hours, up from five. Vercel explicitly positioned that window for long data processing, end-to-end tests and agentic workflows.

That is useful infrastructure. It is not evidence that an agent reasons productively for 24 hours. A sandbox is the room in which a worker operates: isolation, compute and a maximum lifetime. It says nothing by itself about whether the worker keeps a coherent plan, notices a broken assumption, stops on a dangerous action or leaves evidence another engineer can audit.

The distinction matters because generated work moves cost downstream. I have already argued that generated code shifts the bottleneck into review and testing. Extending a run without redesigning those queues does not remove the bottleneck. It batches more inventory in front of it.

Measure the review interval instead

The metric I would put in a vendor matrix is verified change per review interval: how much accepted work arrives before a human needs to reconstruct what happened. Runtime is one input to that measure, not the result.

Run the same bounded task at 30, 60 and 120 minutes. For each run, record accepted changes, checks passed, human interventions, review minutes, rollback effort and defects found after review. Keep the model, repository and acceptance test fixed. This is a proposed evaluation, not a benchmark I have run against these products, but it would make the trade visible.

rendering diagram…

If accepted change rises while review time stays flat, the longer window earned its keep. If the diff gets larger but review time and reversals rise faster, the autonomy number is deferred review debt. That is the same ownership problem behind giving agent-built applications an owner and an expiry date: unattended creation is cheap; accountable maintenance is not.

A long run needs controls inside the run

The 30-second Prompt of the Day produced on August 13 focuses on the fallback reviewer. It draws on an Anthropic-controlled study in which paid testers caught 143 of 1,053 planted harmful requests, while the vendor’s classifier blocked 937. Those are controlled vendor-study results, not a measured rate for production engineering teams.

The clip is a companion, not proof of the runtime comparison. Its useful point is narrower: controls have to operate while the agent is working. A human review at minute 200 cannot retroactively prevent a destructive action at minute twelve. Put deny rules, budget limits, test gates, scoped credentials and stop conditions inside the session; keep the human for ambiguity and consequence.

Ask vendors for the maximum runtime, certainly. Then ask the questions the larger number avoids: what evidence accumulates during the run, which actions are impossible, what stops a failing loop, and how long does a reviewer need to accept or reverse the result? Buy the longest window only when it improves those answers.

Autonomy is not how long an agent can stay busy; it is how much verified work it can return before review becomes archaeology.