---
#### other_backends / other_backend_kwargs
{: .no_toc }
Type: list[str] | None / list[dict] | None
Default: None
Register additional LM backends. The first other_backend is used as the default for depth-routed sub-calls (e.g. llm_query() calls from code at depth > 0 are routed to the other backend). Additional backends are registered by model name and can be selected explicitly.

---
#### logger
{: .no_toc }
Type: RLMLogger | None
Default: None
Logger for capturing trajectory metadata. When provided, the returned RLMChatCompletion.metadata field contains the full trajectory (iterations, code blocks, sub-calls).

---
#### verbose
{: .no_toc }
Type: bool
Default: False
Enable rich console output showing:
- Metadata at startup
- Each iteration's response
- Code execution results
- Final answer and statistics
---
#### persistent
{: .no_toc }
Type: bool
Default: False
When enabled, reuses the same environment across multiple completion() calls. This enables multi-turn conversations where each call adds a new context and the model retains all previous variables and state.
Contexts are versioned (context_0, context_1, ...) with context always aliasing context_0. Conversation histories from previous calls are available as history_0, history_1, etc.
Supports the context manager protocol for automatic cleanup:

---
#### custom_tools
{: .no_toc }
Type: dict[str, Any] | None
Default: None
Custom functions and data available in the REPL environment. Callable values are added to globals (callable by the model), non-callable values are added to locals (accessible as variables).
Two formats are supported:

Reserved names (llm_query, rlm_query, context, history, answer, SHOW_VARS, and their batched variants) cannot be used as tool names.
---
#### custom_sub_tools
{: .no_toc }
Type: dict[str, Any] | None
Default: None
Separate set of custom tools for child RLMs spawned via rlm_query(). If None, children inherit the parent's custom_tools. Pass an empty dict {} to disable custom tools for children.
---
#### compaction
{: .no_toc }
Type: bool
Default: False
When enabled, automatically summarizes the conversation history when token usage exceeds compaction_threshold_pct of the model's context window. The full history (including summaries) is available in the REPL as the history variable.
---
#### compaction_threshold_pct
{: .no_toc }
Type: float
Default: 0.85
Fraction of the model's context window that triggers compaction. Only used when compaction=True.
---
#### Event Callbacks
{: .no_toc }
Optional callbacks for monitoring execution progress:
| Callback | Signature | Triggered when |
|:---------|:----------|:---------------|
| on_iteration_start | (depth: int, iteration_num: int) | An iteration begins |
| on_iteration_complete | (depth: int, iteration_num: int, duration: float) | An iteration completes |
| on_subcall_start | (depth: int, model: str, prompt_preview: str) | A child RLM is spawned |
| on_subcall_complete | (depth: int, model: str, duration: float, error: str \| None) | A child RLM finishes |
---
Methods  Copy Chapter
completion() ')" title="Copy section prompt for LLMs"> Copy Section
Main entry point for RLM completions.

#### Parameters
prompt
{: .no_toc }
The context/input to process. Becomes the context variable in the REPL.

root_prompt
{: .no_toc }
Optional short prompt shown to the root LM on every iteration. Useful for Q&A tasks where the question should be visible throughout.

#### Returns
RLMChatCompletion dataclass:

#### Example

close() ')" title="Copy section prompt for LLMs"> Copy Section
Clean up persistent environment resources. Called automatically when using the context manager protocol (with RLM(...) as rlm:).
---
Response Types  Copy Chapter
RLMChatCompletion ')" title="Copy section prompt for LLMs"> Copy Section

UsageSummary ')" title="Copy section prompt for LLMs"> Copy Section

---
REPL Functions  Copy Chapter
The following functions are available to model-generated code inside the REPL:
| Function | Description |
|:---------|:------------|
| llm_query(prompt, model=None) | Single plain LM completion. Fast, no REPL or iteration. |
| llm_query_batched(prompts, model=None) | Multiple plain LM completions concurrently. A single failed call doesn't fail the batch — that slot returns "Error: llm() call failed - <msg>", the rest return normally. |
| rlm_query(prompt, model=None) | Spawn a child RLM with its own REPL for deeper thinking. Falls back to llm_query at max depth. |
| rlm_query_batched(prompts, model=None) | Spawn multiple child RLMs. Falls back to llm_query_batched at max depth. |
| answer | A dict ({"content": "", "ready": False}). Set answer["content"] to your final answer and answer["ready"] = True to terminate the run. |
| SHOW_VARS() | List all user-created variables in the REPL. |
| print(...) | Print output visible to the model in the next iteration. |
---
Error Handling  Copy Chapter
RLM follows a "fail fast" philosophy:

