The first time you see a coding agent work for hours without stopping, a thought pops into your head: the model got stronger, so now it can just keep going.

That’s half right.

The models are improving. But what actually lets an agent push through bugs, work across dozens of turns, and stay on target isn’t a magic prompt. It’s an engineering loop – and Ralph Loop and Codex /goal are two of the best examples of this loop in the wild.

Ralph Loop uses shell scripts and file-based memory to repeatedly restart fresh agents. Codex /goal bakes the long-running objective into the runtime itself so the agent can auto-resume.

Both solve the same problem: how do you make an agent stick with a goal and keep making progress, instead of firing one prompt and clocking out?

So what’s the difference? Ralph Loop wires the mechanism up with external scripts and files. Codex /goal pushes it inside the runtime as a persistent goal state machine.

Let me lead with the conclusion.

Ralph Loop, at its core, is: repeatedly launch fresh agents, save memory in files and git. Codex /goal is: persisted goal state, runtime auto-continuation, and budget accounting.

In one line: Ralph Loop is an external orchestrator. Codex /goal is a built-in state machine.

Neither of these is about making the model “will itself to keep working.” They add a control layer outside the model – one that saves goals, tracks progress, triggers the next round, decides when to stop, and makes sure every round picks up from real ground truth.

Ralph Loop: Don’t Trust the Context Window. Trust Files.

Ralph is dead simple in design.

It’s not a fancier model or a heavy agent framework. The main loop is essentially a shell orchestrator.

Ralph runs Amp or Claude Code over and over. Each round is a brand new agent instance with a clean context. Whatever happened last round isn’t stored in chat history – it’s recovered from files, git, and task state.

Ralph pulls state from places like:

  • prd.json – task list and story status
  • progress.txt – current progress, next steps, risks
  • git history – code changes that actually landed
  • test output – real verification results

Ralph Loop’s core insight, put bluntly: context can be thrown away. State cannot.

Long chat contexts rot. The model starts forgetting early constraints, misreading the current situation, or doubling down in the wrong direction. It’s like cooking a complex dish entirely from memory versus turning to the recipe’s current step every time.

Ralph doesn’t try harder to compress the context. It restarts the context on purpose. Each round, a fresh agent reads the project files, the PRD, the progress log, and the git state, then reconstructs its understanding from scratch.

Here’s the Ralph Loop flow, simplified:

  1. Read prd.json, progress.txt, and git state
  2. Launch a fresh coding agent
  3. The agent picks an unfinished story
  4. The agent writes code, runs tests, updates progress
  5. ralph.sh captures the agent’s output
  6. If it sees COMPLETE, stop. Otherwise sleep, then launch the next fresh agent.

So the outer shell script really only does three things: launch the agent, capture output, decide whether to keep going.

What story to work on, how to change the code, how to run tests, how to log progress – none of this is hardcoded in the shell. It all lives in the prompt contract. At bottom, Ralph Loop is:

shell loop + prompt contract + file-based memory + completion token

The part of Ralph that really opens your eyes isn’t the shell script. It’s the judgment call about where agent memory belongs.

Most agent systems default to storing memory in the conversation history. Ralph flips this:

  • Goals go in the PRD
  • Progress goes in progress.txt
  • Ground truth lives in code and tests
  • Changes live in git

The next agent round doesn’t need to “remember” what it said before. It just needs to re-read these external artifacts to reconstruct the full picture.

This is critical for long tasks. The reliable state of a long-running coding task shouldn’t be “what the model thinks it did.” It should be: what’s in the files, whether the tests pass, what git diff shows, which stories in the PRD are done, what blockers are logged in progress.txt.

Ralph Loop pulls the agent out of the “long chat” paradigm and back into an engineering workflow.

Codex /goal: Making Continuation a Runtime Responsibility

Codex /goal solves the same problem from a different angle.

Ralph is an external script that keeps launching agents. Codex /goal moves the long-running objective inside the Codex runtime.

A normal prompt is one-shot: you give a task, the agent runs one turn, returns a result, and the round ends. /goal creates a persistent objective instead:

  • You set the goal
  • The runtime saves the goal state
  • The agent runs a turn
  • The runtime tallies progress and budget
  • If the goal is still active, it auto-injects a continuation prompt
  • The agent runs the next turn
  • This repeats until complete, budget-limited, or paused

So /goal isn’t really about the slash command. It’s about the goal state. A goal needs to track at least: the objective, the status (active, complete, budget-limited), tokens used, budget, and the thread it belongs to.

