@Oliviacoder1: MIT just made every AI company's billion dollar bet look embarrassing. They solved AI memory. Not by building a bigger …

X AI KOLs Timeline Papers

Summary

MIT CSAIL researchers propose a novel approach to AI memory that avoids context rot by storing documents externally and having the AI navigate and query them, achieving 10 million token effective context at lower cost.

MIT just made every AI company's billion dollar bet look embarrassing. They solved AI memory. Not by building a bigger brain. By teaching it how to read. The paper dropped on December 31, 2025. Three MIT CSAIL researchers. One idea so obvious it hurts. And a result that makes five years of context window arms racing look like the wrong war entirely. Here is the problem nobody solved. Every AI model on the planet has a hard ceiling. A context window. The maximum amount of text it can hold in working memory at once. Cross that line and something ugly happens — something researchers have a clinical name for. Context rot. The more you pack into an AI's context, the worse it performs on everything already inside it. Facts blur. Information buried in the middle vanishes. The model does not become more capable as you feed it more. It becomes more confused. You give it your entire codebase and it forgets what it read three files ago. You hand it a 500-page legal document and it loses the clause from page 12 by the time it reaches page 400. So the industry built a workaround. RAG. Retrieval Augmented Generation. Chop the document into chunks. Store them in a database. Retrieve the relevant ones when needed. It was always a compromise dressed up as a solution. The retriever guesses which chunks matter before the AI has read anything. If it guesses wrong — and it does, constantly — the AI never sees the information it needed. The act of chunking destroys every relationship between distant paragraphs. The full picture gets shredded into fragments that the AI then tries to reassemble blindfolded. Two bad options. One broken industry. Three MIT researchers and a deadline of December 31st. Here is what they built. Stop putting the document in the AI's memory at all. That is the entire idea. That is the breakthrough. Store the document as a Python variable outside the AI's context window entirely. Tell the AI the variable exists and how big it is. Then get out of the way. When you ask a question, the AI does not try to remember anything. It behaves like a human expert dropped into a library with a computer. It writes code. It searches the document with regular expressions. It slices to the exact section it needs. It scans the structure. It navigates. It finds precisely what is relevant and pulls only that into its active window. Then it does something that makes this recursive. When the AI finds relevant material, it spawns smaller sub-AI instances to read and analyze those sections in parallel. Each one focused. Each one fast. Each one reporting back. The root AI synthesizes everything and produces an answer. No summarization. No deletion. No information loss. No decay. Every byte of the original document remains intact, accessible, and queryable for as long as you need it. Now here are the numbers. Standard frontier models on the hardest long-context reasoning benchmarks: scores near zero. Complete collapse. GPT-5 on a benchmark requiring it to track complex code history beyond 75,000 tokens — could not solve even 10% of problems. RLMs on the same benchmarks: solved them. Dramatically. Double-digit percentage gains over every alternative approach. Successfully handling inputs up to 10 million tokens — 100 times beyond a model's native context window. Cost per query: comparable to or cheaper than standard massive context calls. Read that again. One hundred times the context. Better answers. Same price. The timeline of the arms race makes this sting harder. GPT-3 in 2020: 4,000 tokens. GPT-4: 32,000. Claude 3: 200,000. Gemini: 1 million. Gemini 2: 2 million. Every generation, every company, billions of dollars spent, all betting on the same assumption. More context equals better performance. MIT just proved that assumption was wrong the entire time. Not slightly wrong. Fundamentally wrong. The entire premise of the last five years of context window research — that the solution to AI memory was a bigger window — was the wrong answer to the wrong question. The right question was never how much can you force an AI to hold in its head. It was whether you could teach an AI to know where to look. A human expert handed a 10,000-page archive does not read all 10,000 pages before answering your question. They navigate. They search. They find the relevant section, read it deeply, and synthesize the answer. RLMs are the first AI architecture that works the same way. The code is open source. On GitHub right now. Free. No license fees. No API costs. Drop it in as a replacement for your existing LLM API calls and your application does not even notice the difference — except that it suddenly works on inputs it used to fail on entirely. Prime Intellect — one of the leading AI research labs in the space — has already called RLMs a major research focus and described what comes next: teaching models to manage their own context through reinforcement learning, enabling agents to solve tasks spanning not hours, but weeks and months. The context window wars are over. MIT won them by walking away from the battlefield. Source: Zhang, Kraska, Khattab · MIT CSAIL · arXiv:2512.24601 Paper: http://arxiv.org/abs/2512.24601 GitHub: http://github.com/alexzhang13/rlm
Original Article
View Cached Full Text

Cached at: 06/15/26, 09:14 AM

MIT just made every AI company’s billion dollar bet look embarrassing.

They solved AI memory. Not by building a bigger brain. By teaching it how to read.

The paper dropped on December 31, 2025. Three MIT CSAIL researchers. One idea so obvious it hurts. And a result that makes five years of context window arms racing look like the wrong war entirely.

Here is the problem nobody solved.

Every AI model on the planet has a hard ceiling. A context window. The maximum amount of text it can hold in working memory at once. Cross that line and something ugly happens — something researchers have a clinical name for.

Context rot.

The more you pack into an AI’s context, the worse it performs on everything already inside it. Facts blur. Information buried in the middle vanishes. The model does not become more capable as you feed it more. It becomes more confused. You give it your entire codebase and it forgets what it read three files ago. You hand it a 500-page legal document and it loses the clause from page 12 by the time it reaches page 400.

So the industry built a workaround. RAG. Retrieval Augmented Generation. Chop the document into chunks. Store them in a database. Retrieve the relevant ones when needed.

It was always a compromise dressed up as a solution.

The retriever guesses which chunks matter before the AI has read anything. If it guesses wrong — and it does, constantly — the AI never sees the information it needed. The act of chunking destroys every relationship between distant paragraphs. The full picture gets shredded into fragments that the AI then tries to reassemble blindfolded.

Two bad options. One broken industry. Three MIT researchers and a deadline of December 31st.

Here is what they built.

Stop putting the document in the AI’s memory at all.

That is the entire idea. That is the breakthrough. Store the document as a Python variable outside the AI’s context window entirely. Tell the AI the variable exists and how big it is. Then get out of the way.

When you ask a question, the AI does not try to remember anything. It behaves like a human expert dropped into a library with a computer. It writes code. It searches the document with regular expressions. It slices to the exact section it needs. It scans the structure. It navigates. It finds precisely what is relevant and pulls only that into its active window.

Then it does something that makes this recursive.

When the AI finds relevant material, it spawns smaller sub-AI instances to read and analyze those sections in parallel. Each one focused. Each one fast. Each one reporting back. The root AI synthesizes everything and produces an answer.

No summarization. No deletion. No information loss. No decay. Every byte of the original document remains intact, accessible, and queryable for as long as you need it.

Now here are the numbers.

Standard frontier models on the hardest long-context reasoning benchmarks: scores near zero. Complete collapse. GPT-5 on a benchmark requiring it to track complex code history beyond 75,000 tokens — could not solve even 10% of problems.

RLMs on the same benchmarks: solved them. Dramatically. Double-digit percentage gains over every alternative approach. Successfully handling inputs up to 10 million tokens — 100 times beyond a model’s native context window.

Cost per query: comparable to or cheaper than standard massive context calls.

Read that again. One hundred times the context. Better answers. Same price.

The timeline of the arms race makes this sting harder. GPT-3 in 2020: 4,000 tokens. GPT-4: 32,000. Claude 3: 200,000. Gemini: 1 million. Gemini 2: 2 million. Every generation, every company, billions of dollars spent, all betting on the same assumption.

More context equals better performance.

MIT just proved that assumption was wrong the entire time.

Not slightly wrong. Fundamentally wrong. The entire premise of the last five years of context window research — that the solution to AI memory was a bigger window — was the wrong answer to the wrong question.

The right question was never how much can you force an AI to hold in its head.

It was whether you could teach an AI to know where to look.

A human expert handed a 10,000-page archive does not read all 10,000 pages before answering your question. They navigate. They search. They find the relevant section, read it deeply, and synthesize the answer.

RLMs are the first AI architecture that works the same way.

The code is open source. On GitHub right now. Free. No license fees. No API costs. Drop it in as a replacement for your existing LLM API calls and your application does not even notice the difference — except that it suddenly works on inputs it used to fail on entirely.

Prime Intellect — one of the leading AI research labs in the space — has already called RLMs a major research focus and described what comes next: teaching models to manage their own context through reinforcement learning, enabling agents to solve tasks spanning not hours, but weeks and months.

The context window wars are over.

MIT won them by walking away from the battlefield.

Source: Zhang, Kraska, Khattab · MIT CSAIL · arXiv:2512.24601 Paper: http://arxiv.org/abs/2512.24601 GitHub: http://github.com/alexzhang13/rlm


Recursive Language Models

Source: https://arxiv.org/html/2512.24601 Alex L. Zhang MIT CSAIL [email protected] &Tim Kraska MIT CSAIL [email protected] &Omar Khattab MIT CSAIL [email protected]

Abstract

We study allowing large language models (LLMs) to process arbitrarily long prompts through the lens of inference-time scaling. We proposeRecursive Language Models(RLMs), a general inference paradigm that treats long prompts as part of an externalenvironmentand allows the LLM toprogrammaticallyexamine, decompose, andrecursively call itself oversnippets of the prompt. We find that RLMs can successfully process inputs more than an order of magnitude beyond model context window limits and, even for shorter prompts, dramatically outperform the quality of vanilla frontier LLMs and common long-context and coding scaffolds (e.g., on GPT-5 by a median across the evaluated benchmarks of26%26\%against compaction,130%130\%against CodeAct with sub-calls, and13%13\%against Claude Code) across four diverse long-context tasks while having comparable cost. At a small scale, we post-train the first model around the RLM. Our model,RLM-Qwen3-8B, outperforms the underlying Qwen3-8B model by a median of28%28\%and even approaches the quality of vanilla GPT-5 on three long-context tasks. Code is available athttps://github.com/alexzhang13/rlm.

1Introduction

Refer to captionFigure 1:A comparison of GPT-5 and a corresponding RLM(recursion depth=1) using GPT-5 on three long-context tasks of increasing complexity:S-NIAH,OOLONG, andOOLONG-Pairs. For each task, we scale the input length from2132^{13}to2202^{20}. GPT-5 performance degrades significantly as a function of both input length and task complexity, while the RLM maintains strong performance. Inputs beyond the red region do not fit in GPT-5’s context window of 272K tokens, but the RLM handles them effectively. Additional experiments across other models and benchmarks are in §3.Frontier reasoning models have limited context windows and, even within their limits, tend to exhibitcontext rot(Honget al.,2025), a phenomenon illustrated in Figure1where quality degrades steeply as prompts get longer. Though we expect context lengths to steadily rise through improvements to training, architecture, and infrastructure, we are interested inwhether it is possible to scale the context size of general-purpose LLMs by orders of magnitude. This is increasingly urgent as LLMs begin to be widely adopted for long-horizon tasks, in which they must routinely process tens if not hundreds of millions of tokens.

We study this question through the lens of scaling inference-time compute. We are inspired by the way thatreasoning models, another inference strategy, have become the fundamental interface to LLMs, resulting not only in empirical gains but also additional theoretical expressive power(Merrill and Sabharwal,2024)compared to vanilla Transformers. Though most inference-time methods for dealing with long context are task-specific(Wuet al.,2021; Changet al.,2024), the most popular general approach iscontext condensationorcompaction(Khattabet al.,2021; Smith,2025; OpenAI,2025a; Wuet al.,2025), where context from user requests or agent trajectories is repeatedly summarized once it exceeds a length threshold. Unfortunately, compaction is rarely expressive enough for tasks that require dense access throughout the prompt. It presumes thatsomedetails that appear early in the prompt can safely be forgotten to make room for new content.

Refer to captionFigure 2:A Recursive Language Model (RLM) treats prompts as part of the environment. It loads the input prompt as a variable inside a REPL environmentℰ\mathcal{E}and writes code to peek into, decompose, and invoke itself recursively over programmatic snippets of the variable.We introduceRecursive Language Models(RLMs), a general-purpose inference paradigm for dramatically scaling the effective input and output lengths of LLMs. The key insight is that arbitrarily long user prompts should not be fed into the neural network (e.g., Transformer) directly but should instead be treated aspart of the environment that the LLM is tasked tosymbolically and recursivelyinteract with.This system serves as an abstracted “language model” without context limitations.

As Figure2shows, an RLM exposes the same external interface as an LLM or a reasoning model: it accepts a string prompt of arbitrary structure and produces a string response. Given a promptPP, the RLM initializes a Read-Eval-Print Loop (REPL) programming environment in whichPPis set as the value of a variable. It then offers the LLM general context about the REPL environment (e.g., the length of the stringPP), and permits it to write code that peeks into and decomposesPP, and to iteratively observe any side effects from execution. Crucially, RLMs encourage the LLM to understand, transform, and execute the input prompt bywriting symbolic programs that invoke the LLM itselfon as many slices of the input as necessary.

By treating the prompt itself as an external object and enabling symbolic recursion, RLMs tackle limitations of expressive power in recent work on coding agents, retrieval agents, and sub-agent delegation. In particular, prior coding agents and retrieval agents treat some designated external data source (e.g., a filesystem or a corpus of search documents) as an environment for fetching snippets. However, they can only fill up the underlying LLM’s context window with snippets before facing compaction. Similarly, prior self-delegation approaches(Anthropic,2025; Sentient AI,2025; Schroederet al.,2025; Sunet al.,2025)allow LLMs to invoke themselves as sub-agents. However, they are handicapped by the underlying LLM’s limited output lengths because they are designed to verbalize sub-calls autoregressively rather than producing them programmatically.

We evaluate RLMs using a frontier closed model (GPT-5;Singhet al.2025) and a frontier open model (Qwen3-Coder-480B-A35B;Qwen Team2025b) across four tasks with varying levels of complexity: deep research(Chenet al.,2025), information aggregation(Bertschet al.,2025), code repository understanding(Baiet al.,2025), and a synthetic pairwise reasoning task where even frontier models fail catastrophically. We compare RLMs against direct LLM calls as well as context compaction, retrieval tool-use agents, and code-generation agents with and without sub-calls.

We find that RLMs demonstrate extremely strong performance even at the 10M+ token scale, and substantially outperform other approaches at long-context processing, in many cases by double-digit percentage gains while maintaining comparable cost. In particular, as demonstrated in Figure1, RLMs exhibit far less severe degradation for longer contexts and more sophisticated tasks.

Finally, at a small scale, we post-train the first natively recursive language model, demonstrating that RLMs can be improved quickly with little additional training. While a small open model (Qwen3-8B;Yanget al.2025) struggles to solve long context tasks even in an RLM scaffold, our simple general-purpose training recipe uses only 1,000 samples from unrelated domains to improve its performance by a median of28.3%28.3\%across the four evaluation tasks.

2Recursive Language Models

Given a base neural language modelℳ\mathcal{M}with maximum context sizeKK, a Recursive Language Model (RLM) is an inference-time scaffold aroundℳ\mathcal{M}that treats the user prompt as part of the environment without giving up the ability to densely process its content through different calls toℳ\mathcal{M}. Given an arbitrary-length prompt stringP∈Σ⋆P\in\Sigma^{\star}, an RLM interacts with a persistent external environmentℰ\mathcal{E}and returns a response stringY∈Σ⋆Y\in\Sigma^{\star}(Figure2). We would like effectivelyunbounded input tokens(|P|≫K|P|\gg K),unbounded output tokens, and anunbounded semantic horizon, e.g. the ability to doΩ​(|P|)\Omega(|P|)orΩ​(|P|2)\Omega(|P|^{2})semantic work.

Algorithm1describes how an RLM achieves this. Given a promptPP, the RLM initializes a persistent REPL programming environment with a variable containing the user prompt as a string and a function for invoking a sub-RLM with a new prompt. Then, it starts the RLM loop. In the first iteration, the algorithm invokes therootneural modelℳ\mathcal{M}with only (constant-size) metadata about the user prompt, like its length, a short prefix, and how to access parts of it.

The root is instructed via prompting (AppendixC) and/or fine-tuning (AppendixA) to operate like an RLM: that is, togenerate code that helps it understand and transform parts of its promptPP, and to build up intermediate values and the final response into new variables, potentially byinvoking the sub-RLM within loops. In Section4, we find that existing LLMs can be prompted to do this and that training an 8B model to be natively recursive is promising.