If the RLM exhausts max_iterations without the model setting answer["ready"] = True, it prompts the LM one more time to provide a final answer based on the conversation history.
RLM raises explicit exceptions when limits are exceeded:
| Exception | Raised when | Key attributes |
|:----------|:------------|:---------------|
| BudgetExceededError | max_budget exceeded | spent, budget |
| TimeoutExceededError | max_timeout exceeded | elapsed, timeout, partial_answer |
| TokenLimitExceededError | max_tokens exceeded | tokens_used, token_limit, partial_answer |
| ErrorThresholdExceededError | max_errors consecutive errors | error_count, threshold, last_error, partial_answer |
| CancellationError | KeyboardInterrupt during completion | partial_answer |
All exceptions are importable from the top-level package:

---
Thread Safety  Copy Chapter
Each completion() call:
1. Spawns its own LMHandler socket server
2. Creates a fresh environment instance (unless persistent)
3. Cleans up both when done
This makes completion() calls independent, but the RLM instance itself should not be shared across threads without external synchronization.
---
Example: Full Configuration  Copy Chapter

---
Architecture  Copy Section
---
layout: default
title: Architecture
nav_order: 3
---
Architecture

{: .no_toc }
How the RLM runtime, LM handler, code execution, and recursive sub-calls fit together.
{: .fs-6 .fw-300 }
Table of Contents  Copy Chapter

{: .no_toc .text-delta }
1. TOC
{:toc}
---
Overview  Copy Chapter
An RLM completion involves three cooperating pieces:
1. RLM (rlm/core/rlm.py) — the main loop that drives iteration.
2. LMHandler (rlm/core/lm_handler.py) — a per-completion TCP server that routes LM API calls.
3. LocalREPL (rlm/environments/local_repl.py) — the Python execution environment where model-generated code runs.

---
LM Handler  Copy Chapter
What it is  Copy Section
The LMHandler is a multi-threaded TCP socket server that sits between
the execution environment and the actual LM API backends. Every call to
RLM.completion() spins up a fresh handler (unless the environment is
persistent and already has one).
Why a socket server?  Copy Section
The handler exists so that code running inside the execution environment
can make LM calls back to the host process without directly importing or
calling the LM client. This is essential for isolated environments (Docker,
Modal) that run in separate processes or machines — they communicate with
the handler over TCP. The local environment uses the same protocol for
consistency, even though it runs in-process.
Lifecycle  Copy Section

- The server binds to 127.0.0.1 with port 0 (OS auto-assigns an available port).
- It runs in a daemon thread so it doesn't block process exit.
- Each incoming connection is handled by a new thread (ThreadingTCPServer).
Wire protocol  Copy Section
All messages use a simple framing: 4-byte big-endian length prefix + UTF-8 JSON payload.

Implemented in socket_send() / socket_recv() in rlm/core/comms_utils.py.
Client routing  Copy Section
The handler can hold multiple LM clients and routes requests based on the
model and depth fields in the request:

This lets you use a different (e.g. cheaper/faster) model for sub-LM calls
by specifying other_backends / other_backend_kwargs in the RLM constructor.
---
Code Execution Environment (LocalREPL)  Copy Chapter
In-process exec() — not a subprocess  — not a subprocess')" title="Copy section prompt for LLMs"> Copy Section
LocalREPL executes model-generated code in the same Python interpreter
process as the RLM, using Python's built-in exec(). There is no
subprocess, no fork, and no IPC for code execution.

What this means in practice  Copy Section
- Fast: No process spawn overhead. Code execution is as fast as native Python.
- Persistent namespace: Variables created in one code block are visible in the next. The self.locals dict accumulates state across iterations.
- Shared memory: Helper functions like llm_query() and rlm_query() are plain Python closures in self.globals. When model code calls llm_query("..."), it's a direct function call within the same process.
- Limited sandbox: Dangerous builtins (eval, exec, compile, input) are removed from the namespace. This is a soft sandbox — it prevents accidental misuse but is not a security boundary.
Namespace layout  Copy Section

