PaperlayerView exact revision on arXiv

Source-linked AI summary

Thinking Before Thinking: Scaling Agentic Inference Through Meta-Reasoning

Paras Dahal, Anton Bakhtin, Taco Cohen, Zhengxing Chen, Carole-Jean Wu, Rob Fergus, Scott Yih, Gabriel Synnaeve, Ruslan Salakhutdinov, Sanjeev Arora, Jason Weston, Anirudh Goyal

arXiv:2609.38147v1cs.AI

TL;DR

Long-running agents must decide what work to build on, revisit, or stop, making control a distinct part of solving a task. Agentic meta-reasoning uses a controller to assess progress, consider and evaluate next steps, and dispatch work from persistent memory; across the benchmarks, it improves matched comparisons and continues improving where direct control often plateaus.

  • Problem

    As agents produce more work, they face consequential choices about what to trust, build on, or stop, while existing agents often interleave control decisions with task-level work.

    Source: §1 · p. 2

  • Method

    An inference-time harness separates task-level workers from a controller that assesses progress, proposes and evaluates next computations under budget, and dispatches work with selected persistent-memory context.

    Source: §1 · p. 2, §3.1 · p. 4

  • Results

    Across four benchmarks, meta-reasoning yields higher point estimates in all 12 matched comparisons at the main allowances, with mean gains of 3.6–4.2 score points by benchmark.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Across the tested budget ranges, meta-reasoning keeps improving where direct control often plateaus, and the authors conclude structured control scales better as tasks grow longer and more complex.

    Source: §1 · p. 2, §8 · p. 16

    Additional control computation can hurt at small budgets, and lossy compact state risks misleading assessments or discarded good work that is not reread.

    Source: §7.3 · p. 15

Abstract

from arXiv · show

As agents take on longer and more complex problems, controlling the execution becomes a task in its own right. Each step in the run brings new control choices, like which partial work to build on, whether to start fresh, or when to stop. We introduce agentic meta-reasoning, an inference-time harness that makes these choices an explicit and structured reasoning process. Workers carry out the task-level computation, while a controller consolidates what the run has established, explores next options, assesses what each option is worth under the remaining budget, and dispatches the chosen work with context drawn from persistent memory. Between decisions the controller carries only a compact account of the run rather than replaying its full history. Our baselines span production coding agents and research harnesses, together with a Direct Control Agent using the same workers and compute budget allowance. On ProgramBench, which tests long-horizon agentic capability through program reconstruction, meta-reasoning achieves 71.5% with GPT-5.5 against 58.0% for Codex; with Opus 4.8 it achieves 67.2% against 65.5% for Claude Code. On the other benchmarks, spanning abstract reasoning, multi-domain long-horizon reasoning, and proof generation, it gains between 3.6 and 4.2 points over direct control, averaged across three frontier models. It keeps improving over the tested budget ranges where direct control plateaus, though its overhead can hurt at small budgets. Artifact-graph analysis reveals more reuse of earlier work, higher coverage of correct solutions in most settings, and nonuniform gains in final selection. These results indicate that spending computation on structured control becomes more important as agents scale to longer runs.

1 Introduction

The paper treats decisions about what an agent should do next as a distinct part of solving long-running tasks. It introduces a controller that deliberates over progress, options, and their value before dispatching work, and reports gains over matched direct control and other baselines.

1 Introduction

  • As agents spend more calls on a problem, choosing whether to extend, check, or abandon partial work becomes part of solving it.The passage illustrates the choice with a proof whose central lemma remains unverified; each option consumes computation that may be wasted if chosen poorly.Source: §1 · p. 2
  • Agentic meta-reasoning gives control choices their own inference-time harness, separating task-level workers from a controller that decides what work to assign.The controller maintains a compact progress assessment, while full worker outputs remain in persistent memory for retrieval as needed.Source: §1 · p. 2
  • Each control cycle updates the run state, proposes next computations, evaluates their value under the remaining budget, and dispatches selected work with context.Controller calls count against the same budget as worker calls, and artifact graphs record which earlier outputs later work uses.Source: §1 · p. 2
  • The evaluation spans proof search, abstract reasoning, long-horizon reasoning, and program reconstruction across four benchmarks and three frontier models.Baselines include production coding agents, research harnesses, and a Direct Control Agent that holds workers and actions fixed while changing the control process.Source: §1 · p. 2
  • At the main allowances, meta-reasoning yields higher point estimates in all 12 matched comparisons, with mean gains of 3.6–4.2 score points by benchmark.On ProgramBench with GPT-5.5, mean per-problem test-pass rate is 71.5%, compared with 58.0% for Codex and 63.7% for direct control.Source: §1 · p. 2

