RLM: Recursive Language Models for Large Codebases

How can a coding agent investigate a large monorepo without losing the context it needs? Recursive Language Models, or RLMs, provide a context-management pattern that can be incorporated into a coding-agent harness. The paper comes from Alex L. Zhang, Tim Kraska and Omar Khattab; Shashi Jagtap’s walkthrough applies its ideas to source repositories.

The starting problem is familiar: a coding agent works well on a small repository, then becomes less effective as the context grows. In Jagtap’s account, large monorepos make that degradation especially apparent. The agent must retain architecture and relationships across files while filtering out irrelevant material. Having more code available does not automatically give it a useful understanding of the system.

Existing harnesses manage this problem in several ways:

These approaches determine what the agent finds, what enters its working context and what survives beyond the current interaction.

Externalize context management into a programmable execution environment. That is the central RLM move. The repository remains available as data outside the main model’s context window, and the model writes code to inspect it, select portions of it or compute relevant values. The results of those operations become the material returned to the model.

A dedicated REPL—a read–evaluate–print loop—gives the model a place to perform that work. Instead of receiving the entire repository as prompt text, it can investigate the repository and bring selected observations into its working context. Jagtap also proposes this external environment as a possible memory layer for a coding agent.

Imagine joining a project as its lead engineer and encountering a huge monorepo. You would begin by inspecting its structure, identifying dependencies and making notes. When something remained unclear, you might ask another engineer or a specialist for help. Reading every line before doing anything useful would be an impractical starting point.

The RLM environment plays the role of that engineer’s notebook. Files, documentation and configuration form the material under investigation; REPL state holds the working notes; scripts perform targeted searches. A call to llm_query plays the role of consulting a specialist in another model environment. Its answer returns to the investigation, which eventually produces a clean synthesis. The delegated work can involve one question or several.

Translated into an execution loop, the procedure is:

1. Inspect the external context. The model writes REPL code that operates on the repository.
2. Return a bounded observation. Execution produces selected evidence for the model to consider.
3. Delegate when needed. A call to llm_query sends a focused question to another model environment and returns its response.
4. Continue or finish. The parent investigation uses the returned information, performs further work if needed and terminates with a final result.

The subquery is part of the investigation: its response comes back to the parent loop rather than becoming a separate, disconnected answer.

Repositories make this pattern particularly interesting because their meaning is distributed across structure as well as text. Directories, imports and dependencies encode relationships; tests, images and configuration accompany the source. A codebase is structured data, so the investigation must reason about how its parts fit together, not merely locate passages in a long document.

rlm-code is Superagentic AI’s open-source research playground for experimenting with these ideas. It supplies a harness, documentation and source code, but it is one implementation of RLM rather than the definition of RLM itself.

The paper’s authors provide RLM and RLM Minimal. Another implementation is dspy.RLM, within DSPy. These are separate implementations of the same general pattern; using RLM does not require adopting DSPy or any particular library. Jagtap uses rlm-code as an independent reference harness to expose the mechanism during the demonstration.

In rlm-code’s RLM mode, the stated core remains REPL execution and recursive model calls. Around that core, Jagtap describes several implementation choices:

• Model backend: Run with a local model or a cloud model.
• Observability: Connect the investigation to an observability framework.
• Agent framework: Apply the pattern through a framework such as Pydantic AI or Google ADK.

A companion source repository provides a way to try the concepts. The demonstration’s purpose is to make the path visible: where context is created, what Python the model writes, what it sends to llm_query and how those operations produce the final answer.

The CLI demonstration uses the checked-out rlm-code source as its target repository. The accompanying README offers instructions for local-model execution, but the recorded run uses Gemini. Jagtap starts the script, shows the Docker sandbox container starting and then returns to the completed execution.

The first visible step is model-written Python REPL code that builds evidence from the repository. A small probe for investigating the subquery mechanism, for example, can search from the repository root and return short excerpts around llm_query:

