OpenAI Published Its Playbook for Handing Codex a Multi-Hour Job. The Part It Underplays Is the Two Bills You'll Get.
On June 22, OpenAI published guidance on doing long-running work with Codex: the kind of multi-hour, multi-step task where you hand the agent a goal and let it grind. The advice is solid and, notably, not hype: treat Codex as a persistent workspace that holds context across a long job, break ambitious goals into verifiable steps, and be deliberate about when to delegate to the agent versus when a human should stay in the loop.
I want to take that advice seriously, because it's good. But the guidance is written by the company that bills you for the tokens, and there are two costs of long-running autonomy that it understandably underplays. A solo operator has to price both before handing Codex a four-hour task.
What the guidance gets right
Start with the part I agree with, because it's the load-bearing insight. OpenAI's own framing tells you to decompose a big goal into verifiable steps and to keep human judgment in the loop at the right moments. That's the company that profits from autonomy telling you not to run fully autonomous. Worth noticing.
The persistent-workspace idea is genuinely useful too. The reason long tasks fail with agents usually isn't that the model can't do any single step. It's that context gets lost between steps, the agent forgets what it already decided, and it drifts. A workspace that preserves state across a long job directly attacks that failure mode. If you've ever watched an agent re-solve a problem it solved twenty minutes ago, you know why this matters.
So the guidance is right. The question it doesn't answer for you is whether the task in front of you is shaped to pay back the cost. And there are two costs.
Bill #1: tokens don't scale on a line
The obvious cost is the token bill, and the trap is assuming it scales with the size of the output. It doesn't. A long-running autonomous run scales with how much the agent wanders: every step it takes, every file it re-reads, every dead end it explores and backs out of, every time it reloads context to remember where it was. A task that produces 200 lines of final code might burn through a transcript many times that length getting there.
This is the part that ruins a month if you're not watching. A bounded task with a tight spec keeps the agent on a short path, and the bill is predictable. A fuzzy task ("improve the performance of this module," "clean up the test suite") invites the agent to roam, and roaming is where the curve bends up. You don't find out until the invoice arrives, because the wandering happened while you were doing something else, which was the whole point of delegating it.
The rule I'd anchor on: the cost of a long-running run is roughly proportional to how under-specified the task is. Specification is the throttle. The tighter you scope it, the flatter the curve.
Bill #2: the verification tax
The second cost is the one almost nobody prices, and in 2026 it's the bigger one. The bottleneck in AI-assisted development this year stopped being generation speed and became verification capacity. Agents can produce more code, faster, than experienced developers can review well. That gap is the actual constraint on shipping, and a multi-hour autonomous run makes it worse, not better.
Here's the math that matters. A four-hour Codex run can produce more review surface than you can clear in four hours. If the agent touched thirty files across a long, meandering session, you now own the job of understanding and trusting all of it before any of it ships. The time you "saved" by delegating gets handed straight back as review time, and review is slower and more cognitively expensive than writing, because you have to reconstruct intent you didn't form yourself.
This is why OpenAI's "break it into verifiable steps" line is the most important sentence in the guidance, and why I'd follow it further than the guidance does. A step is only worth delegating if you can cheaply check it was done right. If verifying the output costs nearly as much as doing the work, the agent didn't save you anything. It just moved your effort from your hands to your eyes and added an integration risk.
The honest read on when long-running Codex is worth it
So here's my actual position, and it's a take, not a hedge. Long-running autonomous Codex is worth it for work that is bounded, well-specified, and cheaply verifiable: a migration with a clear before-and-after, a mechanical refactor you can confirm with a test suite, generating boilerplate against a spec you can diff. In those cases the persistent workspace earns its keep and the verification tax is low because correctness is checkable at a glance.
It's a trap for fuzzy, open-ended, hard-to-verify work: the "make this better" tasks where you can't cheaply tell whether the agent succeeded. That's exactly the work people are most tempted to throw at a long autonomous run, because it's the work they least want to do themselves, and it's exactly the work where the token curve bends up and the review burden explodes. The temptation and the trap point the same direction.
Most solo work, honestly, isn't shaped right for a multi-hour autonomous run yet. Not because the tooling is bad (Codex is good), but because most of what a solo operator does day to day is the fuzzy kind, and the fuzzy kind is where this goes wrong.
What I'd actually do
Before you hand Codex a long-running job, run it through two questions. Can I write the spec tightly enough that there's a clear right answer? And can I verify the result for less effort than doing it myself? If both are yes, delegate it and let the persistent workspace do its thing. This is exactly what it's for. If either is no, don't start a four-hour run; break off the bounded, checkable piece and keep the fuzzy part in your own hands where your judgment is the cheap resource.
And put a budget alert on it regardless. The single best protection against the token curve is a hard cap that pings you before "I delegated this" becomes "I have a bill I didn't model." OpenAI gave you a good playbook. The two costs it underplays are yours to manage, and managing them is the whole skill.
Author
Lukas
@lukcombinator