Scaffold restoration  Copy Section
After each exec(), LocalREPL restores all reserved names to prevent model
code from corrupting the environment. If the model writes
llm_query = "oops" or context = None, the next execution will still
have the real functions and data. See _restore_scaffold().
---
How llm_query() and rlm_query() Work  and rlm_query() Work')" title="Copy chapter prompt for LLMs"> Copy Chapter
These are the two functions available to model-generated code for making LM calls.
They have very different behaviors:
llm_query(prompt, model=None) — Plain LM call  — Plain LM call')" title="Copy section prompt for LLMs"> Copy Section
Always makes a single, direct LM completion. No REPL, no iteration — just
prompt in, text out. Fast and lightweight.

rlm_query(prompt, model=None) — Recursive RLM sub-call  — Recursive RLM sub-call')" title="Copy section prompt for LLMs"> Copy Section
Spawns a child RLM that gets its own REPL and can reason iteratively
over the prompt — just like the parent. Use this when the subtask needs
multi-step reasoning, code execution, or its own iterative problem-solving.
Falls back to llm_query when recursion is not available (i.e. the current
depth has reached max_depth).

llm_query_batched / rlm_query_batched  / rlm_query_batched')" title="Copy section prompt for LLMs"> Copy Section
Same semantics as above, but for multiple prompts. llm_query_batched sends
all prompts as a single batched request to the handler, which processes them
concurrently with asyncio.gather. rlm_query_batched calls subcall_fn
sequentially for each prompt (each child RLM is a blocking call).
Failure handling is per-prompt. A single failed call does not fail the
whole batch — that slot returns the string "Error: llm() call failed - <msg>"
(with the underlying error message) while the other prompts return their real
responses. Results stay aligned with the input prompts by index, so the list is
always the same length as prompts.
---
Recursive Sub-Calls (Depth > 1)  Copy Chapter
How depth works  Copy Section

- depth=0 is the root RLM that the user calls.
- Each child increments depth by 1.
- When next_depth >= max_depth, _subcall() does a plain client.completion() instead of creating a child RLM. This is the leaf case — no REPL, no iteration.
- llm_query() always does a plain LM call regardless of depth. Only rlm_query() triggers recursion.
Each child gets its own handler and environment  Copy Section
When a child RLM is created via _subcall(), its completion() method calls
_spawn_completion_context() which creates:
1. A new LMHandler listening on a different auto-assigned port.
2. A new LocalREPL with its own isolated namespace.

The child's handler and environment are torn down when the child's completion() finishes.
Resource limits propagate  Copy Section
The parent passes remaining budget/timeout/tokens to the child, not the
original totals. This prevents a child from consuming all of the parent's resources:

Metadata flows back  Copy Section
Each child RLM can have its own RLMLogger. When the child completes, its
full trajectory metadata (iterations, code blocks, sub-calls) is captured in
the returned RLMChatCompletion.metadata dict. The parent's logger records
this as part of the REPL result's rlm_calls list, creating a nested
metadata tree.
---
Putting It All Together  Copy Chapter
Here's the complete request flow for a depth-2 RLM call:

│   │  answer = rlm_query("What patterns exist in: " + context[:5000])
 │   │

Key takeaways  Copy Section
| Aspect | Detail |
|:-------|:-------|
| Code execution | In-process exec() in the same Python interpreter. Not a subprocess. |
| LM calls from code | Go through a local TCP socket server (LMHandler), even for in-process execution. |
| Handler per completion | Each completion() call gets its own handler on an auto-assigned port. |
| Child RLMs | Created by _subcall(), each with its own handler + LocalREPL. Fully independent. |
| llm_query vs rlm_query | llm_query = always plain LM call. rlm_query = recursive child RLM (or fallback). |
| Depth limit | At max_depth, rlm_query falls back to llm_query. No further recursion. |
| Resource isolation | Children get remaining budget/timeout, not the full amount. |
| Namespace isolation | Each LocalREPL has its own globals/locals. No shared state between parent and child. |
---
CONTRIBUTING  Copy Section
I'm too lazy to write up a stricter set of rules for PRs, but generally I just ask that you avoid touching core/ files unless necessary. I'd like to keep the repo as minimal as possible for as long as possible so it's still easy for users to read the entire repo in a short sitting.
Generally though, I'll outline the things we 1) need to implement; 2) want to implement; 3) can dream about implementing. The state of this repo is that it should be fully functional for most use cases, but it isn't super fast or anything.
There are likely more things we'll want to do, but here are some things I've been meaning to tackle. 
Urgent TODOs  Copy Chapter

