Python RLM Coding Harness with Docker and Monty Sandboxes

Recursive Language Models have attracted growing interest since the original research showed how a model could keep a large corpus outside its prompt, inspect that corpus through code, and make focused model calls over selected parts. We explored that architecture in RLM Code, our research environment for running, measuring, and comparing recursive workflows. Prime Intellect recently released Prime Agent, a coding agent built around a persistent IPython environment and recursive agents. We first connected it to SuperQode through Agent Client Protocol in Prime Agent in SuperQode. We then released Prime Agent Python Client, which lets Python applications host Prime Agent through its public RPC mode without implementing the transport themselves. Those integrations run the official Prime Agent process. They are useful when a developer wants Prime Agent's own session model, continual harness, skills, schedules, heartbeats, or provider layer.

We have now added a separate RLM harness directly to SuperQode. It is written in Python, runs through SuperQode's native harness stack, and gives the model one executable tool named python. The environment behind that tool provides repository context, file operations, shell execution, focused model calls, and recursive coding sessions. Prime Agent and its Python client remain independent routes and are not dependencies of this harness.

From RLM research to a native coding harness

We built RLM Code as a research harness, and it remains the research environment. It is designed for bounded experiments, trajectory analysis, evaluation, and comparison across recursive strategies. SuperQode serves a different role. It owns the interactive terminal, provider connections, HarnessSpec configuration, sessions, events, policies, and repository workflow used during everyday coding. The native RLM harness brings the RLM execution pattern into that SuperQode environment. A user can select it beside Core, Workbench, and PiPy, connect an existing model, and continue working in the same TUI. The model sees a different tool surface, while the surrounding SuperQode session remains familiar. The model-facing contract contains one tool:

tools: python

Reading files, searching the repository, editing code, running commands, selecting context, and creating recursive work all happen through Python APIs inside the tool.

One Python tool

Most coding harnesses expose separate schemas for file reads, search, edits, shell commands, and directory operations. The RLM harness puts those operations into a persistent Python namespace:

source = workspace.read("src/service.py")
matches = workspace.search("retry", "src")
result = shell.run(["uv", "run", "pytest", "tests"])

workspace and shell are Python objects rather than additional model tools. The model can combine repository operations with loops, functions, regular expressions, JSON parsing, sorting, and aggregation without returning to the tool protocol for each small step.

Variables and imports remain available on later calls. A large intermediate result can stay in Python while the root conversation receives a bounded observation:

sources = context.select("src/**/*.py", "tests/**/*.py")
chunks = sources.chunk(size=8000)

reviews = llm_query_batched([
    f"List the invariants this code must preserve:\n{chunk.labelled()}"
    for chunk in chunks
])

for index, review in enumerate(reviews):
    print(index, review.text[:800])

The repository is available as a data source through context. The model can list files, search text, select paths, build chunks, and send only the relevant material to another model call. Large source trees, logs, traces, and test output do not need to enter the root prompt as one block.

Semantic subcalls and recursive sessions

The namespace provides two forms of delegated work.

llm_query() and llm_query_batched() make bounded model calls over text already selected by the root agent. They are suitable for reviewing independent source chunks, extracting constraints from several files, or classifying sections of a large artifact.

questions = [
    "Review the parser contract:\n" + workspace.read("deploy_audit/parser.py"),
    "Extract the release rules:\n" + workspace.read("RUNBOOK.md"),
]

parser_review, runbook_review = llm_query_batched(questions)

rlm.run() and rlm.run_batch() create child coding sessions when a task needs its own repository interaction and conversation:

children = rlm.run_batch([
    "Review the deployment parser and report its ordering rules",
    "Review the tests and list every required output invariant",
])

children[0].steer("Check how duplicate attempts are resolved")
reviews = rlm.wait_all(children)

Each child receives the same single python tool. The root can wait for a result, send a follow-up, steer an active child, or cancel work. Recursion depth, total child count, parallelism, and semantic-call quotas are enforced by the host runtime rather than by objects the model can replace inside Python. Usage remains attached to the RLM session when its worker restarts.

Pi, PiPy, and the SuperQode runtime