2 Related Work

The related work situates agentic meta-reasoning among inference-time computation, orchestration, metacognitive control, memory, and run diagnostics. Its distinction is to treat control over a growing computation and its persistent artifacts as an explicit agentic process.

2 Related Work

  • Prior inference-time methods allocate computation along fixed paths, samples, refinement rounds, or search structures, while agentic harnesses direct next computations using model judgments.The paper frames growing intermediate artifacts and noisier context as a motivation for online artifact-graph construction.Source: §2 · p. 3
  • Learned orchestration work trains, searches, or optimizes coordination systems, whereas this paper isolates control as its own agentic process.The cited line includes learned communication, coordination systems, harness optimization, and automated harness construction.Source: §2 · p. 3
  • Prior metacognitive approaches regulate chains, tool triggers, or stopping rules; this work instead controls a growing external computation over persistent artifacts.The related work describes monitoring computation and using it to regulate what a system does next.Source: §2 · p. 3
  • Memory systems preserve or select information, but here memory is an action surface for choosing what prior work each worker receives and can build on.The passage contrasts this role with systems for memory management, persistent interfaces, structured memory, and programmatic interaction-log search.Source: §2 · p. 3
  • Agent-run diagnostics move beyond final accuracy, and this work uses the artifact graph to measure compute use, topology, coverage, monitoring, and selection together.The paper ties its diagnostic approach to the graph induced by each run.Source: §2 · p. 3

3 Agentic Meta-Reasoning

Agentic meta-reasoning separates control from object-level work while preserving outputs in persistent memory and carrying a compact state between decisions. Its control cycle assesses progress, proposes and evaluates options, dispatches work, and records dependencies in an artifact graph.

3 Agentic Meta-Reasoning

  • Agentic meta-reasoning makes the choice of what to compute next its own agentic reasoning task, separate from the object-level computation it directs.This lets work accumulate without conditioning every control decision on the full run history.Source: §3 · p. 4

3.1 Memory, State, and Worker Context

  • The controller rewrites a compact textual state each cycle, while stored artifacts remain available for retrieval and workers receive only selected context.Workers receive the task, a controller-authored instruction, and artifacts chosen for their assignment, not the controller’s private deliberation.Source: §3.1 · p. 4

3.2 Actions over the Run

  • The controller can read and write artifacts, launch workers, or stop by selecting an artifact already in memory as its final answer.Worker assignments and contexts can produce a fresh attempt, targeted repair, or synthesis, with outputs stored alongside their input-artifact links.Source: §3.2 · p. 4

3.3 The Control Cycle

  • Each control cycle assesses new work, proposes options, qualitatively evaluates their value against remaining budget, then dispatches the chosen computation or stopping action.Propose generates alternatives without seeing the remaining budget; Dispatch selects the artifacts workers receive as context.Source: §3.3 · p. 5

3.4 Recording the Artifact Graph

  • The artifact graph records controller-selected dependencies between stored outputs, forming a directed acyclic graph of roots, branches, and follow-ups.It does not necessarily capture every information channel and represents only controller-generated dependencies.Source: §3.4 · pp. 5–6

3.5 Direct Control and the Cost of Deliberation

  • Direct Control uses the same workers and interfaces but chooses each action in one turn over accumulated history, so comparison isolates the combined control design.It does not separately identify the effects of staging, state compression, or memory access; both systems receive the same nominal model-call budget, which does not equalize token cost, latency, or FLOPs.Source: §3.5 · p. 6

4 Diagnosing Agentic Inference Through Artifact Graphs

Artifact-level diagnostics separate how an agent spends its budget, whether it finds correct work, and whether it submits that work. They also compare selection against a structural baseline. [p61]