from pathlib import Path

root = Path.cwd()
excerpts = []

for path in sorted(root.rglob("*.py")):
    lines = path.read_text(encoding="utf-8", errors="replace").splitlines()
    for line_no, line in enumerate(lines):
        if "llm_query" in line:
            start = max(0, line_no - 2)
            stop = min(len(lines), line_no + 3)
            excerpt = "\n".join(lines[start:stop])
            excerpts.append(
                f"{path.relative_to(root)}:{line_no + 1}\n{excerpt[:1200]}"
            )
            break
    if len(excerpts) == 6:
        break

print("\n\n".join(excerpts))

The files remain on disk. The observation consists of selected excerpts with file locations, and the output limits keep that inspection from dumping the repository into the model’s context.

The recorded run then sends a prompt through llm_query, receives the response and produces a final answer. This exposes the transition from programmatic evidence collection to a model subquery and then to synthesis.

Jagtap describes this run as making two tool calls. The terminal also displays token usage.

Editor’s note: Jagtap’s companion report counts model requests instead: a root-planning call and an llm_query subcall. The distinction matters when interpreting the count; this demonstration does not establish a general cost or performance result.

The run leaves records that can be inspected afterward. Jagtap opens the stored runs and sessions, showing that the final answer is accompanied by a trace of the work that produced it. He presents these records as material that can be connected to an observability platform.

The experimental terminal interface exposes the same mechanism through a coding-agent-style workflow:

1. Connect a model. Use connect to select the provider and model. The demonstration again uses Gemini.
2. Check the environment. Run doctor. It reports warnings involving Deep Agents, ADK and other framework integrations, which Jagtap identifies as irrelevant to this particular demonstration.
3. Submit a bounded investigation. Send the question with a spending budget. Maximum steps and recursion depth provide additional controls over the run.

These controls make the amount of investigation an explicit part of the request.

After execution, the research-lab view shows completion and a reward display. The more revealing view is the trajectory, which exposes the REPL operations, generated code and final output. An events view records when execution started and ended. Together, these views let the user inspect the sequence of work rather than judge the system only by its final response.

Returning to the slides, Jagtap connects the visible stages: context is loaded, Python extracts snippets, llm_query supplies a model response and the investigation produces its result. The traces are available in JSONL for use in an observability workflow. The answer draws on evidence from multiple files, making the recorded path through that evidence useful alongside the answer itself.

The immediate applications are investigations of large or unfamiliar repositories:

• Root-cause analysis: Gather relevant code and relationships to investigate why a system behaves as it does.
• Repository onboarding: Explore an unfamiliar codebase and build an understanding of its structure.

These are starting points for applying the pattern to a concrete engineering task.

A custom harness should capture the whole trajectory: planning, generated code, observations, subcalls, budget and final output. That record makes it possible to inspect how the investigation proceeded, what evidence it collected and where it spent its resources. The harness can be adapted to the task while preserving visibility into those stages.

The closing discussion turns to related behavior in proprietary agent systems. Jagtap reports seeing posts about managed agents and dynamic workflows using RLM concepts. He also describes observing Codex write Python in a REPL to curate context, and associates Claude and Gemini managed-agent workflows with similar ideas. These are his observations and comparisons, rather than established descriptions of those products’ internal architectures.

The dynamic-workflow example extends the comparison: an agent receives a task, spawns other agents with separate sandboxes and combines their results. That arrangement resembles the consultation-and-return structure of the earlier engineer analogy.

Jagtap suggests that software factories may also use RLM ideas, while explicitly leaving that adoption uncertain. He then reports acknowledgments on X by Anthropic engineers about using RLM concepts.

Editor’s note: The original RLM paper distinguishes ordinary code execution from externalizing context and making programmatic model subqueries. Python execution and separate sandboxes can support that pattern, but do not by themselves establish that a product implements RLM or derives from the research.