This means the goal isn’t just a sentence in your chat history. It’s a state object the runtime can read, update, and audit – the same way your bank balance isn’t a verbal promise but a number in a database.

What makes Codex /goal capable of sustained work is runtime continuation.

After every agent turn, the runtime checks the thread:

  • Is there an active goal?
  • Is there budget remaining?
  • Is there no turn currently running?
  • Is there no new user input queued up?
  • Is the agent allowed to keep pushing forward?

If all conditions are met, the runtime constructs a continuation turn on its own.

This is different from a human saying “keep going.” Manual “keep going” relies on the human remembering the task and the model fishing the goal back out of context. With /goal, the runtime already knows an active goal exists, so it injects the goal, the budget, the token usage, and the completion requirements directly into the model.

So Codex /goal boils down to:

persisted goal state + runtime continuation + budget accounting + structured completion

It upgrades “keep going” from a chat habit into a runtime mechanism.

There’s another boundary in Codex /goal worth paying attention to: the model can’t just say “I’m done” in natural language and call it complete.

In the implementation, the model has to mark a goal complete through a structured tool call. Budget exhaustion, pausing, resuming – these are controlled by the system or the user, not the model.

This matters. If the model could freely change all states, it might mark an unfinished goal as complete just to end the task. Structured state updates narrow the model’s power: the model can push the task forward and can mark completion once confirmed, but budget and pause control belong to the runtime or the user.

This is where /goal behaves more like an engineering system than a regular prompt. It doesn’t just let the agent continue – it also constrains when the agent is allowed to stop.

Ralph Loop vs Codex /goal: External Workflow vs Built-In State Machine

Put them side by side and the differences jump out.

The first thing you notice is where the state lives.

Ralph Loop puts state in externally visible engineering artifacts: prd.json, progress.txt, git, test results. Codex /goal puts goal state in the Codex runtime’s persistent thread state: thread goal state, goal status, token accounting, continuation scheduling.

The continuation mechanism is different too. Ralph Loop is a shell for-loop – launch fresh agent, inspect output, repeat. Codex /goal is turn-finished, runtime checks active goal, injects continuation prompt, next turn.

Completion signals differ as well. Ralph uses an output convention – spot the COMPLETE marker and stop. Codex uses a structured tool state update – update_goal status=complete.

Put another way: Ralph Loop turns agent long tasks into a visible external workflow. Codex /goal turns agent long tasks into a built-in runtime capability.

One lives outside, one lives inside. One runs on shell and files, one runs on runtime and state machine.

But the underlying principles are the same:

  • Goals must be persisted
  • Progress must be recoverable
  • Feedback must be verifiable
  • Continuation must be controllable
  • Stopping must have clear boundaries

What This Means for Developers

If you want to understand long-horizon coding agents, don’t just study prompts.

Study these questions instead: How do you turn a goal from one sentence into trackable state? How do you move progress out of chat history and into files, databases, or git? How do you give the agent concrete feedback each round instead of relying on its self-assessment? How do you design budget and stop conditions so the loop doesn’t spiral? How do you make completion auditable instead of relying on verbal promises from a model?

Ralph Loop gives you a minimal, working version you can study. Codex /goal gives you a productionized runtime version.

Both point the same way: the coding agent of the future isn’t a longer chat window. It’s a more reliable goal execution system.

If you’re deep into AI coding tools and want to understand how agents really sustain long tasks, follow the “全栈之巅-梦兽编程” WeChat channel for weekly AI programming content.

Also check out Dream Beast Programming AI Assistant to put agent tools to work in your daily development.

References

FAQ

Which one should I use, Ralph Loop or Codex /goal?

Depends on what you’ve got. Ralph Loop is an open-source shell script you can fork and customize – ideal if you like building your own workflow. Codex /goal is built into Codex, zero setup but locked to the Codex ecosystem. If you use Codex CLI, /goal is the easiest path. If you want to bring Claude Code or other agents into a long-task pipeline, Ralph’s approach is easier to adapt.

Why not just give the model a bigger context window?

Longer contexts dilute attention. Multiple experiments show that models tend to “forget” information in the middle of long context windows – like reading page 300 of a 500-page book and having no clear memory of chapter one. Both Ralph Loop and Codex /goal keep the model focused on “just the current step” instead of cramming the entire project history into one window.

What’s the biggest pitfall with long-running agent tasks?

Direction drift. The agent gradually veers off the original goal because each turn it makes locally optimal decisions within the current context. Ralph counters this with PRD and progress.txt. Codex counters it with goal state and structured status updates. Both emphasize an external anchor rather than trusting the model to remember where it’s headed.