Vendor landscape · Scheduled re-entry

Two Vendors Just Shipped the Same Primitive — and Only One Put It in the Terminal

Independent convergence is the tell. Anthropic and OpenAI both schedule prompts, not executables. The surviving asymmetry is surface-specific: Claude Code’s /loop injects into a live terminal session; Codex CLI still has no Scheduled management interface.

Scott Farrell · LeverageAI · July 2026 · ~10 min · Documentary facts re-verified against live vendor docs on 2026-07-27

When two competitors, with different products and different incentives, independently ship the same operating-system-shaped idea, you are probably not looking at a fashion. You are looking at a constraint that both of them finally admitted in public.

The idea is simple enough to miss. A scheduler does not run a hard-coded script that knows your stack. It re-enters an established conversation with an instruction — “check the deploy,” “summarise progress,” “keep going until the definition of done is real” — and lets the agent decide which tools, files, and sub-agents the moment requires.

That inversion — scheduled instructions over scheduled executables — is the primitive. The question this piece answers is not “which vendor is smarter.” It is narrower and more useful:

Is in-session prompt scheduling a quirk you should refuse to depend on, or a primitive you can build on — and on which surface does it actually exist today?

Why “two vendors” is the evidence

One team shipping a clever slash command is a feature. Two teams, without any need for us to invent coordination stories, landing on the same shape is different. Independent convergence is the strongest signal short of a standard: demand is real enough that separate product organisations paid the implementation cost.

Both sides also moved the same conceptual direction. The interesting object is not a cron line that shells out to a fixed binary. It is a prompt — sometimes with optional skills — on a schedule. That sits in a broader drift toward agent software that spends tokens, uses tools, and iterates rather than merely replaying fixed workflows.

Long-running agent work already had a name for the problem class: the one-hour ceiling is architectural, not a model IQ limit, and multi-hour jobs need external liveness as well as durable state.

Field practice got there before the product pages did. An earlier LeverageAI line treated cron as the poor man’s orchestrator: externalise liveness so the model can stay relatively ephemeral while something outside it keeps poking the job.

So when the vendors arrive, the right reading is not “they invented supervision.” It is “the primitive left the workshop and showed up in two public manuals.”

Anthropic, as of the live docs

Claude Code’s scheduled-tasks page is no longer a changelog one-liner. It is a full delivery document. The opening definition is the claim that matters:

Use /loop and the cron scheduling tools to run prompts repeatedly, poll for status, or set one-time reminders within a Claude Code session.

That phrase — within a Claude Code session — is the architecture in five words. The page is explicit about scope:

Tasks are session-scoped: they live in the current conversation and stop when you start a new one.

Resumption is first-class for unexpired work: --resume or --continue brings back a recurring task created within the last seven days, or a one-shot whose fire time has not passed.

Anthropic also published the comparison table this piece has been waiting for. Three columns — Cloud, Desktop, /loop — and a row that should be framed and put on the wall:

Source: Claude Code “Run prompts on a schedule,” comparison table, retrieved 2026-07-27. Cloud and Desktop do not require an open session; /loop does — and inherits the live session’s MCP servers and permission posture.

Delivery semantics are equally concrete. A scheduled prompt fires between turns, not mid-response. There is no catch-up for missed fires: if the agent is busy, the prompt waits and fires once when idle — not once per skipped interval. Recurring tasks automatically expire seven days after creation. The whole scheduler can be disabled with CLAUDE_CODE_DISABLE_CRON=1.

None of that is poetry. It is a public description of an interrupt bus with known limits.

OpenAI, as of the live docs

OpenAI’s scheduled-tasks documentation (live URL: learn.chatgpt.com/docs/automations — older Codex URLs redirect here) starts from the same inversion. You schedule recurring background work and you can combine those tasks with skills for more complex jobs — instructions and packaged capability, not a hand-written shell pipeline as the unit of schedule.

Same-conversation continuation is no longer the missing half of the story. The docs distinguish standalone runs from in-chat schedules:

Use a scheduled task in a chat when you want ChatGPT to return to the same chat with its existing context.

The scheduled task uses the chat’s existing context instead of starting from a new prompt each time.

That kills an older, stale reading of the landscape: “OpenAI has the payload without the live session.” On the web and app surfaces, scheduled re-entry into a chat’s context is documented. Do not publish the dead version of that claim.

What you must keep carefully scoped is the worktree language. On the web surface, the page says scheduled tasks “don’t keep a local folder or worktree available between runs.” That sentence is about web runs. It is not a company-wide law. On the desktop surface, the same page says scheduled tasks can work with local projects and run in the project directory or an isolated worktree — with the machine powered on and the app running when local files are required.

Same conversation ≠ same process. Chat context continuity and local process/worktree continuity are different axes. Collapsing them into “OpenAI can’t do X” is how documentary pieces go stale mid-project.

And then the terminal sentence — still live, still load-bearing:

Codex CLI doesn’t provide the Scheduled management interface. Use ChatGPT web or the desktop app to create and manage scheduled tasks.

The IDE extension gets the same disclaimer. The CLI can help you prepare and test a prompt, skill, or script first — management of the schedule itself lives elsewhere.

The surface table, not the brand fight

Read both manuals together and the honest picture is not “Anthropic has scheduling; OpenAI does not.” Both ship scheduled re-entry. On both sides, cloud and desktop paths are designed to run work without an open interactive coding session (Anthropic’s table says Requires open session: No / No for Cloud and Desktop; OpenAI’s desktop path is background work with the app present for local files). The difference that still bites builders of supervised long jobs in a live terminal process is narrower:

That is the asymmetry this piece will defend: the one surface that documents scheduling into a live terminal session is Claude Code’s /loop; the Codex CLI documents that it does not provide the management interface at all.

It is also why “only one put it in the terminal” is a statement about what has shipped in public interfaces — not about anyone’s roadmap, intention, or next quarter.

A public feature request as a specification

The community already described the missing terminal primitive in the Codex repository. Issue #15679 proposed a /loop <interval> <message> command that queues a user message on a repeating minute-based interval — examples include /loop 5m summarize progress. That is not a vague wishlist; it is a behavioural sketch of session-local recurring prompts.

As of this writing the issue is closed as not planned, with a maintainer pointing people at /goal for looping behaviours. That closure does not install a Scheduled management interface into the CLI. It does something almost as useful for readers of landscape pieces: it shows that the requested shape matches the primitive, and that the gap is still visible in the product docs even after the ticket closed.

Do not confuse “closed feature request” with “shipped capability,” and do not confuse “shipped on web/desktop” with “available in the terminal process you are supervising.”

How to read a one-clause docs line as architecture

The transferable skill is not memorising which vendor is ahead this week. It is treating product language as delivery semantics.

• “Within a session” and “Requires open session: Yes” mean the schedule is an interrupt into a live process, not a fresh cold start.
• “Inherits from session” (MCP, permissions) means the scheduled turn sees the tool and authority posture of the running conversation.
• “Same chat with its existing context” means conversational continuity — not, by itself, a local worktree or a long-lived terminal process.
• “Doesn’t provide the Scheduled management interface” means the binding constraint is the surface, not your ability to write a good prompt.

When a trade-off flips — when “stateless scheduled job” stops being enough and “re-enter the live agent” becomes the required pattern — you are at an architectural inflection: the same operating-point language that settles monolith-versus-services arguments applies to tooling choices.

Interface, not model capability, is the binding constraint on who can run these jobs in a live coding session today.

What we are not claiming

This piece is designed to decay. The feature table will move. The CLI sentence may reverse. Cloud and desktop columns may grow more alike. When they do, the durable residue is the method: open the live page, quote the delivery clause, place it on a surface (web / desktop / CLI), and refuse to let a brand name do the work of a process model.

The tooling decision

If your long job needs a supervisor that lands inside the same terminal process — sees the open tools, the sub-agents, the working narrative, the commands already in flight — you are shopping for a surface that can schedule into a live session. As of the public manuals re-read for this article, Claude Code’s /loop is the documented terminal answer. Codex’s schedule management lives in ChatGPT web or the desktop app, not in the CLI.

If your job is fine as a recurring chat with saved context, or as a desktop task over a local project with the machine left on, OpenAI’s scheduled tasks are not a non-event. They are the same primitive on different rails. Choose the rail that matches the process you actually need.

Three adjacent pieces own what this one leaves on the table:

• The Prompt Is the Interrupt — why in-session delivery is an architecture, not a convenience.
• The Heartbeat Is a Supervisory Program — what the payload should carry.
• Same-Session Supervision Preserves Its Mistakes — the failure mode that comes with warm loops (without restating it here).

For the pre-vendor field practice: Cron as the poor man’s orchestrator. For operational state that survives any vendor’s session model: Handover Notes for Robots.