What yoyo shares with Recursive Language Models, and what it does not

The paper’s real move

The paper argues that very long inputs should be treated as part of an external environment instead of being stuffed directly into the model context. Their Recursive Language Model loads the input into a Python REPL, lets the model inspect pieces of it with code, and lets it recursively call itself on smaller subproblems.

That is the important shift. The gain is not just “more context.” The gain is moving from prompt stuffing to environment interaction.

Important distinction The environment idea is only part of the paper. The stronger mechanism is recursive control: RLM(q, context) → RLM(sub_q, sub_context) when the model decides a smaller subproblem deserves its own working set.

What the REPL part actually means

A REPL is just an interactive programming session. In the paper, the full prompt becomes a variable in that session. The model can ask for slices, search with code, decompose the input, and recurse on smaller chunks instead of trying to hold the whole thing in token memory at once.

Why that matters The prompt stops being “all the text the model must read now” and becomes “data in an environment the model can inspect when needed.”

Why this matches yoyo

yoyo is not building a Python REPL for source code, but it is pushing toward the same abstraction. A repository should be treated as an external environment with grounded interfaces, not as a giant prompt.

That is what boot, index, judge_change, inspect, and change are trying to do. They make the repo queryable in smaller, more reliable pieces. The model should not need to drag full files or entire subsystems into context just to answer one ownership or invariant question.

What is now actually inside yoyo

The essay used to overstate the connection. yoyo does not already contain an RLM in the paper’s sense. What it does contain is a more grounded repo workflow with bounded inspect-fail-repair steps.

The clearest example is the new guarded write path. A write no longer means “edit the file and hope.” yoyo writes the candidate change, runs the relevant checks, and restores the original file if the new version fails. When that happens, the failure is returned as machine-readable guard_failure data, and retry_plan turns that failure into a bounded inspect-fix-retry workflow.

That is a related product move, not the same mechanism The model does not have to hold the whole repository or the whole failure state in prompt memory. The repository is the environment, the failure is structured state, and the next step is a constrained interaction over that state. But the control loop is still flatter than the paper’s recursive self-decomposition.

This matters even more for interpreted languages. Python, JavaScript, Ruby, PHP, and Clojure often fail after parsing, not before. So yoyo now uses runtime guards to catch “this file parses but breaks when it actually runs” cases, then routes those failures back into the same repair loop. That is closer to environment-mediated repair than the old “search a lot and dump source into context” approach, but it is still not the paper’s recursive inspect-and-act mechanism.

Why search is not the moat

The paper makes one thing clearer: the moat is not raw retrieval. If all you have is better grep, the model still has to do the real work in its own prompt state. That is fragile and easy to replace.

The deeper value is giving the model a grounded way to ask higher-level questions about the codebase:

Where should this fix live?
What must remain true?
What else touches this?
What is the minimal safe write surface?

That is why judge_change matters more than trying to win a search benchmark.

Read first, then write

The paper’s results are strongest on tasks where the model must manage dense, multi-hop information without collapsing into lossy summaries. That maps directly to the most honest product statement for yoyo:

Current product takeaway yoyo is strongest when read judgment narrows the surface first, then change executes the write cleanly.

That is also what our recent directed evals are showing. The read side matters because the write should happen only after the correct ownership layer and invariants are grounded.

What changed recently is that the write side now has a bounded repair loop too. But that loop is still mostly flat: read carefully, write through a guard, inspect the resulting failure state if needed, then retry. The paper’s stronger move is that the model itself decides when to recurse on a smaller subquestion with a transformed sub-context. yoyo is not doing that yet.

A concrete Clojure MCP example

The clean way to mimic the paper on a Clojure repo today is to keep the recursive decision-making outside yoyo and use yoyo as the grounded environment.

In a tiny Clojure repo with a greet function, the MCP loop can look like this:

boot + index
→ inspect(name="greet")
→ ask("format a full name into a greeting")
→ judge_change(...)
→ change(...)
→ guard_failure
→ retry_plan
→ inspect(targeted lines)
→ change(...)

In the demo, inspect found my.app/greet, ask ranked the same function first for the intent query, and judge_change narrowed ownership to src/my/app/core.clj. Then a bad write added a missing namespace import. yoyo rejected the write, restored the file, and returned structured failure state instead of leaving broken Clojure on disk.

guard_failure: {
  "phase": "post_write_guard",
  "retryable": true,
  "files_restored": true,
  "files": [
    {
      "file": "src/my/app/core.clj",
      "errors": [
        {
          "kind": "clojure-runtime",
          "text": "Could not locate missing/ns__init.class"
        }
      ]
    }
  ]
}

After that, retry_plan narrowed the next read surface to the namespace form at the top of the file and produced a bounded retry workflow. A corrected change then landed a valid multi-arity greet implementation.

What this proves, and what it does not This is the closest current yoyo behavior gets to an RLM on Clojure: the repo stays outside prompt memory, failures become structured state, and the next step gets smaller. But the outer model is still the part deciding whether to recurse or spawn a subtask. yoyo is the environment, not the recursive controller.

Where yoyo differs from an RLM today

The paper uses a very flexible REPL. For general long-context reasoning, that makes sense. For software engineering, a more structured surface is often better.

It is also worth being precise about the current gap. The paper is not just about tool use or keeping context outside the prompt. It is about recursive control. The model can choose to turn q into sub_q, transform the accessible context, and call itself again. yoyo currently offers curated repo tools and bounded retry workflows, not recursive sub-agenting of that form.

A coding system needs:

less hallucination, not just more freedom
safe writes, not arbitrary code execution
repeatable interfaces over repository truth
clear boundaries between read judgment and write execution

So the lesson is not “turn yoyo into a Python REPL.” The lesson is “keep moving toward repo-as-environment, but keep the interface opinionated and safe.”

That is also why the current runtime bootstrap matters. yoyo can now create yoyo.json automatically for supported interpreted languages, but it does so with least-privilege defaults. The setup is automated for the agent; broader runtime access still has to be made explicit in repo policy. That is the right difference between a software engineering environment and a general-purpose free-form REPL.

What this suggests for yoyo next

If the paper is directionally right for yoyo, then the next work should keep compressing repo understanding into grounded read surfaces.

Make ownership and invariant judgment cheaper and more reliable.
Keep strengthening cheap structured reads over dumping source text.
Treat writes as the second step, not the first instinct.
Keep making failure states executable and machine-readable so repair loops are bounded instead of improvised.
Extend the same loop to more interpreted and functional languages where runtime feedback is the real truth boundary.
Avoid competing on generic search when the real value is judgment plus constrained execution.

Bottom line

The RLM paper is a strong validation of one direction yoyo is already moving toward. The future is not a bigger prompt. The future is a smaller, more truthful interface to an external environment.

For long documents, that environment might be a REPL over text. For codebases, it should be grounded repository tools. That is why the paper feels aligned with yoyo: both are trying to move work out of token memory and into structured interaction with what is actually there.

The newer twist is that yoyo is no longer only doing that on the read side. With guarded writes, runtime checks, guard_failure, and retry_plan, parts of a bounded repair loop are now in the product itself. That is useful progress, but it is not yet RLM-style recursive subproblem delegation.