Each iteration of the RLM loop executes code in the REPL, updates REPL state (intermediate variables), and collects instdoutany printed text. Only (constant-size) metadata aboutstdout, like a short prefix and length, is appended toℳ\mathcal{M}’s history for the next iteration.111This is key: it forcesℳ\mathcal{M}to rely on variables and sub-calls to manage long strings instead of polluting its window. In principle, if we trim each turn tocctokens, we will have at mostK/cK/croot iterations, each of which can launch arbitrarily many sub-calls. This is not a fundamental limitation, e.g. one could move the root horizon itself into a variable, but we typically want to limit the iterations at any level of recursion irrespective.Once the RLM sets the variableFinalinside the REPL, iteration stops and the value inFinalis returned as the response.

RLMs make three simple design choices that are missing from many existing scaffolds. To highlight these, we include Algorithm2to illustrate a deceptively “similar” algorithm that is far less expressive. Both algorithms support some notion of sub-calls, external objects, and code execution, but they differ in terms of where the prompt and intermediate values live and where recursion occurs.

Input:promptPP

Output:response

YY state

←\leftarrowInitREPL(prompt=P)

state

←\leftarrowAddFunction(state,sub_RLMM)

hist

←[Metadata(state)]\leftarrow[\texttt{Metadata(state)}] whileTruedo

code

←\leftarrowLLMM(hist)

(state,stdout)

←\leftarrowREPL(state, code)

hist

←\leftarrowhist

∥\,\|\,code

∥\,\|\,Metadata(stdout)

ifstate[Final]is setthen

returnstate[Final]

Algorithm 1A recursive language model, around LLMℳ\mathcal{M}, which itself acts as a “language model”. Input:promptPP

Output:response

YY actions

←{Finish,Exec,Search,sub_LLMℳ}\leftarrow\{\texttt{Finish},\,\texttt{Exec},\,\texttt{Search},\,{\color[rgb]{0.78515625,0,0.78515625}\definecolor[named]{pgfstrokecolor}{rgb}{0.78515625,0,0.78515625}\texttt{sub\_LLM}}_{\mathcal{M}}\} hist

←[Metadata(actions),P]\leftarrow[\texttt{Metadata(actions)},\,P]Flaw #1

whileTruedo

(action,val)

←\leftarrowLLMM(hist)

ifactionisFinishthen

returnvalFlaw #2

out

←\leftarrowRUN(action, val)Flaw #3

hist

←\leftarrowhist

∥\|(action,val,out)

ifTok(hist)> Kthen

hist

←\leftarrowCompact(hist)

Algorithm 2Alternate scaffold with standard (poor) design choices.

First, an RLM must give the underlying LLMℳ\mathcal{M}asymbolic handleto the user promptPP, so the model can manipulate it without copying text into the root context window. Instead, ineffective Algorithm2starts by putting the user promptPPinto the LLM context window (hist), inheriting the window limitations ofℳ\mathcal{M}and falling back to heuristics like context compaction. Even though the scaffold can access external data with, say, aSearchaction, it is bounded with respect to user input.

Second, ineffective Algorithm2asksℳ\mathcal{M}to generate the output directly, via aFinishaction. This may seem innocuous, but it means outputs cannot be longer than the context window ofℳ\mathcal{M}.

Third, and perhaps most importantly, an RLM requiressymbolic recursion. That is, code runninginsideℰ\mathcal{E}must be able to invokeℳ\mathcal{M}on programmatically constructed transformations ofPP(e.g., inside arbitrarily large loops), storing intermediate results symbolically. Though Algorithm2includes both a code execution action and a “sub-LLM” action separately, it is not able to invoke the sub-LLM programmatically and hence can only delegate a fewexplicitly verbalized tasksrather than writing short programs that can, say, loop over slices of the prompt and launchΩ​(|P|)\Omega(|P|)or evenΩ​(|P|2)\Omega(|P|^{2})processes to understand or transform all parts ofPP.

We implement our RLM definition in Algorithm1as follows: we equip an LLM with a Python REPL, where all tools, including sub-LM or sub-RLM calls, are available as modules. The initial prompt is stored as a variable in the REPL. The LLM interacts in a loop until it provides a final answer, which can be from either a variable in the REPL, or from the LLM itself. The LLM can also print from the REPL, but it is truncated to prevent overflowing the context too quickly.

3Scaling Long Context Tasks

We hypothesize that the effective context window(Hsiehet al.,2024; Goldmanet al.,2025; Honget al.,2025)of an LLM cannot be understood independently of thespecific task. That is, more “complex” problems will exhibit degradation at evenshorterlengths than simpler ones. Because of this, we must characterize tasks in terms of how their complexityscales with prompt length.

For example, needle-in-a-haystack (NIAH) problems generally keep ‘needles’ constant as prompt length is scaled. As a result, frontier models can now reliably solve these tasks in RULER(Hsiehet al.,2024)in the 1M+ token settings but struggle at far shorter lengths on OOLONG(Bertschet al.,2025), a task where the answer depends explicitly on almost every line in the prompt.222This helps explain the patterns seen in Figure1earlier:GPT-5scales effectively on the S-NIAH task, where the needle size is constant despite longer prompts, but shows faster degradation at increasinglyshortercontext lengths on thelinear-complexity OOLONG and thequadratic-complexity OOLONG-Pairs.

3.1Tasks

We design our evaluation around tasks where we can vary the lengths of the prompts, so we can consider problems whose difficulties scale differently with context length.

S-NIAH. Following the single needle-in-the-haystack task in RULER(Hsiehet al.,2024), we consider a set of 50 single tasks that require finding a specific phrase or number in a large set of unrelated text. Here, the information being sought scales asO​(1)O(1)with respect to input length.

BrowseComp-Plus (1K documents)(Chenet al.,2025). A multi-hop question-answering benchmark for DeepResearch(OpenAI,2025b)questions that requires reasoning over multiple different documents in an offline corpus. FollowingSunet al.(2025), we use 150 randomly sampled instances as our evaluation set; we provide10001000randomly chosen documents as input, in which the gold and evidence documents are guaranteed to exist. We report the percentage of correct answers. The answer to each task requires piecing together information from several documents, making this harder thanS-NIAHdespite also requiring a constant number of documents.

OOLONG(Bertschet al.,2025). A long reasoning benchmark that requires semantically labeling and aggregating these labels to form a final answer. We focus specifically on thetrec_coarsesplit, a set of5050tasks over a dataset of questions with semantic labels. Each task requires using nearly all dataset questions, and therefore scales linearly in processing complexity relative to the input length.

OOLONG-Pairs. A modified variant of thetrec_coarsesplit of OOLONG with2020queries that specifically require aggregatingpairsof chunks to construct the final answer. We report F1 scores over the answer, which is a list of entries. Each task requires using nearly allpairsof entries of the dataset, and therefore requires processing quadratically-many items relative to the input length. In AppendixD.1, we list all queries in this benchmark.

LongBench-v2 CodeQA(Baiet al.,2025). A multi-choice code repository understanding split from LongBench-v2 that is challenging for modern frontier models. Each instance requires reasoning over a fixed number of files in a codebase to find the right answer.

3.2Methods and Baselines

We compare RLMs against commonly used task-agnostic inference methods, using two modern LMs, GPT-5 with medium reasoning(Singhet al.,2025)and default sampling parameters, and Qwen3-Coder-480B-A35B(Yanget al.,2025)using the sampling parameters described inQwen Team (2025b). For Qwen3-Coder-480B-A35B, we compute costs based on the compute provider Fireworks(Fireworks AI,2025). In addition to evaluating the base model on all tasks, we also evaluate the following methods and baselines:

CodeAct.We compare directly to a CodeAct(Wanget al.,2024)agent that can execute code inside of a ReAct(Yaoet al.,2023)loop. Unlike an RLM, CodeAct does not offload the user prompt to the code environment, and instead provides it directly to the LM. We consider two variants: (1) a version followingJimenezet al.(2024); Chenet al.(2025)where we equip this agent with a BM25(Robertson and Zaragoza,2009)retriever; (2) a version with a sub-call tool inside of the REPL. Compared to RLMs, this method loads the context directly into the model.

Compaction agent.FollowingSunet al.(2025); Wuet al.(2025); Yuet al.(2025), we consider an iterative agent that compacts the context as it is filled. For example, given a corpus of documents, it will iteratively accumulate the documents and summarize when full. In cases where a single document exceeds the model window, the agent will chunk the document and iteratively compact it. For the GPT-5 experiments, due to the extremely high cost of applying this strategy to millions of tokens, we use GPT-5-nano for compaction and GPT-5 to provide the final answer.

Coding agents.We compare against commonly used coding agents like OpenCode(Anomaly,2026)and Claude Code(Anthropic,2025). We consider two variants, one where the context is offloaded to a file, and another where it is directly used as the initial prompt. Closed source agents like Claude Code are designed around a corresponding model, so we use Claude Opus 4.1 with Claude Code v2.0.0 (released around the same time as the GPT-5 model we use in our main results) for this baseline.

RLM. We implement an RLM with a Python REPL environment, which loads a module for querying a sub-LM and uses a system prompt presented in AppendixC. For the GPT-5 experiments, we use GPT-5-mini for the recursive LMs and GPT-5 for the root LM, as we found this choice to strike a good balance between the capabilities of RLMs and the cost of the recursive calls. We also evaluate several different max recursion depths allowable to the RLM, from 0-3. Max recursion depth 0 is an RLM without sub-calling capabilities. Max recursion depth 1 allows sub-calling LLMs, while max depth >1 allows sub-calling RLMs. We notate a RLM with max recursion depthNNusing a model as RLM(model, depth=NN), e.g. RLM(GPT-5, depth=2), and assume depth=1 if not stated otherwise.

Fine-tuning.To createRLM-Qwen3-8B, we fine-tune Qwen3-8B on 1,000 filtered trajectories of Qwen3-Coder-480B-A35B as an RLM with Qwen3-8B sub-calls on LongBenchPro(Chenet al.,2026)tasks. We use sampling parameters described inQwen Team (2025a), and evaluate the fine-tuned RLM-Qwen3-8B as an RLM. The key insight for training is that being an effective sub-call model is roughly similar to being a general purpose reasoning model, so we can make the training much more tractable at small scale by focusing on improving the root model’s ability to manipulate the REPL and to launch recursive calls. We provide more training details in AppendixA.

4Results and Discussion

Table1reports our main evaluation results. We additionally explore how vanilla frontier model and RLM performance degrade as input contexts grow in Figure1.

Table 1:Performance comparison of different methods across long-context benchmarks of varying complexity. Ingrayis the average API cost±\pmthe standard deviation of each method on each task.∗indicates runs where a method (sometimes) ran into input context limits. Provider costs were computed under OpenAI for GPT-5, under Fireworks for Qwen3 models, and under Anthropic for Claude Opus 4.1. All non-zero scores are rounded to at least0.10.1.Observation 1: RLMs can scale to the 10M+ token regime and can outperform base LMs and existing task-agnostic agent scaffolds on long context tasks. Across all tasks, RLMs demonstrate strong performance on prompts well beyond the effective context window of a frontier LM, outperforming base models and common long-context scaffolds by up to2×2\timesthe performance while maintaining comparable or cheaper average token costs. Notably, RLMs scale well beyond the base models’ context window. For instance, on BrowseComp-Plus (1K), a linearly extrapolated cost for GPT-5-mini ingesting 6-11M input tokens is​1\.50−​2.75\mathdollar 1.50-\mathdollar 2.75, while RLM(GPT-5, depth=1) has an average cost of$​0.99\mathdollar 0.99and outperforms both the compaction and retrieval baselines by over29%29\%.

Furthermore, on tasks where processing costs scale with the input context, RLMs make significant improvements over the base model, even on tasks within the model’s context window. On OOLONG, the RLM(depth=1) with GPT-5 and Qwen3-Coder outperform the base model by28.4%28.4\%and33.3%33.3\%respectively. On OOLONG-Pairs, both GPT-5 and Qwen3-Coder make little progress with F1 scores of≤0.1%\leq 0.1\%, while the RLM(depth=1) using these models achieve F1 scores of58.0%58.0\%and23.1%23.1\%respectively, highlighting the capability of RLMs to handle extremely information-dense tasks.

Observation 2: The REPL is necessary for handling long inputs, while the recursive sub-calling of RLMs provides strong benefits on information-dense inputs.A key characteristic of RLMs is offloading the context as a variable in an environmentℰ\mathcal{E}that the model can interact with. In particular, RLM(depth=0) and coding agents like Claude Code and OpenCode are able to scale beyond the context limit of the model and outperform other task-agnostic baselines on most long context settings. On CodeQA in particular with Qwen3-Coder-480B-A35B, the no-sub-calling RLM(depth=0) is able to outperform all sub-calling variants of the RLM.

On information-dense tasks like OOLONG or OOLONG-Pairs, we observed several cases where programmatic recursive LM sub-calling is necessary. In §5, we see RLM(Qwen3-Coder) perform the necessary semantic transformation line-by-line through recursive sub-calls, while the ablation without sub-calls is forced to use keyword heuristics to solve these tasks. On OOLONG-Pairs in particular, the higher recursive depth variants of the RLM for GPT-5 outperform all other methods including Claude Code and OpenCode by a large margin.

Observation 3: LM performance degrades as a function of input length and problem complexity, while RLM performance scales better.The benchmarks S-NIAH, OOLONG, and OOLONG-Pairs contain a fixed number of tasks over contexts with lengths ranging from2132^{13}to2202^{20}. Each benchmark can be categorized by different processing complexity of the input context with respect to length (roughly constant, linear, and quadratic respectively). In Figure1, we directly compare an RLM(GPT-5, depth=1) to base GPT-5, and find that GPT-5 performance degrades significantly faster for more complex tasks, which aligns with the findings ofGoldmanet al.(2025), while RLM performance degrades at a slower rate. For context lengths beyond2142^{14}, the RLM consistently outperforms GPT-5.

Furthermore, RLM costs scale proportionally to the complexity of the task, while still remaining in the same order of magnitude of cost as GPT-5 (see Figure16in AppendixF). In §5, we explore the choices that the RLM makes that cause these differences in cost.

Observation 4: The inference cost of RLMs remains comparable to other methods, and in some cases base LM calls.On average, we find in Table1that the inference cost of RLMs is cheaper or comparable to most other baselines, including standard coding agents. Furthermore, in Figure11in AppendixF, we find that the median RLM run is cheaper than the median base model run, but more expensive on average due to outlier trajectories where the RLM struggles to find an answer.

We additionally report runtime numbers of each method in Figures12,13in AppendixF, but we note several important caveats. Unlike API costs, these numbers are heavily dependent on implementation details such as the machine used, API request latency, and the asynchrony of LM calls. In our implementation of the baselines and RLMs, all LM calls are blocking / sequential. Nevertheless, similar to costs, we observe a wide range of runtimes, especially for RLMs.

Table 2:Solve rate onLongCoT-mini(Motwaniet al.,2026), a difficult long reasoning benchmark that frontier models struggle to solve. We select the best performing model from the paper (GPT-5.2) and compare to an RLM with and without decomposition hints (prompt provided in AppendixC.3).Observation 5: Beyond long-context, RLMs enable longer reasoning capabilities.In Table2, we report RLM performance on LongCoT-mini(Motwaniet al.,2026), a challenging long reasoning benchmark where frontier models solve compositional problems containing interdependent subproblems. We compare with the best model reported in the paper, GPT-5.2, and find that RLM(GPT-5.2, depth=1) uses the REPL to outperform the base model. Furthermore, when providing explicit hints on how to decompose tasks, we find the RLM is able to reliably generate a graph of the problem, solving each node using sub-calls as it programmatically traverses the reasoning graph. It outperforms the base model on all domains and by a69.5%69.5\%performance increase overall.

Observation 6: Training RLMs on one domain can improve general downstream RLM performance, as well as efficiency. Training also exhibits length generalization.Certain behaviors in RLM trajectories are common among different domains, such as probing the input and recursively sub-calling on shorter contexts. In Figure3(a), we find thatRLM-Qwen3-8B, a Qwen3-8B model that we fine-tuned on RLM(Qwen3-Coder-480B-A35B) trajectories on a small,unrelatedset of tasks (LongBenchPro;Chenet al.2026) considerably outperforms the base Qwen3-8B as a RLM across all tasks. Furthermore, its inference costs are much lower and more than3×3\timesfaster (see Figure6in AppendixA) due to better decision making and fewer mistakes as a RLM. Furthermore, we find that training RLMs exhibits length generalization; in Figure3(b), we train Qwen3-4B-Instruct-0527 as an RLM(depth=1) on MRCRv2(Vodrahalliet al.,2024), a synthetic long-context task where the model must count and reproduce instances of a body of text in a corpus. By purely training through reinforcement learning with verifiable rewards (RLVR) on a smaller split, we find that RLM(Qwen3-4B-Instruct-0527) is able to generalize to the longer, more difficult split.