4 Diagnosing Agentic Inference Through Artifact Graphs

  • The diagnostics distinguish runs that never produce a correct candidate from runs that find one but fail to submit it.This separates coverage-bound failures from selection-bound failures, which motivate different remedies: exploration or object-level problem solving versus assessment, verification, and commitment.Source: §4 · p. 6, §4.2 · p. 7, §4.3 · p. 8

4.1 What Did the Agent Do with Its Budget?

  • Budget utilization measures the fraction of the allowance used, while artifact-graph nodes and edges record worker outputs and their supplied-context dependencies.Graph summaries include roots and descendants, mean and maximum fan-in, depth, and width; memory reads, writes, and running-state size track reuse and context.Source: §4.1 · pp. 6–7

4.2 Did the Agent Find and Submit a Correct Answer?

  • Coverage tracks whether a correct candidate appears, while selection measures whether a run containing one submits a correct answer.Success factors into finding a correct answer and choosing it once it exists; coverage can be tracked across call checkpoints.Source: §4.2 · p. 7
  • Worker confidence and controller verdicts are evaluated separately by how well they rank correct candidates above incorrect ones, with half credit for ties.This Type-2 AUC measures discrimination rather than calibration; Direct Control has no corresponding controller-verdict signal.Source: §4.2 · p. 7

4.3 Does Selection Improve on a Structural Baseline?

  • Frontier selection gain compares actual submission correctness with the chance of correctness from a uniform choice among deepest terminal artifacts.Positive gain means the agent beats uniform frontier choice; because submissions need not be on the frontier, gain can also reflect choosing a better, shallower answer.Source: §4.3 · pp. 7–8

5 Experimental Setup

The experiments test performance, budget scaling, and run structure across reasoning and program-reconstruction settings. They compare staged meta-reasoning with direct control and other systems under shared call allowances. [p43, p44, p49, p53]

5.1 Tasks

  • The evaluation spans proof generation, abstract visual reasoning, multi-domain long-horizon reasoning, and long-horizon program reconstruction.The four tasks are IMO ProofBench-Advanced, ARC-AGI-2, LongCoT-mini, and ProgramBench, respectively.Source: §5 · p. 8, §5.1 · p. 8

5.2 Comparisons

  • The main comparison pairs meta-reasoning with Direct Control using the same workers and interfaces, while other comparisons include RLM and production coding agents.Meta-reasoning uses compact state and staged control; Direct Control chooses actions in one call over accumulated history, and neither controller is fine-tuned for these experiments.Source: §5.2 · pp. 8–9

5.3 Models and Budgets

  • The largest nominal allowances are 100 calls per reasoning problem and 1200 per ProgramBench problem, with smaller budgets also tested.Controller and worker calls count toward the same allowance, including parallel calls; systems may stop early, and external baselines receive added call accounting.Source: §5.3 · p. 9

5.4 Measurements

  • Measurements cover benchmark performance, call use, artifact-graph structure, memory operations, and controller context.Intermediate-artifact coverage, monitoring, selection, and frontier selection gain are analyzed on reasoning benchmarks, but not ProgramBench because its intermediate reconstructions lack a grading protocol.Source: §5.4 · p. 9

6 Experimental Results

At the main budgets, meta-reasoning scores highest in all 12 matched comparisons and exceeds the evaluated external configurations. As budgets grow, it continues improving where direct control often plateaus, while producing more reusable work, finding correct candidates in more runs, and selectively revisiting compact memory.

6.1 Meta-Reasoning Improves Performance Across Tasks and Models

  • At the main budgets, meta-reasoning scores highest in every model and benchmark pairing across the 12 matched comparisons.Table 1 reports performance at 100 calls on reasoning benchmarks and 1200 on ProgramBench, including controller calls.Source: §6.1 · pp. 9–10, Figure 2 · p. 10, Table 1 · p. 11
  • 71.5% versus 58.0%: GPT-5.5 meta-reasoning beats Codex on ProgramBench; with Opus 4.8, it scores 67.2% versus 65.5% for Claude Code.Meta-reasoning also exceeds mini-SWE Agent with all three models, by 2.5–13.9 points.Source: §6.1 · pp. 9–10, Figure 2 · p. 10