- [ ] Additional Sandboxes. Any more interesting, commonly used sandboxes (e.g. Prime Sandboxes are WIP atm).
- [ ] Persistent REPL across the client. Currently, the REPL is only persistent across an RLM completion call, but for multi-turn settings we may want a flag to handle persistence. There's some trickiness here though, which is that after every turn, the input context will change / be added onto. I haven't decided yet (open to suggestions), but we could add context_{x} and tell the model that it has a new context or something in the next completion step.
- [ ] Finding interesting benchmarks / examples we can provide to get started.
- [ ] Improve documentation. See docs/.
Low-hanging fruit of the urgent TODOs:
- [ ] Add better unit tests. I have a Mock LM class inspired by verifiers, but we need more comprehensive unit tests. Generally these should be made with most PRs.
- [ ] Do more comprehensive bug finding: Just find bugs and report them, we'll try to squash them all
Would-be-nice TODOs  Copy Chapter

- [ ] Multi-modal / arbitrary input support. As it stands, we just support str / standard LM dict messages, but we should generally support any type of picklable-inputs. We might want to think of clever ways to do this lazily as well.
- [ ] File-system based environments. Beyond REPLs, we can also think about supporting filesystem + bash as a new type of environment. There seems to be a lot of interest in this.
- [ ] Improved UI for visualization.
- [ ] Improvements to what data gets stored, useful for training and statistics about RLMs/
"If you can tackle these, thanks LOL" TODOs  Copy Chapter

- [ ] Pipelining / asynchrony of LM calls. This could be a paper of its own IMO, but how we deal with LM calls and how we actually implement these recursive calls can have big implications. I suspect this might happen when the repo has a massive overhaul, but something to think about.
- [ ] Efficient prefix caching. Another "would be nice" thing, but requires restructuring a lot of the core logic. Could also be a paper / entire research project of its own.
- [ ] Training models to work as RLMs. See the verifiers rlm_env as a starting point.
---
README  Copy Section
---
<h1 align="center" style="font-size:2.8em">
<span>Recursive Language Models (<span style="color:orange">RLM</span>s)</span>
</h1>
<p align="center" style="font-size:1.3em">
  <a href="https://arxiv.org/abs/2512.24601">Full Paper</a> •
  <a href="https://alexzhang13.github.io/blog/2025/rlm/">Blogpost</a> •
  <a href="https://alexzhang13.github.io/rlm/">Documentation</a> •
  <a href="https://github.com/alexzhang13/rlm-minimal">RLM Minimal</a>
</p>
<p align="center">
  <a href="https://github.com/alexzhang13/rlm/actions/workflows/style.yml">
    <img src="https://github.com/alexzhang13/rlm/actions/workflows/style.yml/badge.svg" alt="Style" />
  </a>
  <a href="https://github.com/alexzhang13/rlm/actions/workflows/test.yml">
    <img src="https://github.com/alexzhang13/rlm/actions/workflows/test.yml/badge.svg" alt="Test" />
  </a>
</p>
<p align="center">
  <a href="https://arxiv.org/abs/2512.24601">
    <img src="media/paper_preview.png" alt="Paper Preview" width="300"/>
  </a>
</p>
Overview  Copy Chapter

Recursive Language Models (RLMs) are a task-agnostic inference paradigm for language models (LMs) to handle near-infinite length contexts by enabling the LM to programmatically examine, decompose, and recursively call itself over its input. RLMs replace the canonical llm.completion(prompt, model) call with a rlm.completion(prompt, model) call, acting as a "language model". RLMs offload the context as a variable in a REPL environment that the LM can interact with and launch sub-LM calls inside of.
RLMs are a bet on future "language model" design choices. We argue for a CodeAct-style harness (i.e. all language models should have access to a code environment) with sub-(R)LM calls as functions in code, and context / prompts as objects in code. RLMs explicitly defer code execution with sub-calls as functions to the language model itself, which is incredibly flexible and lends itself well to scale if trained correctly. We want to move away from the JSON tool-calling standard for both sub-agents and generic tool calls. The naming comes from the fact that such a system is itself a "language model" (a probabilistic mapping from text to text) that builds around and relies on recursive sub-LLM calls.
This repository provides both an extensible inference engine and training environment for using RLMs around standard API-based and local LLMs. The initial experiments and idea were proposed in a blogpost in 2025, with expanded results in an arXiv preprint.
We now also include a verifiers training environment based on Prime Intellect's prime-rl in the training/ folder. Train your own RLMs, which directly can be plugged into our inference engine!
NOTE
This repository contains inference code for RLMs with support for various sandbox environments. Open-source contributions are welcome. This repository is maintained by the authors of the paper from the MIT OASYS lab.
Quick Setup  Copy Chapter