Refer to captionFigure 3:(a) We show how rejection fine-tuning Qwen3-8B on distilled RLM(Qwen3-Coder-480B-A35B) trajectories improves performance on the benchmarks in Table1. (b) On MRCRv2(Vodrahalliet al.,2024), RL training RLM(Qwen3-4B-0527-Instruct) on the 64k sequence length, 2-needle split generalizes to the 1M, 8-needle split. We also show the 1M, 8-needle score for a 1M-context frontier model (Gemini 3.1 Pro(Google Gemini Team,2026)).

5Analyses of RLM Trajectories

RLMs exhibit interesting context and problem decomposition behavior. We discuss observable behavior in small and large LLMs as RLMs to understand how we can steer and improve their performance and efficiency through training and prompt tuning.

Observed RLM decomposition patterns.Current models as RLMs attempt to probe, then decompose a task into sub-tasks for recursive sub-calls to solve. In many cases such as on BrowseComp-Plus, the LM uses model priors to programmatically narrow the search space of sub-calls. RLMs are also able to output beyond their context window by stitching together sub-LM calls inside the REPL, which is required to solve tasks like OOLONG-Pairs. We detail particular trajectories in AppendixE.

Refer to captionFigure 4:(a) On OOLONG, we report the performance of RLM(GPT-5) by varying the in-context examples provided in the system prompt. For each rollout, we categorize the first task decomposition attempt made by the RLM. (b) From the RLM(depth=1) runs in Table1, we report, bucketed by correct or incorrect rollouts, the percentage of RLM trajectories with at least one syntax error.First decomposition and errors in RLM trajectories.RLMs defer essentially unbounded-length reasoning chains to sub-LM calls. The choice of decomposition can greatly affect task performance, especially for information-dense problems. In Figure4(a), we ablate how sensitive RLM behavior is to in-context decomposition examples in its system prompt on OOLONG. We find that in-context RLM trajectories greatly improve both overall performance and the initial decomposition attempt made by the RLM, even if the example is unrelated to the actual task. Furthermore, while RLMs frequently recover from an initially incorrect decomposition pattern, we find that the first decomposition attempt is important for overall performance. In Figure4(b), we plot how many RLM(depth=1) trajectories in Table1contains syntax errors. We find that RLM(Qwen3-Coder) trajectories contain significantly more syntax errors, even for correct trajectories, compared to RLM(GPT-5). These errors explain why higher recursion depths for RLM(Qwen3-Coder)perform worse on average: Qwen3-Coder-480B-A35B often makes syntax errors that result in failed outputs, and having sub-RLM calls propagates this issue to sub-calls. We include additional analysis for erroneous RLM behavior in AppendixF.1.

6Related Works

Long-Context LM Systems.There have primarily been two orthogonal directions for long-context management in language model systems: 1) directly changing the architecture of and retraining the base LM to handle longer contexts(Presset al.,2022; Guet al.,2022; Munkhdalaiet al.,2024), and 2) building a scaffold around the LM that implicitly handles the context – RLMs focus on the latter. One popular class of such strategies islossycontext management(Chenet al.,2023), which uses compaction or truncation to compress the input context at the cost of potentially losing fine-grained information. For example, ReSum(Wuet al.,2025)adds a summarization tool to periodically compress the context of a multi-turn agent. Another class of strategies implement an explicit memory hierarchy in the agent scaffold(Packeret al.,2024; Chhikaraet al.,2025; Zhanget al.,2025). RLMs differ from these works in that all context window management is implicitly handled by the LM itself.

Task Decomposition through sub-LM calls.Many LM-based agents(Guoet al.,2024; Anthropic,2025)use multiple, well-placed LM calls to solve a problem; however, many of these calls are placed based on human-engineered workflows. Several methods like ViperGPT(Suríset al.,2023), THREAD(Schroederet al.,2025), ReDel(Zhuet al.,2024), Context Folding(Sunet al.,2025), and AgentFold(Yeet al.,2025)have explored deferring the choice of sub-LM calls to the LM. These techniques emphasizetaskdecomposition through recursive LM calls, but are unable to handle long context inputs beyond the length of the base LM. DisCIPL(Grandet al.,2025)generates programs with sub-LM calls, but these programs are generated in a single-step and cannot recover from generation mistakes. RLMs, on the other hand, are enabled by an extremely simple intuition (i.e., placing the prompt in the external environment) tosymbolicallymanipulate arbitrarily long strings and to iteratively refine their recursion via execution feedback from the persistent REPL.

7Limitations and Future Work

While RLMs show strong performance on tasks beyond the context window limitations of existing LMs at reasonable inference costs, evaluations for more difficult and natural long-context processing tasks and the best mechanisms for implementing guardrails for RLMs both remain highly under-explored. Broadly, RLMs add a layer of complexity on top of existing LMs that may lead to unintentional side-effects like exploding sub-call costs, which we leave for future work to solve. We also note that future strategies involving asynchronous sub-calls and sandboxed REPLs can potentially significantly reduce the runtime and inference cost of RLMs, but further contribute to this complexity. We include additional limitations and negative results in AppendixB.

Lastly, we focused our experiments on evaluating RLMs usingexistingfrontier models, but show initial evidence on a Qwen3-8B model that explicit training as a RLM provides very rapid performance improvements, even outside the training domain. We hypothesize that RLM trajectories can be viewed as a form of reasoning(OpenAIet al.,2024; DeepSeek-AIet al.,2025), which can be trained by bootstrapping existing models(Zelikmanet al.,2022,2024). We hope that training native RLMs can be treated as a new axis of scale to improve LM performance on general and long-horizon tasks.

8Conclusion

We introduced Recursive Language Models (RLMs), a general inference framework for language models that offloads the input context and enables language models to recursively sub-query language models before providing an output. We explored an instantiation of this framework that offloads the context into a Python REPL environment as a variable in memory, enabling the LM to reason over its context in code and recursive LM calls, rather than purely in token space. Our results across multiple settings and models demonstrated that RLMs are an effective task-agnostic paradigm for both long-context problems and general reasoning. Building on our small fine-tuning experiments, we are excited to see future work that explicitly trains models to reason as RLMs, which could result in another axis of scale for the next generation of language model systems.