6.2 Meta-Reasoning Keeps Improving as the Budget Grows

  • 64.1% to 71.5%: GPT-5.5 meta-reasoning improves on ProgramBench from 400 to 1200 calls while direct control stays near 64%; smaller budgets can favor direct control.With Opus 4.8, meta-reasoning trails direct control at 400 calls, 56.6% versus 62.7%, then leads at 1200 calls, 67.2% versus 65.3%.Source: §6.2 · pp. 10–11

6.3 What computation does the additional budget produce?

  • More than 2.5 times as many nodes and nearly four times as many edges: GPT-5.5 ProgramBench graphs grow from 400 to 1200 calls, alongside greater artifact reuse in reasoning runs.At the largest allowance, meta-reasoning produces more nodes and edges than direct control with each model.Source: §6.3 · p. 11, Figure 4 · p. 12

6.4 Finding Correct Answers Is Only Part of the Problem

  • 20 percentage points: Gemini 3.1 Pro’s correct-candidate coverage gain on IMO ProofBench-Advanced; coverage improves in most evaluated settings, though Opus 4.8 is approximately tied on LongCoT-mini.Coverage on IMO ProofBench-Advanced uses binary correctness rather than the partial-credit proof score.Source: §6.4 · p. 12, Figure 6 · p. 14
  • 0.55 versus 0.88: on IMO ProofBench-Advanced with Gemini 3.1 Pro, worker confidence is near chance at ranking correctness, while the controller’s verdict performs better.The controller’s ranking advantage is smaller with GPT-5.5 and Opus 4.8, and nearly absent for GPT-5.5 on LongCoT-mini.Source: §6.4 · p. 12, Figure 6 · p. 14
  • 11 percentage points versus 3: on ARC-AGI-2 with GPT-5.5, meta-reasoning’s frontier selection gain exceeds direct control’s, but selection gains are not uniform across models.Frontier selection gain compares the submission with a random choice from the same frontier.Source: §6.4 · pp. 12–13, Figure 6 · p. 14

6.5 Can control retain useful history without replaying it all?

  • 4.4 to 9.8 reads versus 1.9 to 3.3: retrieved controller notes are revisited more often than worker artifacts, serving as recurring organizational references.The controller maintains a state of thousands to tens of thousands of characters, rather than replaying the full history; the proposed link to direct control’s plateau was not tested directly.Source: §6.5 · pp. 13–14, Figure 7 · p. 14

7 Discussion and Limitations

The discussion frames run direction as a measurable component of agent performance and argues that meta-level reasoning needs its own multi-step process and memory. The authors also describe compute costs, a chess failure case, and model-dependent gains.

7.1 Meta-Reasoning Is Part of Agent Capability

  • With models, workers, and allowances held fixed, every matched setting improves and margins widen with budget; Figure 8 contrasts accumulated history with compact assess state.The figure describes the representations persisted between control decisions.Source: §7.1 · p. 14, Figure 8 · p. 15

7.2 Meta-Reasoning Is Itself an Agentic Process

  • Meta-level reasoning involves retrieving artifacts, recording judgments, and revisiting notes as epistemic actions that change what the agent knows.The four stages are one proposed organization; the authors emphasize separating functions and providing memory, retrieval, and multiple reasoning steps.Source: §7.2 · p. 15

7.3 Limitations

  • Staged control adds compute, and low-budget crossovers show it is not uniformly preferable to direct control.An incorrect assessment can propagate misleading state or discard useful work that is not reread; compact state is lossy and depends on future memory reads.Source: §7.3 · p. 15
  • In LongCoT-mini chess, meta-reasoning underperforms direct control; preliminary trajectory sampling points to extra checking destabilizing already-correct answers.The authors leave full analysis and targeted interventions for future work.Source: §7.3 · p. 15
  • Gain size varies by model: Gemini 3.1 Pro benefits strongly on reasoning benchmarks, GPT-5.5 especially on ProgramBench, and Opus 4.8 shows smaller but uniformly positive gains.These differences describe controller behavior in this harness, where task difficulty, prompting, and worker competence also enter.Source: §7.3 · p. 15

