Ralph Loops Are Not About Throwing Away Context

A developer known as Geoffrey Huntley introduced the Ralph loop, a Bash loop pattern for running coding agents indefinitely by resetting the context window each iteration and storing state on the filesystem. The technique, named after Ralph Wiggum, aims to avoid performance degradation from growing context, but critics note it is not about discarding all context—rather, it keeps the working context small and pushes durable state to disk. OpenAI has productized a similar approach in its Codex CLI, and studies like 'Lost in the Middle' and 'Context Rot' confirm that model performance degrades as input length increases.

There is a technique making the rounds called the Ralph loop. In its purest form it is a Bash loop: while :; do cat PROMPT.md | claude-code ; done . You point a coding agent at a task, give it a fresh context window every iteration, and let it run until the work is done. State lives in files, not in the conversation. The pitch is that you can run an agent indefinitely without it drowning in its own accumulated context. The pitch is right about the destination and wrong about how it describes the trip. "Throw away the context every turn" is a catchy summary and a misleading one. The technique that actually works is narrower and more interesting, and it comes with two costs the excitement skips over. One of them is a bill you can measure in dollars. A Ralph loop is a pattern for long-running agents where each iteration starts with a clean context window and durable state is carried on the filesystem instead of in the conversation history. It matters because model performance degrades as context grows, so a small clean context can beat a large accumulated one. It differs from a single long session in that memory lives in external artifacts the agent re-reads, rather than in a transcript that keeps growing until it rots. That definition is doing a lot of quiet work, and the rest of this post is about the parts of it that the one-line version hides. The name comes from Geoffrey Huntley, who wrote it up in July 2025 and named it after Ralph Wiggum, because the loop is, in his own words, "deterministically bad in an undeterministic world." He is not selling it as rigorous. He says building with it "requires a great deal of faith and a belief in eventual consistency." That honesty is worth holding onto, because most of the reposts drop it. Read past the one-line Bash version and the actual guidance is more careful. Huntley's rule is one item per loop, and to keep the primary context window small on purpose. He claims the usable window is smaller than advertised, that "the quality of output clips at the 147k to 152k mark" on a model that lists a 200k window. His design uses the main context as a scheduler that hands expensive work to subagents, rather than doing everything in one growing thread. So the real technique is not "discard everything." It is "keep the working context small and clean, and push durable state out to disk." The pattern has moved past meme status, which is the strongest signal it is more than a joke. There is a popular open-source implementation whose description is exact about the mechanism: each iteration is a fresh instance with clean context, and memory persists via git history, a progress file, and a spec file. OpenAI shipped its own version in the Codex CLI, a goal command that keeps looping until the model judges the goal complete or the token budget runs out. When a lab productizes your meme, the meme had something in it. This is the part with real evidence, and it is the foundation the whole technique stands on. Models get worse as their input gets longer, and not just when the window fills up. The canonical result is Lost in the Middle by Liu and colleagues https://dub.sh/YEQtrmr https://dub.sh/YEQtrmr , published in 2023. They slid a relevant document through different positions in a long input and measured a U-shaped accuracy curve: the model does best when the key information is at the very start or the very end, and worst when it is buried in the middle. The effect held across models and context lengths. Information does not have to fall out of the window to stop being used well. It just has to be in the wrong place in a large pile. The more recent and more pointed study is Context Rot from Chroma https://dub.sh/E5pABeY https://dub.sh/E5pABeY , from July 2025. They tested 18 frontier models and found a consistent pattern of degradation as input length grew, even when the window was nowhere near full. One of their findings is genuinely strange and worth sitting with: models sometimes did better on a shuffled haystack than on a logically structured one, which suggests the structure of a long input affects attention in ways nobody fully controls. The practical reading, which matches what coding-agent builders report, is that an agent accumulates noise as it searches, explores, and backtracks, and that noise degrades every output that comes after it. So the case for a clean context is not vibes. It is measured. If you let an agent run for an hour in one thread, the transcript fills with stale tool outputs, abandoned approaches, and dead ends, and the model's later decisions get worse because of it. Starting fresh each iteration is a way to keep the working context in the high-accuracy zone. This is the same underlying reason I argued for treating context as a cost lever and sending less of it https://dev.to/blog/context-window-cost-lever : more context is not more help, and past a point it is actively less. Here is the cost the excited version never mentions, and it is a real one. Prompt caching is how you make repeated agent calls affordable. The provider stores the processed prefix of your prompt so it does not have to reprocess those tokens on the next call. But caching has a hard requirement: the cached prefix must match exactly. Anthropic's caching documentation https://dub.sh/utnLMe6 https://dub.sh/utnLMe6 states that cache hits require 100% identical prompt segments up to the cached block, and advises putting stable content at the very beginning. OpenAI's caching works the same way https://dub.sh/JdNr797 https://dub.sh/JdNr797 , on an exact prefix match for prompts over 1024 tokens. Change the front of your prompt and the cache is gone. The economics are the whole point. A cache read costs roughly a tenth of the normal input price, and OpenAI reports input cost reductions up to 90% on cached prefixes. That discount is enormous, and it only exists if your prefix is stable across calls. Now look at what a naive Ralph loop does. If every iteration rebuilds the prompt from scratch, reads a different set of files, and reconstructs the context, the prefix is different every time and the cache never hits. You pay full price on every token, every loop. OpenAI's own docs flag this exact interaction, warning you to carefully consider the impact of caching from context-engineering techniques that rewrite the prompt. This is why the naive framing is dangerous. If you actually threw the whole context away and rebuilt it randomly each turn, you would be running the single most expensive version of the agent possible, paying full freight on a large prompt hundreds of times. The disciplined version avoids this by keeping a stable prefix. The spec, the system prompt, and the standing instructions go at the front and stay byte-identical, so they cache. Only the volatile tail, the files that changed, varies. That is a deliberate design choice, and it is the difference between a loop that is merely wasteful and one that is ruinous. I went deeper on the mechanics of keeping that prefix stable in the piece on prompt caching in practice https://dev.to/blog/agno-prompt-caching , and it applies directly here. | Approach | Working context | Cache behavior | Failure mode | |---|---|---|---| | One long session | Grows every turn | Prefix stable, caches well, but context rots | Accuracy decays as the transcript fills with noise | | Naive Ralph loop | Fresh, rebuilt randomly each turn | Prefix changes, cache misses, full price every loop | Ruinous token cost, and loses the reasoning | | Disciplined Ralph loop | Small and clean, stable spec prefix | Spec caches, only the changed tail is uncached | Still loses the "why" unless artifacts encode it | The table is the argument in one frame. There is no free option. The long session rots, the naive loop bankrupts you, and even the disciplined loop pays a subtler cost, which is the next section. Files are a good place to keep state and a bad place to keep reasoning. This is the deepest problem with the pattern, and it is not a caching issue, it is an information one. When an agent writes its progress to a file and the next iteration reads it, what survives is the artifact. The code exists, the progress note says step four is done, the spec is updated. What does not survive is the deliberation: why the agent chose this approach over the two it tried and abandoned, why a particular edge case was handled the way it was, what it had learned not to do. A fresh instance reads the files, sees the what, and cannot see the why. So it is free to undo a decision it does not know was deliberate, or to re-litigate a question that was already settled in a transcript that no longer exists. There is a clean way to say this that has been floating around the practitioner conversation: code tells you what happened, transcripts tell you how you got there. A filesystem checkpoint captures the first and discards the second. For a task where the reasoning does not matter much, that is fine. For a task where a later step depends on understanding why an earlier step was done a certain way, it is a landmine, and the agent steps on it by confidently redoing work or contradicting its past self. The mitigation is to make the agent write down its reasoning as an artifact, not just its results, which is more discipline than the one-line loop implies and is easy to skip. This is also why observability matters more here, not less. When an agent runs across many stateless iterations, the only record of what it decided and why is whatever it chose to write down, and if it wrote down only outcomes, you are debugging blind. The same gap I wrote about in agent observability https://dev.to/blog/agent-observability-gap shows up sharper in a Ralph loop, because there is no single long transcript to scroll back through. The trace is scattered across file writes, and the reasoning is often not in any of them. Yes, and that is the strongest evidence the core idea is sound, along with the strongest evidence that the naive version fails. Anthropic published a piece on effective harnesses for long-running agents in November 2025 that describes the exact problem in their own words: each new session begins with no memory of what came before, like a project staffed by engineers working in shifts where each new engineer arrives with no memory of the previous shift. That is the Ralph problem stated precisely. And their finding is blunt. Even a frontier model running in a loop across multiple context windows will fall short of building a production-quality app if it is only given a high-level prompt. The naive loop does not work. Their fix is a two-agent structure: an initializer agent that sets up the environment once, and a coding agent that makes incremental progress each session while leaving clear artifacts for the next one. They name the two failure modes a naive loop hits, and they are worth memorizing because they are exactly the costs above. The first is running out of context mid-implementation and leaving the next session a half-built feature with no explanation, after which the next agent guesses at what happened. The second is premature completion, where a later instance looks around, sees that progress was made, and declares the job done when it is not. Both are the "what without the why" problem wearing different clothes. Anthropic's separate writing on context engineering makes the same point about compaction, warning that overly aggressive compaction loses subtle context whose importance only becomes clear later. The vendors converged on the shape of the technique and documented, in detail, why the lazy version breaks. This is the disciplined harness thinking I have written about in harness engineering https://dev.to/blog/harness-engineering , applied to the specific problem of memory across sessions. Sometimes, and with your eyes open. The honest status is that the premises are measured and the recipe is not. Context rot is real and well-studied. External memory beating a fixed context is established, going back to the MemGPT paper https://dub.sh/N4EEVtA https://dub.sh/N4EEVtA from 2023, which framed the model as an operating system paging state between a small main context and external storage. What is not established is the Ralph loop itself. There is no controlled benchmark of the loop against a compaction-based long session, and no published head-to-head on the cost tradeoff. The evidence for the loop specifically is field reports and vendor engineering posts, not experiments. So treat it as convergent engineering with documented costs, not a proven method. Run it when the task is long-horizon and decomposes into steps that a fresh agent can pick up from artifacts, when you have done the work to keep a stable cacheable prefix, and when you have made the agent write down its reasoning and not just its output. Do not run it as the naive Bash one-liner on anything that costs real money or where a later step depends on earlier reasoning, because you will pay full token price on every loop and watch the agent undo its own good decisions. The pattern is a clever hack sitting on a solid foundation. The foundation is context rot and external memory, both real. The hack is the loop, and its bill comes due in cache misses and lost reasoning. Knowing that is the difference between using it well and being surprised by it. A Ralph loop is a way to run an AI coding agent on a long task by repeatedly restarting it with a fresh context window and keeping durable state in files rather than in the conversation. It was named by Geoffrey Huntley after Ralph Wiggum, half as a joke, because the loop is simple and stubborn. Each iteration reads the current state from disk, makes incremental progress, and writes it back, so the agent can run indefinitely without its context growing. Because model accuracy degrades as the context grows. Research on lost-in-the-middle and context rot shows models use information less reliably as input gets longer, even before the window is full. A long session fills with stale tool outputs and abandoned approaches, and that noise makes later decisions worse. Restarting with a clean context each iteration keeps the working context in the high-accuracy zone, which is the real benefit of the loop. It can, and this is the biggest hidden cost. Prompt caching requires an exact, stable prefix to get a cache hit, which cuts input cost by up to about 90%. If every iteration rebuilds the prompt differently, the prefix changes and the cache never hits, so you pay full token price on every loop. The fix is to keep a stable prefix, the spec and system prompt at the front, byte-identical across iterations, and let only the changed files vary. Files preserve the what, not the why. The code and the progress notes survive, but the reasoning behind them does not. A fresh agent instance sees the artifacts but not the deliberation that produced them, so it can undo deliberate decisions or re-litigate settled questions. The mitigation is to have the agent write its reasoning down as an explicit artifact, not just its results, which takes more discipline than the simple loop suggests. No, not in a rigorous sense. The premises it rests on are measured: context rot is well-studied, and external memory beating a fixed context goes back to MemGPT. But the loop itself has no controlled benchmark against a compaction-based baseline, and no published cost comparison. The evidence for it is practitioner field reports and vendor engineering posts. Treat it as convergent engineering with real, documented costs, not a peer-reviewed method. Both converged on the same shape and warned that the naive loop fails. Anthropic's harness guidance uses a two-agent structure, an initializer plus a worker that leaves clear artifacts each session, and documents two failure modes of naive loops: running out of context mid-task and premature completion. OpenAI shipped a goal command in its Codex CLI that loops until the goal is judged complete or the token budget runs out. The vendor versions add the artifact discipline that the one-line loop leaves out. Use it for long-horizon tasks that break into steps a fresh agent can resume from artifacts, when you have kept a stable cacheable prefix to control cost, and when the agent records its reasoning and not just its output. Avoid the naive one-line version on anything expensive or where later steps depend on earlier reasoning, because you will pay full price every loop and risk the agent undoing its own work. It is a real tool, not a default.