Pi is a compact TypeScript coding-agent foundation. Prime Agent uses Pi's agent and terminal packages around its IPython environment, then adds recursive agents and its continual harness features. PiPy is SuperQode's Python implementation of the same small-harness approach. A normal PiPy session provides read, bash, edit, and write, with grep, find, and ls available in its broader tool set. It also provides streaming events, parallel tool execution, steering, compaction, session trees, and extension hooks. The native RLM harness uses PiPy's model and event foundation but replaces the normal coding tool set with python. Repository operations remain available inside the Python namespace, while model streaming, provider access, session events, and terminal rendering continue through the existing SuperQode path. PiPy is the compact Python harness with conventional coding tools. RLM is the one-tool Python harness for programmable context and recursive work.

Runtime and session continuity

The RLM path is connected to the rest of SuperQode through Harness Protocol:

SuperQode TUI
      |
Harness Protocol session
      |
Resident RLM root worker
      |
Persistent Python kernel
      |
workspace, shell, context, llm_query, rlm

The resident worker owns the active turn, Python namespace, child-agent tree, checkpoints, and usage limits. The TUI connects to that worker and displays its events. Detaching the terminal leaves the worker running. Reopening the same SuperQode session and entering :rlm attach follows the active turn and replays available events.

Serializable user variables are checkpointed after successful Python calls. Large values stay in the namespace and can be inspected through smaller slices. Process objects, open files, locks, and live child handles are not restored as ordinary Python data.

Host, Docker, and Pydantic Monty

The execution profile decides where model-written Python runs. From 0.2.92 all three ship as built-in harnesses, selectable with :harness switch rlm, rlm-docker, or rlm-monty, and a HarnessSpec overrides the defaults when a repository needs its own limits. The host profile runs Python with the permissions of the SuperQode process. It is intended for trusted local work where direct access is acceptable. The docker profile places the interpreter inside a container. The HarnessSpec controls repository mounts, write access, network access, command rules, execution time, output size, and checkpoint size. Direct Python calls such as open() and subprocess.run() remain inside the container. This is the coding profile used in the included implementation example. The monty profile runs the persistent kernel with Pydantic Monty, a restricted Python interpreter written for agent-generated code. Monty has no general host filesystem, environment, network, subprocess, or third-party import access. SuperQode supplies a narrow set of external functions for repository context and semantic model calls.

Under the RLM Monty profile, the model can use persistent Python state, context, workspace.read, llm_query, and llm_query_batched. Calls to workspace.write, workspace.edit, shell.run, completion gates, and rlm.run refuse with a profile-specific error. Monty snapshots preserve interpreter state, and the host stores the snapshot bytes without loading them as a pickle.

SuperQode also has a standalone python_repl tool backed by Pydantic Monty. That tool creates a fresh isolated interpreter for each call and can be added to conventional tool profiles. The RLM profile is separate: its Monty session persists across calls and exposes the RLM context and semantic-subcall APIs.

Prime Agent and SuperQode RLM

Prime Agent and the native SuperQode RLM harness share the one-tool coding approach. Both give the model a Python environment that can inspect context and compose coding operations. Both can keep large intermediate values outside the root conversation. Prime Agent uses the TypeScript Pi stack around IPython. It provides executable skills, schedules, heartbeats, direct agent messaging, persistent sessions, recursive agents, and Prime's model-provider layer. SuperQode can launch the official process through ACP or through prime-agent-python-client over RPC.

SuperQode RLM stays within the Python harness stack. It adds the context object, bounded semantic subcalls, recursive coding sessions, host-owned quotas, resident execution, and the Host, Docker, and Monty profiles. It uses the local, BYOK, and supported plan model routes configured in SuperQode. The two harnesses remain available in the same terminal. Selecting Prime Agent runs Prime Agent. Selecting RLM runs the native SuperQode implementation.

Start the RLM harness in the TUI

Install SuperQode with uv:

uv tool install superqode

Open a repository and start the terminal interface:

cd your-repository
superqode

