Long-running agents need budget rails

OpenAI's long-horizon Codex post has the kind of number that eats the room: a blank repo, one design-tool spec, about 25 hours of uninterrupted work, about 13 million tokens, and about 30,000 lines of code.

That is impressive. It is also the wrong number to optimize around.

I care less about whether the agent can keep going than about what tells it to stop, spend less, or hand the work back.

Sources: OpenAI's Codex long-horizon write-up and the METR paper OpenAI cites on measuring long tasks. I checked the Asha.News public feed and digest during the run; they did not have a specific owned story for this developer-tool topic.

Time horizon is now a product surface

OpenAI frames the shift clearly: coding agents are getting better at staying coherent over longer tasks. The Codex loop is familiar by now: plan, edit, run tools, observe logs, repair failures, update status, repeat.

That loop is not just an implementation detail. It is the product.

A short chat answer can be wrong and cheap. A 25-hour agent run can be wrong and expensive. It can also be half-right in a way that leaves you with 30,000 lines of plausible debt.

Longer horizon changes the UI requirement. The interface has to expose the run as a sequence of budgeted decisions, not a single magical progress bar.

A stop rule should be visible before the run starts

For a long-running agent, I want the launch screen to answer five things before I press go:

1. Maximum wall-clock time.
2. Maximum token or dollar spend.
3. Validation commands that must pass.
4. Conditions that force a pause.
5. The artifact I will review at the end.

The pause conditions matter most. If tests fail three times for the same reason, stop. If the diff crosses a file-count limit, stop. If the agent needs a credential, stop. If the plan changes shape, stop and ask for review.

Without that, autonomy becomes a tab you are afraid to look at.

Durable memory is good. Budget memory is better.

OpenAI's strongest practical advice is boring in the best way: keep the spec, plan, implementation instructions, and status in markdown files the agent can revisit. That reduces drift because the agent has something more stable than chat history.

I would add one more file: budget.md.

It should not be a finance spreadsheet. It should be a run contract:

Max runtime: 90 minutes
Max spend: $12
Stop after: 2 failed build repairs
Allowed scope: editor state + export path
Forbidden scope: auth, billing, deployment
Review artifact: PR plus run log

That file gives the agent a thing to obey and gives the reviewer a thing to inspect. If the agent blows through the boundary, the failure is not a vibe. It is a contract violation.

Receipts beat confidence

The Codex post emphasizes continuous verification: tests, lint, typecheck, build, and fixes after failed checks. That is the right instinct.

The next layer is the receipt.

A long run should end with a compact report that says:

• what changed;
• which commands ran;
• which checks failed before passing;
• what the agent deliberately skipped;
• where it exceeded or approached the budget.

This is where a lot of agent products still feel too theatrical. They show a beautiful transcript and make the user do accounting by hand.

I do not want a transcript as the primary artifact. I want a receipt I can scan in 30 seconds, then drill into when something smells off.

The uncomfortable part: agent work can be too cheap to notice

OpenAI's long-horizon post points to METR's time-horizon framing: frontier agents are getting better at tasks that take longer for humans to complete. The exact horizon estimates are model-dependent, so I would treat them as directional, not as clean productivity math.

The pattern still matters. People are learning to delegate bigger chunks.

That creates a strange product risk: an agent run can feel cheap at the moment of delegation and expensive at review time. The bill is not only tokens. It is review load, merge risk, bug surface, and the time spent untangling a run that went one step too far.

For long-horizon agents, budget rails are not procurement theater. They are UX.

My default long-run contract

If I were setting up a serious coding-agent workflow today, I would start with a small standard contract:

Plan first. No edits until the plan has acceptance checks.
Checkpoint every milestone. Run the checks before moving on.
Stop on repeated failure. Do not loop forever on the same error.
Keep a budget file. Runtime and spend are part of scope.
End with a receipt. Diff, checks, failures, skips, next human decision.

That does not make long-running agents safe by itself. It does make them inspectable.

A 25-hour agent run is a real signal. The next product race should not be who can run longest. It should be who makes the long run easiest to bound, review, and stop.