Letting Claude Run Indefinitely: Three Key Loops for Long-Horizon Agent Tasks

When an Agent Starts Rewriting the Compiler for You

Most people use Claude in a question-and-answer fashion—at most writing a function or fixing a bug. But there's a category of usage that pushes this boundary much further: give the model a sufficiently hard, sufficiently tedious goal, equip it with an automated pass/fail verification mechanism, and then let it run for days and weeks.

YouTube creator Theo recently shared an extreme workflow. In his words, it's not a practical guide—rather, it showcases "things I shouldn't be doing." He built several projects with Claude: rewriting TypeScript in Rust (TS Rust), building an alternative compiler that can accelerate Rust compilation a hundredfold (Lust), and a skateboarding game, Skate 3 Bench, generated entirely from scratch by Claude. These projects have cumulatively run Claude for nearly 4,000 hours.

What underpins all of this isn't some magic prompt—it's a reusable methodology.

Core Principle: Hill Climbing and Verifiable Rewards

To understand why a model can propel itself forward for extended periods, we first need to revisit how it was trained.

A model's capabilities broadly split into two parts: knowledge comes from pretraining data, and behavior comes from reinforcement learning. Modern models extensively use a mechanism called RLVR during training—reinforcement learning with verifiable rewards. During training, the model is placed in environments where success can be programmatically determined—for example, "convert file A to file B and output the specified errors." Success yields a reward; failure triggers adjustment. As a result, the model is shaped into a behavioral pattern that proactively tests, writes code to verify, and switches approaches after failure.

This explains a key phenomenon: when your task resembles the model's training environment, it performs much better. The TypeScript port was feasible precisely because a compiler's inputs and outputs are inherently verifiable—by compiling real projects at fixed versions and comparing results and error messages character by character, the agent knows whether it got it right.

In Theo's own words: first get TS Rust to produce output exactly matching the official compiler, then say "don't stop until it's twice as fast as the official one." The first version was actually slower than the official compiler, but because there were clear success criteria, it optimized its way to the target on its own. TS Rust ultimately produced approximately 1,800 revisions and 7,884 commits.

RLVR (Reinforcement Learning with Verifiable Rewards) is a key paradigm in recent large-model training. Traditional RLHF relies on human preference scoring, which is costly and noisy; RLVR instead delegates the reward signal to environments where success can be programmatically determined—for example, whether unit tests pass, whether compiler output matches character by character, or whether a math answer is correct. The model samples and trial-and-errors across many such environments; successful trajectories are reinforced, and failed ones are suppressed. The result is that the model acquires a behavioral policy of "hypothesize—verify—correct" rather than merely memorizing knowledge. When deployment tasks are isomorphic to the training environment (such as code porting or compiler optimization), the model can spontaneously test, roll back, and switch approaches, thereby sustaining long-horizon autonomy.

The Four-Step Loop: From Goal to Compute Supply

Theo breaks the entire process down into a self-reinforcing closed loop.

Step 1: Find Something Tedious Enough

A developer's instinct is to avoid repetitive labor, but here you want the opposite. The more tedious a task—the less likely anyone would ever complete it by hand—the more suitable it is for an agent. Rewriting a codebase of a hundred thousand files from one language to another is torture for a human but merely takes a bit longer for an agent.

Step 2: Design the Verification Method

This is the crux of the entire method. Verification must be determinable by code as pass/fail, or at least let another agent look at the results and make a judgment. If it requires a human staring at a screen saying "this is good, that's bad," progress slows to the point of meaninglessness.

Skate 3 Bench took a more clever approach: after the model is satisfied with a version, it takes an automatic screenshot, feeds that screenshot alongside a similar frame from the original Skate to a panel of LLM judges for scoring, and continues iterating based on the feedback. Theo admits this approach isn't elegant—he himself was surprised it worked. The cost was that the model once spent a considerable number of tokens obsessing over the skybox just to make the visuals look more like the original.

LLM-as-a-judge (LLM judging panel) refers to using another large model to score or rank generated results, replacing subjective evaluations that are hard to quantify. In Skate 3 Bench, the agent takes a screenshot, sends it together with the original game frame to the judging model, which assesses similarity and provides feedback. This approach is flexible but has known biases: the judging model may prefer certain styles, be insensitive to details, or even be "gamed." Therefore, in practice, strategies such as multi-model voting, pairwise comparison, and reference anchors are often used to reduce noise. It serves as a compromise when hard criteria are lacking, but it should not replace programmatically verifiable pass/fail standards.