NOTE
rlms requires Python 3.11 or later.
You can try out RLMs quickly by installing from PyPi:

The default RLM client uses a REPL environment that runs on the host process through Python exec calls. It uses the same virtual environment as the host process (i.e. it will have access to the same dependencies), but with some limitations in its available global modules. As an example, we can call RLM completions using GPT-5-nano:

<details>
<summary><b>Manual Setup</b></summary>
Set up the dependencies with uv (or your virtual environment of choice):

This project includes a Makefile to simplify common tasks.
- make install: Install base dependencies.
- make check: Run linter, formatter, and tests.
To run a quick test, the following will run an RLM query with the OpenAI client using your environment variable OPENAI_API_KEY (feel free to change this). This will generate console output as well as a log which you can use with the visualizer to explore the trajectories.

</details>
REPL Environments  Copy Chapter

We support two types of REPL environments -- isolated, and non-isolated. Non-isolated environments (default) run code execution on the same machine as the RLM (e.g. through exec), which is pretty reasonable for some local low-risk tasks, like simple benchmarking, but can be problematic if the prompts or tool calls can interact with malicious users. Fully isolated environments use cloud-based sandboxes (e.g. Prime Sandboxes, Modal Sandboxes) to run code generated by the RLM, ensuring complete isolation from the host process. Environments can be added, but we natively support the following: local (default), ipython, docker, modal, prime, daytona, e2b.

Local Environments  Copy Section

The default local environment LocalREPL runs in the same process as the RLM itself, with specified global and local namespaces for minimal security. Using this REPL is generally safe, but should not be used for production settings. It also shares the same virtual environment (e.g. Conda or uv) as the host process.
#### IPython (requires pip install 'rlms[ipython]')
IPythonREPL runs cells inside a real IPython session — either in-process (default) or in a separate ipykernel subprocess. Subprocess mode adds hard cell_timeout enforcement and full namespace isolation from the RLM host. See the IPythonREPL docs for details.
#### Docker <img src="https://github.com/docker.png" alt="Docker" height="20" style="vertical-align: middle;"/> (requires Docker installed)
We also support a Docker-based environment called DockerREPL that launches the REPL environment as a Docker image. By default, we use the python:3.11-slim image, but the user can specify custom images as well. The container runs fully isolated from the host; a lightweight host-side proxy bridges LM access back into the container.
DockerREPL supports the full feature set of the local environment: single LM calls (llm_query / llm_query_batched), recursive sub-RLM calls (rlm_query / rlm_query_batched, including parallel batched sub-calls bounded by max_concurrent_subcalls), custom_tools / custom_sub_tools, persistent=True multi-turn sessions (versioned context_N / history_N reused across completion() calls), and compaction=True auto-summarization of the running history. For isolated environments, custom tools should be passed as Python code strings or JSON-serializable values (host callables cannot cross the process boundary).
Isolated Environments  Copy Section

We support several different REPL environments that run on separate, cloud-based machines. Whenever a recursive sub-call is made in these instances, it is requested from the host process.
#### Modal Sandboxes <img src="https://github.com/modal-labs.png" alt="Modal" height="20" style="vertical-align: middle;"/>
To use Modal Sandboxes as the REPL environment, you need to install and authenticate your Modal account.

#### Prime Intellect Sandboxes <img src="https://github.com/PrimeIntellect-ai.png" alt="Prime Intellect" height="20" style="vertical-align: middle;"/>
NOTE
Prime Intellect Sandboxes are currently a beta feature. See the documentation for more information. We noticed slow runtimes when using these sandboxes, which is currently an open issue.

To use Prime Sandboxes, install the SDK and set your API key:

Model Providers  Copy Section

We currently support most major clients (OpenAI, Anthropic), as well as the router platforms (OpenRouter, Portkey). For local models, we recommend using vLLM (which interfaces with the OpenAI client). To view or add support for more clients, start by looking at rlm/clients/.
Training  Copy Chapter