8 Conclusion

The paper concludes that agentic meta-reasoning improves matched benchmark comparisons and continues improving over evaluated budget ranges where direct control often plateaus. Its analysis links the approach to greater reuse of earlier work and more frequent correct candidates.

8 Conclusion

  • Across four benchmarks and three frontier models, meta-reasoning improves every matched comparison at main budgets and keeps improving where direct control often plateaus.The analysis also reports more allowance spent, greater reuse of earlier results, and correct candidates in more runs.Source: §8 · p. 16
  • Agent performance depends on deciding what work is worth doing as well as doing the work, and that decision becomes work in its own right as runs lengthen.Source: §8 · p. 16

A Scope of the Evidence

This section defines the evaluated meta-reasoning setup, including controller evaluation and stopping, dispatch, orchestration and budget rules, and worker context and prompts across text tasks and ProgramBench. The evidence supports the design as a whole, but does not isolate its components or establish equal-cost efficiency or broad generalization.

A Scope of the Evidence

  • The matched comparison supports the evaluated design as a whole, but cannot establish the necessity or independent causal effect of its stages, compact state, or memory access.Stage-removal, state-only, and memory-interface ablations would be needed to isolate those mechanisms.Source: A Scope of the Evidence · p. 20
  • Results concern common nominal call budgets, not equal-cost performance, token efficiency, or latency, because call lengths, runtime, and budget use can differ.Systems choose different fractions of the available allowance, so the comparison does not establish efficiency at matched cost.Source: A Scope of the Evidence · p. 20
  • Experiments cover three frontier models and four benchmarks, including a 30-problem proof set, but do not establish significance for every difference or generalization beyond tested settings.External-agent comparisons apply only to the evaluated versions and configurations.Source: A Scope of the Evidence · p. 20

B Meta-Reasoning Agent Prompts

  • The controller uses four sequential stages—assess, propose, evaluate, and dispatch—each in a fresh-context agentic loop, with shared text-benchmark prompts and verbatim ProgramBench prompts.The three text benchmarks use the same prompt structure with minor benchmark-specific wording changes.Source: B Meta-Reasoning Agent Prompts · p. 20

B.1 Assess

  • Assess incrementally reviews new candidates, updates the overall assessment and stop recommendation, and maintains evidence-cited implementation status and unexplored work for ProgramBench.Its text-benchmark prompt also records unresolved questions; the ProgramBench snapshot carries forward valid entries and distinguishes implemented, broken, unverified, unexplored, and abandoned work.Source: §B.1 · pp. 21–23

B.2 Propose

  • Propose generates plausible next actions without self-filtering, while evaluate decides which actions to pursue and how many workers to allocate.Actions may include new approaches, targeted repair, verification, counterexample searches, synthesis, or stopping when a solution is ready.Source: §B.2 · p. 24

B.3 Evaluate

  • Evaluate receives the turn index and consumed model calls as its budget, the only stage given budget information.Its inputs also include the task, memory index, compact state, and proposals.Source: §B.3 · p. 25
  • Evaluation weighs expected progress against worker and deliberation costs, prioritizing unresolved questions or implementation gaps when budget cannot fund every high-value action.For ProgramBench, incomplete broken or unverified issues take priority over new findings; tied actions are ranked by issues cleared, gain per call, then added coverage. For text benchmarks, ties favor resolving outstanding questions, gain per call, then pool diversity.Source: §B.3 · pp. 25–27
  • Stopping requires a likely-correct text candidate with no touching unresolved questions, low-value further actions, and confidence to stake the run on it.For ProgramBench, stop only when unexplored work is exhausted or out of scope, broken work is fixed or accepted, all claimed implementation is independently verified, and proposed actions are low value; otherwise continue when another dispatch can add value.Source: §B.3 · pp. 26–27
  • ProgramBench actions are rated by likely test coverage, with one worker for shared-file coding and multiple workers permitted for read-only work.Refactoring code that already passes is low value; finite budget should target incomplete issues before new findings.Source: §B.3 · p. 26

