Compare RLM task decomposition with repo implementation
Compare RLM task decomposition with repo implementation
Agent
Claude Code
Model
Claude Opus 4.8
Shared
May 31, 5:15 PM
Messages38
Downloads4
Workspace
Researched recursive language models and their task decomposition strategy.
UnderstandExplored the Sovereign Hive repo's orchestration core and decomposition approach.
UnderstandConfirmed the repo's core workflow is a stub with no nested LLM calls.
VerifyCaveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.
Caveat: Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.model
Set model to [1mOpus 4.8 (1M context) (default)[22m and saved as your default for new sessions
Stdout: Set model to [1mOpus 4.8 (1M context) (default)[22m and saved as your default for new sessionsWhat are recursive language models? You might already have some information from your training data but I would like you to augment that knowledge with the latest developments, as there have been many new developments on this front in recent weeks.
I'll research this for you. Recursive language models (RLMs) is an active research area, and since you want the latest developments, let me pull current information from the web.
{
"type": "tool_reference",
"tool_name": "WebSearch"
}
{
"type": "tool_reference",
"tool_name": "WebFetch"
}I'll search for the latest on recursive language models.
Web search results for query: "recursive language models RLM"
Links: [{"title":"Recursive Language Models","url":"https://arxiv.org/pdf/2512.24601"},{"title":"Recursive Language Models","url":"https://arxiv.org/html/2512.24601v1"},{"title":"[2512.24601] Recursive Language Models","url":"https://arxiv.org/abs/2512.24601"},{"title":"GitHub - grishahq/recursive-llm: Recursive Language Models for unbounded context processing. Process 100k+ tokens with any LLM by storing context as variables instead of prompts. · GitHub","url":"https://github.com/grishahq/recursive-llm"},{"title":"GitHub - alexzhang13/rlm: General plug-and-play inference library for Recursive Language Models (RLMs), supporting various sandboxes. · GitHub","url":"https://github.com/alexzhang13/rlm"},{"title":"Recursive Language Models: the paradigm of 2026","url":"https://www.primeintellect.ai/blog/rlm"},{"title":"Recursive Language Models: Infinite Context that works | by Pietro Bolcato | Medium","url":"https://medium.com/@pietrobolcato/recursive-language-models-infinite-context-that-works-174da45412ab"},{"title":"Think, But Don't Overthink: Reproducing Recursive Language Models","url":"https://arxiv.org/pdf/2603.02615"}]
Based on the search results, here's what Recursive Language Models (RLM) are:
Recursive Language Models are a general inference strategy that treats long prompts as part of an external environment and allows the LLM to programmatically examine, decompose, and recursively call itself over snippets of the prompt.
The key insight is that long prompts should not be fed into the neural network directly but should instead be treated as part of the environment that the LLM can symbolically interact with. 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 successfully handle inputs up to two orders of magnitude beyond model context windows and, even for shorter prompts, dramatically outperform the quality of base LLMs and common long-context scaffolds across four diverse long-context tasks.
RLM-Qwen3-8B outperforms the underlying Qwen3-8B model by 28.3% on average and even approaches the quality of vanilla GPT-5 on three long-context tasks.
This approach enables training directly with the RLM scaffolding and never actually summarizes context, which leads to information loss. Instead, it pro-actively delegates context to Python scripts and sub-LLMs.
The framework was introduced by Alex Zhang and colleagues at MIT in 2025, and there are now open-source implementations and libraries available for using RLMs with various language models.
REMINDER: You MUST include the sources above in your response to the user using markdown hyperlinks.
Web search results for query: "recursive language models 2026 latest research"
Links: [{"title":"Recursive Language Models: A new framework for infinite context in LLMs - TechTalks","url":"https://bdtechtalks.com/2026/01/26/recursive-language-models/"},{"title":"What are Recursive Language Models (RLMs)? - Rise Data Labs Blog","url":"https://risedatalabs.com/blog/recursive-language-models"},{"title":"[2512.24601] Recursive Language Models","url":"https://arxiv.org/abs/2512.24601"},{"title":"Recursive Language Models: the paradigm of 2026","url":"https://www.primeintellect.ai/blog/rlm"},{"title":"Recursive Language Models: Could This Be the Real Fix for Long-Context AI in 2026? | by Vinod Polinati | Medium","url":"https://medium.com/@vinodpolinati/recursive-language-models-could-this-be-the-real-fix-for-long-context-ai-in-2026-070328df9329"},{"title":"Think, But Don't Overthink: Reproducing Recursive Language Models","url":"https://arxiv.org/pdf/2603.02615"},{"title":"Reinforcing Recursive Language Models | alphaXiv","url":"https://www.alphaxiv.org/blog/reinforcement-learning-for-rlms"},{"title":"MIT's Recursive Language Models Improve Performance on Long-Context Tasks - InfoQ","url":"https://www.infoq.com/news/2026/01/mit-recursive-lm/"},{"title":"Recursive Language Models Alex L. Zhang MIT CSAIL [REDACTED] Tim Kraska","url":"https://arxiv.org/pdf/2512.24601"},{"title":"Recursive Language Models","url":"https://arxiv.org/html/2512.24601v2"}]
Based on the latest research, here's what's happening with recursive language models in 2026:
Recursive Language Models (RLMs), a new framework developed by researchers at MIT CSAIL, provide a solution to the limited context window of large language models (LLMs). Published as a preprint in late 2025 and updated in January 2026, RLMs enable models to handle inputs far beyond standard context limits, often with better accuracy and comparable or lower cost.
RLMs treat long prompts as part of an external environment and allow the LLM to programmatically examine, decompose, and recursively call itself over snippets of the prompt. This approach enables models to process arbitrarily long prompts without incurring massive memory costs or requiring the models to undergo special training to extend their context windows.
RLMs can handle prompts up to 100x longer than base LLMs. Prime Intellect is already calling it "the paradigm of 2026".
Recent work in 2026 has explored different directions:
One framework enables Large Language Models to process near-infinite contexts by offloading the prompt into an external REPL environment, while investigating the impact of scaling the recursion depth.
Researchers are RL fine-tuning small (4B) models to behave as native recursive language models by training parent and child RLMs under a single, shared policy.
REMINDER: You MUST include the sources above in your response to the user using markdown hyperlinks.
Let me dig into the primary sources, including the most recent papers, to get the details.
Based on the arXiv abstract provided, here's what can be determined about this paper:
The paper introduces Recursive Language Models (RLMs), an inference paradigm that enables LLMs to handle arbitrarily long prompts by treating them as an external environment. The system allows models to "programmatically examine, decompose, and recursively call itself over snippets of the prompt."
RLMs can process inputs "up to two orders of magnitude beyond model context windows," meaning they handle prompts roughly 100x longer than standard context limits.
The paper reports substantial improvements across diverse long-context tasks:
A fine-tuned variant, RLM-Qwen3-8B, achieved "28.3% improvement on average" over the base Qwen3-8B model and approached GPT-5 quality on three long-context tasks.
Code is available via GitHub, and the work includes a post-trained model demonstrating the approach's viability.
The abstract doesn't specify details about particular benchmarks (OOLONG, BrowseComp-Plus), cost analysis, REPL environment specifics, or acknowledged limitations—these details likely appear in the full paper.
The authors successfully reproduced results from a paper on Recursive Language Models (RLMs), implementing the approach to verify its effectiveness. They made their reproduction code publicly available on GitHub for transparency and reproducibility.
The research examined how RLMs perform across different recursion depths. The critical insight is captured in their title: there's a sweet spot in recursive processing. The authors discovered that models benefit from some internal reasoning steps, but excessive recursion actually degrades performance rather than improving it—hence "don't overthink."
A major contribution was identifying that RLMs exhibit diminishing returns or actual performance degradation when recursion depth increases beyond optimal levels. This suggests that while intermediate reasoning can enhance model capabilities, unlimited recursive computation wastes resources and confuses the model rather than enabling better solutions.
The reproduction study provided empirical validation of RLM effectiveness while also clarifying practical limitations. The findings challenge assumptions that "more thinking" automatically yields better results, suggesting practitioners should carefully calibrate recursion depth rather than maximizing it. This has implications for models like those from DeepSeek and Kimi that implement thinking modes.
[Binary content (application/pdf, 392.9KB) also saved to /Users/me/.claude/projects/-Users-me-c-vendor-DietCode/7114d46b-12a7-4768-bab0-d402eb79c29a/tool-results/webfetch-1780247357482-f7h0i2.pdf]
The server returned HTTP 403 Forbidden.
The response body was not retrieved. If this URL requires authentication, use an authenticated tool (e.g. gh for GitHub, or an MCP-provided fetch tool) instead of WebFetch.
Let me get the cost/benchmark specifics and the RL training developments from a couple more sources.
The paper evaluates RLMs across four tasks of increasing complexity:
S-NIAH (Single Needle-in-a-Haystack): 50 tasks finding specific phrases in unrelated text, with O(1) complexity relative to input length.
BrowseComp-Plus: Multi-hop question-answering over 1,000 randomly sampled documents requiring reasoning across multiple sources.
OOLONG: Long reasoning benchmark requiring semantic transformation and aggregation with linear processing complexity relative to input length.
OOLONG-Pairs: Modified OOLONG variant requiring pairwise chunk aggregation with quadratic complexity.
CodeQA (LongBench-v2): Code repository understanding requiring reasoning over fixed files.
The system uses a Python REPL environment where the input prompt is loaded as a string variable. Key features include:
context variable containing the full input as a stringllm_query() function for recursively querying sub-LLMs (handling ~500K characters)print() for output inspectionRoot Model vs. Sub-calls:
For GPT-5 experiments, GPT-5 serves as the root model making decisions, while GPT-5-mini handles recursive sub-calls. For Qwen3-Coder-480B, it functions as both root and sub-caller. The fine-tuned RLM-Qwen3-8B uses Qwen3-8B for both roles.
Key findings from Table 1:
Model Capability Requirements: Smaller models lacking sufficient coding ability struggle as RLMs; Qwen3-8B required fine-tuning.
Synchronous Call Bottleneck: Current implementation uses blocking sequential calls, causing runtime inefficiency. Authors note asynchronous sub-calls could significantly reduce costs.
Output Token Constraints: "Thinking models without sufficient output tokens struggle as RLMs"—trajectories exceeded maximum output token lengths.
System Prompt Sensitivity: Fixed prompts across models proved problematic; Qwen3-Coder required additional warnings against excessive sub-calls.
Structural Output Brittleness: Distinguishing final answers from intermediate thoughts using FINAL() tags was "brittle," requiring safeguards and model-specific adjustments.
Limited Recursion Depth: Evaluation uses maximum recursion depth of one; deeper recursion levels remain unexplored.
Web search results for query: "reinforcing recursive language models RL fine-tuning parent child shared policy 4B"
Links: [{"title":"Reinforcing Recursive Language Models | alphaXiv","url":"https://www.alphaxiv.org/blog/reinforcement-learning-for-rlms"},{"title":"Tapered Off-Policy REINFORCE: Stable and efficient reinforcement learning for LLMs","url":"https://arxiv.org/pdf/2503.14286"},{"title":"What are Recursive Language Models (RLMs)? - Rise Data Labs Blog","url":"https://risedatalabs.com/blog/recursive-language-models"},{"title":"RL Fine-Tuning of Language Models CS 224R Default Project Specification","url":"https://cs224r.stanford.edu/material/CS224R_Default_Project_Guidelines.pdf"},{"title":"Think, But Don't Overthink: Reproducing Recursive Language Models","url":"https://arxiv.org/pdf/2603.02615"},{"title":"Shattering the Agent-Environment Interface for Fine-Tuning Inclusive Language Models","url":"https://arxiv.org/pdf/2305.11455"},{"title":"Reinforcement Learning without Human Feedback for Last Mile Fine-Tuning of Large Language Models","url":"https://arxiv.org/pdf/2408.16753"}]
Based on the search results, here's what I found:
The search reveals a project on "Reinforcing Recursive Language Models" where researchers RL fine-tune small (4B) models to behave as native recursive language models (RLMs) by training parent and child RLMs under a single, shared policy.
Rather than training separate policy models for parent and child RLMs, they train one model to play both roles of a parent decomposer and child sub-agent. With RL, small models can learn task-specific, RLM behavior that cannot be elicited through prompting or even SFT.
On an evidence selection task over several scientific documents, they show that an RL fine-tuned 4B model performs just as well as Claude Sonnet 4.6 with an identical RLM harness and REPL environment, all while being a fraction of the size and cost.
The key innovation here is using a shared policy approach where a single model handles both the parent role (decomposing tasks) and the child role (solving sub-tasks) in a recursive language model framework, rather than training separate models for each role.
REMINDER: You MUST include the sources above in your response to the user using markdown hyperlinks.
Recursive Language Models are an inference strategy (not a new model architecture) for handling near-unbounded context. The core move: instead of cramming a giant prompt into the model's context window, you treat the prompt as data in an environment that the model interacts with programmatically, recursively calling itself (or a smaller sibling) over chunks of it.
The paradigm was introduced by Alex L. Zhang and Tim Kraska at MIT CSAIL (arXiv 2512.24601, late 2025, updated Jan 2026). It's gotten enough traction that Prime Intellect dubbed it "the paradigm of 2026."
context string variable inside a Python REPL — it never goes into the model's prompt directly.print(), string ops, etc.), using variables as scratch buffers.llm_query() — a recursive sub-call to an LM instance (handling ~500K chars per call). Those sub-calls can themselves be RLMs.FINAL() tags).The key philosophical claim: never summarize/compact the context (which loses information). Instead, delegate it to scripts and sub-LMs that read the relevant parts on demand.
Smaller models need coding ability (Qwen3-8B required fine-tuning); synchronous/blocking sub-calls hurt latency (async would help a lot); thinking models can blow past output-token limits; system-prompt sensitivity; brittle answer/thought separation; and notably the original paper only evaluated recursion depth of 1.
The two most significant recent additions:
1. "Think, But Don't Overthink: Reproducing Recursive Language Models" (arXiv 2603.02615). An independent reproduction that (a) confirms RLMs work and open-sources the reproduction, and crucially (b) probes the recursion-depth axis the original left unexplored. Finding: there's a sweet spot — some recursion helps, but deeper recursion degrades performance and wastes compute rather than improving it. This pushes back on the intuition that "more recursive thinking = better" and argues depth must be calibrated, not maximized.
2. "Reinforcing Recursive Language Models" (alphaXiv). Moves RLMs from a prompting scaffold to a trained capability. They RL fine-tune a small (4B) model to be a native RLM, with the key trick of a single shared policy playing both roles — parent (decomposer) and child (sub-agent) — rather than two separate models. Result: on an evidence-selection task over scientific documents, the RL'd 4B model matched Claude Sonnet 4.6 under an identical RLM harness, at a fraction of the size/cost. Notably, they report this RLM behavior can't be elicited by prompting or even SFT — it requires RL.
The throughline of these recent works: RLMs are shifting from a clever inference-time hack toward a trainable, optimized behavior, while the community simultaneously maps out where it breaks (depth/overthinking).
Beyond the academic libraries (alexzhang13/rlm — a plug-and-play inference library supporting various sandboxes), there are now community implementations like grishahq/recursive-llm for running RLMs over 100k+ token contexts with arbitrary LLMs.
A note on confidence: today is 2026-05-31 and some of these (the 2603.xxxxx reproduction, the RL work) postdate my training cutoff, so I'm relaying them from the sources rather than prior knowledge — worth reading the primaries directly before relying on specific numbers.
Sources:
Want me to go deeper on any thread — e.g. the RL training recipe, the depth/overthinking analysis, or how RLMs compare to alternatives like RAG and context-compaction agents?
How does this strategy of task decomposition compare with the implementation (and aspirations) in this repo? What are the tradeoffs?
Good question — but I need to actually understand this repo first. Let me explore it.
>echo "=== TREE (src) ===" && find src -type f 2>/dev/null | head -100; echo "=== ROOT FILES ===" && ls -1 *.md *.ts *.json 2>/dev/null; echo "=== README head ===" && head -60 README.md 2>/dev/null=== TREE (src) ===
src/implementation-report.md
src/IMPLEMENTATION_SUMMARY.md
src/DRIFT_PREVENTION_REPORT.md
src/PRODUCTION_HARDENING_COMPLETE.md
src/PRODUCTION_HARDENING_AUDIT.md
src/PRODUCTION_HARDENING_AUDIT_REPORT.md
src/UNIFIED_SAFETY_MODERN_INTEGRATION.md
src/SAFETY_TOOL_INTEGRATION_COMPLETE.md
src/PRODUCTION_HARDENING_PHASE2_REPORT.md
src/INFRASTRUCTURE_TOOLS_PRODUCTION_READINESS.md
src/NATIVE_PREWORK_AUDIT.md
src/SECOND_PASS_AUDIT_REPORT.md
src/integration-demo.ts
src/PROTOCOL_INTEGRATION_SUMMARY.md
src/ui/terminal.ts
src/test/find_missing_id.ts
src/test/verify_drift_prevention.ts
src/test/verify_nuclear_patch.ts
src/test/verify_schema_patching.ts
src/utils/stringUtils.ts
src/shared/McpDisplayMode.ts
src/shared/Languages.ts
src/shared/array.ts
src/shared/focus-chain-utils.ts
src/shared/getApiMetrics.ts
src/shared/string.ts
src/shared/slashCommands.ts
src/shared/HistoryItem.ts
src/shared/mcp.ts
src/shared/AutoApprovalSettings.ts
src/shared/string.test.ts
src/shared/config-types.ts
src/shared/api.ts
src/shared/combineErrorRetryMessages.ts
src/shared/prompts.ts
src/shared/constants.ts
src/shared/combineHookSequences.test.ts
src/shared/net.ts
src/shared/tools.ts
src/shared/combineHookSequences.ts
src/shared/ChatContent.ts
src/shared/context-mentions.ts
src/shared/index.ts
src/shared/skills.ts
src/shared/combineApiRequests.ts
src/shared/combineCommandSequences.ts
src/shared/cline-rules.ts
src/shared/TelemetrySetting.ts
src/shared/content-limits.ts
src/shared/array.test.ts
src/shared/Patch.ts
src/shared/FocusChainSettings.ts
src/infrastructure/SelectedOptionsBuilder.ts
src/infrastructure/TransactionManager.ts
src/infrastructure/PromptLoader.ts
src/infrastructure/TypeScriptValidator.ts
src/infrastructure/FuzzySearchRepository.ts
src/infrastructure/NodeTerminalAdapter.ts
src/infrastructure/PromptMiddlewareManager.ts
src/infrastructure/FileTypes.ts
src/infrastructure/TerminalDisplay.ts
src/infrastructure/SemanticIntegrityAdapter.ts
src/infrastructure/NodeSystemAdapter.ts
src/infrastructure/FileSystemAdapter.ts
src/infrastructure/IntegrityAdapter.ts
src/infrastructure/PromptRegistryAdapter.ts
src/infrastructure/WorkerIntegrityAdapter.ts
src/infrastructure/WalkerConfigBuilder.ts
src/infrastructure/ConsoleLoggerAdapter.ts
src/infrastructure/IntegrityVerificationProvider.ts
src/infrastructure/WorkerPoolAdapter.ts
src/infrastructure/BinaryFileTypeDetector.ts
src/infrastructure/EnhancedFileSystemAdapter.ts
src/infrastructure/FileIntegrityAnalyzer.ts
src/domain/Validation.ts
src/domain/Errors.ts
src/domain/LLMProvider.ts
src/domain/Event.ts
src/domain/validation/RiskLevel.ts
src/domain/validation/RollbackProtocol.ts
src/domain/validation/RiskEvaluator.ts
src/ui/design/Theme.ts
src/ui/renderers/CinematicRenderer.ts
src/ui/renderers/HudRenderer.ts
src/ui/renderers/BoxRenderer.ts
src/ui/renderers/MetabolicRenderer.ts
src/ui/components/Hud.ts
src/ui/components/AuthSequence.ts
src/core/context/ContextService.ts
src/core/context/AttachmentResolver.ts
src/core/context/DiscoveryService.ts
src/core/context/Ignorer.ts
src/core/context/RuleContextBuilder.ts
src/core/context/ContextOptimizationService.ts
src/core/context/FileContextTracker.ts
src/core/context/ContextPruner.ts
src/core/capabilities/CommandProcessor.ts
src/core/capabilities/SafetyGuard.ts
src/core/capabilities/ExecutionGovernor.ts
src/core/capabilities/PromptService.ts
=== ROOT FILES ===
AGENTS.md
ARCHITECTURE.md
CLAUDE.md
CODE_OF_CONDUCT.md
CONTRIBUTING.md
DEVELOPMENT.md
eslint_report.json
FEATURES.md
index.ts
INTEGRATION_COMPLETION.md
integrity_audit.md
JOY_ZONING_GUIDE.md
JOY_ZONING_MANIFESTO.md
JOYZONING_AUDIT_REPORT.md
JOYZONING.md
npx_self_heal.ts
package-lock.json
package.json
PHASE_3A_CONTEXT_OPTIMIZATION.md
PREWORK_IMPLEMENTATION_REPORT.md
PREWORK_PROTOCOL_COMPLETION_REPORT.md
prework.json
proto.md
README.md
run_audit_3_0.ts
SECURITY.md
test_focus_shield.ts
test_scaffolding.ts
test-claude-patterns.ts
THIRD_PASS_IMPLEMENTATION_REPORT.md
tsconfig.json
verify_advanced_infrastructure.ts
verify_cinematic_auth.ts
verify_cinematic_boot.ts
verify_dreamstate_boot.ts
verify_hardening.ts
verify_healing.ts
verify_joyfull.ts
verify_joyzoning_bypass_test.ts
verify_joyzoning.ts
verify_matrix_convergence.ts
verify_memory.ts
verify_metabolic_ui.ts
verify_prework.ts
verify_production_hardening.ts
verify_provider_sync.ts
verify_rainbow_shimmer.ts
verify_scoring.ts
verify_setup_hardening.ts
verify_shimmer_pulse.ts
verify_simple_onboarding.ts
verify_sovereign_aether.ts
verify_sovereign_v6.ts
verify_sovereign_v7.ts
verify_swarm.ts
verify_tool_security.ts
verify_triple_down.ts
verify_ui_architecture.ts
verify_vaporwave_ui.ts
=== README head ===
<p align="center">
<img src="assets/vsix/logo.png" width="400" alt="DietCode Logo">
</p>
# 🥗 DietCode: Sovereign Hive
> **"The most sharded, modular, and Level 10 hardened AI orchestration infrastructure in the ecosystem."**
**DietCode** is a minimalist, architecturally pure AI coding assistant. It is engineered with the **Sovereign Hive Architecture**, strictly adhering to **Joy-Zoning** principles to ensure zero-shim, high-throughput AI orchestration in a standalone CLI environment.
---
## 🏛️ The Sovereign Vision
DietCode isn't just a tool; it's a **Sovereign Hive**. By sharding logic into strict, isolated professional zones, we achieve:
- **Axiomatic Finality**: Every action is verified, typed, and hardened.
- **Zero-Shim Orchestration**: Direct, granular control over AI agents without bloated abstractions.
- **Cinematic CLI**: A high-fidelity, immersive terminal interface designed for peak flow.
---
## 🚀 Quick Start
### 1. Prerequisites
- [Bun](https://bun.sh) runtime (v1.2.18+)
- Google Gemini API Key (or other compatible providers)
### 2. Installation
```bash
bun install
```
> [!NOTE]
> The installation process automatically builds the CLI and links the `dietcode` command to your terminal using a `postinstall` hook.
### 3. Launching the Hive
To initiate the cinematic onboarding and establish your neural link:
```bash
dietcode
```
> [!TIP]
> If symbols are not displaying correctly in your terminal, run `dietcode --no-unicode` to enable **Axiom ASCII** compatibility mode.
---
## 📐 Joy-Zoning Architecture
DietCode follows a strict layered architecture to prevent technical drift:
- **📁 DOMAIN**: Pure business logic. The axiomatic heart.
- **📁 CORE**: Orchestration. Coordinating the Hive's pulse.
- **📁 INFRASTRUCTURE**: Concrete adapters (AI SDKs, FS, DB).
- **📁 UI**: Cinematic terminal presentation and renderers.
- **📁 PLUMBING**: Stateless, zero-context utilities.
For a deep dive, see [ARCHITECTURE.md](ARCHITECTURE.md).
---
## 📚 Documentation MapA "Sovereign Hive" orchestration CLI. Let me look at how it actually decomposes/orchestrates work, and what it aspires to — focusing on the orchestration core, the "swarm," and context handling (the part most comparable to RLMs).
Perfect. Now let me compile my comprehensive report based on the actual implementation I've discovered:
---
## DietCode: Task Decomposition vs. RLM Comparison Report
### EXECUTIVE SUMMARY
**DietCode is a "Sovereign Hive" framework that is heavily aspirational/visionary in its documentation but pragmatic in actual implementation.** It is **NOT** a recursive/multi-agent orchestration system like Recursive Language Models. It is a **single-turn, single-provider** CLI that emphasizes:
- **Joy-Zoning** layered architecture (strict module isolation)
- **Context optimization** (token efficiency via file-read caching)
- **Safety guardrails** (tool execution validation)
- **No real task decomposition or agent spawning**
Codebase stats: **333 TypeScript files (~42.8K LOC), 43 markdown docs (~8.6K LOC)** — substantial documentation-to-code ratio indicates heavy aspirationalism.
---
## 1. TASK DECOMPOSITION & ORCHESTRATION
### ACTUAL IMPLEMENTATION: Minimal
**File**: `/Users/me/c/vendor/DietCode/src/core/orchestration/orchestrator.ts:1-195`
The `Orchestrator` class is a **placeholder framework**, not a true decomposition engine:
```typescript
// orchestrator.ts:75-172 - Main workflow execution
async executeWorkflow<T>(workflowInput: T): Promise<unknown> {
// Single branching point - no task breakdown
let result: unknown;
if (this.executionService) {
result = await this.executeCoreWorkflow(workflowInput);
} else {
result = await this.executeFallbackWorkflow(workflowInput);
}
return result;
}
// orchestrator.ts:145-162 - "Core workflow" is hollow
private async executeCoreWorkflow<T>(input: T): Promise<unknown> {
console.log('🎯 Core workflow execution');
// Example: Trigger handover if configured
const handoverTrigger = (input as Record<string, unknown> & { triggerHandover?: boolean })
?.triggerHandover;
if (this.handoverService && handoverTrigger) {
await this.handoverService.executeHandover('default-orchestrator', 'target-orchestrator');
}
return { status: 'completed', input };
}
```
**Analysis**: This is a **pure stub**. There is **zero actual task decomposition logic**. The orchestrator delegates to `ExecutionService` or fallback, but neither actually breaks tasks into subtasks.
### ASPIRATION vs. REALITY
**Aspiration** (proto.md):
> "The Antigravity Harness is a **Living Execution Environment**... `BACKLOG` → `READY` → `SHADOW_SIM` → `SOVEREIGN_DOING` → `VERIFYING` → `DONE`"
**Reality**: The pipeline described in `proto.md` (shadow simulation, pre-flight integrity scoring) **does not exist** in the codebase. No `SHADOW_SIM` state machine, no pre-flight verification scoring.
### Sub-agent / Swarm Spawning: NOT IMPLEMENTED
**File**: `/Users/me/c/vendor/DietCode/src/shared/tools.ts:1-71`
The tool enum includes `USE_SUBAGENTS`:
```typescript
export enum SovereignTool {
USE_SUBAGENTS = "use_subagents",
}
```
**But**: This is a **declared tool definition only**. There is **no executor** for `USE_SUBAGENTS`. No code actually spawns subagents. It's a **wishlist item**.
**Agent Registry** (src/core/capabilities/AgentRegistry.ts:14-54):
```typescript
constructor() {
this.register({
id: 'agent-dietcode',
title: 'DietCode Primary',
systemPrompt: 'You are DietCode, a minimalist but powerful software engineering AI.',
maxTokens: 4096,
});
this.register({
id: 'agent-distiller',
title: 'Memory Distiller',
systemPrompt: 'You are a knowledge distillation engine.',
maxTokens: 1024,
});
this.register({
id: 'agent-architect',
title: 'Swarm Architect',
systemPrompt: 'You are the Swarm Architect.',
maxTokens: 4096,
});
}
```
**Reality**: These three agents are **pre-registered but never invoked sequentially**. There is **no recursive spawning**, no **delegation chain**. The agents exist as statically defined records.
---
## 2. CONTEXT HANDLING
### ACTUAL IMPLEMENTATION: Token-Efficient via Pruning + Caching
**File**: `/Users/me/c/vendor/DietCode/src/core/context/ContextPruner.ts:1-177`
DietCode implements **"Semantic Folding"** — a form of context compression:
```typescript
// ContextPruner.ts:154-161 - File folding strategy
const headSize = Math.floor(this.config.maxLines * this.config.headRatio);
const tailSize = Math.floor(this.config.maxLines * this.config.tailRatio);
const head = lines.slice(0, headSize).join('\n');
const tail = lines.slice(-tailSize).join('\n');
const prunedContent = `${head}\n\n... [FOLDED: ${lines.length - headSize - tailSize} lines hidden for cognitive focus] ...\n\n${tail}`;
```
**Default config**: 150 max lines, 60% head ratio, 30% tail ratio. Files > 150 lines get **summarized by keeping first 90 lines + last 45 lines**, discarding middle.
### Context Optimization Service (Phase 3A)
**File**: `/Users/me/c/vendor/DietCode/src/core/orchestration/ContextOptimizationService.ts:1-303`
This is **more substantial** than the orchestrator — implements **"two-finger pattern"** (file read caching):
```typescript
// ContextOptimizationService.ts:110-184 - Cache-based optimization
async readFileOptimized(
filePath: string,
source: FileReadSource = 'tool_execute',
): Promise<OptimizedFileReadResult> {
// If file already read within time window, return cached signature
const savedSignature = this.signatureDatabase.getSignature(filePath);
const isCachedOptimization = savedSignature?.optimized && this.needsOptimization(filePath);
if (isCachedOptimization) {
return {
result: cachedResult,
wasOptimized: true,
optimizationReason: 'reusing_cached_optimization',
};
}
// Otherwise, read fresh and cache
const result = await this.optimizationService.recordRead(filePath, content, source);
return { result, wasOptimized: ..., optimizationReason: ... };
}
```
**Context Management Strategy**:
- **NOT** a Python REPL or queryable sandbox (unlike RLM)
- **NOT** loading context into a variable the model can introspect
- **Stuffing everything into the prompt** (standard Claude/Gemini pattern)
- **Pruning + caching** to reduce token load before stuffing
**Optimization Decision Logic**: Tracks read patterns and decides whether to emit cached signatures or force fresh reads. No LLM introspection.
---
## 3. LLM CALL STRUCTURE
### ACTUAL IMPLEMENTATION: Single-Provider, Single-Turn
**File**: `/Users/me/c/vendor/DietCode/src/infrastructure/llm/providers/GeminiProvider.ts:1-73`
```typescript
// GeminiProvider.ts:26-60 - Monolithic LLM call
async createMessage(
agent: Agent,
messages: Message[],
_tools: ToolDefinition[],
_metadata?: { taskId?: string },
): Promise<LLMResponse> {
const model = this.client.getGenerativeModel({
model: agent.model || 'gemini-2.0-flash',
});
const contents = messages.map((m) => ({
role: m.role === 'assistant' ? 'model' : 'user',
parts: [{ text: typeof m.content === 'string' ? m.content : JSON.stringify(m.content) }],
}));
const result = await model.generateContent({
contents: contents as any,
});
const text = result.response.text();
return { content: [{ type: 'text', text }], usage };
}
```
**Analysis**:
- **Single `generateContent()` call per user input** — no nesting, no recursion
- **No looping or re-invocation** to refine output
- **Gemini is the hardcoded default** (`gemini-2.0-flash`)
- **Tool definitions are passed but NOT USED** — `_tools` parameter is ignored (`_` prefix)
- **No tool-calling loop** — the Gemini SDK would handle tool calls client-side if needed, but this code doesn't integrate that
**Provider Registry** (`src/core/manager/LLMProviderRegistry.ts`):
- Manages multiple adapter instances (could support Anthropic/OpenAI in theory)
- **Only Gemini is actually implemented** (no Anthropic/OpenAI adapters found)
- No switching between providers mid-task
- No fallback logic
---
## 4. TOOLS / CODE EXECUTION
### ACTUAL IMPLEMENTATION: Declarative Tool List + Safety Wrapper
**File**: `/Users/me/c/vendor/DietCode/src/shared/tools.ts:1-71`
Tools are **declared as enum values**, NOT executable code:
```typescript
export enum SovereignTool {
ASK = "ask_followup_question",
ATTEMPT = "attempt_completion",
BASH = "execute_command",
FILE_EDIT = "replace_in_file",
FILE_READ = "read_file",
FILE_NEW = "write_to_file",
SEARCH = "search_files",
LIST_FILES = "list_files",
MCP_USE = "use_mcp_tool",
// ... 20+ more
}
```
**No built-in Python/shell execution REPL**. Tools are **intent declarations** meant for:
- Claude Code harness to execute (this is a Claude Code plugin)
- External tool executor (not shown)
**Safety Wrapper**: `/Users/me/c/vendor/DietCode/src/core/orchestration/ExecutionService.ts:1-429`
```typescript
// ExecutionService.ts:231-338 - Unified safety envelope
async executeWithUnifiedSafety(
executionOptions?: SafeExecutionOptions,
toolName?: string,
input?: Record<string, unknown>,
): Promise<UnifiedToolExecutionResult> {
// Phase 1: Publish event
this.eventBus.publish(EventType.TOOL_CALL_START, { toolName, input }, { correlationId, ... });
// Phase 2: Route tool (optional)
if (this.toolRouter) {
const routeResult = await this.toolRouter.route({ operationType, target, parameters });
}
// Phase 3: Execute with SafetyGuard wrapper
const toolResult = await this.toolManager.executeWithSafety(toolName, input, executionOptions);
// Phase 4: Publish result + state update
this.eventBus.publish(toolResult.success ? EventType.TOOL_CALL_SUCCESS : EventType.TOOL_CALL_FAILURE, ...);
return { toolName, result, success, riskLevel, approved, ... };
}
```
**Key point**: DietCode **does NOT execute code directly**. It's a **CLI wrapper** that:
1. **Declares** what tools the LLM can call
2. **Validates** tool parameters via SafetyGuard (risk evaluation)
3. **Delegates to external executor** (Claude Code harness)
4. **Records outcomes** in event bus + state
**No Python REPL, no inline bash execution, no programmatic data manipulation by the model itself.**
---
## 5. ASPIRATIONS FROM VISION DOCS
### Vision Claims (README.md, ARCHITECTURE.md, proto.md):
**From README.md:1-9**:
> "DietCode is a minimalist, architecturally pure AI coding assistant. It is engineered with the **Sovereign Hive Architecture**, strictly adhering to **Joy-Zoning** principles to ensure **zero-shim, high-throughput AI orchestration**."
**Reality**: Zero-shim orchestration is **not implemented**. The orchestrator is a hollow stub with placeholders.
---
**From ARCHITECTURE.md:1-88**:
> "DietCode isn't just a tool; it's a **Sovereign Hive**. By sharding logic into strict, isolated professional zones, we achieve:
> - **Axiomatic Finality**: Every action is verified, typed, and hardened.
> - **Zero-Shim Orchestration**: Direct, granular control over AI agents without bloated abstractions."
**Reality achieved**: ✅ Joy-Zoning layering (strict module isolation) — this IS real and well-enforced.
**Reality NOT achieved**: ❌ Zero-shim agent orchestration — no multi-agent control loops exist.
---
**From FEATURES.md:15-21**:
> "At the heart of DietCode is a **Zero-Shim** orchestrator. This provides direct, granular control over AI agents:
> - **Agent Shadows**: Asynchronous, background agents that process secondary tasks without locking the main Hive thread.
> - **Task Sharding**: Complex goals are automatically broken down into atomic, verifiable sub-tasks.
> - **Axiomatic Guardrails**: Every tool call is intercepted and validated against the Hive's safety protocols."
**Reality**:
- ❌ **Agent Shadows**: Declared but not implemented. No async agent spawning code.
- ❌ **Task Sharding**: Zero code for automatic breakdown. Manual `CommandProcessor` only handles slash commands.
- ✅ **Axiomatic Guardrails**: SafetyGuard + ExecutionService do validate and intercept tools.
---
**From proto.md:1-62** (Antigravity Harness v6.0):
> "The Antigravity Harness is a **Living Execution Environment**... performs the implementation in a virtualized memory space. **Verification Loop**: If the Simulated Verification Score < 0.95, the Harness refuses to enter the `SOVEREIGN_DOING` state."
**Reality**: **Not implemented**. No shadow execution, no verification scoring, no state machine pipeline. Proto.md reads like a design document for a future system, not a description of current code.
---
### What DietCode ACTUALLY Aspires to Become (From Docs):
**From JOY_ZONING_GUIDE.md**:
The actual implemented aspiration is **architectural purity via layering**:
- DOMAIN (pure logic) → CORE (orchestration) → INFRASTRUCTURE (adapters) → UI (presentation)
- **Strict dependency flow enforcement** via `[LAYER]` tags in every file
- This **IS working** and **IS enforced** in the actual code
**From PHASE_3A_CONTEXT_OPTIMIZATION.md**:
Real aspiration is **context efficiency**:
- Reduce token usage via intelligent file-read reuse ("two-finger pattern")
- Track file signatures in SQLite
- This **IS partially working** (ContextOptimizationService exists, signatures tracked)
---
## 6. EXECUTION vs. ASPIRATION SUMMARY TABLE
| Dimension | Aspiration | Actual Implementation | Evidence |
|-----------|-----------|----------------------|----------|
| **Task Decomposition** | Automatic breakdown into sub-tasks | No sub-task logic | orchestrator.ts:145-172 returns `{status: 'completed', input}` (hollow) |
| **Multi-Agent Orchestration** | SwarmArchitect + Agent Shadows | 3 pre-registered agents, never invoked | AgentRegistry.ts:18-35 (static list only) |
| **Recursive Model Calls** | Re-invocation for refinement | Single-turn per input | GeminiProvider.ts:26-60 (one `generateContent()` call) |
| **Context as Queryable State** | REPL / introspectable sandbox | Pruned text in prompt | ContextPruner.ts (semantic folding only) |
| **Sub-agent Spawning** | `USE_SUBAGENTS` tool triggers agents | Tool declared, no executor | tools.ts:33 enum entry, no implementation |
| **Shadow Execution** | Pre-flight verification in VM | No verification code | proto.md describes; code missing |
| **Semantic Folding** | Keep first+last, discard middle | ✅ Implemented | ContextPruner.ts:154-161 |
| **Tool Safety Validation** | Risk evaluation before execution | ✅ Implemented | ExecutionService.ts + SafetyGuard |
| **Joy-Zoning Purity** | Strict layer isolation | ✅ Implemented | Every .ts file has [LAYER] tag, enforced |
| **State Persistence** | BroccoliQ (SQLite sharding) | ✅ Partially (signatures DB) | SignatureDatabase usage in ContextOptimizationService |
---
## 7. CODE VOLUME ANALYSIS
- **Total TypeScript**: 333 files, ~42.8K LOC
- **Total Markdown**: 43 files, ~8.6K LOC
- **Markdown-to-Code Ratio**: **0.20** — 20% documentation density
**Interpretation**: This ratio is **high for actual implementation**. Most mature projects have 5-10% doc density. DietCode's high ratio suggests:
1. **Aspirational roadmap docs** (proto.md, FEATURES.md describe future state)
2. **Architecture philosophy docs** (JOYZONING.md, JOY_ZONING_MANIFESTO.md enforce patterns)
3. **Minimal execution code** relative to documentation
---
## COMPARISON TO RECURSIVE LANGUAGE MODELS (RLM)
### Key Differences:
| Aspect | RLM | DietCode |
|--------|-----|----------|
| **Decomposition** | Recursive function calls within a single model invocation | No decomposition; single-turn execution |
| **Context Handling** | Python REPL: model writes + executes code to manipulate context | Text pruning + caching; context supplied in prompt |
| **Agent Interaction** | Multiple agents calling each other with refined context | Three agents exist but never interact |
| **Tool Execution** | Model runs code, inspects output, decides next step | Model declares intent; external executor runs tools |
| **Feedback Loop** | Within-call refinement (recursive calls see results) | Between-call (next user turn provides feedback) |
| **Orchestration** | Built into model's reasoning (agentic) | External command processor (imperative) |
---
## FINAL VERDICT
**DietCode is NOT a Recursive Language Model architecture.**
It is a **Joy-Zoning-enforced CLI wrapper** that:
1. ✅ **Achieves architectural purity** (strict layer separation)
2. ✅ **Implements context efficiency** (pruning + caching)
3. ✅ **Validates tool execution** (SafetyGuard)
4. ❌ **Does NOT decompose tasks** (no sub-task logic)
5. ❌ **Does NOT spawn agents** (USE_SUBAGENTS is declared but not implemented)
6. ❌ **Does NOT use recursive model calls** (single-turn Gemini invocation)
7. ❌ **Does NOT provide introspectable context** (stuffs pruned text in prompt, no REPL)
**The gap between aspiration (proto.md, FEATURES.md) and implementation (hollow orchestrator, unused agent registry) is substantial.** Much of the codebase is **verification scripts, integration scaffolding, and architectural documentation** rather than working orchestration logic.
If compared to RLM on the decomposition axis (the "recursive" part), DietCode scores **0/10** — there is no recursive decomposition. On the context-optimization axis, it scores **6/10** — pruning and caching exist, but no model-driven introspection.The exploration gave me concrete file references. Let me verify the two load-bearing claims directly before I assert them — the orchestrator "stub" and whether USE_SUBAGENTS actually has an executor.
>cd /Users/me/c/vendor/DietCode; echo "=== orchestrator.executeCoreWorkflow ==="; sed -n '140,175p' src/core/orchestration/orchestrator.ts 2>/dev/null; echo; echo "=== grep USE_SUBAGENTS / use_subagents executors ==="; grep -rn "use_subagents\|USE_SUBAGENTS\|spawnSubagent\|executeSubagent\|subAgent" src --include=*.ts | grep -v test | head -30; echo; echo "=== grep recursive llm_query nested generateContent ==="; grep -rn "generateContent\|createMessage" src/infrastructure --include=*.ts | head=== orchestrator.executeCoreWorkflow ===
/**
* Execute core orchestration workflow
*
* @param input Workflow parameters
*/
private async executeCoreWorkflow<T>(input: T): Promise<unknown> {
if (!this.executionService) {
throw new Error('Execution service not configured');
}
// Placeholder for core workflow logic
// This would involve coordinating EventBus, ExecutionService, and other services
console.log('🎯 Core workflow execution');
// Example: Trigger handover if configured
const handoverTrigger = (input as Record<string, unknown> & { triggerHandover?: boolean })
?.triggerHandover;
if (this.handoverService && handoverTrigger) {
await this.handoverService.executeHandover('default-orchestrator', 'target-orchestrator');
}
return { status: 'completed', input };
}
/**
* Execute fallback orchestration workflow
*
* @param input Workflow parameters
*/
private async executeFallbackWorkflow<T>(input: T): Promise<unknown> {
console.log('⚠️ Fallback execution mode (no dependencies configured)');
return { status: 'completed', input, fallback: true };
}
/**
* Get Orchestrator diagnostics
=== grep USE_SUBAGENTS / use_subagents executors ===
(eval):1: no matches found: --include=*.ts
=== grep recursive llm_query nested generateContent ===
(eval):1: no matches found: --include=*.ts>cd /Users/me/c/vendor/DietCode; echo "=== subagent executors ==="; grep -rn "use_subagents\|USE_SUBAGENTS\|spawnSubagent\|executeSubagent" src 2>/dev/null | grep -v -i test | head -30; echo; echo "=== nested/recursive model calls (createMessage callers) ==="; grep -rn "createMessage\|generateContent" src 2>/dev/null | grep -v -i test | head -20; echo; echo "=== where is orchestrator wired into index/main loop? ==="; grep -rn "executeWorkflow\|new Orchestrator\|Orchestrator(" src index.ts 2>/dev/null | head=== subagent executors ===
src/shared/tools.ts:33: USE_SUBAGENTS = "use_subagents",
src/shared/tools.ts:69: SovereignTool.USE_SUBAGENTS,
=== nested/recursive model calls (createMessage callers) ===
src/core/memory/MemoryService.ts:66: const response = await this.llmProvider.createMessage(
src/infrastructure/llm/providers/GeminiProvider.ts:26: async createMessage(
src/infrastructure/llm/providers/GeminiProvider.ts:41: const result = await model.generateContent({
src/infrastructure/llm/providers/GeminiProvider.ts:66: await model.generateContent('ping');
src/infrastructure/llm/providers/GeminiAdapter.ts:34: createMessage(system: string, messages: Message[], tools?: ToolDefinition[]): ApiStream {
src/infrastructure/queue/QueueWorker.ts:200: const response = await this.provider.createMessage(
src/infrastructure/queue/QueueWorker.ts:272: const response = await this.provider.createMessage(
src/domain/LLMProvider.ts:35: createMessage(
src/domain/agent/LLMProviderAdapter.ts:73: createMessage(system: string, messages: Message[], tools?: ToolDefinition[]): ApiStream;
=== where is orchestrator wired into index/main loop? ===
src/DRIFT_PREVENTION_REPORT.md:342:const orchestrator = new DriftDetectionOrchestrator(
src/core/manager/LockOrchestrator.ts:89: LockOrchestrator.instance = new LockOrchestrator();
src/core/manager/orchestrator/StateOrchestrator.ts:99: StateOrchestrator.instance = new StateOrchestrator(
src/core/orchestration/orchestrator.ts:62: return this.executeWorkflow(input);
src/core/orchestration/orchestrator.ts:75: async executeWorkflow<T>(workflowInput: T): Promise<unknown> {
src/core/orchestration/ContextOptimizationService.ts:297:export function createDefaultOrchestrator(
src/core/orchestration/ContextOptimizationService.ts:301: return new ContextOptimizationServiceOrchestrator(signatureDatabase, config);
src/test/verify_drift_prevention.ts:79: const orchestrator = new DriftDetectionOrchestrator(
src/infrastructure/task/integration-demo.ts:85: const orchestrator = new DriftDetectionOrchestrator(
index.ts:250: const orchestrator = new Orchestrator(Verified. The two crux claims hold: USE_SUBAGENTS exists only as an enum entry (tools.ts:33,69) with no executor anywhere; executeCoreWorkflow is literally commented // Placeholder for core workflow logic and returns {status:'completed', input}. The orchestrator is wired into index.ts:250, but its core path is a stub. LLM calls are one generateContent() per createMessage, never nested.
Here's the comparison.
These two systems put task decomposition in opposite places, and that's the whole story.
context variable, and decides — token by token — to slice it and fire llm_query() sub-calls over chunks. The orchestration logic is learned/emergent, expressed as code the model writes at inference time.[LAYER: CORE] Orchestrator, an AgentRegistry with a "Swarm Architect," a USE_SUBAGENTS tool. It's imperative and external: the harness, not the model, is meant to route work. But the routing isn't implemented — executeCoreWorkflow is a placeholder, USE_SUBAGENTS has no executor, and the three registered agents are never invoked.So the comparison is really RLM's working emergent recursion vs. DietCode's declared-but-hollow imperative orchestration, plus a real, working context layer underneath.
| Axis | RLM | DietCode (as implemented) |
|---|---|---|
| Sub-task spawning | llm_query() recursive calls, depth ≥1 | None. Single generateContent() per turn (GeminiProvider.ts:41) |
| Context strategy | Loaded as a variable; model queries it programmatically, never summarizes | Semantic folding — keep head 60% + tail 30%, discard the middle (ContextPruner.ts:154) |
| Long-context limit | ~100× the window | Bounded by the prompt; folding loses the middle |
| Who orchestrates | The model (in-call) | The framework (between turns) — but the core path is a stub |
| Tool/code execution | Real Python REPL the model drives | Tools are intent declarations; execution delegated to an external harness |
The irony worth naming: DietCode's context handling is the exact thing RLM was built to avoid. RLM's central thesis is "never compact, because compaction loses information." DietCode's ContextPruner does precisely that — it folds away the middle of long files for "cognitive focus." On the one axis where DietCode has working code comparable to RLM, it's made the opposite design bet.
The vision docs (FEATURES.md, proto.md) actually aim at something RLM-adjacent but more imperative:
BACKLOG → SHADOW_SIM → SOVEREIGN_DOING → VERIFYING → DONE), not recursive model calls.proto.md's "Shadow Simulation" with a 0.95 verification score gate — a verify-before-act loop RLM doesn't have at all.So even the aspiration differs from RLM in a meaningful way: DietCode wants heterogeneous, role-specialized agents on an explicit pipeline with verification gates; RLM is homogeneous self-recursion with no built-in verification. The recent RL-trained RLM work (shared parent/child policy) actually moves RLM slightly toward DietCode's "one system, multiple roles" idea — but keeps it learned rather than wired.
RLM's approach buys:
…at the cost of:
DietCode's intended approach buys:
ExecutionService/SafetyGuard envelope (which is real) intercepts and risk-rates every tool call; proto.md adds verification gates. RLM has nothing like this.…at the cost of:
USE_SUBAGENTS tool with no executor, and ~43 markdown docs / 8.6K lines describing behavior the code doesn't yet do.If you wanted to close the gap, RLM is a surprisingly good fit for DietCode's stated goals — and it would attack DietCode's two real weaknesses at once:
ContextPruner's lossy folding with an RLM-style "context-as-queryable-variable" approach, so long files aren't gutted in the middle.USE_SUBAGENTS a real executor shaped like llm_query() — recursive createMessage calls over context chunks — which is genuinely small code (the original RLM scaffold is a thin REPL loop), turning the "Swarm" from three static records into something that runs.The philosophical tension to resolve: RLM has no verification step, while DietCode's whole identity (SafetyGuard, the 0.95 SHADOW_SIM gate) is verification-first. The interesting design move would be RLM recursion wrapped in DietCode's safety envelope — emergent decomposition, but every sub-call's tool actions still pass through the risk-rated execution path. That's a combination neither the RLM papers nor this repo currently has, and it plays to each side's strength.
Want me to sketch what a real llm_query()-style executor for USE_SUBAGENTS would look like in this codebase (wired through GeminiProvider + the ExecutionService safety envelope)?