We provide a simple RL training harness for training RLMs used in this repo (specifically the local REPL). The implementation uses no sandboxes for simplicity and slots easily your use case, but an ideal setup would use sandboxes for safety. Training logic is isolated to the training/ folder, which exposes rlm.RLM as a verifiers Environment and plugs straight into prime-rl. See the training README for the launch command. The harness uses subprocess-isolated local REPL execution (no cloud sandboxes), matching the local environment above.
A worked example with an example .toml lives in training/environments/oolong/ (OOLONG long-context QA). New training environments can be added the same way — author a verifiers env that wraps your task (see the verifiers docs), then reference it from a config.
Relevant Reading  Copy Chapter

* [Dec '25] Recursive Language Models arXiv
* [Oct '25] Recursive Language Models Blogpost
If you use this code or repository in your research, please cite:

RLMs being used in the wild  Copy Chapter

There are many amazing demos and production-ready use cases of RLMs. We provide a list of notable examples that explicitly use RLMs as a central piece of their design.
* <img src="https://www.google.com/s2/favicons?domain=dspy.ai&sz=64" alt="DSPy" height="15" style="vertical-align: middle;"/> DSPy.RLM <a href="https://github.com/stanfordnlp/dspy/stargazers"><img src="https://badgen.net/github/stars/stanfordnlp/dspy?icon=github&label=Stars" height="15" alt="GitHub stars"></a>
* <img src="https://github.com/PrimeIntellect-ai.png" alt="Prime Intellect" height="15" style="vertical-align: middle;"/> Prime Agent <a href="https://github.com/PrimeIntellect-ai/prime-agent/stargazers"><img src="https://badgen.net/github/stars/PrimeIntellect-ai/prime-agent?icon=github&label=Stars" height="15" alt="GitHub stars"></a>
* <img src="https://github.com/ax-llm.png" alt="Ax" height="15" style="vertical-align: middle;"/> Ax <a href="https://github.com/ax-llm/ax/stargazers"><img src="https://badgen.net/github/stars/ax-llm/ax?icon=github&label=Stars" height="15" alt="GitHub stars"></a>
* <img src="https://github.com/context-labs.png" alt="context-labs" height="15" style="vertical-align: middle;"/> context-labs/HALO: RLM-based Automatic Agent Optimization Loop <a href="https://github.com/context-labs/halo/stargazers"><img src="https://badgen.net/github/stars/context-labs/halo?icon=github&label=Stars" height="15" alt="GitHub stars"></a>
* viplismism/rlm-cli: CLI for Recursive Language Models <a href="https://github.com/viplismism/rlm-cli/stargazers"><img src="https://badgen.net/github/stars/viplismism/rlm-cli?icon=github&label=Stars" height="15" alt="GitHub stars"></a>
* <img src="https://www.google.com/s2/favicons?domain=alphaxiv.org&sz=64" alt="alphaXiv" height="15" style="vertical-align: middle;"/> alphaXiv Official Blog. Reinforcing Recursive Language Models
* <img src="https://www.google.com/s2/favicons?domain=daytona.io&sz=64" alt="Daytona" height="15" style="vertical-align: middle;"/> Daytona. Building Deep Recursive Language Models
* <img src="https://www.google.com/s2/favicons?domain=symbolica.ai&sz=64" alt="Symbolica" height="15" style="vertical-align: middle;"/> Symbolica. SotA ARC-AGI-2 Results with REPL Agents
* <img src="https://www.google.com/s2/favicons?domain=cloud.google.com&sz=64" alt="Google Cloud" height="15" style="vertical-align: middle;"/> Google Cloud Community Articles. RLMs in ADK
 <img src="https://github.com/PrimeIntellect-ai.png" alt="Prime Intellect" height="15" style="vertical-align: middle;"/> Prime Intellect Blog. Recursive Language Models: the* paradigm of 2026
Optional: Trajectory metadata, logging, and debugging  Copy Chapter

RLMChatCompletion has an optional metadata field (default None) that holds the full trajectory (run config + all iterations and sub-calls) so you can reconstruct the run. Pass an RLMLogger to capture it:
- In-memory only (trajectory on completion.metadata): logger=RLMLogger() (no log_dir).
- Also save to disk (JSONL for the visualizer): logger=RLMLogger(log_dir="./logs").
Visualizing logs. We also provide a simple visualizer to inspect code, sub-LM, and root-LM calls. Use RLMLogger(log_dir="./logs") so each completion writes a .jsonl file:

To run the visualizer locally, we use Node.js and shadcn/ui: