A recursive language model treats its context as an object in a Python REPL, so it can inspect, compute over, and transform that context as data.
2
An RLM can delegate work to another language model in the same environment, which lets it break down long or complicated tasks and return only useful results.
3
RLMs performed especially well on long-context tasks that could be reduced to code, while tasks that fit in context or need low latency are better handled without one.
Summary
Kevin Madura explains recursive language models as models that interact with their context through a symbolic environment, usually a Python REPL. The input lives as a variable, so the model can write code to search, filter, calculate, and inspect it instead of attending to every token at once. An RLM can also call another model, including itself, with defined inputs and outputs. This lets it split a task into smaller analyses and keep the main context focused on returned results. Madura compares this approach with RAG, agents, and ordinary tool calls, where context and intermediate results often move around as strings. He shows a cohort retention analysis over three data frames and describes examples involving invoices, logs, agent traces, and a large codebase. He is clear that RLMs add cost and latency, and that simple, fast tasks may not need them. His larger prediction is that models trained to use RLMs directly will require less hand-built context management.
An RLM treats context as data inside a symbolic environment
Madura defines a recursive language model as a model that treats its context as an object it can interact with symbolically. In practice, that environment is usually a Python REPL. Instead of receiving a tool result as another JSON or text string, the model can work directly with a variable containing the input. It can write code to search, transform, or calculate over that object. This gives the model a way to handle inputs that are too large or awkward to reason over token by token. The environment also gives it a place to keep intermediate results while it works.
Delegation lets the model split a task into recursive subproblems
The second defining property is delegation. An RLM can call another language model, often another instance of itself, and specify whether that submodel should use the same or a different model. The subcall also lives in the REPL environment. A parent model can therefore ask a submodel to examine a subset of the input, interpret a result, or perform a separate computation. The returned result can then be used in another step. Madura connects this to the idea that stronger models should decide more of the procedure themselves, rather than requiring every step to be prescribed in advance.
Madura describes context rot as the quality drop that occurs when a context window becomes crowded. In an RLM, the full input can remain as a variable in the REPL rather than being exposed as tokens in the main model context. The model chooses how to access that variable and can send subtasks to submodels. The main model receives the results that matter for its next decision. This differs from RAG, which adds retrieved material to the context, and from many agent or tool-call designs, which pass strings back and forth. The logic, execution, and results remain closer together inside the REPL.
RLMs fit tasks with large inputs and a decomposable structure
Madura recommends RLMs for large or dense inputs, longer sessions, and tasks that can be broken into separate investigations. He gives searching an entire tax code for possible loopholes as an example: submodels could inspect different areas, return interesting sections, and let the main model reason over those sections. He also says large outputs may be a useful target. An RLM is a poor fit when the task already fits in context, when low latency matters, or when the model is not a strong coder. The method adds work, so its value depends on whether code and decomposition help.
Code-friendly tasks show the largest performance gains
Madura cites testing on a long chain-of-thought benchmark where accuracy rose from 2.6 percent to 45.4 percent. He says the strongest results were on tasks that could be expressed as code, including logic puzzles, chess, and chemistry. The model can write code, bring in only the relevant part of the context, compute over it, and return the result. The main model then harvests those results instead of trying to perform every operation while attending to the full input. He also gives a simpler example: finding and summing twelve numbers scattered across 30,000 tokens is better suited to a short regular expression or other programmatic approach.
A REPL makes structured data easier to explore than repeated JSON calls
Madura walks through a cohort retention analysis using three data frames. The RLM receives the data frames, instructions about what to look for, and the desired output types. It then writes code in its own REPL and interacts with the data frames directly, much like working in a Jupyter notebook. It can inspect results, decide what to do next, and optionally delegate a subset of the data to a submodel. The system separates generated code, reasoning, and the final typed answer. A maximum iteration count can be set, but the model itself decides when it has explored enough and calls submit.
RLMs can handle invoices, logs, traces, and large codebases without manual chunking
Madura describes several applications. Predict RLM is used for knowledge work involving PDFs and spreadsheets, including consolidating a directory of complicated invoices into one inventory. He says this avoids designing a separate chunking and embedding strategy for every long document. Another example uses raw log data to surface useful patterns. Halo examines long traces from agent tasks and iterates on the agent harness itself. Madura also runs an RLM over about 500,000 lines of code from an intentionally vulnerable web application to produce a security report. His point is that these tasks can start from the intended objective and input rather than extensive context-engineering code.
Models trained to use RLMs directly could require less manual control
Madura's closing prediction is that RLMs will become more capable when models are post-trained to understand and use the method directly. Current systems can already decide which code to write, when to delegate, and when to submit, but the developer still defines the environment, schemas, and objective. He expects models that are RLM-aware to take better advantage of recursive calls and the REPL. That could allow developers to specify the task and output while leaving more of the procedure to the model. He presents this as a direction that may make the behavior of these systems much more surprising.
"And so you get this ability to recursively decompose problems and apply and have the LLM basically decide how to apply certain logic or certain interpretations or write its own code to solve those problems and then that recurses down."01:31
Who should watch
You are building systems that process long documents, large datasets, logs, traces, or codebases and want to reduce manual chunking and retrieval logic.
You are comparing RAG, agents, and tool calls with a design where a model can run code directly against its context.
You need to decide whether the extra latency and model calls of recursive decomposition are justified for a production workload.