References

  • Anomaly (2026)Opencode: the open source ai coding agent.External Links:LinkCited by:§3.2.
  • Anthropic (2025)Claude code: subagents — modular ai workflows with isolated agent contexts.External Links:LinkCited by:§C.2,§1,§3.2,§6.
  • Y. Bai, S. Tu, J. Zhang, H. Peng, X. Wang, X. Lv, S. Cao, J. Xu, L. Hou, Y. Dong, J. Tang, and J. Li (2025)LongBench v2: towards deeper understanding and reasoning on realistic long-context multitasks.External Links:2412.15204,LinkCited by:§1,§3.1.
  • A. Bertsch, A. Pratapa, T. Mitamura, G. Neubig, and M. R. Gormley (2025)Oolong: evaluating long context reasoning and aggregation capabilities.External Links:2511.02817,LinkCited by:Appendix B,§D.1,§1,§3.1,§3.
  • Y. Chang, K. Lo, T. Goyal, and M. Iyyer (2024)BooookScore: a systematic exploration of book-length summarization in the era of LLMs.InThe Twelfth International Conference on Learning Representations,External Links:LinkCited by:§1.
  • H. Chen, R. Pasunuru, J. Weston, and A. Celikyilmaz (2023)Walking down the memory maze: beyond context limit through interactive reading.External Links:2310.05029,LinkCited by:§6.
  • Z. Chen, X. Ma, S. Zhuang, P. Nie, K. Zou, A. Liu, J. Green, K. Patel, R. Meng, M. Su, S. Sharifymoghaddam, Y. Li, H. Hong, X. Shi, X. Liu, N. Thakur, C. Zhang, L. Gao, W. Chen, and J. Lin (2025)BrowseComp-plus: a more fair and transparent evaluation benchmark of deep-research agent.External Links:2508.06600,LinkCited by:§C.1,§D.2,§1,§3.1,§3.2.
  • Z. Chen, X. Wu, J. Jia, C. Gao, Q. Fu, D. Zhang, and S. Hu (2026)LongBench pro: a more realistic and comprehensive bilingual long-context evaluation benchmark.External Links:2601.02872,LinkCited by:Appendix A,§3.2,§4.
  • P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav (2025)Mem0: building production-ready ai agents with scalable long-term memory.External Links:2504.19413,LinkCited by:§6.
  • DeepSeek-AI, D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Bi, X. Zhang, X. Yu, Y. Wu, Z. F. Wu, Z. Gou, Z. Shao, Z. Li, Z. Gao, A. Liu, B. Xue, B. Wang, B. Wu, B. Feng, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruan, D. Dai, D. Chen, D. Ji, E. Li, F. Lin, F. Dai, F. Luo, G. Hao, G. Chen, G. Li, H. Zhang, H. Bao, H. Xu, H. Wang, H. Ding, H. Xin, H. Gao, H. Qu, H. Li, J. Guo, J. Li, J. Wang, J. Chen, J. Yuan, J. Qiu, J. Li, J. L. Cai, J. Ni, J. Liang, J. Chen, K. Dong, K. Hu, K. Gao, K. Guan, K. Huang, K. Yu, L. Wang, L. Zhang, L. Zhao, L. Wang, L. Zhang, L. Xu, L. Xia, M. Zhang, M. Zhang, M. Tang, M. Li, M. Wang, M. Li, N. Tian, P. Huang, P. Zhang, Q. Wang, Q. Chen, Q. Du, R. Ge, R. Zhang, R. Pan, R. Wang, R. J. Chen, R. L. Jin, R. Chen, S. Lu, S. Zhou, S. Chen, S. Ye, S. Wang, S. Yu, S. Zhou, S. Pan, S. S. Li, S. Zhou, S. Wu, S. Ye, T. Yun, T. Pei, T. Sun, T. Wang, W. Zeng, W. Zhao, W. Liu, W. Liang, W. Gao, W. Yu, W. Zhang, W. L. Xiao, W. An, X. Liu, X. Wang, X. Chen, X. Nie, X. Cheng, X. Liu, X. Xie, X. Liu, X. Yang, X. Li, X. Su, X. Lin, X. Q. Li, X. Jin, X. Shen, X. Chen, X. Sun, X. Wang, X. Song, X. Zhou, X. Wang, X. Shan, Y. K. Li, Y. Q. Wang, Y. X. Wei, Y. Zhang, Y. Xu, Y. Li, Y. Zhao, Y. Sun, Y. Wang, Y. Yu, Y. Zhang, Y. Shi, Y. Xiong, Y. He, Y. Piao, Y. Wang, Y. Tan, Y. Ma, Y. Liu, Y. Guo, Y. Ou, Y. Wang, Y. Gong, Y. Zou, Y. He, Y. Xiong, Y. Luo, Y. You, Y. Liu, Y. Zhou, Y. X. Zhu, Y. Xu, Y. Huang, Y. Li, Y. Zheng, Y. Zhu, Y. Ma, Y. Tang, Y. Zha, Y. Yan, Z. Z. Ren, Z. Ren, Z. Sha, Z. Fu, Z. Xu, Z. Xie, Z. Zhang, Z. Hao, Z. Ma, Z. Yan, Z. Wu, Z. Gu, Z. Zhu, Z. Liu, Z. Li, Z. Xie, Z. Song, Z. Pan, Z. Huang, Z. Xu, Z. Zhang, and Z. Zhang (2025)DeepSeek-r1: incentivizing reasoning capability in llms via reinforcement learning.External Links:2501.12948,LinkCited by:§7.
  • Fireworks AI (2025)Qwen3 coder 480b a35b instruct.Note:https://fireworks.ai/models/fireworks/qwen3-coder-480b-a35b-instructCited by:§3.2.
  • O. Goldman, A. Jacovi, A. Slobodkin, A. Maimon, I. Dagan, and R. Tsarfaty (2025)Is it really long context if all you need is retrieval? towards genuinely difficult long context nlp.External Links:2407.00402,LinkCited by:§3,§4.
  • Google Gemini Team (2026)Note:Accessed: 2026-05-05External Links:LinkCited by:Figure 3,Figure 3.
  • G. Grand, J. B. Tenenbaum, V. K. Mansinghka, A. K. Lew, and J. Andreas (2025)Self-steering language models.arXiv preprint arXiv:2504.07081.Cited by:§6.
  • A. Gu, K. Goel, and C. Ré (2022)Efficiently modeling long sequences with structured state spaces.External Links:2111.00396,LinkCited by:§6.
  • T. Guo, X. Chen, Y. Wang, R. Chang, S. Pei, N. V. Chawla, O. Wiest, and X. Zhang (2024)Large language model based multi-agents: a survey of progress and challenges.External Links:2402.01680,LinkCited by:§6.
  • K. Hong, A. Troynikov, and J. Huber (2025)Context rot: how context degradation affects llm performance.External Links:LinkCited by:§1,§3.
  • C. Hsieh, S. Sun, S. Kriman, S. Acharya, D. Rekesh, F. Jia, Y. Zhang, and B. Ginsburg (2024)RULER: what’s the real context size of your long-context language models?.External Links:2404.06654,LinkCited by:§3.1,§3,§3.
  • C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan (2024)SWE-bench: can language models resolve real-world github issues?.External Links:2310.06770,LinkCited by:§3.2.
  • O. Khattab, C. Potts, and M. Zaharia (2021)Baleen: robust multi-hop reasoning at scale via condensed retrieval.Advances in Neural Information Processing Systems34,pp. 27670–27682.Cited by:§1.
  • W. Merrill and A. Sabharwal (2024)The expressive power of transformers with chain of thought.InThe Twelfth International Conference on Learning Representations,Cited by:§1.
  • S. R. Motwani, D. Nichols, C. London, P. Li, F. Pizzati, A. Blake, H. Hammoud, T. McDonald, A. Naik, A. Ivanova, V. Baskaran, I. Laptev, R. Glatt, T. Ben-Nun, P. Torr, N. Jaques, A. Prabhu, B. Bartoldson, B. Kailkhura, and C. S. de Witt (2026)LongCoT: benchmarking long-horizon chain-of-thought reasoning.External Links:2604.14140,LinkCited by:Table 3,Table 3,Table 2,Table 2,§4.
  • T. Munkhdalai, M. Faruqui, and S. Gopal (2024)Leave no context behind: efficient infinite context transformers with infini-attention.External Links:2404.07143,LinkCited by:§6.
  • OpenAI, A. Jaech, A. Kalai, A. Lerer, A. Richardson, A. El-Kishky, A. Low, A. Helyar, A. Madry, A. Beutel, A. Carney, A. Iftimie, A. Karpenko, A. T. Passos, A. Neitz, A. Prokofiev, A. Wei, A. Tam, A. Bennett, A. Kumar, A. Saraiva, A. Vallone, A. Duberstein, A. Kondrich, A. Mishchenko, A. Applebaum, A. Jiang, A. Nair, B. Zoph, B. Ghorbani, B. Rossen, B. Sokolowsky, B. Barak, B. McGrew, B. Minaiev, B. Hao, B. Baker, B. Houghton, B. McKinzie, B. Eastman, C. Lugaresi, C. Bassin, C. Hudson, C. M. Li, C. de Bourcy, C. Voss, C. Shen, C. Zhang, C. Koch, C. Orsinger, C. Hesse, C. Fischer, C. Chan, D. Roberts, D. Kappler, D. Levy, D. Selsam, D. Dohan, D. Farhi, D. Mely, D. Robinson, D. Tsipras, D. Li, D. Oprica, E. Freeman, E. Zhang, E. Wong, E. Proehl, E. Cheung, E. Mitchell, E. Wallace, E. Ritter, E. Mays, F. Wang, F. P. Such, F. Raso, F. Leoni, F. Tsimpourlas, F. Song, F. von Lohmann, F. Sulit, G. Salmon, G. Parascandolo, G. Chabot, G. Zhao, G. Brockman, G. Leclerc, H. Salman, H. Bao, H. Sheng, H. Andrin, H. Bagherinezhad, H. Ren, H. Lightman, H. W. Chung, I. Kivlichan, I. O’Connell, I. Osband, I. C. Gilaberte, I. Akkaya, I. Kostrikov, I. Sutskever, I. Kofman, J. Pachocki, J. Lennon, J. Wei, J. Harb, J. Twore, J. Feng, J. Yu, J. Weng, J. Tang, J. Yu, J. Q. Candela, J. Palermo, J. Parish, J. Heidecke, J. Hallman, J. Rizzo, J. Gordon, J. Uesato, J. Ward, J. Huizinga, J. Wang, K. Chen, K. Xiao, K. Singhal, K. Nguyen, K. Cobbe, K. Shi, K. Wood, K. Rimbach, K. Gu-Lemberg, K. Liu, K. Lu, K. Stone, K. Yu, L. Ahmad, L. Yang, L. Liu, L. Maksin, L. Ho, L. Fedus, L. Weng, L. Li, L. McCallum, L. Held, L. Kuhn, L. Kondraciuk, L. Kaiser, L. Metz, M. Boyd, M. Trebacz, M. Joglekar, M. Chen, M. Tintor, M. Meyer, M. Jones, M. Kaufer, M. Schwarzer, M. Shah, M. Yatbaz, M. Y. Guan, M. Xu, M. Yan, M. Glaese, M. Chen, M. Lampe, M. Malek, M. Wang, M. Fradin, M. McClay, M. Pavlov, M. Wang, M. Wang, M. Murati, M. Bavarian, M. Rohaninejad, N. McAleese, N. Chowdhury, N. Chowdhury, N. Ryder, N. Tezak, N. Brown, O. Nachum, O. Boiko, O. Murk, O. Watkins, P. Chao, P. Ashbourne, P. Izmailov, P. Zhokhov, R. Dias, R. Arora, R. Lin, R. G. Lopes, R. Gaon, R. Miyara, R. Leike, R. Hwang, R. Garg, R. Brown, R. James, R. Shu, R. Cheu, R. Greene, S. Jain, S. Altman, S. Toizer, S. Toyer, S. Miserendino, S. Agarwal, S. Hernandez, S. Baker, S. McKinney, S. Yan, S. Zhao, S. Hu, S. Santurkar, S. R. Chaudhuri, S. Zhang, S. Fu, S. Papay, S. Lin, S. Balaji, S. Sanjeev, S. Sidor, T. Broda, A. Clark, T. Wang, T. Gordon, T. Sanders, T. Patwardhan, T. Sottiaux, T. Degry, T. Dimson, T. Zheng, T. Garipov, T. Stasi, T. Bansal, T. Creech, T. Peterson, T. Eloundou, V. Qi, V. Kosaraju, V. Monaco, V. Pong, V. Fomenko, W. Zheng, W. Zhou, W. McCabe, W. Zaremba, Y. Dubois, Y. Lu, Y. Chen, Y. Cha, Y. Bai, Y. He, Y. Zhang, Y. Wang, Z. Shao, and Z. Li (2024)OpenAI o1 system card.External Links:2412.16720,LinkCited by:§7.
  • OpenAI (2025a)Codex cli: a lightweight coding agent for your terminal.External Links:LinkCited by:§1.
  • OpenAI (2025b)Deep research.Note:AI-powered research assistant toolExternal Links:LinkCited by:§3.1.
  • C. Packer, S. Wooders, K. Lin, V. Fang, S. G. Patil, I. Stoica, and J. E. Gonzalez (2024)MemGPT: towards llms as operating systems.External Links:2310.08560,LinkCited by:§6.
  • O. Press, N. A. Smith, and M. Lewis (2022)Train short, test long: attention with linear biases enables input length extrapolation.External Links:2108.12409,LinkCited by:§6.
  • Prime Intellect Team, M. Senghaas, F. Obeid, S. Jaghouar, W. Brown, J. M. Ong, D. Auras, M. Sirovatka, J. Straube, A. Baker, S. Müller, J. Mattern, M. Basra, A. Ismail, D. Scherm, C. Miller, A. Patel, S. Kirsten, M. Sieg, C. Reetz, K. Erdem, V. Weisser, and J. Hagemann (2025)INTELLECT-3: technical report.External Links:2512.16144,LinkCited by:Appendix A,Appendix A.
  • Qwen Team (2025a)Qwen3-8b.Note:https://huggingface.co/Qwen/Qwen3-8BCited by:Appendix A,§3.2.
  • Qwen Team (2025b)Qwen3-coder-480b-a35b-instruct.Note:https://huggingface.co/Qwen/Qwen3-Coder-480B-A35B-InstructCited by:Appendix A,§1,§3.2.
  • J. Redmon and A. Farhadi (2018)YOLOv3: an incremental improvement.External Links:1804.02767,LinkCited by:Appendix B.
  • S. Robertson and H. Zaragoza (2009)The probabilistic relevance framework: bm25 and beyond.Found. Trends Inf. Retr.3(4),pp. 333–389.External Links:ISSN 1554-0669,Link,DocumentCited by:§3.2.
  • P. Schroeder, N. Morgan, H. Luo, and J. Glass (2025)THREAD: thinking deeper with recursive spawning.External Links:2405.17402,LinkCited by:§1,§6.
  • Sentient AI (2025)ROMA: the backbone for open-source meta-agents.Sentient.Note:Accessed: 2025-12-20External Links:LinkCited by:§1.
  • A. Singh, A. Fry, A. Perelman, A. Tart, A. Ganesh, A. El-Kishky, A. McLaughlin, A. Low, A. Ostrow, A. Ananthram, A. Nathan, A. Luo, A. Helyar, A. Madry, A. Efremov, A. Spyra, A. Baker-Whitcomb, A. Beutel, A. Karpenko, A. Makelov, A. Neitz, A. Wei, A. Barr, A. Kirchmeyer, A. Ivanov, A. Christakis, A. Gillespie, A. Tam, A. Bennett, A. Wan, A. Huang, A. M. Sandjideh, A. Yang, A. Kumar, A. Saraiva, A. Vallone, A. Gheorghe, A. G. Garcia, A. Braunstein, A. Liu, A. Schmidt, A. Mereskin, A. Mishchenko, A. Applebaum, A. Rogerson, A. Rajan, A. Wei, A. Kotha, A. Srivastava, A. Agrawal, A. Vijayvergiya, A. Tyra, A. Nair, A. Nayak, B. Eggers, B. Ji, B. Hoover, B. Chen, B. Chen, B. Barak, B. Minaiev, B. Hao, B. Baker, B. Lightcap, B. McKinzie, B. Wang, B. Quinn, B. Fioca, B. Hsu, B. Yang, B. Yu, B. Zhang, B. Brenner, C. R. Zetino, C. Raymond, C. Lugaresi, C. Paz, C. Hudson, C. Whitney, C. Li, C. Chen, C. Cole, C. Voss, C. Ding, C. Shen, C. Huang, C. Colby, C. Hallacy, C. Koch, C. Lu, C. Kaplan, C. Kim, C. Minott-Henriques, C. Frey, C. Yu, C. Czarnecki, C. Reid, C. Wei, C. Decareaux, C. Scheau, C. Zhang, C. Forbes, D. Tang, D. Goldberg, D. Roberts, D. Palmie, D. Kappler, D. Levine, D. Wright, D. Leo, D. Lin, D. Robinson, D. Grabb, D. Chen, D. Lim, D. Salama, D. Bhattacharjee, D. Tsipras, D. Li, D. Yu, D. Strouse, D. Williams, D. Hunn, E. Bayes, E. Arbus, E. Akyurek, E. Y. Le, E. Widmann, E. Yani, E. Proehl, E. Sert, E. Cheung, E. Schwartz, E. Han, E. Jiang, E. Mitchell, E. Sigler, E. Wallace, E. Ritter, E. Kavanaugh, E. Mays, E. Nikishin, F. Li, F. P. Such, F. de Avila Belbute Peres, F. Raso, F. Bekerman, F. Tsimpourlas, F. Chantzis, F. Song, F. Zhang, G. Raila, G. McGrath, G. Briggs, G. Yang, G. Parascandolo, G. Chabot, G. Kim, G. Zhao, G. Valiant, G. Leclerc, H. Salman, H. Wang, H. Sheng, H. Jiang, H. Wang, H. Jin, H. Sikchi, H. Schmidt, H. Aspegren, H. Chen, H. Qiu, H. Lightman, I. Covert, I. Kivlichan, I. Silber, I. Sohl, I. Hammoud, I. Clavera, I. Lan, I. Akkaya, I. Kostrikov, I. Kofman, I. Etinger, I. Singal, J. Hehir, J. Huh, J. Pan, J. Wilczynski, J. Pachocki, J. Lee, J. Quinn, J. Kiros, J. Kalra, J. Samaroo, J. Wang, J. Wolfe, J. Chen, J. Wang, J. Harb, J. Han, J. Wang, J. Zhao, J. Chen, J. Yang, J. Tworek, J. Chand, J. Landon, J. Liang, J. Lin, J. Liu, J. Wang, J. Tang, J. Yin, J. Jang, J. Morris, J. Flynn, J. Ferstad, J. Heidecke, J. Fishbein, J. Hallman, J. Grant, J. Chien, J. Gordon, J. Park, J. Liss, J. Kraaijeveld, J. Guay, J. Mo, J. Lawson, J. McGrath, J. Vendrow, J. Jiao, J. Lee, J. Steele, J. Wang, J. Mao, K. Chen, K. Hayashi, K. Xiao, K. Salahi, K. Wu, K. Sekhri, K. Sharma, K. Singhal, K. Li, K. Nguyen, K. Gu-Lemberg, K. King, K. Liu, K. Stone, K. Yu, K. Ying, K. Georgiev, K. Lim, K. Tirumala, K. Miller, L. Ahmad, L. Lv, L. Clare, L. Fauconnet, L. Itow, L. Yang, L. Romaniuk, L. Anise, L. Byron, L. Pathak, L. Maksin, L. Lo, L. Ho, L. Jing, L. Wu, L. Xiong, L. Mamitsuka, L. Yang, L. McCallum, L. Held, L. Bourgeois, L. Engstrom, L. Kuhn, L. Feuvrier, L. Zhang, L. Switzer, L. Kondraciuk, L. Kaiser, M. Joglekar, M. Singh, M. Shah, M. Stratta, M. Williams, M. Chen, M. Sun, M. Cayton, M. Li, M. Zhang, M. Aljubeh, M. Nichols, M. Haines, M. Schwarzer, M. Gupta, M. Shah, M. Huang, M. Dong, M. Wang, M. Glaese, M. Carroll, M. Lampe, M. Malek, M. Sharman, M. Zhang, M. Wang, M. Pokrass, M. Florian, M. Pavlov, M. Wang, M. Chen, M. Wang, M. Feng, M. Bavarian, M. Lin, M. Abdool, M. Rohaninejad, N. Soto, N. Staudacher, N. LaFontaine, N. Marwell, N. Liu, N. Preston, N. Turley, N. Ansman, N. Blades, N. Pancha, N. Mikhaylin, N. Felix, N. Handa, N. Rai, N. Keskar, N. Brown, O. Nachum, O. Boiko, O. Murk, O. Watkins, O. Gleeson, P. Mishkin, P. Lesiewicz, P. Baltescu, P. Belov, P. Zhokhov, P. Pronin, P. Guo, P. Thacker, Q. Liu, Q. Yuan, Q. Liu, R. Dias, R. Puckett, R. Arora, R. T. Mullapudi, R. Gaon, R. Miyara, R. Song, R. Aggarwal, R. Marsan, R. Yemiru, R. Xiong, R. Kshirsagar, R. Nuttall, R. Tsiupa, R. Eldan, R. Wang, R. James, R. Ziv, R. Shu, R. Nigmatullin, S. Jain, S. Talaie, S. Altman, S. Arnesen, S. Toizer, S. Toyer, S. Miserendino, S. Agarwal, S. Yoo, S. Heon, S. Ethersmith, S. Grove, S. Taylor, S. Bubeck, S. Banesiu, S. Amdo, S. Zhao, S. Wu, S. Santurkar, S. Zhao, S. R. Chaudhuri, S. Krishnaswamy, Shuaiqi, Xia, S. Cheng, S. Anadkat, S. P. Fishman, S. Tobin, S. Fu, S. Jain, S. Mei, S. Egoian, S. Kim, S. Golden, S. Mah, S. Lin, S. Imm, S. Sharpe, S. Yadlowsky, S. Choudhry, S. Eum, S. Sanjeev, T. Khan, T. Stramer, T. Wang, T. Xin, T. Gogineni, T. Christianson, T. Sanders, T. Patwardhan, T. Degry, T. Shadwell, T. Fu, T. Gao, T. Garipov, T. Sriskandarajah, T. Sherbakov, T. Kaftan, T. Hiratsuka, T. Wang, T. Song, T. Zhao, T. Peterson, V. Kharitonov, V. Chernova, V. Kosaraju, V. Kuo, V. Pong, V. Verma, V. Petrov, W. Jiang, W. Zhang, W. Zhou, W. Xie, W. Zhan, W. McCabe, W. DePue, W. Ellsworth, W. Bain, W. Thompson, X. Chen, X. Qi, X. Xiang, X. Shi, Y. Dubois, Y. Yu, Y. Khakbaz, Y. Wu, Y. Qian, Y. T. Lee, Y. Chen, Y. Zhang, Y. Xiong, Y. Tian, Y. Cha, Y. Bai, Y. Yang, Y. Yuan, Y. Li, Y. Zhang, Y. Yang, Y. Jin, Y. Jiang, Y. Wang, Y. Wang, Y. Liu, Z. Stubenvoll, Z. Dou, Z. Wu, and Z. Wang (2025)OpenAI gpt-5 system card.External Links:2601.03267,LinkCited by:§1,§3.2.
  • C. Smith (2025)OpenHands context condensensation for more efficient ai agents.External Links:LinkCited by:§1.
  • W. Sun, M. Lu, Z. Ling, K. Liu, X. Yao, Y. Yang, and J. Chen (2025)Scaling long-horizon llm agent via context-folding.External Links:2510.11967,LinkCited by:§C.2,§1,§3.1,§3.2,§6.
  • D. Surís, S. Menon, and C. Vondrick (2023)ViperGPT: visual inference via python execution for reasoning.Proceedings of IEEE International Conference on Computer Vision (ICCV).Cited by:§6.
  • K. Vodrahalli, S. Ontanon, N. Tripuraneni, K. Xu, S. Jain, R. Shivanna, J. Hui, N. Dikkala, M. Kazemi, B. Fatemi, R. Anil, E. Dyer, S. Shakeri, R. Vij, H. Mehta, V. Ramasesh, Q. Le, E. Chi, Y. Lu, O. Firat, A. Lazaridou, J. Lespiau, N. Attaluri, and K. Olszewska (2024)Michelangelo: long context evaluations beyond haystacks via latent structure queries.External Links:2409.12640,LinkCited by:Appendix A,Figure 3,Figure 3,§4.
  • X. Wang, Y. Chen, L. Yuan, Y. Zhang, Y. Li, H. Peng, and H. Ji (2024)Executable code actions elicit better llm agents.External Links:2402.01030,LinkCited by:§3.2.
  • J. Wu, L. Ouyang, D. M. Ziegler, N. Stiennon, R. Lowe, J. Leike, and P. Christiano (2021)Recursively summarizing books with human feedback.External Links:2109.10862,LinkCited by:§1.
  • X. Wu, K. Li, Y. Zhao, L. Zhang, L. Ou, H. Yin, Z. Zhang, X. Yu, D. Zhang, Y. Jiang, P. Xie, F. Huang, M. Cheng, S. Wang, H. Cheng, and J. Zhou (2025)ReSum: unlocking long-horizon search intelligence via context summarization.External Links:2509.13313,LinkCited by:§C.2,§1,§3.2,§6.
  • A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv, C. Zheng, D. Liu, F. Zhou, F. Huang, F. Hu, H. Ge, H. Wei, H. Lin, J. Tang, J. Yang, J. Tu, J. Zhang, J. Yang, J. Yang, J. Zhou, J. Zhou, J. Lin, K. Dang, K. Bao, K. Yang, L. Yu, L. Deng, M. Li, M. Xue, M. Li, P. Zhang, P. Wang, Q. Zhu, R. Men, R. Gao, S. Liu, S. Luo, T. Li, T. Tang, W. Yin, X. Ren, X. Wang, X. Zhang, X. Ren, Y. Fan, Y. Su, Y. Zhang, Y. Zhang, Y. Wan, Y. Liu, Z. Wang, Z. Cui, Z. Zhang, Z. Zhou, and Z. Qiu (2025)Qwen3 technical report.External Links:2505.09388,LinkCited by:Appendix B,§1,§3.2.
  • S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao (2023)ReAct: synergizing reasoning and acting in language models.External Links:2210.03629,LinkCited by:§3.2.
  • R. Ye, Z. Zhang, K. Li, H. Yin, Z. Tao, Y. Zhao, L. Su, L. Zhang, Z. Qiao, X. Wang, P. Xie, F. Huang, S. Chen, J. Zhou, and Y. Jiang (2025)AgentFold: long-horizon web agents with proactive context management.External Links:2510.24699,LinkCited by:§6.
  • H. Yu, T. Chen, J. Feng, J. Chen, W. Dai, Q. Yu, Y. Zhang, W. Ma, J. Liu, M. Wang, and H. Zhou (2025)MemAgent: reshaping long-context llm with multi-conv rl-based memory agent.External Links:2507.02259,LinkCited by:§C.2,§3.2.
  • E. Zelikman, G. Harik, Y. Shao, V. Jayasiri, N. Haber, and N. D. Goodman (2024)Quiet-star: language models can teach themselves to think before speaking.External Links:2403.09629,LinkCited by:§7.
  • E. Zelikman, Y. Wu, J. Mu, and N. D. Goodman (2022)STaR: bootstrapping reasoning with reasoning.External Links:2203.14465,LinkCited by:§7.
  • G. Zhang, M. Fu, G. Wan, M. Yu, K. Wang, and S. Yan (2025)G-memory: tracing hierarchical memory for multi-agent systems.External Links:2506.07398,LinkCited by:§6.
  • A. Zhu, L. Dugan, and C. Callison-Burch (2024)ReDel: a toolkit for llm-powered recursive multi-agent systems.External Links:2408.02248,LinkCited by:§6.

