RLM (with no R) in goose? Context-as-variables.
- Langage dominant
- Rust
- Étoiles
- 54.2k
- Forks
- 6.2k
- Merge moyen
- 3 j 4 h
- PR mergées (30 j)
- 240
Description
**What problem would this solve?**
On long, data-heavy tasks every cat, grep, or build log lands in the conversation, gets re-billed each turn, and is lost at compaction.
The model then re-reads files and re-derives results it already computed, wasting tokens and sometimes breaking correctness.
**What would a good outcome look like?**
An (opt-in?) session-long Python runtime where variables, imports, and functions persist across turns, across compaction, and (best-effort) across process restarts.
Large tool/file outputs bind to variables, so the model sees a capped preview plus a live inventory instead of the raw blob. Equal-or-better success at lower cost.
**Possible approaches**
Inspiration: [Recursive Language Models](https://arxiv.org/abs/2512.24601) (Zhang et al., MIT CSAIL). \
-- Note: this adopts the paper's context-as-variables idea but not its defining recursion - there are no recursive LLM sub-calls - so it is a persistent execution/context surface rather than a literal RLM.
I prototyped on a default-off platform extension with a single `python` tool:
- Stdlib-only Python subprocess (JSON-lines), no ipykernel/pyo3/zeromq, so zero new Rust deps and the toggle is the feature gate.
- `sh()`/`edit()` helpers so it runs pure or alongside developer.
- After a compaction, a `` block re-anchors the surviving variables so the model reuses them instead of recomputing.
- Per-variable pickle snapshots restore state on process restart.
Trade-offs: needs python3 in the env (errors clearly if absent); snapshots skip unpicklable values; Windows uses kernel-restart instead of cell interrupt.
**Additional context**
Terminal-Bench 2.1 A/B, stock developer+todo vs the pure RLM arm:
| Model | Suite | Pass (RLM vs stock) | Cost/trial |
|---|---|---|---|
| gpt-5.6-terra | 26-task, k=3 | 82.1% vs 78.2% | -58% |
| gpt-5.6-sol | 26-task, k=3 | 87.2% vs 82.1% | -58% |
| claude-opus-5 | 26-task, k=1 | 84.6% tie | -28% |
| gpt-5.6-terra | full 89-task, k=1 | 47.2% tie | -49% |
- Accuracy is parity across evals; every pass edge is within single-run noise.
- Cost win is robust; it holds across the full distribution, with 0 kernel deaths / 0 harness exceptions.
- The win is almost entirely fewer input tokens: data lives in variables, so ~65% less context is re-sent each turn (46K vs 133K tok on terra). RLM's cache hit rate is at parity with stock.
- Compaction-survival verified end-to-end: after a real compaction the re-anchor restores kernel variables and the model answers from them without recomputing.
Follow-up work (separate issue): add the paper's actual recursion at depth 1 - a leaf `llm()` sub-call over a variable's slices - and evaluate it on a long-context benchmark, where recursion is expected to add capability rather than a cost win.
- [x] I have verified this does not duplicate an existing feature request
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
The issue describes a persistent Python runtime for an AI agent. Start by examining the existing tool execution and context management code in the Rust codebase, likely around the 'python' tool or session handling. Look for where compaction happens and how context is re-anchored. The prototype uses a JSON-lines subprocess; understand that interface. Check for feature gating and snapshot mechanisms. 'Done' means the model can reuse variables across turns and compactions, with clear error handling for missing Python.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python, rust
- Domaine
- ai-infra-agents, backend-api-design
- Type d'issue
- Fonctionnalité
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Active
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100