B.4 Dispatch

  • Dispatch translates recommendations into one worker call or a final submission, passing each worker its assigned prompt and memory IDs.For text benchmarks, finish submits the chosen candidate verbatim; for ProgramBench, it submits the current workspace state for evaluation.Source: §B.4 · p. 28
  • Worker steering must be self-contained and actionable because workers do not see deliberation output; use the evaluator’s supplied subagent prompt directly when available.Otherwise, dispatch rewrites the full action as an imperative instruction with concrete files, commands, and success criteria, rather than passing an action ID alone.Source: §B.4 · p. 29

C Direct Control Agent Prompts

  • The Direct Control Agent uses one system prompt and one task message, then accumulates tool calls and results in a single conversation for the whole problem.Source: C Direct Control Agent Prompts · p. 29

C.1 System prompt

  • The system prompt lets the controller choose whether to continue with refined steering and selected prior work or finish with the candidate it trusts most.Prior worker outputs are stored by ID and can be supplied as context; workers may be steered to explore, repair, verify, or synthesize attempts, as the current pool suggests.Source: §C.1 · p. 30

C.2 Budget

  • The harness issues budget updates every 10% of the allowance and a finish coercion once 90% is consumed, requiring the controller to submit its best answer so far.The budget instructions vary with worker type: text workers each consume one LLM call, whereas coding workers consume many calls.Source: §C.2 · p. 31

D Worker Prompts

  • Text-benchmark workers are single model calls, while coding workers are multi-turn bash agents in a shared filesystem; both controller types use identical worker prompts.Each worker sees the benchmark task, selected artifact bodies, and controller-written steering.Source: D Worker Prompts · p. 31
  • Worker outputs use a title and confidence footer that support artifact-graph analysis and let the paper compare worker self-assessments with controller verdicts.Workers receive task-selected artifacts and controller-written steering, but never see the controller’s state or deliberation.Source: D Worker Prompts · pp. 31, 33

E Artifact Memory

The harness stores worker outputs and controller notes as identified artifacts, while giving controller stages a compact index and tools to retrieve artifact bodies. The tools also let the meta-reasoning agent dispatch workers and submit an existing artifact as its final answer.

E Artifact Memory

  • Artifacts pair an identifier, title, and body; worker outputs and controller notes are both stored in the memory pool.Identifiers encode round and worker, and controller notes receive fresh identifiers in the current round.Source: E Artifact Memory · p. 33
  • Each controller stage receives an index of artifact identifiers and titles, with bodies omitted to keep controller state small as the run grows.A read_memory call retrieves an artifact body; an unknown identifier returns NOT FOUND.Source: E Artifact Memory · p. 33
  • Workers receive selected artifacts wrapped as memory, usually without identifiers, so they cannot cite an artifact back by name.The controller chooses which artifacts to provide as worker context.Source: E Artifact Memory · p. 33

F Tools

  • The controller’s finish tool submits an existing artifact by ID, whereas Direct Control submits answer text directly.To submit new content, the controller must first have a worker produce it.Source: F Tools · p. 34
  • The meta-reasoning stages receive read_memory and write_memory, while Direct Control does not because its generated artifacts remain in its accumulating history.run_workers is identical for both agents.Source: F Tools · pp. 33–34

G Implementation details: ProgramBench

On ProgramBench, workers operate on a shared filesystem, commit before returning, and the finish tool submits the workspace state.

G Implementation details: ProgramBench

  • ProgramBench workers are multi-turn agents with bash access to a shared container filesystem, rather than single calls that return text.Each worker commits before returning, and its commit subject becomes the artifact title, making the memory index viewable as a commit log.Source: G Implementation details: ProgramBench · p. 35
  • The finish tool submits the workspace state, specifically compile.sh and the executable it builds.The commit subject becomes the artifact’s title.Source: G Implementation details: ProgramBench · p. 35
  • Each worker’s commit subject becomes its artifact title, so the memory index can be viewed as a commit log.Workers commit before returning.Source: G Implementation details: ProgramBench · p. 35

G.1 Task prompt

ProgramBench asks agents to reconstruct an executable’s behavior from interaction with a provided reference binary under explicit environment and submission constraints. A read-only git tool gives the controller access to committed code as well as worker summaries.