In the TUI, enter :connect, choose Connect a harness with your model, select RLM, then select a configured local, BYOK, or supported plan model. SuperQode connects the selected model to the native harness and reports python as the model-facing tool. That gives you the host profile. From 0.2.92 the two isolation profiles ship as built-in harnesses, so switching the execution boundary is one command in a live session:

:harness switch rlm-docker
:harness switch rlm-monty

:rlm sandbox reports the boundary that is now in force and lists the profiles that exist, so the choice is discoverable from inside the terminal rather than from documentation. Switching reconnects the session against the new profile.

Repository-owned settings still come from a HarnessSpec, and that is what to reach for when the built-in defaults need tuning for a codebase:

superqode --harness rlm-docker.yaml

To open the model picker directly while preserving that HarnessSpec:

superqode --harness rlm-docker.yaml --connect byok

Use --connect local instead when the model runs through Ollama, LM Studio, MLX, vLLM, or another configured local route.

TUI walkthrough with the included example

The SuperQode repository includes an incomplete release-health report. The parser, runbook, incident note, fixture, and tests contain the evidence required to implement build_release_health(). The Docker profile edits that file, so copy the example out of the checkout before running it and the clone stays clean for a second attempt:

git clone https://github.com/SuperagenticAI/superqode.git
cp -R superqode/examples/rlm-demo /tmp/rlm-demo
cd /tmp/rlm-demo

python -m unittest discover -s tests -v

The initial run reports three tests with two errors, both raising NotImplementedError for the unwritten summary. That failing baseline is the reference point for the rest of the walkthrough, and the remaining interaction happens in the SuperQode TUI.

Read-only analysis with Monty

Install the optional runtime and launch the Monty HarnessSpec:

uv tool install 'superqode[monty]'
superqode --harness rlm-monty.yaml --connect byok

The example ships this profile as a file because it tunes the subcall budget and output caps for the exercise. From 0.2.92, :harness switch rlm-monty reaches the same profile on its built-in defaults, which is the shorter route when no tuning is required.

Choose a configured model, then ask in plain language: "Read the runbook, the parser and the tests, and tell me exactly what build_release_health has to do."

The harness briefs the model on the namespace before your first word, so the prompt does not have to name context or llm_query_batched. The model reaches for them because the system prompt already told it to work over the corpus rather than pull it into the conversation.

The model can inspect the repository through controlled context calls and can delegate focused questions through llm_query_batched(). It cannot edit the implementation or run the tests under this profile.

Use the TUI commands to inspect the active environment:

:rlm sandbox doctor
:rlm session
:rlm usage
:rlm status

The sandbox report identifies Monty and reports that shell execution and writes are unavailable.

Coding with Docker

Exit the Monty session and launch the Docker HarnessSpec:

superqode --harness rlm-docker.yaml --connect byok

Choose the same model if you want to compare the two profiles, then ask: "Implement build_release_health and make the tests pass."

This profile can modify the repository, run commands inside Docker, and create recursive child sessions. The TUI continues to display python as the only model tool. From 0.2.92, :harness switch rlm-docker reaches the same boundary without the file, which is the quickest way to compare the two profiles inside one session. The following commands expose the resident worker and recursive work while the task is active:

:rlm status
:rlm sandbox doctor
:rlm agents
:rlm usage

After the task finishes, leave the TUI and verify the repository from the terminal:

python -m unittest discover -s tests -v

Selecting a harness for the task in SuperQode

PiPy suits direct coding with explicit file and shell tools. SuperQode RLM suits work that benefits from programmatic context selection, semantic subcalls, recursive coding sessions, or retained Python state. Monty serves read-only analysis, while Docker supports repository changes and command execution inside a container. Prime Agent remains available through SuperQode for its continual harness, IPython skills, schedules, heartbeats, direct agent messaging, and provider workflow. All three routes use the same SuperQode terminal. Users can choose a harness for each task without moving the repository into another interface.

Source and documentation

SuperQode is available from the Superagentic AI website, GitHub, and PyPI. The native RLM architecture, execution profiles, commands, and limitations are documented in the SuperQode RLM guide.

Prime Agent is maintained by Prime Intellect as a separate project. SuperQode's native RLM harness is an independent Python implementation and does not imply endorsement by Prime Intellect.