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/auth.py")
matches = workspace.search("refresh_token", "src")
result = shell.run(["uv", "run", "pytest", "tests/auth"])

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:

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

reviews = llm_query_batched([
    f"Identify authentication invariants in this source:\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 HarnessSpec selects where model-written Python executes. 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. Repository-owned execution settings can be selected at launch:

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(). Prepare the example from a terminal:

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

python -m unittest discover -s tests -v

The initial test run reports the missing implementation. 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

Choose a configured model, then submit this task in the TUI:

Analyze RUNBOOK.md, deploy_audit/parser.py, INCIDENT.md, and tests/test_report.py. Use context selection and llm_query_batched to identify the complete build_release_health contract. Return an implementation plan with the ordering, retry, latency, and malformed-record rules. Do not modify files or run commands.

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 submit:

Implement build_release_health in deploy_audit/report.py from the repository evidence and run the unit tests. Inspect the runbook, parser, fixture and tests before editing. Use context as data for the incident material and delegate independent reviews of the parser contract and test expectations before deciding on the implementation.

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. 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.