Appendix AAdditional Training Details

We trainedRLM-Qwen3-8Bas a small-scale exercise in training the first natively recursive language model. We hypothesized that, though acting as an RLM appears to produce sophisticated behavior due to recursion, it can be sufficient to focus on improving the root LM’s ability to interact with the programmatic representation of the prompt in the REPL and to discern when sub-calls are useful. In other words, while a typical RLM trajectory can be extremely long due to all of the sub-calls potentially launched (possiblyΩ​(|P|)\Omega(|P|)for a promptPP), the leaf sub-calls are essentially general-purpose LLM requests and the major hurdle is learning to operate as the root model.

This simple insight allowed us to explore a similarly simple recipe for training. In particular, we sampled RLM trajectories from a larger language model (Qwen3-Coder-480B-A35B-Instruct;Qwen Team2025b) and, after filtering, distilled them to a smaller model (Qwen3-8B;Qwen Team2025a) from the same model family. We evaluated RLM(Qwen3-Coder-480B-A35B) on 750 English LongBenchPro[Chenet al.,2026]tasks, collecting a total of 2250 candidate trajectories.

We first remove trajectories that score exactly 0.0 on the benchmark or do not go beyond one turn, bringing it down to 1,072 candidate trajectories. We separated each root RLM turn (i.e. iteration) as a separate SFT sample consisting of an input (the full history) and output (the output the root LM gave at that step).

We then applied a filtering step to remove turns beyond the context limit of Qwen3-8B (we approximated this as 100k characters), and also applied an extra programmatic correction step to fix small template mistakes in RLM usage (e.g. outputting final answers, calling the REPL, etc.). To elaborate, we noticed that trajectories generated by Qwen3-Coder-480B-A35B had noticeable mistakes in following the RLM instructions, which hurt the performance of the distilled RLM-Qwen3-8B. For example, it would often mix FINAL(answer) with FINAL(variable in REPL). We added an extra programmatic fixing step to look for common templated mistakes and patch them, leading to much better performance in the finalRLM-Qwen3-8B. In total, 16% of turns incorrectly used FINAL answers, and 13% of turns incorrectly called a variable from the REPL (i.e. FINAL_VAR) as a final answer. In Figure5, we show pre- and post-filtering statistics for our training trajectories.

Refer to captionFigure 5:We plot statistics for the RLM trajectories on LongBenchPro that were collected and filtered to trainRLM-Qwen3-8B. The left plots show the unfiltered trajectories, and right plots show the post-filtering trajectories.We used theprime-rllibrary[Prime Intellect Teamet al.,2025]for fine-tuning. We used a batch size of 64 for 300 training steps, training for 48 H100 hours. While this exceedingly simple training recipe was able to demonstrate substantial gains for our 8B model, we call on future work to investigate training native RLMs much more thoroughly. We expect that doing so at much larger scales in terms of model size, number and variety of examples, and number of (ideally on-policy and online) rollouts will be necessary to maximize the potential of RLMs.

Below, we provide plots for the runtime speed-up of training in Figure6.

Refer to captionFigure 6:The post-trained RLM-Qwen3-8B is significantly more efficient during its RLM trajectory compared to the base model, in addition to its performance boost.MRCRv2 training.For the MRCRv2[Vodrahalliet al.,2024]training experiment, we similarly usedprime-rllibrary[Prime Intellect Teamet al.,2025], but on Prime Intellect’s host-training platformLab. We RL trained on the 32k-64k token split with 2 needles for 150 steps with a batch size of 128 and 4 rollouts per example. We set a max output token per turn at 4096, and set the max number of RLM iterations to 20. Every 50 steps (starting from0), we evaluated on the 512K-1M token split with 8 needles.

Appendix BNegative Results: Things We Tried That Did Not Work.

Drawing inspiration fromRedmon and Farhadi [2018], we try to be descriptive about what tricks, quirks, and other relevant things failed and succeeded in a concise manner. Some observations are based on longer supplementary experiments, while others are based on small samples of results.

Using the exact same RLM system prompt across all models can be problematic.We originally wrote the RLM system prompt with in context examples for GPT-5, and tried to use the same system prompt for Qwen3-Coder, but found that it led to different, undesirable behavior in the trajectory. We had to add a small sentence to the RLM system prompt for Qwen3-Coder to prevent it from using too many recursive sub-calls.

Models without sufficient coding capabilities struggle as RLMs.Our instantiation of RLMs relies on the ability to reason through and deal with the context in a REPL environment. We found from small scale experiments that smaller models like Qwen3-8B[Yanget al.,2025]struggled without sufficient coding abilities.

Thinking models without sufficient output tokens struggle as RLMs.In addition toQwen3-Coder-480B-A35B-Instruct, we also tried experimenting withQwen3-235B-A22Bas the RLM. While we found positive results across the board from the base model (e.g. on OOLONG[Bertschet al.,2025], performance jumped from30%~30\%to38%~38\%), the smaller gap compared to the evaluated models in the main experiments (Table1) are due to multiple trajectories running out of output tokens while producing outputs due to thinking tokens exceeding the maximum output token length of an individual LM call.

RLMs without asynchronous LM calls are slow.We implemented all sub-LM queries naively as blocking / sequential calls, which caused our RLM experiments to be slow, especially compared to just the base model. We are confident that this can be resolved with a robust implementation.

Depending on the model, distinguishing between a final answer and a thought is brittle for RLMs.The current strategy for distinguishing between a “next turn“ and a final answer for the RLM is to have it wrap its answer in FINAL() or FINAL_VAR() tags. Similar to intuition about structured outputs degrading performance, we also found the model to make strange decisions (e.g. it outputs its plan as a final answer). We added minor safeguards, but we also believe this issue should be avoided altogether in the future when models are trained as RLMs.

Appendix CAdditional Methods and Baseline Details

C.1Prompts for Experiments

We focus on methods that are entirely task agnostic, so we fix our prompt for each method across all tasks. For the RLM prompt, the only difference between GPT-5 and Qwen3-Coder is an added line in the beginning that warns Qwen3-Coder not to use too many sub-LM calls – we found in practice that without this warning, the model will try to perform a subcall on everything, leading to thousands of LM subcalls for basic tasks. For the fine-tuned Qwen3-8B experiment, we provide a slightly different prompt due to the differences in context window size of the smaller model (from 272k in GPT-5 to 32k in Qwen3-8B). In this section, we provide the system prompt used for all methods in §3.2(other than the base model, which does not include a system prompt).

(1a) The system prompt forRLM(depth=1)for GPT-5:

Youaretaskedwithansweringaquerywithassociatedcontext.Youcanaccess,transform,andanalyzethiscontextinteractivelyinaREPLenvironmentthatcanrecursivelyquerysub-LLMs,whichyouarestronglyencouragedtouseasmuchaspossible.Youwillbequeriediterativelyuntilyouprovideafinalanswer.

Yourcontextisa{context_type}with{context_total_length}totalcharacters,andisbrokenupintochunksofcharlengths:{context_lengths}.

TheREPLenvironmentisinitializedwith:

1.A‘context‘variablethatcontainsextremelyimportantinformationaboutyourquery.Youshouldcheckthecontentofthe‘context‘variabletounderstandwhatyouareworkingwith.Makesureyoulookthroughitsufficientlyasyouansweryourquery.

2.A‘llm_query‘functionthatallowsyoutoqueryanLLM(thatcanhandlearound500Kchars)insideyourREPLenvironment.

3.Theabilitytouse‘print()‘statementstoviewtheoutputofyourREPLcodeandcontinueyourreasoning.

YouwillonlybeabletoseetruncatedoutputsfromtheREPLenvironment,soyoushouldusethequeryLLMfunctiononvariablesyouwanttoanalyze.Youwillfindthisfunctionespeciallyusefulwhenyouhavetoanalyzethesemanticsofthecontext.Usethesevariablesasbufferstobuildupyourfinalanswer.

MakesuretoexplicitlylookthroughtheentirecontextinREPLbeforeansweringyourquery.Anexamplestrategyistofirstlookatthecontextandfigureoutachunkingstrategy,thenbreakupthecontextintosmartchunks,andqueryanLLMperchunkwithaparticularquestionandsavetheanswerstoabuffer,thenqueryanLLMwithallthebufferstoproduceyourfinalanswer.

YoucanusetheREPLenvironmenttohelpyouunderstandyourcontext,especiallyifitishuge.RememberthatyoursubLLMsarepowerful--theycanfitaround500Kcharactersintheircontextwindow,sodon’tbeafraidtoputalotofcontextintothem.Forexample,aviablestrategyistofeed10documentspersub-LLMquery.Analyzeyourinputdataandseeifitissufficienttojustfititinafewsub-LLMcalls!

WhenyouwanttoexecutePythoncodeintheREPLenvironment,wrapitintriplebacktickswith’repl’languageidentifier.Forexample,saywewantourrecursivemodeltosearchforthemagicnumberinthecontext(assumingthecontextisastring),andthecontextisverylong,sowewanttochunkit:

‘‘‘repl

chunk=context[:10000]

answer=llm_query(f“Whatisthemagicnumberinthecontext?Hereisthechunk:{{chunk}}“)

print(answer)

‘‘‘

Asanexample,supposeyou’retryingtoansweraquestionaboutabook.Youcaniterativelychunkthecontextsectionbysection,queryanLLMonthatchunk,andtrackrelevantinformationinabuffer.

‘‘‘repl

query=“InHarryPotterandtheSorcerer’sStone,didGryffindorwintheHouseCupbecausetheyled?”

fori,sectioninenumerate(context):

ifi==len(context)-1:

buffer=llm_query(f“Youareonthelastsectionofthebook.Sofaryouknowthat:{{buffers}}.Gatherfromthislastsectiontoanswer{{query}}.Hereisthesection:{{section}}“)

print(f“Basedonreadingiterativelythroughthebook,theansweris:{{buffer}}“)

else:

buffer=llm_query(f“Youareiterativelylookingthroughabook,andareonsection{{i}}of{{len(context)}}.Gatherinformationtohelpanswer{{query}}.Hereisthesection:{{section}}“)

print(f“Aftersection{{i}}of{{len(context)}},youhavetracked:{{buffer}}“)

‘‘‘

Asanotherexample,whenthecontextisn’tthatlong(e.g.>100Mcharacters),asimplebutviablestrategyis,basedonthecontextchunklengths,tocombinethemandrecursivelyqueryanLLMoverchunks.Forexample,ifthecontextisaList[str],weaskthesamequeryovereachchunk:

‘‘‘repl

query=“Amanbecamefamousforhisbook“TheGreatGatsby”.Howmanyjobsdidhehave?“

#Supposeourcontextis~1Mchars,andwewanteachsub-LLMquerytobe~0.1Mcharssowesplititinto5chunks

chunk_size=len(context)//10

answers=[]

foriinrange(10):

ifi<9:

chunk_str=“\n”.join(context[i*chunk_size:(i+1)*chunk_size])

else:

chunk_str=“\n”.join(context[i*chunk_size:])

answer=llm_query(f“Trytoanswerthefollowingquery:{{query}}.Herearethedocuments:\n{{chunk_str}}.Onlyanswerifyouareconfidentinyouranswerbasedontheevidence.“)

answers.append(answer)

print(f“Igottheanswerfromchunk{{i}}:{{answer}}“)

final_answer=llm_query(f“Aggregatingalltheanswersperchunk,answertheoriginalqueryabouttotalnumberofjobs:{{query}}\\n\\nAnswers:\\n“+“\\n”.join(answers))

‘‘‘

Asafinalexample,afteranalyzingthecontextandrealizingitsseparatedbyMarkdownheaders,wecanmaintainstatethroughbuffersbychunkingthecontextbyheaders,anditerativelyqueryinganLLMoverit:

‘‘‘repl

#AfterfindingoutthecontextisseparatedbyMarkdownheaders,wecanchunk,summarize,andanswer

importre