Step 3: Provide Ample Tools

The model knows what to do and what success looks like, but it also needs an environment where it can actually act. Making a game requires a machine that can run Blender, launch a browser, and take screenshots. To this end, Theo stacked multiple machines on his local network, then later moved to cloud solutions because serial queuing became the biggest bottleneck.

Step 4: Repeatedly Ask the Agent "What's Blocking You?"

Theo maintained two threads: one endlessly advancing the TypeScript rewrite, and another dedicated to periodically asking about the current bottleneck. Through this "managerial" dialogue, he discovered that Claude had built its own queue to avoid exhausting memory from excessive concurrency, and that insufficient compute was the main drag. After adding machines and connecting to the cloud, wait times dropped from over ten hours per round to the hour level.

The key to this loop is that it doesn't terminate—solving one bottleneck often exposes the next layer, and that next layer may itself become a new hill-climbing project. Lust was born this way: because Rust compilation was too slow and was dragging down TS Rust, the model was simply tasked with rewriting the compiler.

Multiple Perspectives and Caveats

Theo particularly emphasized several real-world constraints. On cost, the API-equivalent expenses for these projects are extraordinarily high—TS Rust translated to API pricing is about $38,000, and Skate 3 Bench's inference cost is nearly $5,000, consuming over 12 billion tokens. However, subscription pricing heavily subsidizes this, so actual spending is far below list price. He explicitly opposes using API pricing for such experiments.

He also acknowledges that these projects produce practical value only in rare cases. TS Rust, because it can significantly shorten build times for real projects, he considers worthwhile; the remaining projects he describes as "fooling around."

You may not have noticed that this path isn't unique. Theo mentions a community project called Skate 3 Rust Engine, which attempts to rewrite Skate 3's physics system line by line from decompiled code. The difference is: replicating an existing project yields clear success criteria that are easy to hill-climb; creating something that doesn't exist from scratch makes verification design the real challenge.

The mismatch between subscription pricing and API metering is key to understanding the cost of such experiments. Subscription plans for products like Claude typically offer usage far exceeding what the API unit price would imply, for a fixed monthly fee—essentially a subsidy from the vendor to heavy users. The $38,000 Theo mentions is a "shadow cost" calculated at API token unit prices; actual spending may be only a few thousand dollars. This subsidy is unsustainable and should not be used as a cost basis for production-grade projects; once shifted to API pay-per-use, the economics of long-horizon autonomous loops deteriorate rapidly. Therefore, when evaluating such workflows, one must distinguish between "experimental subsidized pricing" and "true marginal cost."

Who Is This Method For?

Theo's own conclusion is straightforward: don't do this now. The process is painful, full of pitfalls, and addictive enough to make you want to keep dismantling the next bottleneck.

But if you treat it as a thinking exercise, its value lies in three points: first, identifying which tasks are verifiable—this is the prerequisite for an agent to be autonomous over long horizons; second, understanding "managing an agent" as supplying compute and clearing blockers rather than reviewing output line by line; third, recognizing that the toolchain itself is an object that can be optimized—when you keep asking what's slowing the agent down, the answer often points to the next component worth rewriting.

As inference costs continue to fall, what looks like a luxury loop today may be routine tomorrow. What's truly scarce isn't tokens—it's the ability to design verification mechanisms and discover bottlenecks.

One-line Summary

Give Claude verifiable goals and compute, and let it autonomously rewrite compilers for thousands of hours.

Paragraph Summary

The article introduces Theo's extreme workflow for long-horizon autonomous programming with Claude: by selecting sufficiently tedious tasks, designing programmatically verifiable success criteria, supplying tools and compute, and repeatedly asking the agent what its current bottleneck is, a self-reinforcing hill-climbing loop is formed. The TS Rust project achieved verification through character-by-character comparison of compiler output, producing approximately 1,800 revisions and 7,884 commits; Skate 3 Bench used an LLM judging panel to score screenshot comparisons. The author emphasizes that this method is isomorphic to the RLVR training environment, but it is costly and most projects yield no practical output, with subscription subsidies masking the true expense. What's truly scarce is the ability to design verification mechanisms and discover bottlenecks.