Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 10 — Oh-My-OpenCode’s Innovations
Token Usage: ~4,100 input + ~1,020 output

10.4 Ralph Loop and Todo Continuation

Autonomy is easy to promise and hard to enforce. OMO’s answer to this enforcement problem appears in two linked mechanisms: the Ralph Loop under src/hooks/ralph-loop/ and the Todo Continuation Enforcer under src/hooks/todo-continuation-enforcer/. Together they try to solve one of the most persistent agent failures: stopping too early.

The Ralph Loop is conceptually simple. If the agent did not actually finish, the system should push it back into work rather than accept a polished but incomplete response. The prompt builder in continuation-prompt-builder.ts makes this explicit: if the completion promise was not emitted, the system injects a continuation directive telling the agent to review progress, continue from where it left off, and stop only when the task is truly done. In Ultrawork mode, the continuation prompt is even prefixed with ultrawork, preserving the autonomous posture across retries.

The name “Ralph Loop” is idiosyncratic, but the deeper metaphor in OMO is the Sisyphus myth. In Greek mythology, Sisyphus is condemned to keep pushing a boulder uphill, only for it to roll back again. OMO transforms that image into a design principle: unfinished work must be pushed forward again and again until it reaches completion. The “boulder pushing” metaphor therefore means relentless continuation under interruption or incomplete output. This is not a standard CS textbook term, so it helps to translate it into system language: Ralph Loop is a forced continuation mechanism with persistent retry semantics.

The Todo Continuation Enforcer addresses the same problem from a second angle. Instead of looking for a missing completion promise, it looks at the task state. If todos remain incomplete, the session should not be allowed to conclude normally. The event handler watches session lifecycle events such as session.idle, session.error, and recovery-related transitions. When the session goes idle, the hook can inspect whether work remains and trigger further continuation logic.

This is important because todos in OMO are not treated as decorative UI elements. They are operational commitments. A system that writes a todo list and then ignores it is not really using structured task management; it is performing task theater. OMO tries to close that loophole. The continuation enforcer makes incomplete todos a runtime condition, not merely a social expectation.

The two mechanisms complement each other well.

• Ralph Loop says: if the explicit completion signal is missing, continue.
• Todo Continuation says: if the state still shows unfinished tasks, continue.

One is output-oriented; the other is state-oriented. Together they reduce the space in which the agent can escape.

This design also reveals a broader truth about advanced agent systems: prompt instructions alone are insufficient. A model can always ignore, forget, compress away, or prematurely summarize instructions. OMO therefore pushes these expectations into hooks and event handlers. In systems theory terms, it converts soft norms into hard control flow.

The reminder injection behavior matters too. OMO can insert system reminders when the task is incomplete. That means the agent is not merely scolded after failure; the runtime actively re-contextualizes the situation and tells it what is still missing. This resembles a watchdog or supervisor process in conventional computing, where one component monitors whether another component has reached a desired state and intervenes if not.

There is also a recovery benefit. If a session is aborted or interrupted, OMO can preserve enough continuation state to resume the same unfinished run rather than start over. This prevents a common failure mode in long tasks: the model forgets why it stopped and gives a generic wrap-up instead of re-entering the exact missing step.

The main trade-off is obvious. Aggressive continuation can create longer runtimes, more tokens, and occasional over-persistence when a task truly should stop. OMO addresses this with stop guards and explicit stop-continuation commands, but the default bias is unmistakable: better to continue than to quit too soon.

That bias is arguably justified. In real coding workflows, premature stopping is more common than dangerous over-completion. Users of coding agents complain far more often that the agent left a task half-finished than that it was slightly too persistent. OMO therefore optimizes for the dominant failure mode.

Seen together, Ralph Loop and Todo Continuation amount to a theory of agent discipline. The theory is that completion should not be inferred from tone, confidence, or narrative closure. It should be inferred from explicit signals and state checks. That is a strong engineering instinct. Human readers are easily fooled by fluent prose; a continuation runtime should not be.

This is why these hooks are more significant than they first appear. They are not just persistence hacks. They are part of OMO’s attempt to make “continue until done” an architectural property rather than a motivational slogan.