counterposition shared

Public

Compare RLM task decomposition with repo implementationPublic

Agent

Claude Code

Model

Claude Opus 4.8

Shared

May 31, 5:15 PM

Messages38

Downloads4

Workspace

Repo

CardSorting/DietCode

Summary

In Progress

Understand
Researched recursive language models and their task decomposition strategy.
Understand
Understand
Explored the Sovereign Hive repo's orchestration core and decomposition approach.
Understand
Verify
Confirmed the repo's core workflow is a stub with no nested LLM calls.
Verify

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.

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.

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 sessions

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

Grepped

I'll search for the latest on recursive language models.

Searched webrecursive language models RLM

Searched webrecursive language models 2026 latest research

Let me dig into the primary sources, including the most recent papers, to get the details.

Readhttps://arxiv.org/abs/2512.24601

Readhttps://arxiv.org/pdf/2603.02615

Readhttps://www.alphaxiv.org/blog/reinforcement-learning-for-rlms

Let me get the cost/benchmark specifics and the RL training developments from a couple more sources.

Readhttps://arxiv.org/html/2512.24601v2

Searched webreinforcing recursive language models RL fine-tuning parent child shared policy 4B

Recursive Language Models (RLMs)

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

How it works

The long input is loaded as a context string variable inside a Python REPL — it never goes into the model's prompt directly.
The root LM sees only the REPL, not the raw context. It writes Python to inspect, slice, grep, and decompose the data (print(), string ops, etc.), using variables as scratch buffers.
When it needs an LM to reason over a chunk, it calls llm_query() — a recursive sub-call to an LM instance (handling ~500K chars per call). Those sub-calls can themselves be RLMs.
Results are aggregated in the REPL, and the root emits a final answer (originally via brittle 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.

Headline results (original paper)

Handles inputs ~100× beyond the model's context window (two orders of magnitude).
Even on short prompts, beats base models and common long-context scaffolds on four tasks: S-NIAH, BrowseComp-Plus, OOLONG / OOLONG-Pairs, and CodeQA (LongBench-v2).
vs. baselines: +26% median over compaction, +130% over CodeAct-with-subcalls, +13% over Claude Code.
A fine-tuned RLM-Qwen3-8B beat base Qwen3-8B by 28.3% and approached vanilla GPT-5 on three tasks.
Cost: typically competitive with base runs (e.g. RLM-GPT-5 on BrowseComp-Plus ~$0.99 vs ~$1.50–2.75 extrapolated base), and ~3× cheaper than summarization agents — but with a long, expensive tail when trajectories balloon. Setup used GPT-5 as root + GPT-5-mini for sub-calls.

Documented limitations

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.

What's new in recent weeks (post-cutoff developments)

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

Ecosystem

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.

A "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

>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

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.

Where "decomposition" lives — the fundamental divergence

These two systems put task decomposition in opposite places, and that's the whole story.

RLM: decomposition is inside the model's reasoning. The root LM sits in a Python REPL, sees the context as a 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.
DietCode: decomposition is aspirationally in the framework — a [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.

Implementation: what DietCode actually does vs. RLM

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.

Aspirations vs. RLM

The vision docs (FEATURES.md, proto.md) actually aim at something RLM-adjacent but more imperative:

"Task Sharding: Complex goals are automatically broken down into atomic, verifiable sub-tasks" — this is decomposition, but state-machine-driven (BACKLOG → SHADOW_SIM → SOVEREIGN_DOING → VERIFYING → DONE), not recursive model calls.
"Agent Shadows: asynchronous background agents" + the "Swarm Architect" — a multi-agent hive, closer to a fixed orchestration graph than to RLM's uniform self-recursion.
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.

Tradeoffs

RLM's approach buys:

True unbounded context without information loss (the middle survives).
Flexibility — the model invents the decomposition per task; no need to pre-build an orchestration graph.
Less framework code.

…at the cost of:

A long, expensive cost tail (runaway trajectories), latency from synchronous sub-calls, and brittleness (needs a capable coding model, output-token headroom, careful prompts). No verification gates — it can confidently recurse into a wrong answer.

DietCode's intended approach buys:

Auditability and safety — the ExecutionService/SafetyGuard envelope (which is real) intercepts and risk-rates every tool call; proto.md adds verification gates. RLM has nothing like this.
Specialization — distinct agents (distiller, architect) tuned per role.
Determinism — an explicit pipeline is debuggable in a way emergent recursion isn't.

…at the cost of:

You have to build and maintain the orchestration graph — and DietCode mostly hasn't. The cost shows up as the aspiration/implementation gap: a hollow orchestrator, an unused agent registry, a USE_SUBAGENTS tool with no executor, and ~43 markdown docs / 8.6K lines describing behavior the code doesn't yet do.
Compaction-based context loses information by construction.

The synthesis

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:

Replace ContextPruner's lossy folding with an RLM-style "context-as-queryable-variable" approach, so long files aren't gutted in the middle.
Give 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)?