G.1 Task prompt

  • The same custom task description is given to every ProgramBench system, while the other three benchmarks use their benchmark-defined problem prompts verbatim.The task is to reconstruct program behavior from observation rather than use an existing source implementation.Source: §G.1 · p. 35
  • The workspace has no internet access or project-specific dependencies, so agents can use only toolchains and packages already present in the base image.Package-registry fetches and installs fail, and switching languages mid-run discards earlier working code.Source: §G.1 · p. 35
  • Agents must write an original codebase that reproduces the reference executable’s behavior, learned solely by running and interacting with it.Wrapping the binary, reusing it, or installing the original tool is disallowed and subject to disqualification.Source: §G.1 · pp. 35–36
  • The provided executable is for behavioral observation; binary analysis tools such as disassemblers and tracing tools are prohibited.The restrictions apply to the provided executable, not binaries agents produce themselves.Source: §G.1 · p. 36
  • The build must make executable compile.sh produce ./executable in the workspace root, while keeping artifacts out of version control.The supplied ./executable_orig is a backup reference for diffing and must not be moved, removed, or overwritten.Source: §G.1 · p. 36

G.2 Read-only git tool

  • On ProgramBench, the two controlled agents receive a read-only git tool that coding-agent baselines do not receive.It lets the controller inspect committed code because it otherwise learns worker progress from written summaries; output is truncated at 8000 characters.Source: §G.2 · p. 36
  • The git tool exposes committed worker code and changes through read-only commands such as log, show, diff, and cat-file.Only read-only subcommands are accepted; output is capped at 8000 characters, and worker prose may be optimistic or hallucinated while commits are the ground truth.Source: §G.2 · pp. 36–37

H Implementation details: Recursive Language Model (RLM)

The RLM baseline uses the authors’ reference implementation with budget accounting and a restricted workspace intended to require delegated computation. One reported Opus 4.8 LongCoT-mini result instead uses the unrestricted workspace.

H Implementation details: Recursive Language Model (RLM)

  • The RLM baseline uses the authors’ reference implementation and default configuration and prompts, with a required final-answer format appended.Two further modifications are made for comparability with the agents.Source: H Implementation details: Recursive… · p. 37
  • The full Python REPL is replaced by a restricted workspace because inline computation gives RLM a capability unavailable to the reasoning agents and is not charged against its model-call budget.The restricted workspace retains context control while removing computation; its code is checked against an AST allowlist before execution.Source: H Implementation details: Recursive… · p. 37
  • The restricted workspace permits context handling and delegated model calls but rejects constructs including loops, imports, arithmetic, and function definitions.Actual work must pass through a sub-model call; the allowed syntax and callables are described to the model in advance.Source: H Implementation details: Recursive… · pp. 37–38
  • One Opus 4.8 LongCoT-mini RLM result uses the unrestricted full-Python workspace; the other eight RLM cells use the restricted workspace.Under the restricted workspace, that model kept attempting to compute in the workspace instead of decomposing the problem.Source: H Implementation details: Recursive… · p. 38
  • Every model call at any depth is charged against the shared allowance, with budget messages injected at the same thresholds used for the other agents.A system turn is appended at each tenth of the allowance, and at ninety percent a further message requires submission.Source: H Implementation details: Recursive… · p. 38

I Implementation details: Claude Code and Codex

Claude Code and Codex use the same per-problem container and MCP tool channel as the paper’s other agents. Their native tools are disabled, and both agents receive explicit model-call budget information.

I Implementation details: Claude Code and Codex

  • Both coding agents use the same per-problem container and MCP tool channel as the other agents, matching output truncation, memory limits, and recovery behavior.Source: I Implementation details: Claude Code… · p. 38
  • Claude Code’s built-in tools are disabled, and Codex runs read-only with shell access unable to write scored files, so edits go through the shared MCP channel.File edits use heredocs and shell commands, as with the Meta-Reasoning Agent and Direct Control Agent.Source: I Implementation details: Claude Code… · p. 38
  • A budget line is prefixed to the next tool result after each tenth of the allowance is consumed, and the prompt states that every turn costs one call.Source: I Implementation details: Claude Code… · p. 38

Related papers

Loading 2609.38147v1…