sections=re.split(r’###(.+)’,context[“content”])

buffers=[]

foriinrange(1,len(sections),2):

header=sections[i]

info=sections[i+1]

summary=llm_query(f“Summarizethis{{header}}section:{{info}}“)

buffers.append(f“{{header}}:{{summary}}“)

final_answer=llm_query(f“Basedonthesesummaries,answertheoriginalquery:{{query}}\\n\\nSummaries:\\n“+“\\n”.join(buffers))

‘‘‘

Inthenextstep,wecanreturnFINAL_VAR(final_answer).

IMPORTANT:Whenyouaredonewiththeiterativeprocess,youMUSTprovideafinalanswerinsideaFINALfunctionwhenyouhavecompletedyourtask,NOTincode.Donotusethesetagsunlessyouhavecompletedyourtask.Youhavetwooptions:

1.UseFINAL(yourfinalanswerhere)toprovidetheanswerdirectly

2.UseFINAL_VAR(variable_name)toreturnavariableyouhavecreatedintheREPLenvironmentasyourfinaloutput

Thinkstepbystepcarefully,plan,andexecutethisplanimmediatelyinyourresponse--donotjustsay“Iwilldothis“or“Iwilldothat“.OutputtotheREPLenvironmentandrecursiveLLMsasmuchaspossible.Remembertoexplicitlyanswertheoriginalqueryinyourfinalanswer.

(1b) The diff of the system prompt forRLM with REPL (Qwen3-Coder-480B-A35B), which adds a line from the prompt above for GPT-5:

---a/REPL_SYSTEM_PROMPT_QWEN.txt

+++b/REPL_SYSTEM_PROMPT_QWEN.txt

@@-15,0+15,3@@

+IMPORTANT:Beverycarefulaboutusing‘llm_query‘asitincurshighruntimecosts.Alwaysbatchasmuchinformationasreasonablypossibleintoeachcall(aimforaround~200kcharacterspercall).Forexample,ifyouhave1000linesofinformationtoprocess,it’smuchbettertosplitintochunksof5andcall‘llm_query‘oneachchunk(200callstotal)ratherthanmaking1000individualcalls.Minimizethenumberof‘llm_query‘callsbybatchingrelatedinformationtogether.

+

(1c) The diff of the system prompt for depth>1, which provides an rlm_query function that enables higher recursion depth.

---a/REPL_SYSTEM_PROMPT.txt

+++b/REPL_SYSTEM_PROMPT_DEEP.txt

@@-4,13+4,18@@

TheREPLenvironmentisinitializedwith:

1.A‘context‘variablethatcontainsextremelyimportantinformationaboutyourquery.Youshouldcheckthecontentofthe‘context‘variabletounderstandwhatyouareworkingwith.Makesureyoulookthroughitsufficientlyasyouansweryourquery.

-2.A‘llm_query‘functionthatallowsyoutoqueryanLLM(thatcanhandlearound500Kchars)insideyourREPLenvironment.

-3.Theabilitytouse‘print()‘statementstoviewtheoutputofyourREPLcodeandcontinueyourreasoning.

+2.A‘llm_query(prompt)‘functionthatallowsyoutoqueryanLLM(thatcanhandlearound500Kchars)insideyourREPLenvironment.Usethisforstraightforwardsub-taskslikesummarization,extraction,oransweringaquestionaboutachunk.

+3.An‘rlm_query(context,query)‘functionfor**complexsub-tasks**thatbenefitfromiterative,multi-stepreasoning.ThisspawnsafullRLM_REPLloop(withitsownREPLenvironment,sub-LLMcalls,anditerativecodeexecution)toanalyzethegivencontextandanswerthequery.Usethiswhenasub-taskistoodifficultforasingle‘llm_query‘call-forexample,whenthesub-taskitselfrequireschunking,aggregation,ormulti-stepanalysis.Note:ifthemaximumrecursiondepthisreached,‘rlm_query‘automaticallyfallsbackto‘llm_query‘.

+4.Theabilitytouse‘print()‘statementstoviewtheoutputofyourREPLcodeandcontinueyourreasoning.

YouwillonlybeabletoseetruncatedoutputsfromtheREPLenvironment,soyoushouldusethequeryLLMfunctiononvariablesyouwanttoanalyze.Youwillfindthisfunctionespeciallyusefulwhenyouhavetoanalyzethesemanticsofthecontext.Usethesevariablesasbufferstobuildupyourfinalanswer.

MakesuretoexplicitlylookthroughtheentirecontextinREPLbeforeansweringyourquery.Anexamplestrategyistofirstlookatthecontextandfigureoutachunkingstrategy,thenbreakupthecontextintosmartchunks,andqueryanLLMperchunkwithaparticularquestionandsavetheanswerstoabuffer,thenqueryanLLMwithallthebufferstoproduceyourfinalanswer.

YoucanusetheREPLenvironmenttohelpyouunderstandyourcontext,especiallyifitishuge.RememberthatyoursubLLMsarepowerful--theycanfitaround500Kcharactersintheircontextwindow,sodon’tbeafraidtoputalotofcontextintothem.Forexample,aviablestrategyistofeed10documentspersub-LLMquery.Analyzeyourinputdataandseeifitissufficienttojustfititinafewsub-LLMcalls!

+

+**Choosingbetween‘llm_query‘and‘rlm_query‘:**

+-Use‘llm_query(prompt)‘forsimplesub-tasks:summarizeachunk,extractafact,answeradirectquestion.ThisisasingleLLMcallandisfast/cheap.

+-Use‘rlm_query(context,query)‘whenasub-taskisitselfcomplexenoughtorequireiterativereasoningwithcodeexecution-e.g.,analyzingaverylargesub-contextthatneedsitsownchunkingstrategy,oramulti-stepreasoningchain.Thisisslowerandmoreexpensive,butmorepowerful.

WhenyouwanttoexecutePythoncodeintheREPLenvironment,wrapitintriplebacktickswith’repl’languageidentifier.Forexample,saywewantourrecursivemodeltosearchforthemagicnumberinthecontext(assumingthecontextisastring),andthecontextisverylong,sowewanttochunkit:

‘‘‘repl

@@-52,6+57,15@@

final_answer=llm_query(f“Aggregatingalltheanswersperchunk,answertheoriginalqueryabouttotalnumberofjobs:{{query}}\n\nAnswers:\n“+“\n”.join(answers))

‘‘‘

+Foratrulycomplexsub-task,youcanuse‘rlm_query‘todelegateittoafullRLM_REPLloop:

+‘‘‘repl

+#Supposewehaveasub-taskthatitselfrequiresmulti-stepreasoningwithcode

+#Forexample,analyzingahugesub-contextthatneedsitsownchunkingandaggregation

+sub_context=“\n”.join(context[500:1000])#Alargesub-section

+answer=rlm_query(sub_context,“Whatarethekeythemesacrossthese500documents?”)

+print(f“Deepanalysisresult:{{answer}}“)

+‘‘‘

+

Asafinalexample,afteranalyzingthecontextandrealizingitsseparatedbyMarkdownheaders,wecanmaintainstatethroughbuffersbychunkingthecontextbyheaders,anditerativelyqueryinganLLMoverit:

‘‘‘repl

#AfterfindingoutthecontextisseparatedbyMarkdownheaders,wecanchunk,summarize,andanswer

(1d) The diff of the system prompt forRLM(Qwen3-8B, depth=1), which has a few changes from the GPT-5 prompt due to differences in context length and similar sub-calling behavior as Qwen3-Coder-480B-A35B:

---a/REPL_SYSTEM_PROMPT.txt

+++b/REPL_SYSTEM_PROMPT_QWEN3_8B.txt

@@-2,0+3,3@@

+IMPORTANT:Youhaveatotalcontextwindowofapproximately~32ktokens.Beverycarefulaboutcontextlengthlimits.Thesub-LLMsyoucanqueryalsohavethissame~32ktokenlimit,soyoumustbeconservativewithhowmuchcontextyousendineachcall.

+

@@-7+10@@

-2.A‘llm_query‘functionthatallowsyoutoqueryanLLM(thatcanhandlearound500Kchars)insideyourREPLenvironment.

+2.A‘llm_query‘functionthatallowsyoutoqueryanLLM(thatcanhandlearound~100kchars,roughly32ktokens)insideyourREPLenvironment.

@@-12+15@@

-YoucanusetheREPLenvironmenttohelpyouunderstandyourcontext,especiallyifitishuge.RememberthatyoursubLLMsarepowerful--theycanfitaround500Kcharactersintheircontextwindow,sodon’tbeafraidtoputalotofcontextintothem.Forexample,aviablestrategyistofeed10documentspersub-LLMquery.Analyzeyourinputdataandseeifitissufficienttojustfititinafewsub-LLMcalls!

+YoucanusetheREPLenvironmenttohelpyouunderstandyourcontext,especiallyifitishuge.RememberthatyoursubLLMshavea~32ktokenlimit(approximately~24kcharacters)--becarefulnottoexceedthis.Forexample,aviablestrategyistofeed2-3documentspersub-LLMquery.Analyzeyourinputdataandseeifitissufficienttojustfititinafewsub-LLMcalls!

+

+IMPORTANT:Beverycarefulaboutusing‘llm_query‘asitincurshighruntimecosts.Alwaysbatchasmuchinformationasreasonablypossibleintoeachcallwhilestayingwithinthe~32ktokenlimit(aimforaround~10k-15kcharacterspercalltobesafe).Forexample,ifyouhave1000linesofinformationtoprocess,it’smuchbettertosplitintochunksof50-100andcall‘llm_query‘oneachchunk(10-20callstotal)ratherthanmaking1000individualcalls.Minimizethenumberof‘llm_query‘callsbybatchingrelatedinformationtogether,butalwaysrespectthe~32ktokenlimit.

@@-15+20@@

-chunk=context[:10000]

+chunk=context[:1000]

@@-62,0+68@@

+FINAL_VAR(final_answer)

+

@@-66+73@@

-IMPORTANT:Whenyouaredonewiththeiterativeprocess,youMUSTprovideafinalanswerinsideaFINALfunctionwhenyouhavecompletedyourtask,NOTincode.Donotusethesetagsunlessyouhavecompletedyourtask.Youhavetwooptions:

+IMPORTANT:Whenyouaredonewiththeiterativeprocess,youMUSTprovideafinalanswerinsideaFINALfunctionwhenyouhavecompletedyourtask,NOTincodeorrepltags.Donotusethesetagsunlessyouhavecompletedyourtask.Youhavetwooptions:

(2) The system prompt forRLM with REPL (no sub-calls):

Youaretaskedwithansweringaquerywithassociatedcontext.Youcanaccess,transform,andanalyzethiscontextinteractivelyinaREPLenvironment,whichyouarestronglyencouragedtouseasmuchaspossible.Youwillbequeriediterativelyuntilyouprovideafinalanswer.

Yourcontextisa{context_type}with{context_total_length}totalcharacters,andisbrokenupintochunksofcharlengths:{context_lengths}.

TheREPLenvironmentisinitializedwith:

1.A‘context‘variablethatcontainsextremelyimportantinformationaboutyourquery.Youshouldcheckthecontentofthe‘context‘variabletounderstandwhatyouareworkingwith.Makesureyoulookthroughitsufficientlyasyouansweryourquery.

2.Theabilitytouse‘print()‘statementstoviewtheoutputofyourREPLcodeandcontinueyourreasoning.

YouwillonlybeabletoseetruncatedoutputsfromtheREPLenvironmenttonotoverflowthecontextwindow.Usethesevariablesasbufferstobuildupyourfinalanswer.

MakesuretoexplicitlylookthroughtheentirecontextinREPLbeforeansweringyourquery.Anexamplestrategyistofirstlookatthecontextandfigureoutachunkingstrategy,thenbreakupthecontextintosmartchunks,andsaveinformationtobuffers.

YoucanusetheREPLenvironmenttohelpyouunderstandyourcontext,especiallyifitishuge.

WhenyouwanttoexecutePythoncodeintheREPLenvironment,wrapitintriplebacktickswith’repl’languageidentifier.Forexample,saywewanttopeekatthefirst10000charactersofthecontext:

‘‘‘repl

chunk=context[:10000]

print(f“First10000charactersofcontext:{{chunk}}“)

‘‘‘

Asanotherexample,afteranalyzingthecontextandrealizingweneedtosearchforspecifictopics,wecanuseregextofindrelevantsectionsandmaintainstatethroughbuffers:

‘‘‘repl

#Afterfindingoutweneedtosearchfor“magic“and“number“inthecontext

importre

query_terms=[“magic”,“number”]

relevant_sections=[]

buffers=[]

#Searchforsectionscontainingourqueryterms

fori,chunkinenumerate(context):

chunk_text=str(chunk).lower()

ifany(terminchunk_textforterminquery_terms):

relevant_sections.append((i,chunk))

#Processeachrelevantsectionandprintfindings

forsection_idx,section_contentinrelevant_sections:

print(f“Foundrelevantsection{{section_idx}}containingmagic/numberreferences:“)

print(f“Content:{{section_content[:500]}}...“)#Printfirst500chars

buffers.append(f“Section{{section_idx}}:Containsmagic/numberreferences“)

print(f“Totalrelevantsectionsfound:{{len(relevant_sections)}}“)

print(“Summaryoffindings:”)

forbufferinbuffers:

print(f“-{{buffer}}“)

‘‘‘

IMPORTANT:Whenyouaredonewiththeiterativeprocess,youMUSTprovideafinalanswerinsideaFINALfunctionwhenyouhavecompletedyourtask,NOTincode.Donotusethesetagsunlessyouhavecompletedyourtask.Youhavetwooptions:

1.UseFINAL(yourfinalanswerhere)toprovidetheanswerdirectly

2.UseFINAL_VAR(variable_name)toreturnavariableyouhavecreatedintheREPLenvironmentasyourfinaloutput

Note:Ifyouarereadytoprovideafinalanswer,youcannotwriteanythingotherthanthefinalanswerintheFINALorFINAL_VARtags.

Thinkstepbystepcarefully,plan,andexecutethisplanimmediatelyinyourresponse--donotjustsay“Iwilldothis“or“Iwilldothat“.OutputtotheREPLenvironmentasmuchaspossible.Remembertoexplicitlyanswertheoriginalqueryinyourfinalanswer.

(3a) The system prompt forCodeAct with BM25. We give CodeAct access to a BM25 retriever for BrowseComp+ following experiments in the original paper[Chenet al.,2025].:

YouareahelpfulassistantinaCodeAct(Code+Acting)loopthatcanexecutePythoncodeandsearchthroughdocumentstoanswerquestions.

Youmustfollowthisformatforeachstep:

1.THINK:Reasonaboutwhatyouneedtodonext

2.ACT:Takeanaction(eitherexecutecodeorSEARCH)

**ENCOURAGED:UsePythoncodeexecutionwhenhelpful!**

-Codeexecutionisverifiableandhelpsyoucheckyourworkprogrammatically

-Usecodetosolveproblems,verifycalculations,analyzedata,andvalidateyourreasoning

-Codeexecutionresultsarereliableandhelpyoubuildconfidenceinyouranswers

-Whenindoubt,writingcodetocheck,verify,orcomputecanbehelpful

-**However,ifyoucananswerthequestionwithoutcode(e.g.,straightforwardfactualquestions,simplereasoning),youcanprovideyourfinalanswerdirectlywithoutexecutingcode**

AvailableActions:

-ExecutePythoncode:Writecodein‘‘‘pythoncodeblocks.Thecodewillbeexecutedandresultsreturned.

-SEARCH(query):SearchthroughdocumentsforinformationusingBM25retrieval.

-Providefinalanswer:Whenyouhaveenoughinformation,youcanprovideyourfinalansweras“ANSWER:[youranswer]“

FormatRequirements:

-Starteachturnwith“THINK:“followedbyyourreasoning

-Theneither:

*WritePythoncodein‘‘‘pythonblockstoexecute

*Use“SEARCH(querytext)“tosearchdocuments

-Youcanexecutecodemultipletimes,searchmultipletimes,orcombineboth

-Codeexecutionresultswillbereturnedtoyouautomatically

-Variablespersistacrosscodeexecutionsinthesamesession

-**CRITICAL:Codeisexecutedas-isinafreshPythonenvironment.Youmustincludeallnecessaryimports,datadefinitions,andcontextwithinyourcodeblocks.Donotusefillers(e.g.FILLINWITHREALDATA),theyhavetobewrittenincode.**

Exampleworkflow:

‘‘‘

Question:Howmanywordsinthelist[’error’,’correct’,’arrow’,’berry’,’carrot’,’mirror’]haveexactly2r’s?

THINK:Ineedtocounthowmanywordsinthelisthaveexactly2r’s.IcanwritePythoncodeusingregextodothis.

‘‘‘python

importre

words=[’error’,’correct’,’arrow’,’berry’,’carrot’,’mirror’]

pattern=r’^[^r]*r[^r]*r[^r]*$’#Matcheswordswithexactly2r’s

count=0

matching_words=[]

forwordinwords:

ifre.match(pattern,word):

count+=1

matching_words.append(word)

print(f“{word}has2r’s“)

print(f“Totalwordswith2r’s:{count}“)

‘‘‘

‘‘‘

[Codeexecutionresultsreturned...]

Examplewithsearch:

‘‘‘

Question:Whatinformationisavailableaboutmachinelearninginthedocuments?

THINK:Ineedtosearchthedocumentsforinformationaboutmachinelearning.

SEARCH(machinelearning)

‘‘‘

[Searchresultsreturned...]

---

Important:

-AlwaysstartwithTHINKtoreasonaboutyournextstep

-Youcancombinecodeexecutionandsearchasneeded

-Bestrategictoavoidexceedingthecontextwindow

-**CODEEXECUTION**:Usecodetoverify,check,andsolveproblemsprogrammaticallywhenhelpful.However,ifyoucananswerthequestionwithoutcode(e.g.,straightforwardfactualquestions,simplereasoning),youcanprovideyourfinalanswerdirectlywithoutexecutingcode.

-**CODEEXECUTIONCONTEXT**:Yourcodeisexecutedas-is.Youmustexplicitlyincludeallimports,data,andcontextneeded.Variablespersistacrossexecutions,buteachcodeblockmustbeself-containedwithallnecessarysetup.

(3b) The system prompt forCodeAct. For tasks other than BrowseComp+, a retriever is not usable / helpful because there is nothing to index or it all fits in context. We modify the prompt to remove the retriever.:

YouareahelpfulassistantinaCodeAct(Code+Acting)loopthatcanexecutePythoncodetohelpyouanswerquestions.

Youmustfollowthisformatforeachstep:

1.THINK:Reasonaboutwhatyouneedtodonext

2.ACT:Takeanaction(executecode)

**ENCOURAGED:UsePythoncodeexecutionwhenhelpful!**

-Codeexecutionisverifiableandhelpsyoucheckyourworkprogrammatically

-Usecodetosolveproblems,verifycalculations,analyzedata,andvalidateyourreasoning

-Codeexecutionresultsarereliableandhelpyoubuildconfidenceinyouranswers

-Whenindoubt,writingcodetocheck,verify,orcomputecanbehelpful

-**However,ifyoucananswerthequestionwithoutcode(e.g.,straightforwardfactualquestions,simplereasoning),youcanprovideyourfinalanswerdirectlywithoutexecutingcode**

AvailableActions:

-ExecutePythoncode:Writecodein‘‘‘pythoncodeblocks.Thecodewillbeexecutedandresultsreturned.

-Providefinalanswer:Whenyouhaveenoughinformation,youcanprovideyourfinalansweras“ANSWER:[youranswer]“

FormatRequirements:

-Starteachturnwith“THINK:“followedbyyourreasoning

-ThenwritePythoncodein‘‘‘pythonblockstoexecute

-Youcanexecutecodemultipletimes.

-Codeexecutionresultswillbereturnedtoyouautomatically

-Variablespersistacrosscodeexecutionsinthesamesession

-**CRITICAL:Codeisexecutedas-isinafreshPythonenvironment.Youmustincludeallnecessaryimports,datadefinitions,andcontextwithinyourcodeblocks.Donotusefillers(e.g.FILLINWITHREALDATA),theyhavetobewrittenincode.**

Exampleworkflow:

‘‘‘

Question:Howmanywordsinthelist[’error’,’correct’,’arrow’,’berry’,’carrot’,’mirror’]haveexactly2r’s?

THINK:Ineedtocounthowmanywordsinthelisthaveexactly2r’s.IcanwritePythoncodeusingregextodothis.

‘‘‘python

importre

words=[’error’,’correct’,’arrow’,’berry’,’carrot’,’mirror’]

pattern=r’^[^r]*r[^r]*r[^r]*$’#Matcheswordswithexactly2r’s

count=0

matching_words=[]

forwordinwords:

ifre.match(pattern,word):

count+=1

matching_words.append(word)

print(f“{word}has2r’s“)

print(f“Totalwordswith2r’s:{count}“)

‘‘‘

‘‘‘

[Codeexecutionresultsreturned...]

Answer:4

---

Important:

-AlwaysstartwithTHINKtoreasonaboutyournextstep

-Bestrategictoavoidexceedingthecontextwindow

-**CODEEXECUTION**:Usecodetoverify,check,andsolveproblemsprogrammaticallywhenhelpful.However,ifyoucananswerthequestionwithoutcode(e.g.,straightforwardfactualquestions,simplereasoning),youcanprovideyourfinalanswerdirectlywithoutexecutingcode.

-**CODEEXECUTIONCONTEXT**:Yourcodeisexecutedas-is.Youmustexplicitlyincludeallimports,data,andcontextneeded.Variablespersistacrossexecutions,buteachcodeblockmustbeself-containedwithallnecessarysetup.

C.2Summary agent baseline

The summarization agent baseline follows the scaffolds presented inSunet al.[2025], Wuet al.[2025], Yuet al.[2025], mimicking how contexts are typically compressed in a multi-turn setting in agents like Claude Code[Anthropic,2025]. In an iterative fashion, the agent is given inputs until its context is full, at which point it is queried to summarize all relevant information and continue. If the agent is given a context in a single step that is larger than its model context window, it chunks up this context and performs the summarization process over these chunks.

For our GPT-5 baseline, we chose to use GPT-5-nano to perform summarization to avoid exploding costs. This explains the large discrepancy in cost in Table1between GPT-5 and Qwen3-Coder on BrowseComp-Plus, where the summary agent using Qwen3-Coder is nearly15×15\timesmore expensive on average. On this task in particular, we found on a smaller set of2020random samples that the performance between using GPT-5 and GPT-5-nano is comparable.

C.3LongCoT-mini experiment.

For the LongCoT-mini RLM experiment, we use the same RLM algorithm described in Algorithm1, but a slightly different implementation than what was used for the rest of §3. Instead, we use Prime Intellect’srlm-harness, which enables interfacing with their sandboxes for higher throughput evaluations and was forked from the original implementation used for evaluating Table1. The mechanism for determining final answers also differs, which is reflected in the prompt.

Why GPT-5 base does not include decomposition hints.Even when provided with decomposition hints, we find that GPT-5 cannot reasonably execute this decomposition and solve sub-problems using the standard chain-of-thought autoregressive reasoning. While performance on the MATH split improves, we generally find the model gets confused on the more programmatic tasks without a REPL-like mechanism to isolate sub-task solving.

Table 3:Solve rate onLongCoT-mini[Motwaniet al.,2026], a difficult long reasoning benchmark that frontier models struggle to solve. We adapt a similar set of decomposition hints provided to the RLM in Table2(without sub-calling details), and find the model often gets confused or makes more mistakes on certain splits, while improving on the more difficult splits like math.The appended environment hint used for LongCoT-mini with decomposition hints on solving these problems is provided below:

<env_tips>

Orchestrate;don’tsolve.Theseproblemsdriftonasinglechainof

thought(lostpartials,compoundingsignerrors)-“justthinkharder

intheREPL“scores~0%

reasonerthatcanhandleanyindividualsub-problem(competitionmath,

combinatorics,numbertheory,probability,geometry,algebra)givena

clearself-containedprompt.Trustit;don’twritesolvercodeforit.

Yourjob:(1)decomposeintoself-contained“nodes“,(2)delegateall

reasoningto‘llm_batch‘,(3)memoizeanswersinadictacrossturns,

(4)verifyeachanswerbeforeanychildconsumesit,(5)inline

verifiedparentvaluesverbatimintochildprompts,(6)assemblethe

finalanswerbydictlookuponly.YoudoNOmath-ifyou’rewriting

Pythonthatenumerates,solves,simulates,orpicksamongcandidates

(vs.verifyingone),STOPanddelegate.Rootcompute=dictlookup+

stringformatting+correctnesschecks.

##Theonlystatethatmatters

KeeptwovariablesaliveacrosseveryREPLturn:

answers={}#node_id->VERIFIEDanswer(string)

plan={}#JSONstructurereturnedbytheplanningsub-LM

Ifavalueisn’tin‘answers‘,itdoesn’texist.Don’ttrustvariables

fromearlierturns,numbersinyourownthinking,orpastedvalues-

contextdrifts.Memoizeeverythingyou’llreuse.

##Step1-Plan(turn1,one‘llm_batch‘call)

Askasub-LMtoextractstructureasJSON-donotsolveanything:

planning_prompt=(

“Readthefollowingmulti-stepproblemandreturnONLYvalid”

“JSONoftheform:\\n”

’{“nodes”:[’

’{“id”:“node_0”,“question”:“<verbatim>”,“deps”:[]},’

’{“id”:“node_1”,“question”:“<verbatim>”,“deps”:[“node_0”]},’

’...’

’],’

’“final”:“<howtobuildthefinalanswerfromnodeanswers,’

’includingtheexactoutputformat>“,’

’“cycles”:[“<idsofnodesreferencedbytheirowntransitive’

’deps;[]ifnone>“]}\\n’

“CopyeachnodequestionVERBATIM-doNOTparaphraseor”

“simplifywording.DoNOTsolveanything.\\n”

“---\\n”

)+FULL_PROBLEM_TEXT

plan=json.loads(llm_batch([planning_prompt])[0])

Forsingleself-containedpuzzles,havetheplannersplitintominimum

self-containedsteps(e.g.“parseinstance”,“runalgorithmX”,

“formatoutput”).Sameworkflowapplies.

##Step2-Solvelayerbylayer(one‘llm_batch‘perDAGlayer)

Anodeis“ready“whenallits‘deps‘arein‘answers‘.DispatchALL

readynodesinONE‘llm_batch‘(parallel).Eachsub-promptmustbe

self-contained-thesub-LMneverseestheglobalproblemorthe

‘answers‘dict,socopythenodequestionverbatim,inlineevery

parent’sverifiedvalueverbatim,andaskforonlythefinalvalue.

defbuild_subprompt(node):

ctx=“\\n”.join(f“-{d}={answers[d]}“fordinnode[“deps”])

return(

“Solvethissubprobleminisolation.\\n\\n”

“Verifiedparentvalues(useEXACTLY,donotrecompute):\\n”

f“{ctxor’(none)’}\\n\\n“

f“Question:\\n{node[’question’]}\\n\\n“

“ReturnONLYthefinalvalue.Noprose,noderivation.”

)

pending=[nforninplan[“nodes”]

ifn[“id”]notinplan.get(“cycles”,[])]

whilepending:

ready=[nforninpending

ifall(dinanswersfordinn[“deps”])]

ifnotready:

break#cycle-seeStep4

raw=llm_batch([build_subprompt(n)forninready])

forn,ainzip(ready,raw):

answers[n[“id”]]=a.strip()

pending=[nforninpendingifn[“id”]notinanswers]

Prefermanysmallper-layer‘llm_batch‘callsoveronemonolithicone.

##Step3-Verifyeveryanswerbeforeitpropagates

Usethecheapestdefinitivecheck:(a)independentsecondopinion-

re-dispatchthenodevia‘llm_batch‘withrephrasedinstructions,

acceptonlyifbothagree;(b)plausibility-range/sign/units/

integrality/shapeexpecteddownstream.Onfailure,re-dispatchJUST

thatnodewiththefailurereasonappended,thenre-verify.Never

propagateanunverifiedanswer.

##Step4-Cycles

If‘plan[“cycles”]‘isnon-empty,pickaseednode‘c‘,set

‘answers[c]‘toacandidate,runStep2ontherest,checkthe

cycle-definingconstraint.Use‘llm_batch‘(nothandcomputation)to

proposethenextcandidatefromthepreviousmiss.Cachetrialsto

avoidredoingdownstreamwork:

trials={}#candidate->dictofdownstreamanswersunderit

Freezeanswersoncetheconstraintissatisfied.

##Step5-Assemble

Onceeverynodein‘plan[“final”]‘isverifiedin‘answers‘,buildthe

finalstringbydictlookupONLY-norecomputation.Youcanuse

‘llm_batch‘toaggregateifneeded.

withopen(“/task/answer.txt”,“w”)asf:

f.write(final_answer)

##Redflags(youareoff-track)

-Pythondoingmath(enumerate/solve/sum/factor/simulate/search/

optimize/MonteCarlo/gametrees/Z3/SAT/bruteforce)insteadof

‘llm_batch‘->STOP,delete,delegate.

-Abouttouseanunverifiednodeanswer->verifyfirst.

->2turnsin,<3‘llm_batch‘calls->you’resolvingityourself.

Reset.

-Coderunning>30sor>100MB->brute-forcing;delegateinstead.

-Rememberingavaluenotin‘answers‘->re-dispatch;workingmemory

isn’treliable.

-Abouttoemitfinalbut‘answers‘missinganodefrom

‘plan[“final”]‘->dispatchthemissingnodes.

-Manyturnsononenodewithoutaverifiedanswer->re-prompt

‘llm_batch‘withclearer/longersub-promptandfailurecontext.

DoNOTswitchtowritingsolvercode.

##Outputcontract

Writeyourfinalanswerto/task/answer.txt-thatfileistheonly

thingscored.Assistant-messagecontentisignored.

</env_tips>“”“

_ENV_TIPS_CONDENSED=“”“

<env_tips>

Orchestrate;don’tsolve.Yoursub-agent(‘llm_batch‘)isagenius-level

reasonerthatcancrackanyindividualsub-problem-competitionmath,

combinatorics,numbertheory,probability,geometry,algebra-givenaclear

self-containedprompt.Trustit.Modelsthat“justthinkharderintheREPL“

score~0%

Workflow:

-Turn1:dispatchONE‘llm_batch‘askingasub-LMtoextracttheproblem’s

structureasaDAGofself-containednodes(id,verbatimquestion,deps,

final-assemblyrecipe,cyclelist).Donotsolveanything.

-Thensolvelayerbylayer:everyturn,dispatchALLreadynodes

(depssatisfied)inONE‘llm_batch‘inparallel.Eachsub-promptis

self-contained-copythenodequestionverbatim,inlineeveryparent’s

verifiedvalueverbatim,askforonlythefinalvalue.

-Memoizeverifiedanswersinadictthatpersistsacrossturns.Ifitis

notinthedict,itdoesnotexist-donottrustvariablesfromearlier

turns,numbersinyourownthinking,orpastedvalues.

-Verifyeachanswerbeforeanychildconsumesit:independent

second-opinionre-dispatch(acceptonlyifbothagree)orplausibility

check(sign/range/units/shapeexpecteddownstream).Onfailure,

re-dispatchjustthatnodewiththefailurereason.Neverpropagatean

unverifiedvalue.

-Cycles:seedthecyclenodewithacandidate,rundownstream,checkthe

cycleconstraint;use‘llm_batch‘(nothandcomputation)toproposethe

nextcandidategiventhepreviousmiss.

-Assemblethefinalanswerbydictlookuponly-norecomputationunlessyouareverifyinganodeanswer.

YoudoNOmath.IfyoucatchyourselfwritingPythonthatenumerates,solves,

simulates,brute-forces,orpicksamongcandidates(vs.verifyingone),STOP

andhanditto‘llm_batch‘.Rootcompute=dictlookup,stringformatting,

correctnesschecks.Prefermanysmallper-layer‘llm_batch‘callsoverone

monolithicprompt.

Writeyourfinalanswerto/task/answer.txt-thatfileistheonlything

scored.Assistant-messagecontentisignored.

</env_tips>“”“

APPEND_SYSTEM_PROMPT=f““”\

Whenyouareready,writeyourfinalanswer-andONLYyourfinalanswer-

to{ANSWER_FILE}intheexactformatthequestionrequests.Thenstopcalling

tools.Example:

withopen({ANSWER_FILE!r},“w”)asf:

f.write(“42”)

Appendix DAdditional Benchmark Details

We provide additional details about the benchmarks used to evaluate RLMs in §3.

D.1OOLONG-Pairs Benchmark

OOLONG-Pairs consists of2020synthetically generated tasks based on the ground-truth labels for the OOLONGBertschet al.[2025]trec_coarsesplit for input contexts of length in [1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144, 524288, 1048576]. Similar to OOLONG, each question requires correctly predicting the semantic mapping for each entry.

OOLONG-Pairs ensures quadratic scaling. Many tasks that aggregate over pairs of entries can actually be solved without looking at the pairs and only looking at each entry in a linear fashion (e.g. using the principle of inclusion-exclusion in set theory). However, in OOLONG-Pairs, each question is created such that the model must return all pairs satisfying some properties, rather than just counting.

Task 1 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a numeric value or location. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 2 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with an entity or human being. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 3 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a description and abstract concept or abbreviation. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 4 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a human being or location, and all instances that are a human being for both users must be after January 6, 2023. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 5 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with an entity or numeric value, and all instances that are an entity for both users must be before March 15, 2023. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 6 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a location or abbreviation. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 7 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a description and abstract concept or numeric value, and all instances that are a numeric value for both users must be after February 1, 2023. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 8 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a human being or description and abstract concept. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 9 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with an entity or location, and all instances that are a location for both users must be after April 10, 2023. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 10 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) where both users have at least one instance with a numeric value or abbreviation, and all instances that are an abbreviation for both users must be before May 20, 2023. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 11 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least one instance with entity and one with abbreviation, and the other user has exactly one instance with entity. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 12 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least two instances with numeric value, and the other user has at least one instance with location and at least one instance with human being. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 13 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has exactly one instance with description and abstract concept, and the other user has at least one instance with abbreviation and at least one instance with entity. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 14 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least one instance with human being and at least one instance with numeric value, and the other user has exactly two instances with location. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 15 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least one instance with entity, at least one instance with location, and at least one instance with abbreviation, and the other user has exactly one instance with numeric value. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 16 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least one instance with description and abstract concept and at least one instance with human being, and the other user has at least two instances with entity and exactly one instance with abbreviation. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 17 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has exactly one instance with numeric value, and the other user has at least one instance with location and at least one instance with description and abstract concept. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 18 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least one instance with abbreviation and exactly one instance with human being, and the other user has at least one instance with entity and at least one instance with numeric value. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 19 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least two instances with location and at least one instance with entity, and the other user has exactly one instance with description and abstract concept and exactly one instance with abbreviation. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

