rlm — context as a variable

The blob stays on disk. You pull bounded slices out of it. It never enters your context whole, so its size stops being your problem.

This is prime-agent's RLM idea in the shape this harness allows: they give the model one tool (a persistent IPython kernel) and make rlm() a Python call. Here, the slicer is a script and the recursive half is Workflow — where agent() already is rlm(), a subagent spawned as a function call.

The rule

Never Read a file over ~50k tokens. Map it, grep it, slice what grep found.

R=~/.claude/skills/rlm/rlm.py

python3 $R map   FILE                  # what's in here, what would it cost
python3 $R grep  FILE PATTERN          # where the answer lives (locations, not content)
python3 $R slice FILE START END        # read only that range

One pass, streaming, bounded output. Flags: --max (output lines), --width (chars per line), --regex, --case.

map prints DO NOT read whole above ~100k tokens. Believe it.

Every command announces what it withheld — [capped: showing 40 of 4950 hits]. A cap you can't see reads as "that was everything", which is how a partial answer gets reported as a complete one.

It is enforced, not advised

A PreToolUse hook denies a Read over 2000 lines when no offset/limit was given, and names the command to run instead. That case is the whole point: Read returns a prefix with no marker in the content, so the answer gets built from the first slice and reported as if the file had been read.

The prompt matcher can't catch this — it scores the prompt and never sees a tool call, so a 4 GB log discovered three calls into a task is invisible to it. Explicit Read(offset/limit) is always allowed; that's paging on purpose.

Tune with RLM_MAX_LINES (default 2000) and RLM_MIN_BYTES (default 102400, the size below which the line count isn't worth paying for).

The loop

1. map — orient. Size, token cost, structural lines spread across the file.
2. grep — locate. You get line numbers, not the file.
3. slice — read the one range that matters, and nothing either side of it.
4. Still too big? That's the recursive half: fan the ranges out to subagents via Workflow, one agent() per range, and keep only what they return. The blob never lands in any single context — not yours, not theirs.

A million-token file becomes three bounded reads and a handful of subagent results. That is the whole trick.

Why Python

Measured on this machine, 2026-08-11, 793 MB blob, same substring search, interleaved runs:

Ripgrep lost on a 3.6 GB box already in swap — its buffering wants half a gig, and the machine, not the instruction count, is the binding constraint. Real corpus: a 43 MB / 11.2M-token transcript maps in 0.21 s at 16 MB.

metal routes it the same way independently — this is a dispatch layer, never a compute layer, and a one-shot script run by hand is question 2. It flips to Rust the moment it becomes resident: a daemon holding context across turns is question 1, and that is a different project, not a rewrite of this.

Boundaries

For files that fit comfortably, Read is better — it's one call and you get the whole thing. This earns its place only when the input is genuinely larger than the context, and reaching for it on a 200-line file is ceremony.

python3 rlm.py --selftest verifies the caps hold.