Article
Attention Is the Scarce Resource
What OpenAI’s Persistent mode for Codex shows about the cost of running an agent.
WIRED reports that OpenAI is testing a version of Codex that continues working until it is put to sleep. Code reviewed by WIRED shows an agent that creates its own follow-up tasks, continues them across sessions, uses past interactions and knowledge of the user to choose what to work on next, and occasionally messages the user first. OpenAI confirmed the test and has no immediate launch planned.
The detail that matters most is where the setting lives. Persistent mode appears in Codex’s reasoning-effort menu, among the levels that decide how much computing power, how many tokens, and how much time a model may spend before it answers. The other settings stop after minutes or hours, whether the work is finished or not. Persistent mode runs until someone puts it to sleep.
Persistence, in that design, is delivered as more inference.
The demand behind it is real. Software work should continue after a developer closes the browser or leaves for the night. The open question is what the customer is paying for when it does.
What the customer is paying for
Agentic systems return results on an unpredictable schedule and report success and failure in the same composed voice. Someone has to stay present to check what arrived, restore the context, judge whether it is right, and decide what happens next. That is the real bill. The cost of inference falls every year. The operator’s hours do not, and they are the constraint. A system that generates quickly while its operator absorbs a continuous attention burden has added a productivity tool rather than capacity.
More inference can enlarge that burden rather than reduce it. An agent that runs through the night and creates its own follow-up work produces more output to review, arriving on a less predictable schedule, from a chain of decisions nobody was present for.
The constraint on agentic software work is the attention it takes to keep it moving.
What a remote worker returns
Tapestry is a remote worker. The customer provides the mission, Tapestry executes it without supervision, and evidence guides the work.
The first persona is the Python Developer. Executives, project managers, architects, and others who set direction provide requirements, objectives, constraints, and priorities. Tapestry does the engineering and hands back a reviewable result.
The Python Developer takes requirements and requests and returns pull requests for review.
A person reviews the result rather than the process. A pull request arrives at a defined point and is reviewed once. Supervision has no defined point; it lasts as long as the work runs.
Tapestry supplies the continuity a supervisor would otherwise provide. The pull request that reaches the customer has already been built, tested in isolation, and cleared by the Regulator for release. Five core elements carry that work as one system: the Knowledge Engine, the Actor, the Motivator, Engram, and the Regulator.
Persistence and consistency
Language model output is improving quickly. It also remains variable. The same model can produce an excellent implementation in one run and a subtly flawed one in the next, understand the central requirement while missing a constraint, or solve a hard problem and then make a basic mistake in the code around it.
More time and more tokens buy more opportunity to reason. They also buy more opportunity to introduce assumptions, follow unproductive branches, and drift from the original requirement. An early misunderstanding can become the premise for hours of technically competent work aimed at the wrong target.
Tapestry measures progress in accepted work. When an attempt fails, Tapestry records the evidence, revises the work, and tests it again without anyone having to notice the failure. The requirement, the task state, and the evidence are kept outside any one inference, so each model invocation starts from the recorded state of the work instead of an expanding conversation.
The inference can end while the work remains.
What each design makes durable
| Customer question | Codex’s Persistent mode, as reported by WIRED | Tapestry |
|---|---|---|
| What persists? | The agent continues across sessions until put to sleep | The mission, task state, evidence, software artifacts, and release decisions |
| How is follow-up work created? | The agent creates tasks for itself | Follow-up work becomes a recorded task, scheduled when its dependencies are met |
| What informs the next work? | Past interactions and knowledge of the user | Current mission state, ready tasks, dependencies, evidence, and recorded failures |
| How is access bounded? | Persistence does not expand permission; external alterations require approval | Permission and policy are set for the engagement; every request arriving and every release leaving is evaluated at the Regulator against the mission, policy, scope, and permitted systems |
| What does the customer receive? | Proactive messages and work completed in the session | A pull request for review |
Beyond the dial
Persistent mode is the answer its architecture supports. When one agent holds the requirement, the plan, the implementation, and the judgment, continuity means keeping that agent running, and turning the dial up is the available move.
Tapestry puts the durable parts outside the model, and that changes where the customer’s attention goes. It is spent setting the mission, answering a decision-ready question when the work needs information or judgment outside it, and reviewing pull requests. The work between those points continues without anyone watching.
If you are evaluating an agent this year, measure the hours of attention it takes from the people responsible for it. That is the cost you pay every week, whatever the inference bill says.