Task 20 In the above data, list all pairs of user IDs (no duplicate pairs, list lower ID first) such that one user has at least one instance with numeric value and at least one instance with human being, and the other user has at least one instance with location, at least one instance with entity, and exactly one instance with abbreviation. Each of the questions can be labelled as one of the labels (the data does not provide the labels, you need to figure out the label from the semantics of the question): description and abstract concept, entity, human being, numeric value, location, abbreviation. In your answer, list all pairs in the format (user_id_1, user_id_2), separated by newlines.

D.2Scaling Huge Document Corpora in BrowseComp+

In addition to the BrowseComp+[Chenet al.,2025]results fork=1000k=1000documents in §4, we also include a smaller set of results on a subset of2020tasks from the original150150to show how performance degrades as a function of input size. In our original experiments, the base LMs were unable to handle the input contexts, so we add results to show how they degrade. We include two new baselines, namelyReAct w/ GPT-5 + BM25(a variant of the CodeAct baseline without access to a code environment) andGPT-5 + pre-query BM25(GPT-5 on pre-queried documents).

Refer to captionFigure 7:We plot the performance and API cost per answer of various methods using GPT-5 on 20 random queries in BrowseComp-Plus given increasing numbers of documents in context. Only the iterative methods (RLM, ReAct) maintain reasonable performance at 100+ documents.RLMs are able to scale well without performance degradation.RLM(GPT-5) is the only model / agent able to achieve and maintain perfect performance at the 1000 document scale, with the ablation (no recursion) able to similarly achieve90%90\%performance. The base GPT-5 model approaches, regardless of how they are conditioned, show clear signs of performance dropoff as the number of documents increases.

RLM inference cost scales reasonably.The inference cost of RLMs on this setup scale log-linearly, and are reasonably bounded compared to other common strategies like ReAct + BM25. If we extrapolate the overall token costs of GPT-5 assuming it has an infinite context window, we observe that the inference cost of using RLM(GPT-5) is cheaper.

Appendix EAdditional RLM Trajectories

In this section, we provide several example trajectories to highlight characteristics of frontier models as RLMs. Many of the trajectories are too long to fit in text, so we describe each step and show specific examples when relevant.

Refer to captionFigure 8:RLMs have common patterns in their trajectories when solving tasks. (a) We frequently observed RLMs filtering and interacting with their context throughregexcode. (b) We found that RLMs can effectively decompose their context through recursive sub-calls (c) On long-output tasks, RLMs are able to solve sub-problems using recursive sub-LM calls and stitch their outputs to form a final output.A few noticeable properties of these trajectories are that RLMs often make non-optimal choices despite their strong results in §3. For example, in ExampleE.2, we observed that the RLM with Qwen3-Coder carefully constructs its final answer through a mix of recursive sub-calls and code execution in the first iteration, but then discards this information and continues wasting sub-calls before not using these stored answers. We also observed distinct differences in model behavior such as in ExampleE.3, where we found Qwen3-Coder make hundreds to thousands of recursive sub-calls for a single simple task, while GPT-5 makes on the order of ten. While these examples are not comprehensive, they provide useful qualitative insight into how to improve RLMs.

E.1RLM(GPT-5) on BrowseComp-Plus-Query_74

The total cost of this trajectory was$0.079. In this task, the agent must find the answer to the following multi-hop query given a corpus of 1000 unique documents ( 8.3M total tokens) that contain evidence documents and negatives:

Thisvegetablestewusesfish,butaddingmeatispossible.Italsousesasaltyandintensecondiment,whichisthecriticalingredientofthedish.Asof2023,atownshipholdsacelebrationnamedafterthisstew.Between1995and2005inclusive,thisfestivitybeganafterauthoritiesshiftedthehighlightandsubjectoftheireventtosetthemapartfromotherareasintheregionthatusethesameproductintheircelebrations.ThistownholdstheeventeveryyearafterFebruarybutbeforeSeptember.Duringitsthirteenthanniversary,itconductedacompetitionthatshowcasedtownandprovincialfestivitiesintheregion,whereallthreewinnerscamefromthesameprovince.Abeautypageantwasalsoapartofthecelebration.Whatarethefirstandlastnamesofthepersonwhowonthatcontestthatyear?

Step 1.GPT-5 (as the root LM) first decides to probe at the 1000 document list with regex queries. It has some priors about these events (as shown from its particular choice of words it looks for), but it also looks for specific keywords in the prompt like “beauty pageant” and “festival”.

[Uncaptioned image]

Step 2.After running its regex queries, the root LM finds an interesting snippet on the chunk at index 6, so it launches a recursive LM call over this snippet to look for information relevant to the original query. The RLM is able to both store this information in a variableanswer6, as well as print this information out for the root LM to see. The sub-LM call finds the answer is likely ‘Maria Dalmacio‘ and stores this information back in the root LM’s environment.

[Uncaptioned image]

[Uncaptioned image]

Step 3.After checking the information above, the root LM reasons that it has enough information to answer the query. The root LM chooses to check its answer again with two additional recursive LM calls to confirm that its answer aligns with this check. Finally, the root LM returns its final answer as ‘Maria Dalmacio‘, which is the correct answer.

[Uncaptioned image]

E.2RLM(Qwen3-Coder) on OOLONG-Pairs-Query_3

The total cost of this trajectory was$1.12. In this task, the agent must output all pairs of user IDs satisfying some set of properties given a list of entries ( 32k tokens total). This is both an information dense long input as well as long output task, making it particularly challenging for current LMs.

Answerthefollowing:Intheabovedata,listallpairsofuserIDs(noduplicatepairs,listlowerIDfirst)wherebothusershaveatleastoneinstancewithadescriptionandabstractconceptorabbreviation.Eachofthequestionscanbelabelledasoneofthelabels(thedatadoesnotprovidethelabels,youneedtofigureoutthelabelfromthesemanticsofthequestion):descriptionandabstractconcept,entity,humanbeing,numericvalue,location,abbreviation.Inyouranswer,listallpairsintheformat(user_id_1,user_id_2),separatedbynewlines.YouranswermustbesortedbyfirstuserID.Forexample,iftheansweristheInstanceIDpairs(22740,35839)and(35839,52032),youshouldreturn‘(22740,35839),(35839,52032)‘.Ifthereisnoanswer,returnanemptylist[].

Step 1.The model begins by probing the context with various code snippets, including printing out the first few characters and printing out the first few lines. We noticed in particular that Qwen3-Coder-480B-A35B tends to output multiple code blocks in a single step unlike GPT-5, outputs code blocks in a more iterative fashion.

[Uncaptioned image]

The model continues probing by splitting the input context by newline characters and checking roughly what the data format looks like.

[Uncaptioned image]

From the given format, the model chooses to first semantically classify the data using sub-LM calls over smaller chunks of the input (to avoid context rot and mistakes in larger contexts) and provides a sample back to the root LM of what it observed during this process.

[Uncaptioned image]

Using these classifications outputted by recursive LM calls, the model passes this variable into a function to categorize each programmatically. From here, the root LM is choosing to answer the rest of the question programmatically rather than by trying to output all pairs through model generations.

[Uncaptioned image]

The root LM specifically looks for instances satisfying the query (the user in the pair has to have at least one instance with a description and abstract concept or abbreviation) and adds them to a variable of target users.

[Uncaptioned image]

The root LM forms a list of unique pairs with this loop, and is essentially now able to answer the question.

[Uncaptioned image]

The model has stored these pairs in a variable to be outputted at the end. At this stage, the model has the answer (assuming the sub-LM calls were entirely correct) ready in a variable to be returned.

Step 2.By this point the model has already successfully extracted the answer. Interestingly, however, as we observed frequently with Qwen3-Coder, the model will continue to repeatedly verify its answers. The model also attempts to return its answer wrapped in a ‘FINAL_VAR()‘ tag, but it does not accept its answer. This is likely a consequence of a) not tuning the prompt specifically for this model and b) the model not being trained to act as an RLM, but we include these descriptions in text for brevity. At this step, the model checks its pairs.

Step 3.The model prints out the first and last pairs and attempts to have the root LM verify its correctness.

Step 4.The model prints out statistics to verify whether its answer matches with its process of forming the answer.

Step 5.The model repeats its process in Step 1 and attempts to re-generate the answer with more recursive sub-LM calls!

Step 6 - 11.The model repeats its process in Step 1 with slight differences and again attempts to re-generate the answer with more recursive sub-LM calls! It actually repeats this process 5 times, before finally returning an answer after being prompted to provide a final answer. However, the answer it returns is the root LM generating an answer, which actually provides the wrong answer – in this instance, it never returned the answer it built up in its code environment through sub-LM calls. This is an example of a case where the RLM failed.

E.3RLM(Qwen3-Coder) on OOLONG-Query_212

The total cost of this trajectory was$0.38. In this task, the agent must answer an aggregate query over a set of entries in a list of questions. The query is always about aggregating some kind of semantic transformation over the entries, meaning rule-based syntax rules are unable to perform these transformations programmatically. In this example, the RLM is answering the following question:

Thefollowinglinescontainthousandsofgeneral-knowledgequestions,oneperline.EachlinehasaUserID,whichisnotnecessarilyunique,i.e.eachUserIDcanbeassociatedwithmultiplequestions.Eachquestionhasananswerthatcanbedescribedasoneof6categories:’numericvalue’,’entity’,’location’,’descriptionandabstractconcept’,’abbreviation’,’humanbeing’--rememberthattheyarenotexplicitlylabeled,soyouneedtofigureoutthelabelfromthesemanticsofthequestion.Youwillbeaskedtoanswerquestionsabouttheaggregatelabelstatisticsacrossallexamplesinthisdataset.Donottrytoguess,estimate,orapproximatetheresult.Answerthefollowing:Intheabovedata,islabel’descriptionandabstractconcept’morecommon,lesscommon,orthesamefrequencyaslabel’numericvalue’?Giveyourfinalanswerintheform’Answer:descriptionandabstractconceptis[X]numericvalue’,where[X]is’morecommonthan’,’lesscommonthan’,or’samefrequencyas’.

Step 1.The model begins by probing the context with various code snippets, including printing out the first few characters and printing out the first few lines. Like in the OOLONG-Pairs example, we noticed that Qwen3-Coder-480B-A35B tends to output multiple code blocks in a single step unlike GPT-5, which outputs code blocks in a more iterative fashion.

[Uncaptioned image]

As mentioned previously, Qwen3-Coder differs from GPT-5 in how liberal it is in its use of sub-calls. The function Qwen3-Coder defines for classifying entries semantically uses a sub-LM callper line, leading to thousands of recursive sub-calls when applied to the full input context.

[Uncaptioned image]

[Uncaptioned image]

Step 2.After defining and testing several functions for running the above classification question over its input context, the root LM launches a long code execution call to classify and answer the query.

[Uncaptioned image]

Final.The model concludes programmatically from the large number of sub-calls it performed in Step 2 that ‘Answer: description and abstract concept is less common than numeric value‘ was the correct answer. While the RLM was able to conclude the correct answer, it likely would have been able to solve the question with significantly less sub-calls.

E.4RLM(GPT-5) on CodeQA-Query_44

The total cost of this trajectory was$0.27. In this task, the agent must answer a question that involves understanding a large codebase. The codebase here is 900k tokens, and the agent must answer the following query:

Youareahelpfulassistantthatcananswerquestionsaboutcoderepositories.Youmustanswerthegivenquestion:Thisisacoderepositoryusedforfine-tuningtext-to-imagemodelsortrainingLoRAmodels.Therepositoryisusedfortheauthor’sresearchonsomerelateduses.BelowarethestepsIfollowedduringtheprocess.Couldyouhelpmecheckwhichoneisrightstatement?basedonthestoredcontextanswerwithexactlyonenumberchoiceusingonlythechoicesprovided:

0:Inthisrepository,duringthetrainingprocess,tasksaredividedintomultipleprocessesbasedontheconfigurationfile,suchas“extension,““extract,”“generate,“andsoon.Foreachprocess,acorrespondingclasshasbeenwritten.TheseclassesmostlyinherittheattributesoftheBaseJobclassandacceptanOrderedDictdictionary,whichrepresentsapre-definedconfigurationfilethatwehavesetupinadvance.Therefore,multipleprocessescanbeexecutedinparallel,allowingforthesimultaneouscompletionofmultipletasks.Thisparallelizationsignificantlyenhancesefficiencybydistributingtheworkload,ensuringthattaskssuchasdataextension,extraction,andgenerationcanrunconcurrently,reducingtheoveralltimerequiredfortraining.

1:Preparethedataset,typicallysupportingformatssuchasJPG,JPEG,PNG,andwritecorresponding.txtfilestodescribethecontentoftheimages.Triggerwordscanbeadded,soaftertrainingiscomplete,wecangenerateimageswiththetriggerwordsintheprompt.Intheconfigdirectory,findtheconfigurationfilesandmodifythe.ymlfiles.Specifythemodelpath,datasetlocation,storagelocation,andwheretosavetheLoRAmodel.Onlyafterconfiguringthesesettingscanitrunproperly.

2:Beforetraining,wecanusealabeleddatasetorthebuilt-inannotationtoolinthisrepository.Tousethisannotationtool,weneedtodownloadtheFlorencemodel,whichisusedtoinferthecontentofimages.Additionally,thisrepositoryiscapableofsupportingmulti-GPU(multi-card)training,whichcansignificantlyspeedupthetrainingprocessbydistributingtheworkloadacrossmultipleGPUs.Toenablethisfeature,allyouneedtodoisconfiguretheGPUparametersintheprovidedconfigurationfile.ByspecifyingtheavailableGPUs,thetrainingprocesscanautomaticallytakeadvantageofthehardwareforparallelprocessing,makingitsuitableforlargerdatasetsandmorecomplexmodels.Thisflexibilityinconfigurationallowsforefficienttraining,regardlessofthescaleofthetask.

3:Thisprojecthasseveralwaystorun.Forgeneralusers,therearemodelswithaUIinterfaceandterminal-basedmodels.However,bothrequireaconfigurationfiletospecifytrainingparametersanddatastoragelocations.AfterLoRatrainingiscompleted,wecanruntherun.pyfunctiontoperformprompt-to-imageinference,butthisfileneedstosettheconfigurationparametersspecifically,ifyouwanttousetheLoRamodelyoutrainedbefore,youneedtospecifyassistant_lora_pathandlora_pathintheconfigurationparameters,otherwiseonlytheoriginalmodelwillberun.(indexedfrom0to3).

Step 1.It is not always true that an input context can be solved by partitioning it and recursively sub-querying models over each partition, but in tasks that are not information dense, this is possible. In this case, the model chooses to break down the codebase into parts and sub-query LMs to look for clues. The model then aggregates these clues and provides a final answer as a separate sub-query.

[Uncaptioned image]

Final.The RLM answers choice ‘1’, which is the correct answer.

Appendix FAdditional Quantitative Results

F.1Additional Quantitative Analysis of Main Results

We supplement Table1with fine-grained rollout success of a few baseline methods compared to the RLM(recursion depth=1). In Figure9, we generally find RLMs solve the same tasks, and more tasks than, other baselines, especially for GPT-5.

Refer to captionFigure 9:For GPT-5 and Qwen3-Coder-480B-A35B-Instruct, we plot how the RLM(recursion depth=1) compares to other baselines using the same models. For all tasks where at least one method gets the answer correct, we show how many only the RLM got correct in green, how many both got correct in gray, and how many only the baseline got correct in red.We also explore how sub-calling behavior differs between rollouts. In Figure10, we find a wide range of sub-calling behaviors that greatly differ across models and even for correct and incorrect rollouts. For example, GPT-5 uses significantly more sub-calls for BrowseComp-Plus than any other model. However, for OOLONG, Qwen3-Coder uses a large number of sub-calls ( 500 on average) for correct rollouts, which is significantly more than the number used by GPT-5. Furthermore, Qwen3-8B in particular tends to use more sub-calls on incorrect trajectories.

Refer to captionFigure 10:For each task in Table1, we plot the average number of sub-calls made during an RLM(depth=1) trajectory for each task, grouped by whether it got the task correct or incorrect.

F.2Additional Runtime and Cost Analysis of RLMs

We supplement the cost and runtime analysis of RLMs with additional, fine-grained plots. We focus on RLMs with depth=0 (i.e. no sub-calls) and depth=1. In Figures14,15we include a histogram for the cost of each method on every task for both GPT-5 and Qwen3-Coder. We generally observe long-tailed, high-variance trajectories for RLMs in both models. We plot the cost of RLM(depth=1) and baselines at quartiles in Figure11.

We additionally include log-scaled runtime plots (Figure12,13) for each method below. The tail end (e.g. 95th percentile) shows extremely long runtimes, which is mainly due to sequential sub-LLM calls taking up most of the runtime. However, we observe these cases happen infrequently, and can be early-stopped with timeout logic. As we remarked in §5, the runtime for these methods can be significantly improved through asynchrony of LM calls and additional prompting to discourage long sub-LM calls or code.

For the scaling plot in Figure1, we also provide the average API cost per task.

Refer to captionFigure 11:Cost of RLM and baselines described in §3.2plotted at the 25th, 50th, 75th, and 95th percentile of total API cost. We observe comparable or even lower costs for RLMs at the 50th percentile, but sharp increases at the tail end due to potentially long RLM trajectories.Refer to captionFigure 12:Plotted quartiles of the runtime for methods and baselines around GPT-5 across OOLONG, OOLONG-Pairs, CodeQA, and BrowseComp+ (1K) for all methods described in §3.2. We plot the 25th, 50th, 75th, and 95th percentiles.Refer to captionFigure 13:Plotted quartiles of the runtime for methods and baselines around Qwen3-Coder-480B-A35B-Instruct across OOLONG, OOLONG-Pairs, CodeQA, and BrowseComp+ (1K) for all methods described in §3.2. We plot the 25th, 50th, 75th, and 95th percentiles.Refer to captionFigure 14:Histogram of the API costs for GPT-5 across OOLONG, OOLONG-Pairs, CodeQA, and BrowseComp+ (1K) for all methods described in §3.2.Refer to captionFigure 15:Histogram of the API costs for Qwen3-Coder-480B across OOLONG, OOLONG-Pairs, CodeQA, and BrowseComp+ (1K) for all methods described in §3.2.Refer to captionFigure 16:We plot the API cost in USD for the runs in Figure1.

Similar Articles

There's a reason why AI memory is still fucked

Reddit r/AI_Agents

The article critiques AI memory tools for relying on simple vector stores, causing issues like outdated data and contradictions, and calls for advanced features such as typed extraction, contradiction handling, and entity resolution.