Paper deep dive
Long Live the Librarian! A Persistent Search Sub-Agent for Energy-Efficient Multi-Agent Software Engineering Systems
Seunghyuk Cho, Sunghyun Choi, Jaeseung Heo, Youngbin Choi, Saemi Moon, MoonJeong Park, Dongwoo Kim
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 7/8/2026, 9:26:56 PM
Summary
The paper identifies redundant output tokens from repeated file exploration as the primary driver of high inference energy in multi-agent software engineering systems. It introduces Librarian, a persistent search sub-agent that tracks repository history, suppresses redundant exploration, and returns short file pointers instead of full excerpts. Evaluated on SWE-Bench Verified with BOAD and HyperAgent using Qwen3.6 models, Librarian reduces per-episode GPU energy by up to 25% while maintaining task performance.
Entities (11)
Relation Signals (9)
Librarian → evaluatedon → SWE-bench Verified
confidence 97% · We apply the Librarian on SWE-Bench Verified to BOAD and HyperAgent
Librarian → reduces → GPU energy consumption
confidence 97% · On SWE-Bench Verified, Librarian reduces per-episode GPU energy consumption of existing multi-agent SWE systems by up to 25% while preserving task performance.
Output tokens → dominates → GPU energy consumption
confidence 96% · an output token consumes 30 to 1,000 times more energy than an input or cached token.
Librarian → suppresses → Redundant exploration
confidence 96% · we propose Librarian, a persistent search sub-agent that tracks repository-search history and suppresses redundant exploration actions across agents.
Redundant exploration → causes → Output tokens
confidence 95% · MAS inflate per-episode output because agents repeatedly re-explore overlapping repository regions.
Librarian → integrateswith → Multi-Agent Systems
confidence 95% · To integrate Librarian into an existing MAS, we provide a guideline that replaces the MAS’s code-navigation sub-agent with Librarian and routes all exploration through it.
BOAD → isa → Multi-Agent Systems
confidence 94% · We consider two MAS designs that delegate the SWE workflow across specialized sub-agents: BOAD (Xu et al., 2026) and HyperAgent (Phan et al., 2024).
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Multi-agent systems (MAS) have substantially advanced autonomous software engineering (SWE), but their growing inference energy demands raise sustainability concerns. In this paper, we demonstrate that this cost is concentrated in an overlooked source: redundant output tokens generated across agents. Two empirical findings ground this claim. First, our per-token energy attribution for MAS reveals a sharp asymmetry: an output token consumes 30 to 1,000 times more energy than an input or cached token. Second, MAS inflate per-episode output because agents repeatedly re-explore overlapping repository regions. To address this inefficiency, we propose Librarian, a persistent search sub-agent that tracks repository-search history and suppresses redundant exploration actions across agents. By returning short references to file regions instead of full file excerpts, Librarian further reduces output-token volume. On SWE-Bench Verified, Librarian reduces per-episode GPU energy consumption of existing multi-agent SWE systems by up to 25% while preserving task performance.
Tags
Links
- Source: https://arxiv.org/abs/2605.27787v1
- Canonical: https://arxiv.org/abs/2605.27787v1
Trouble viewing inline? Open PDF directly →
Full Text
85,138 characters extracted from source content.
Expand or collapse full text
Long Live the Librarian! A Persistent Search Sub-Agent for Energy-Efficient Multi-Agent Software Engineering Systems Seunghyuk Cho 1 , Sunghyun Choi 1 , Jaeseung Heo 1 , Youngbin Choi 1 , Saemi Moon 2 , MoonJeong Park 1 , Dongwoo Kim 1,2,* 1 Graduate School of Artificial Intelligence, POSTECH, 2 Department of Computer Science and Engineering, POSTECH, shhj1998, sunghyunchoi, jsheo12304, choi.youngbin, saemi, mjeongp, dongwoo.kim@postech.ac.kr Abstract Multi-agent systems (MAS) have substantially advanced autonomous software engineering (SWE), but their growing inference energy de- mands raise sustainability concerns. In this paper, we demonstrate that this cost is concen- trated in an overlooked source: redundant out- put tokens generated across agents. Two em- pirical findings ground this claim. First, our per-token energy attribution for MAS reveals a sharp asymmetry: an output token consumes 30 to 1,000 times more energy than an input or cached token. Second, MAS inflate per-episode output because agents repeatedly re-explore overlapping repository regions. To address this inefficiency, we propose Librarian, a persistent search sub-agent that tracks repository-search history and suppresses redundant exploration actions across agents. By returning short refer- ences to file regions instead of full file excerpts, Librarian further reduces output-token volume. On SWE-Bench Verified, Librarian reduces per- episode GPU energy consumption of existing multi-agent SWE systems by up to 25% while preserving task performance. 1 Introduction The rapid deployment of large language models (LLMs) has driven a sharp rise in the electricity demand of large-scale computing and is projected to drive further growth in the coming years (de Vries, 2023; International Energy Agency, 2026; Fernandez et al., 2025; Morrison et al., 2025). This consumption translates into a substantial en- vironmental footprint, ranging from carbon emis- sions (Luccioni et al., 2024) to freshwater drawn by host data centers (Li et al., 2025). These con- cerns have motivated recent work on measuring LLM inference energy (Fernandez et al., 2025; Niu et al., 2026) and improving efficiency through system- and hardware-aware optimizations (Patel et al., 2024b; Stojkovic et al., 2025). However, most existing analyses focus on the per-call setting and offer limited insight into agen- tic deployments where a single task spans many LLM calls. This limitation is sharpest in multi- agent systems (MAS) for software engineering (SWE) (Tao et al., 2024; Hong et al., 2024; Wad- hwa et al., 2024; Qian et al., 2024; Phan et al., 2024; Xu et al., 2026), where bug fixing (Jimenez et al., 2024; Zhang et al., 2025) and feature implementa- tion (Hong et al., 2024; Qian et al., 2024) are split across specialized sub-agents. MAS are increas- ingly adopted in SWE for the performance gains of role specialization, yet no energy analysis exists for this setting. SWEnergy (Tripathy et al., 2025) takes a first step but is restricted to single-agent runs, leaving MAS deployments uncharacterized. In this work, we measure the GPU energy of multi-agent SWE systems and find a counterintu- itive pattern: MAS consume more GPU energy than their single-agent counterparts even at lower aggregate token counts. To explain this gap, we conduct turn-level attribution that decomposes each episode’s GPU energy into the input, output, and cached tokens of every LLM call. The attribution traces the gap to two compounding effects: MAS produce more output tokens per episode, and each output token incurs much higher energy than its input or cached counterpart. Thus, aggregate token counts and API-pricing-based proxies can underes- timate actual GPU energy and obscure the category- level effects that drive agentic energy consumption. We trace the excessive output to redundant file exploration across sub-agent invocations. In exist- ing MAS designs, no sub-agent preserves an explo- ration history across invocations, so each lookup begins from scratch. As a result, when the orches- trator issues different queries, sub-agents repeat- edly traverse overlapping files and regenerate long file excerpts, amplifying the most energy-intensive token category. To break this re-exploration cycle, we propose 1 arXiv:2605.27787v1 [cs.MA] 27 May 2026 the Librarian, a MAS-agnostic code-lookup sub- agent that returns the relevant region for each or- chestrator query. We instantiate it with three design choices. First, to eliminate redundant exploration, its session persists across all invocations within an episode, so prior searches are reused. Second, to keep the session consistent with the current repos- itory state, each invocation is supplied with the files and line ranges edited since the previous call, prompting the Librarian to re-traverse those regions. Third, to minimize output tokens, each answer is returned as a short view command rather than the inlined file excerpt itself. To integrate Librarian into an existing MAS, we provide a guideline that replaces the MAS’s code-navigation sub-agent with Librarian and routes all exploration through it. We apply the Librarian on SWE-Bench Veri- fied (Jimenez et al., 2024) to BOAD (Xu et al., 2026) and HyperAgent (Phan et al., 2024) with two open-weight LLMs from the Qwen3.6 family, 35B-A3B (Qwen Team, 2026b) and 27B (Qwen Team, 2026a). Across both MAS and both back- bones, the Librarian variants preserve or improve the underlying MAS’s pass rate while reducing the GPU energy consumed per episode by up to 25%. Ablations confirm that this energy reduction stems from Librarian invocations eliminating the dupli- cate output tokens diagnosed above. We summarize the contributions as follows: we confirm that output tokens dominate resource use in agentic settings (§3); we diagnose the energy over- head of existing MAS designs as a consequence of duplicate lookups across the debugging cycle that no existing sub-agent recognizes (§3.3); we propose the Librarian, a persistent search sub-agent that integrates into existing MAS designs to sup- ply this missing role (§4); and we show on SWE- Bench Verified that it minimizes hardware energy at matched pass rate (§5). 2 Related Work 2.1 Energy footprint of LLM inference LLM inference energy is conventionally quantified at the GPU level, since GPU consumption domi- nates per-server serving power (Patel et al., 2024a). Within this scope, Luccioni et al. (2024) bench- mark per-inference energy across model and task configurations, and Fernandez et al. (2025) fur- ther model per-query GPU duration and energy as a function of inference-optimization choices and workload geometry. At a finer granularity, Niu Token Count MethodUncached CachedOut Total Energy (M)(M)(K)(M)(kJ) Qwen3.6-35B-A3B Vanilla0.112.69 16.82.8110.31 HyperAgent0.262.16 48.52.4725.64 BOAD0.193.71 28.53.9317.45 Qwen3.6-27B Vanilla0.102.59 15.42.7157.45 HyperAgent0.211.35 35.41.59121.84 BOAD0.213.07 24.33.3088.96 Table 1: Token usage and energy consumption across SWE Agents. We report token usage by category, un- cached input, cached input, and output, alongside per- episode mean energy consumption for a single-agent SWE system denoted as Vanilla and two multi-agent SWE systems, HyperAgent and BOAD. HyperAgent shows the smallest cached and total token counts yet the largest energy consumption. et al. (2026) decompose per-request power into the prefill and decode stages, yielding per-token en- ergy estimates per stage that inform energy-aware serving designs (Patel et al., 2024b; Stojkovic et al., 2025). While these works yield hardware-grounded per-call energy characterizations, all are defined per inference call, not over multi-turn agentic tra- jectories. SWEnergy (Tripathy et al., 2025) ex- tends per-call energy measurement to SWE-agent frameworks, but its analysis is restricted to small LLMs with near-zero task resolution. Moreover, its per-category attribution uses univariate correla- tion, which gives each category’s per-token energy scaled by how much its count varies across turns, not the per-token energy itself. 2.2 Multi-agent software engineering systems Multi-agent SWE systems organize execution around specialized roles such as planner, naviga- tor, coder, and reviewer that collaborate to resolve a single task. Two paradigms for stitching these roles recur. Pipeline-based MAS hardcode the role sequence at design time, so each role advances the task one predetermined phase and hands off to the next role (Qian et al., 2024; Hong et al., 2024; Wadhwa et al., 2024). In SWE, however, execution order is not fixed in advance and coordi- nation evolves as the task unfolds (Xu et al., 2026). Orchestrator-driven MAS instead route through a central orchestrator that picks the next sub-agent at each step, so the workflow emerges at runtime (Tao 2 et al., 2024; Phan et al., 2024; Xu et al., 2026). Such designs form sub-agent teams at runtime to fit each issue (Tao et al., 2024). 2.3 Context management of LLMs Context management for LLMs extracts query- relevant content from model history or external sources. Retrieval-based methods rank documents or prior turns by similarity to the current query and prepend the top results to one LLM call (Lewis et al., 2020; Zhang et al., 2023; Shrivastava et al., 2023). Compression-based methods remove or summarize non-essential tokens from an oversized prompt to keep query-aligned content (Jiang et al., 2023, 2024; Chevalier et al., 2023; Li et al., 2023). Agentic memory persists state across many calls of a single agent through structured memory stores or reflective summaries (Packer et al., 2024; Shinn et al., 2023; Park et al., 2023; Xu et al., 2025). Their target, however, is a single agent interacting with a user or environment, rather than an orchestrator- invoked sub-agent within MAS. 3 An Energy Profile of SWE Agents In this section, we identify where the GPU energy of SWE agents is spent. We first describe how we measure per-turn token counts and GPU energy. We then decompose per-turn energy into the con- tributions of three token categories and show that output tokens dominate. Finally, we trace the ex- cess output of MAS to repeated file lookups across sub-agent invocations. 3.1 Measuring per-turn energy and tokens We treat each SWE-agent turn as a sequence of an LLM call, action extraction, and action execution. A SWE-agent’s episode is a sequence of turns, and per-episode cost sums over turns. This applies to single-agent systems and MAS alike; the two architectures differ only in how each turn’s context is assembled. For each turntwe record two quantities. The first is a triple of token counts: the input tokens processed by prefill,x u t ; the input tokens served from the key-value cache,x c t ; and the output to- kens generated by decoding,x o t . The second is the GPU energy drawn during the call,E t , obtained by reading NVIDIA’s hardware energy counter and subtracting the idle baseline. 1 Appendix A.1 states the measurement formally. 1 NVML exposes this counter on the A100-80GB and B200 SXM GPUs used in this study. Per-token energy (mJ/tok) Settingβ u β c β o R 2 A3B / A100 30.50± 1.95 1.36± 0.11 967± 20 0.979 A3B / B2006.43± 1.56 0.54± 0.02 660± 8 0.987 27B / B200 33.97± 1.04 2.04± 0.06 3,512± 23 0.992 Table 2: Estimated per-token energy by token category. We fit a linear regression of total per-request energy on the number of uncached input (u), cached input (c), and output tokens (o);β u ,β c ,β o are the resulting per-token coefficients andR 2 is the regression fit. Output tokens show a 30 to 1,000×gap relative to the other categories. 3.2 Token-level energy attribution We first ask whether aggregate token count predicts energy. Table 1 shows that it does not: one of the systems achieves the smallest total token count yet draws the most energy. We therefore need a finer-grained attribution. To isolate each token category’s contribution, we fit a multiple linear regression of per-turn energy on the three token counts: E t = α + β u x u t + β c x c t + β o x o t + ε t ,(1) whereαabsorbs fixed per-turn overhead,β i is the marginal energy per token of categoryi, andε t is the residual. We fit this regression on per-turn records collected from Vanilla, BOAD (Xu et al., 2026), and HyperAgent (Phan et al., 2024) runs on SWE-Bench Verified (Jimenez et al., 2024), across two backbones, Qwen3.6-35B-A3B (Qwen Team, 2026b) and Qwen3.6-27B (Qwen Team, 2026a), and two GPUs, A100 and B200. Full fit details appear in Appendix A.2. Table 2 reports the fitted coefficients, and Table 8 reports the variance-inflation factors (VIFs), which diagnose coefficient reliability. Output tokens cost 30 to 1,000 times more energy per token than either input category, and all VIFs satisfyVIF ≤ 1.05, indicating nearly orthogonal regressors and thus reliable coefficient estimates. The same ordering appears at the episode level: in Table 1, per-episode energy across systems tracks output token counts rather than total or input counts. Output volume is therefore the dominant lever for reducing per- episode energy. 3.3 Sources of excess MAS output §3.2 shows that BOAD and HyperAgent emit more output per episode than the single-agent Vanilla. To localize this excess, we examine how per-turn out- put relates to the agent’s file-access pattern. A large 3 share of MAS output is emitted on turns whose file read repeats a region the sub-agent has already in- spected earlier in the episode. The mechanism is straightforward. The file read itself is an external observation, not output. The output arrives when the sub-agent then re-emits the located region, quoted or paraphrased, in the answer it returns to the orchestrator. A region in- spected multiple times across the episode is there- fore rewritten multiple times. Measuring duplicate rewrites. We flag a turn whose action is a file read as a duplicate read if the returned observation overlaps, in file-line range, an earlier read within the same episode; any interven- ing write to the file resets this history. The output to- kens emitted on such turns are counted as duplicate output. We further split duplicate reads into same- agent overlap, where the prior read came from the same sub-agent invocation, and cross-agent over- lap, where it came from a different invocation. Two invocations of the same sub-agent role count as cross-agent, because read history is scoped to an invocation rather than to a role. Table 3 decomposes the ratio of duplicate out- put tokens to read output tokens for BOAD and HyperAgent, aggregated across both backbones. R 1 ,R 2 , andR 3 denote the code navigator, issue analyzer, and orchestrator for BOAD, and the nav- igator, editor, and executor for HyperAgent. Hy- perAgent’s orchestrator is excluded since it does not read files. Both systems show frequent within- invocation re-exploration, and HyperAgent addi- tionally shows across-invocation re-exploration even within the same role. Together, these indi- cate that re-exploration accounts for a non-trivial portion of the MAS baselines’ excess output. 4 Method: The Librarian Sub-Agent 4.1 Overview We propose the Librarian, a persistent sub-agent that handles every code lookup an episode requires through a single long-lived session, eliminating the within-episode re-exploration diagnosed in §3.3. Three properties define it. Persistent session: one session spans the whole episode, so every query starts from the full history of prior searches. Pointer-only answers: each answer to the orches- trator is a list of view-command pointers rather than inlined file content, keeping output tokens small in the response. Retrieval-only scope: the role is restricted to file and code lookup, excluding the Across invocations (%) Within invocation (%) Source SystemCurrent R 1 R 2 R 3 BOAD R 1 0.08.10.19.1 R 2 0.10.00.118.6 R 3 9.93.70.022.7 HyperAgent R 1 12.10.30.99.8 R 2 1.90.40.30.7 R 3 1.80.326.834.4 Table 3: Output duplication in BOAD and HyperAgent. Each cell shows the fraction of file-read output tokens that are duplicated.R 1 ,R 2 , andR 3 denote different roles of each MAS. The Within invocation column tracks duplication by the same sub-agent during a single in- vocation, while the Across invocations block tracks the fraction of duplicated content from earlier calls (rows: current sub-agent, columns: source sub-agent). analytical and editing work that MAS navigators typically conflate with it (Xu et al., 2026). §4.2 walks through a single invocation and shows how each property takes effect. §4.3 pro- vides a MAS-agnostic recipe for integration. Fig- ure 1 visualizes the architecture, and the implemen- tation details appear in Appendix B. 4.2 Anatomy of an invocation An invocation proceeds in three stages, each realiz- ing one of the properties defined in §4.1. Context assembly. The Librarian’s context re- tains its full trajectory from earlier invocations in the episode, so prior searches and answers are on hand. To keep this history aligned with the repos- itory’s current state, each invocation prepends a freshness report listing the files and line ranges modified since the previous call, and instructs the Librarian to re-traverse those regions before reusing cached excerpts. Invocations that issued no file reads are dropped from the persisted his- tory. The implementation details of pruning the invocation history and freshness report appear in Appendix B.1 and Appendix B.2. For context man- agement, we also try retrieval instead of history accumulation, comparing sparse and dense top-k variants over the same prior history in §5.3. Scoped search. The Librarian then resolves the query by running search commands such asgrep andfindand by viewing matching files, under two scope guards. The system prompt declares edit- ing, test execution, and analytical reasoning out of scope, confining shell use to repository navi- gation. The tool layer pairs thebashshell with 4 OpenHands’s file view tool (Wang et al., 2025) and requires every file read to go through it, so each read is recorded at an explicit file-line range. Pointer-only submission.The invocation closes with a call to asubmittool. Its argument is a list of view commands referring to the located code, plus a natural-language explanation; the commands cannot inline the code itself. The tool executes the commands on the Librarian’s behalf and forwards the excerpts to the orchestrator. The orchestrator therefore receives the actual snippets, while the Librarian’s output stays a short pointer list. An example of a submission and the orchestrator mes- sage it produces appears in Appendix B.3. 4.3 Integration into an existing MAS An existing orchestrator’s system prompt typically comprises three blocks: a SWE context describing the operating environment, the per-task user query, and a solve plan laying out the step-by-step proce- dure. Adding the Librarian touches only the solve plan; the SWE context, the user query, and every non-navigation step of the plan stay untouched. Tool swap and plan rewrite. We replace the or- chestrator’s existing navigator-delegation tool with a Librarian-delegation tool, then rewrite each nav- igation step of the solve plan to phrase its action as a natural-language lookup query. Any navigator responsibility beyond file and code lookup, such as cross-module analysis, is redirected to other steps in the plan. The rewrite is formalized as a prompt- level guideline in Appendix B.6, and the result- ing BOAD and HyperAgent plans appear in Ap- pendix B.7. Tool-selection policy.We prepend a short policy to the solve plan to keep the Librarian invoked only for lookup. The policy directs the orchestrator to call the Librarian for unknown-location queries and to keep analytical tasks such as bug diagnosis outside the Librarian’s scope. It is identical across MAS and appears in Appendix B.5. 5 Experiments In this section, we empirically validate the Librar- ian’s ability to reduce per-episode energy consump- tion. We also confirm that the saving stems from lower output tokens, the primary mechanism that the Librarian’s design targets. 5.1 Experimental setup We describe the experimental setup used to com- pare the Librarian against prior systems on the SWE task, covering the benchmark, implementa- tion details, and baselines. 5.1.1 Benchmark We evaluate every method on the 500 tasks of SWE- Bench Verified (Jimenez et al., 2024), a benchmark of real GitHub issues drawn from open-source Python repositories. For each task, the SWE-agent receives the issue description and the repository at the buggy commit, and must produce a patch that passes the maintainer’s test suite for the issue. 5.1.2 Implementation details We explain the two main components to run a SWE- agent: i) the LLM driving it and i) the scaffold mediating its repository interaction. LLM serving. For the LLM, we evaluate two Qwen3.6 variants: the sparse mixture-of-experts 35B-A3B (Qwen Team, 2026b) with3B active pa- rameters and the dense 27B (Qwen Team, 2026a). Both backbones run in FP8 on a single NVIDIA B200 SXM GPU, served by vLLM (Kwon et al., 2023). We enable prefix caching so that each sub- agent reuses its prior prefix across successive invo- cations within a session. We size the KV cache to avoid eviction in every episode. The serving config- uration and the sampling hyper-parameters are held fixed across all episodes as listed in Appendix C.1. Agent interface. For the interface which allows the SWE-agent to interact with the code repository, we provide a base tool set comprising abashshell, thestr_replace_editorfile editor from Open- Hands (Wang et al., 2025) that takes a view or edit mode along with a file path and a line range, and asubmittool that marks the agent’s solution as final. Each agent role draws on whichever subset of this set it needs and may additionally define role- specific tools such as sub-agent delegation. To keep long-trajectory runs stable, we adopt three safe- guards from the OpenHands runtime, a wall-clock timeout on each shell command, loop detection on agent outputs, and truncation of tool observations. We describe how each mechanism is implemented in Appendix C.1. 5.1.3 Baselines We confirm the Librarian’s effectiveness by apply- ing it to two orchestrator-delegation multi-agent 5 Figure 1: Illustration of the overall process of multi-agent SWE systems resolving a SWE task. The orchestrator calls a sub-agent viainvokeaction, which navigates the repository throughbashand file view/edit tools and returns its answer via asubmitcall; the content of this call becomes the observation for the orchestrator’s invocation. On a subsequent invocation of the same role, prior MAS (top right) start from a fresh context, discarding all history, and returns the full file excerpt. In contrast, the Librarian (bottom right) appends the new task given by the invocation to its existing trajectory and continues from there, reusing the accumulated repository knowledge, and only generates the file pointer for response, which is converted to file excerpt later. SWE systems. We additionally compare against token-efficiency methods that can be combined with any SWE-agent. Multi-agent systems.We consider two MAS de- signs that delegate the SWE workflow across spe- cialized sub-agents: BOAD (Xu et al., 2026) and HyperAgent (Phan et al., 2024). BOAD’s orches- trator first delegates code localization for the issue to one sub-agent, then bug-cause navigation to a second sub-agent, and finally produces a patch by aggregating the outputs of both sub-agents. Hyper- Agent’s orchestrator manages three sub-agents: a navigator for code exploration, an editor for file modification, and an executor for test execution. The orchestrator itself holds only the sub-agent del- egation and submit tools. Following a pre-defined plan detailed in Appendix B.7, the orchestrator iter- ates this navigate-edit-execute cycle until it submits a patch. While BOAD imposes no tool restrictions on its sub-agents, HyperAgent restricts each sub- agent’s tool set by role, such as confining the navi- gator to file viewing and the editor to file edits. Token-efficiency methods. We consider two token-efficiency techniques: caveman prompt- ing (Brussee, 2026; Hakim, 2026) and LastNOb- servation (Yang et al., 2024) that we apply across every role of the MAS to reduce token consumption. Caveman prompting appends a fixed style directive, given in Appendix C.2, to the system prompts of every sub-agent and the orchestrator, inducing sim- pler answer text while leaving the thinking trace intact. LastNObservation is a SWE-agent (Yang et al., 2024) scaffold feature that truncates all but the most recentNtool observations in each role’s context, replacing each truncated observation with a short placeholder while preserving the thinking traces and action calls. We setN = 5in all subse- quent experiments. 5.2 Results and analysis We first report the main results of attaching the Li- brarian to existing MAS baselines on SWE-Bench Verified, then analyze the observed energy reduc- tion from three angles: robustness across task dif- ficulty, localization to the replaced role, and the reuse of accumulated history across invocations. Results. Table 4 reports results on SWE-Bench Verified for BOAD and HyperAgent across four configurations: bare MAS, MAS with a token- efficiency technique, Librarian-augmented MAS, and Librarian-augmented MAS with caveman prompting. We report pass rate, per-episode output tokens, and GPU energy, denoted as Pass, Out tok, and Energy respectively. The Librarian matches or improves the pass rate in most of the settings, while 6 MethodPassOut tokEnergy (%)(K)(kJ) Qwen3.6-35B-A3B HyperAgent66.048.525.64 + Librarian67.242.222.73 + LastNObservation56.853.334.79 + Caveman66.237.719.99 + Caveman + Librarian66.234.718.63 BOAD69.828.517.45 + Librarian71.624.614.66 + LastNObservation63.233.526.87 + Caveman68.424.714.79 + Caveman + Librarian70.420.612.37 Qwen3.6-27B HyperAgent69.835.4121.84 + Librarian72.026.391.45 + LastNObservation64.834.0135.84 + Caveman68.021.979.40 + Caveman + Librarian67.618.066.05 BOAD71.824.388.96 + Librarian71.819.771.76 + LastNObservation70.226.2122.91 + Caveman70.217.566.20 + Caveman + Librarian71.413.551.21 Table 4: Results on SWE-Bench Verified. We report the overall pass rate alongside the per-episode means for output tokens and energy consumption for each SWE agent. The Librarian improves output token efficiency and energy consumption across all settings while pre- serving the pass rate. substantially reducing energy. LastNObservation truncates recent observations to reduce per-turn in- put tokens, but per-episode GPU energy increases across all settings: sub-agents are forced to re- explore lost context, inflating output tokens in three of four settings. Pass rate also degrades in every set- ting. Caveman prompting alone reduces energy but degrades pass rate in three of four settings. Across all settings, the Librarian with caveman prompting attains the lowest energy consumption. Robustness across task difficulty. We examine whether this trend holds across difficulty levels. We define each task’s difficulty as the max input tokens observed on a reference single-agent run. Table 5 stratifies per-episode energy by difficulty, and the reduction holds across all bins and is largest on the harder tasks, with the Librarian variants attaining the lowest energy in nearly every cell. The sole exception is the most difficult bin of HyperAgent on 27B, where LastNObservation achieves lower energy. However, Table 12 shows that its pass rate in this bin drops to roughly half of the baseline. Reference max-input tokens (K) Method 0–32K32–64K64–96K>96K (n=36)(n=312)(n=130)(n=22) Qwen3.6-35B-A3B HyperAgent10.3617.6140.4676.87 + Librarian5.8316.2036.8459.65 + LastNObservation7.9026.2556.2972.69 + Caveman4.3312.9233.1168.30 + Caveman + Librarian4.8812.4231.0056.10 BOAD7.2212.5026.9947.97 + Librarian5.1211.0320.9844.41 + LastNObservation7.6919.8243.2860.83 + Caveman4.3110.2823.6443.64 + Caveman + Librarian3.928.8219.0436.97 Qwen3.6-27B HyperAgent32.6179.36208.19359.95 + Librarian25.3164.40142.91279.35 + LastNObservation37.35106.47217.76229.48 + Caveman25.9354.11129.45231.94 + Caveman + Librarian19.0541.17110.24234.59 BOAD40.6869.77127.81210.46 + Librarian34.7856.26104.22160.26 + LastNObservation52.24101.43174.50238.36 + Caveman26.2048.93100.29175.19 + Caveman + Librarian20.1037.4380.67123.42 Table 5: Per-episode GPU energy (kJ) of the SWE- agents with respect to the task difficulty. We report the per-episode GPU energy of the SWE-agents across difficulty classes. The addition of the Librarian reduces the energy consumption in almost all settings. 0 32K3264K6496K>96K Reference max-input tokens (K) 0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 Mean Librarian invocations HyperAgent + Librarian HyperAgent + Caveman + Librarian BOAD + Librarian BOAD + Caveman + Librarian Figure 2: Mean Librarian invocations per episode across task difficulty. We plot the per-episode mean Librar- ian invocation count for the Librarian-augmented MAS variants run with Qwen3.6-27B against the reference max-input-token bin. The invocation frequency grows monotonically with task difficulty. The plot for 35B- A3B is in Figure 3. The Librarian instead preserves the pass rate, and the energy reduction persists even as it is invoked more often on harder tasks, as shown in Figure 2. Energy reduction at the lookup role.We inves- tigate the source of the energy reduction, focusing on the role that the Librarian replaces. For each MAS baseline, we identify the role the Librarian substitutes for: BOAD’s code navigator and Hyper- 7 Replaced role+ Librarian ModelMethodOut (K)E (kJ)Out (K)E (kJ) A3B HyperAgent13.927.546.023.57 HyperAgent + Caveman10.515.694.672.66 BOAD13.818.541.931.08 BOAD + Caveman11.086.621.700.94 27B HyperAgent10.5036.634.7016.92 HyperAgent + Caveman6.9925.743.3812.65 BOAD5.6320.791.826.56 BOAD + Caveman5.1019.321.445.43 Table 6: Per-episode comparison on the role that the Librarian replaces. We report the per-episode means of output tokens and GPU energy at the replaced role. The Librarian reduces energy at the replaced role across all settings. The full per-role breakdown is in Appendix D. 510152025 Librarian invocation k 4 6 8 Mean LLM turns at invocation k HyperAgent, 35B-A3B HyperAgent, 27B BOAD, 35B-A3B BOAD, 27B Figure 3: Visualization of the mean LLM turns to an- swer per Librarian invocation. We report the mean number of turns each Librarian variant takes to emit an output at thek-th invocation. All cases except BOAD on 35B-A3B show a decreasing trend as k grows. Agent’s navigator. Table 6 reports that the Librar- ian outputs fewer tokens and consumes less energy than its counterpart. Tables 10 and 11 further show that this reduction does not inflate the token usage or energy consumption of other roles. History reuse across invocations. We track the number of LLM turns the Librarian takes to answer the orchestrator’sk-th call, averaged over episodes that reach thek-th call. Figure 3 plots the average number of turns againstk. The number of turns decreases in most configurations overk, confirming that the Librarian reuses its accumulated history to resolve later queries with fewer turns. 5.3 Comparison with retrieval baselines We compare the Librarian against two retrieval- based variants that replace the persistent his- tory with retrieved context.The variants use BM25 (Robertson and Zaragoza, 2009) for sparse scoring and SFR-Embedding-Code-2B_R (Liu et al., 2024) for dense scoring. At each invocation, the scoring method ranks prior file-read command- MethodPass (%) Out tok (K) Energy (kJ) Qwen3.6-35B-A3B HyperAgent71.044.923.77 + Sparse retrieval72.044.423.65 + Dense retrieval69.047.025.05 + Librarian72.039.519.75 BOAD77.028.617.47 + Sparse retrieval76.022.312.93 + Dense retrieval77.021.412.42 + Librarian74.022.813.61 Qwen3.6-27B HyperAgent73.033.1114.86 + Sparse retrieval70.028.097.95 + Dense retrieval69.030.4107.11 + Librarian70.023.682.42 BOAD76.023.084.25 + Sparse retrieval68.020.072.86 + Dense retrieval74.020.173.36 + Librarian74.019.471.08 Table 7: Comparison between the Librarian and the retrieval-based context management baselines. We com- pare the Librarian against two baselines that swap the Librarian sub-agent’s persistent-history context for one constructed by retrieval. We report the per-episode means on 100 randomly sampled tasks per backbone. The Librarian shows better performance and energy effi- ciency than the retrieval counterparts almost all settings. observation pairs by similarity to the orchestrator’s query, and the top-kform the context. Table 7 reports pass rate, output tokens, and per-episode energy across the four variants on a shared random sample of 100 tasks per backbone withk = 5. The Librarian achieves a higher pass rate and lower energy than both retrieval variants in almost all settings, indicating that the orchestrator’s queries need active context management and reasoning, not lookup alone. 6 Conclusion In this work, we identify and eliminate a major source of energy waste in multi-agent SWE sys- tems. We first analyze per-turn energy across to- ken categories and find that output tokens domi- nate. Tracing the excess output, we then identify re-exploration of the same files across invocations as the primary source. We finally address this with the Librarian, a sub-agent that retains its explo- ration history across invocations. Integrating the Librarian into existing MAS reduces per-episode GPU energy while preserving task performance. 8 Limitations In this work, we propose a sub-agent which re- duces the energy of the existing multi-agent SWE systems. We acknowledge two limitations of our current study. First, the solution is limited to code navigation. The executor sub-agent in Hy- perAgent, which reproduces the issue and runs tests, also produces duplicate outputs across in- vocations. Extending the Librarian’s core design to such execution-oriented roles is a promising next step toward system-wide energy reduction. Sec- ond, the scale of the open LLMs we evaluate is limited. Our experiments cover backbones in the active-parameter range of roughly 3B to 27B, and it remains open whether the observed reductions in output tokens and energy carry over to substantially larger open models over 500B inference parame- ters. References Julius Brussee. 2026. caveman. Alexis Chevalier, Alexander Wettig, Anirudh Ajith, and Danqi Chen. 2023. Adapting language models to compress contexts. In The 2023 Conference on Em- pirical Methods in Natural Language Processing. Alex de Vries. 2023. The growing energy footprint of artificial intelligence. Joule, 7(10):2191–2194. Jared Fernandez, Clara Na, Vashisth Tiwari, Yonatan Bisk, Sasha Luccioni, and Emma Strubell. 2025. En- ergy considerations of large language model infer- ence and efficiency optimizations. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 32556–32569, Vienna, Austria. Association for Computational Linguistics. MD Azizul Hakim. 2026.Brevity constraints re- verse performance hierarchies in language models. Preprint, arXiv:2604.00025. Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. MetaGPT: Meta pro- gramming for a multi-agent collaborative framework. In The Twelfth International Conference on Learning Representations. International Energy Agency. 2026. Key questions on energy and AI. Technical report, IEA, Paris. Licence: C BY 4.0. Huiqiang Jiang, Qianhui Wu, Chin-Yew Lin, Yuqing Yang, and Lili Qiu. 2023. LLMLingua: Compressing prompts for accelerated inference of large language models. In The 2023 Conference on Empirical Meth- ods in Natural Language Processing. Huiqiang Jiang, Qianhui Wu, Xufang Luo, Dong- sheng Li, Chin-Yew Lin, Yuqing Yang, and Lili Qiu. 2024. LongLLMLingua: Accelerating and enhanc- ing LLMs in long context scenarios via prompt com- pression. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Vol- ume 1: Long Papers), pages 1658–1677, Bangkok, Thailand. Association for Computational Linguistics. Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. 2024. SWE-bench: Can language mod- els resolve real-world github issues? In The Twelfth International Conference on Learning Representa- tions. Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. 2023. Effi- cient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles. Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Hein- rich Küttler, Mike Lewis, Wen-tau Yih, Tim Rock- täschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-augmented generation for knowledge- intensive nlp tasks. In Proceedings of the 34th Inter- national Conference on Neural Information Process- ing Systems, NIPS ’20, Red Hook, NY, USA. Curran Associates Inc. Pengfei Li, Jianyi Yang, Mohammad A. Islam, and Shaolei Ren. 2025. Making ai less ’thirsty’. Com- mun. ACM, 68(7):54–61. Yucheng Li, Bo Dong, Frank Guerin, and Chenghua Lin. 2023. Compressing context to enhance inference ef- ficiency of large language models. In Proceedings of the 2023 Conference on Empirical Methods in Natu- ral Language Processing, pages 6342–6353, Singa- pore. Association for Computational Linguistics. Ye Liu, Rui Meng, Shafiq Jot, Silvio Savarese, Caim- ing Xiong, Yingbo Zhou, and Semih Yavuz. 2024. Codexembed: A generalist embedding model family for multiligual and multi-task code retrieval. arXiv preprint arXiv:2411.12644. Sasha Luccioni, Yacine Jernite, and Emma Strubell. 2024. Power hungry processing: Watts driving the cost of ai deployment? In Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency, FAccT ’24, page 85–99, New York, NY, USA. Association for Computing Machinery. Jacob Morrison, Clara Na, Jared Fernandez, Tim Dettmers, Emma Strubell, and Jesse Dodge. 2025. Holistically evaluating the environmental impact of creating language models. In The Thirteenth Interna- tional Conference on Learning Representations. 9 Chenxu Niu, Wei Zhang, Jie Li, Yongjian Zhao, Tongyang Wang, Xi Wang, and Yong Chen. 2026. Tokenpowerbench: Benchmarking the power con- sumption of llm inference.Proceedings of the AAAI Conference on Artificial Intelligence, 40(38):32582–32590. Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. 2024. Memgpt: Towards llms as operating systems. Preprint, arXiv:2310.08560. Joon Sung Park, Joseph O’Brien, Carrie Jun Cai, Mered- ith Ringel Morris, Percy Liang, and Michael S Bern- stein. 2023. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th an- nual acm symposium on user interface software and technology, pages 1–22. Pratyush Patel, Esha Choukse, Chaojie Zhang, Íñigo Goiri, Brijesh Warrier, Nithish Mahalingam, and Ricardo Bianchini. 2024a. Characterizing power management opportunities for llms in the cloud. In Proceedings of the 29th ACM International Confer- ence on Architectural Support for Programming Lan- guages and Operating Systems, Volume 3, ASPLOS ’24, page 207–222, New York, NY, USA. Association for Computing Machinery. Pratyush Patel, Esha Choukse, Chaojie Zhang, Aashaka Shah, Íñigo Goiri, Saeed Maleki, and Ricardo Bian- chini. 2024b. Splitwise: Efficient generative llm inference using phase splitting. In 2024 ACM/IEEE 51st Annual International Symposium on Computer Architecture (ISCA), pages 118–132. Huy Nhat Phan, Tien N Nguyen, Phong X Nguyen, and Nghi DQ Bui. 2024. Hyperagent: Generalist software engineering agents to solve coding tasks at scale. arXiv preprint arXiv:2409.16299. Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2024. ChatDev: Communicative agents for software development. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 15174–15186, Bangkok, Thailand. Association for Computational Linguistics. Qwen Team. 2026a. Qwen3.6-27B: Flagship-level cod- ing in a 27b dense model. Qwen Team. 2026b. Qwen3.6-35B-A3B: Agentic cod- ing power, now open to all. Stephen Robertson and Hugo Zaragoza. 2009. The probabilistic relevance framework: Bm25 and be- yond. Found. Trends Inf. Retr., 3(4):333–389. Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik R Narasimhan, and Shunyu Yao. 2023. Re- flexion: language agents with verbal reinforcement learning. In Thirty-seventh Conference on Neural Information Processing Systems. Disha Shrivastava, Denis Kocetkov, Harm de Vries, Dzmitry Bahdanau, and Torsten Scholak. 2023. Re- pofusion: Training code models to understand your repository. Preprint, arXiv:2306.10998. Jovan Stojkovic, Chaojie Zhang, Íñigo Goiri, Josep Tor- rellas, and Esha Choukse. 2025. Dynamollm: De- signing llm inference clusters for performance and energy efficiency. In HPCA. Wei Tao, Yucheng Zhou, Yanlin Wang, Wenqiang Zhang, Hongyu Zhang, and Yu Cheng. 2024. MAGIS: LLM-based multi-agent framework for github issue resolution. In The Thirty-eighth An- nual Conference on Neural Information Processing Systems. Arihant Tripathy, Ch Pavan Harshit, and Karthik Vaid- hyanathan. 2025. Swenergy: An empirical study on energy efficiency in agentic issue resolution frame- works with slms. Preprint, arXiv:2512.09543. Nalin Wadhwa, Atharv Sonwane, Daman Arora, Ab- hav Mehrotra, Saiteja Utpala, Ramakrishna B Bairi, Aditya Kanade, and Nagarajan Natarajan. 2024. MA- SAI: Modular architecture for software-engineering AI agents. In NeurIPS 2024 Workshop on Open- World Agents. Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, and 5 others. 2025. Openhands: An open platform for AI software developers as gener- alist agents. In The Thirteenth International Confer- ence on Learning Representations. Iris Xu, Guangtao Zeng, Zexue He, Charles Jin, Aldo Pareja, Dan Gutfreund, Chuang Gan, and Zhang-Wei Hong. 2026. BOAD: Discovering hierarchical soft- ware engineering agents via bandit optimization. In The Fourteenth International Conference on Learn- ing Representations. Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, and Yongfeng Zhang. 2025. A-mem: Agen- tic memory for llm agents. In Advances in Neural Information Processing Systems, volume 38, pages 17577–17604. Curran Associates, Inc. John Yang, Carlos E Jimenez, Alexander Wettig, Kil- ian Lieret, Shunyu Yao, Karthik R Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-computer inter- faces enable automated software engineering. In The Thirty-eighth Annual Conference on Neural Informa- tion Processing Systems. Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. 2023. RepoCoder: Repository-level code completion through iterative retrieval and gen- eration. In Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, 10 pages 2471–2484, Singapore. Association for Com- putational Linguistics. Linghao Zhang, Shilin He, Chaoyun Zhang, Yu Kang, Bowen Li, Chengxing Xie, Junhao Wang, Maoquan Wang, Yufan Huang, Shengyu Fu, Elsie Nallipogu, Qingwei Lin, Yingnong Dang, Saravan Rajmohan, and Dongmei Zhang. 2025. Swe-bench goes live! In Advances in Neural Information Processing Systems, volume 38. Curran Associates, Inc. A Per-Token Energy Regression: Implementation Details This appendix details the measurement and fitting behind the energy attribution of §3. We first for- malize the per-turn token counts and GPU-energy measurement introduced in §3.1 (Appendix A.1), then specify the linear regression and reliability diagnostics that produce Table 2 and Table 8 (Ap- pendix A.2). A.1 Formalism of per-turn statistics For each turn we record two quantities that the regression of Appendix A.2 later relates: the three token counts the call processes and the GPU energy it draws. We formalize each in turn. Token counts. Each turn’s LLM call processes an input contextc t and generates a sequence of output tokens, and its energy cost depends on how these tokens split across three inference operations: auto-regressive decoding, key-value cache lookup, and prefill (Niu et al., 2026; Fernandez et al., 2025). We therefore record three per-turn token counts. The output countx o t is the number of tokens pro- duced by auto-regressive decoding. The inputc t splits further, since modern inference systems reuse the key-value hidden states of recurring prefixes: a cached prefixx c t = | prefix cache (c t )|is served by key-value cache lookup, while the remaining x u t =|c t |− x c t tokens are processed by prefill. GPU energy. GPU energy is the time integral of device power, from which we subtract an idle baseline to isolate the dynamic draw of active computation. Letτ start t andτ end t be the wall- clock times bracketing the LLM call of turnt, and ∆τ t = τ end t − τ start t its duration. Given the in- stantaneous GPU powerP (τ )and the idle power P idle,t during the turn, the idle-subtracted dynamic energy of turn t is E net t = Z τ end t τ start t (P (τ )− P idle,t )dτ = Z τ end t τ start t P (τ )dτ − P idle,t ∆τ t . The integral term is the cumulative GPU energy drawn over the turn, 2 soE net t follows from reading the counter atτ start t andτ end t and subtracting the idle term P idle,t ∆τ t . A.2 Linear regression over token categories We fit the per-turn energy model of §3.2 by ordinary least squares and verify that its coefficients are reliable, describing the fitted data, the regression specification, and the reliability diagnostics in turn. A.2.1 Setup We run the three systems studied in §3.2, namely the single-agent Vanilla and the MAS baselines BOAD and HyperAgent, on SWE-Bench Veri- fied, with Qwen3.6-35B-A3B on both A100 and B200 and Qwen3.6-27B on B200.The sam- ple sizes used in Table 2 are 23,353 turns / 185 episodes (A3B/A100), 196,310 turns / 1,500 episodes (A3B/B200), and 179,011 turns / 1,500 episodes (27B/B200). A.2.2 Regression model The dependent variable for turntis the idle- subtracted dynamic energy E net t = E raw t − P idle,t ∆τ t ,(2) whereE raw t is the GPU energy integrated over the call,P idle,t the NVML idle power reading, and∆τ t the call duration, all in millijoules. With design matrixX = [1 X u X c X o ] ∈R n×4 , the per-turn model reproduces the regression of §3.2, E net t = α + β u x u t + β c x c t + β o x o t + ε t , whereαcaptures fixed per-turn overhead and is omitted from Table 2. Collecting the per-turn re- sponsesE net t into the vectory, we fit by ordinary least squares, ˆ β = arg min b∈R 4 ∥y− Xb∥ 2 2 = (X ⊤ X) −1 X ⊤ y, (3) usingnp.linalg.lstsqwithout centering, scal- ing, regularization, or robust losses. 2 NVIDIA’s NVML exposes this quantity as a hardware- level counter. 11 A.2.3 Reliability diagnostics Table 8 reports three diagnostics per fit, namely the overallR 2 , the variance-inflation factor per coefficient, and the partial R 2 per coefficient. OverallR 2 .R 2 on the fit sample is the conven- tional in-sample fraction of variance explained, R 2 = 1 − P t (y t − ˆy t ) 2 P t (y t − ̄y) 2 ,ˆy = X ˆ β. Variance-inflation factor.VIF per regressorj ∈ u,c,omeasures how well columnX j is linearly explained by the remaining regressors. LetR 2 j be theR 2 of regressingX j onX −j , fitted with the samelstsqcall. The variance-inflation factor is then VIF j = 1 1− R 2 j . Values close to 1 indicate near-orthogonality with the other regressors. PartialR 2 . The partialR 2 for coefficientjis the share of variance inyuniquely explained by X j afterX −j is partialled out, and we compute it via Frisch–Waugh–Lovell residualisation. Let M −j = I−X −j (X ⊤ −j X −j ) −1 X ⊤ −j be the residual- projector onto the orthogonal complement ofX −j , and writee y = M −j yande X j = M −j X j for the corresponding residuals. The partialR 2 is then the R 2 of the univariate regression of e y on e X j , partialR 2 j = e ⊤ y e X j 2 e ⊤ X j e X j e ⊤ y e y . B Librarian Implementation Details This appendix specifies how a Librarian invocation manages and returns its context, then reproduces every prompt it uses. Two mechanisms keep the persistent context both current and compact across invocations—history pruning (Appendix B.1) and the freshness report (Appendix B.2)—and the sub- mission step (Appendix B.3) turns the Librarian’s pointer-only answer into the verbatim excerpts the orchestrator receives. We then reproduce every prompt used by the Librarian and by the per-MAS integration recipe. B.1 History pruning The Librarian persists its full trajectory across in- vocations within an episode, but keeps an invo- cation only if that invocation surfaced genuinely SettingCoefficientPearson rVIFpartial R 2 A3B / A100 (R 2 =0.979) β u 0.157 1.010.4128 β c 0.228 1.020.3064 β o 0.978 1.020.9769 A3B / B200 (R 2 =0.987) β u 0.050 1.010.0705 β c 0.111 1.020.0584 β o 0.993 1.010.9870 27B / B200 (R 2 =0.992) β u 0.097 1.040.1806 β c 0.133 1.050.1877 β o 0.995 1.020.9919 Table 8: Coefficient reliability for Table 2. Pearsonr is the univariate correlation between each regressor and turn energy. VIF denotes the variance-inflation factor, where values close to 1 indicate no collinearity with the other regressors. PartialR 2 is the Frisch–Waugh semi- partialR 2 , namely the share of variance in turn energy uniquely explained by this coefficient after the others are partialled out. All three setups satisfyVIF≤ 1.05 and R 2 ≥ 0.97. new code. After an invocation returns, we estimate the previously-unseen file content it produced and discard the invocation when that estimate is small. Detecting file reads. A turn is counted as a file read if it either (i) calls the OpenHands str_replace_editortool inviewmode, or (i) runs one ofcat,sed -n,head,tail, orawk on a repository file. From the tool call we recover the target file and the line range it reads; each such read returns a line-numbered observation of that range. Counting new content. Novelty is judged against the Librarian’s entire retained session, not the current invocation alone: the Librarian keeps a single cumulative record of which lines of each file it has already viewed across all kept invocations, and a read counts only the observation characters on lines absent from that record. A read confined to already-seen lines therefore contributes zero, a partially overlapping read is scaled by the fraction of newly-seen lines, and a whole-file view counts only on first sight; the newly read lines are then added to the record. Two rules keep this record consistent with the retained history: a pruned invo- cation (below) has its additions rolled back, and the freshness report clears a file’s entry whenever that file is written, so a re-read of its changed content counts as new again. Summing over the invocation gives its new-content size. Pruning rule. If the new-content size is below 500characters, the invocation is treated as con- tributing nothing reusable to future queries and 12 its turns are discarded—the next invocation’s con- text is reconstructed as if it never occurred. Other- wise its turns are appended to the persistent history. Trivial or purely re-derived lookups thus leave no residue, while substantive lookups accumulate. B.2 Freshness report Because the editor and executor may modify files between two Librarian invocations, an excerpt cached in the persistent history can go stale. Ev- ery invocation with non-empty history therefore prepends a freshness report that tells the Librarian which cached regions it may still trust. The report is built in two steps. Modified ranges. We rungit diff -U0 HEAD in the repository and read each file’s modified line ranges directly from the hunk headers. Every line location reported to the Librarian is derived from this diff. Selecting which files to surface. The Librarian stores a hash of each file’sgit diffsection. At every invocation it re-runsgit diffand, for any file whose hash is new or differs from the stored one, adds the file to the report, updates the stored hash, and resets that file’s viewed-line cache; files whose hash is unchanged are omitted. Contents. For each surfaced file the report lists its modified line ranges as pointers (e.g.path: lines [10–15, 40] ), not the diff text. The accom- panying instruction states that content outside those ranges is unchanged and should be quoted from his- tory, and that a listed range need be re-viewed only if a prior view intersects it; reverted files are flagged so their cached excerpts are discarded. When no file has changed since the previous invocation, the report states this and directs the Librarian to an- swer from history. The example below is drawn from an episode on theastropyrepository, where the intervening edits touched three line ranges of sliced_wcs.py. Example file freshness report [FILE FRESHNESS REPORT -- NEW edits since the previous wake. For each listed file, content OUTSIDE these ranges is unchanged from when you last viewed it -- quote from history. Re-view ONLY if your prior view intersects the listed ranges. Files NOT listed here are either unchanged entirely or already known-modified from a prior freshness report.] ,→ ,→ ,→ ,→ ,→ ,→ - astropy/wcs/wcsapi/wrappers/sliced_wcs.py: lines [188-196, 258, 264-265],→ B.3 Pointer-only submission A Librarian invocation ends by callingsubmit, the tool that realizes the pointer-only answers of §4.2. The call carries two fields:result, a short natural-language description of what was found, andview_commands, a list of[path, start, end]triples naming the located line ranges. The code itself is referenced through these pointers and never inlined intoresult, so the tokens the Li- brarian generates stay bounded by the length of its description, however much code it surfaces. Submit call. The example below is from an episode on thedjangorepository, where the or- chestrator asked where a management command initializes its output streams. The Librarian locates the relevant range and submits one view command alongside a one-sentence summary. Example Librarian submission submit("result": "Lines 230-260 of `/testbed/django/core/management/base.py` shown below. Stdout/stderr initialization is in`__init__` at lines 239-248 —`self.stdout` and`self.stderr` are`OutputWrapper` instances wrapping `sys.stdout`/`sys.stderr`.`stderr.style_func` is set to`self.style.ERROR` for error coloring.", "view_commands": "[[\"/testbed/django/core/management/base.py\", 230, 260]]") ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ Transformation into the orchestrator message. The tool executes each view command on the Librarian’s behalf—equivalent tocat -nover the named range—and builds the orchestrator- facing message by prepending the resulting line- numbered excerpts to theresulttext, tagging the whole with the delegation tool name (here delegate_to_librarian). The orchestrator thus receives the verbatim code that the Librarian never emitted, followed by the Librarian’s summary, while the submission the Librarian generated re- mained the short pointer list above. Example message delivered to the orchestra- tor [delegate_to_librarian] Here's the result of running`cat -n` on /testbed/django/core/management/base.py lines 230-260: ,→ ,→ 230 output_transaction = False # Whether to wrap the output in a "BEGIN; COMMIT;",→ 231 requires_migrations_checks = False 232 requires_system_checks ='__all__' 233 # Arguments, common to all commands, which aren't defined by the argument,→ 234 # parser. 235 base_stealth_options = ('stderr','stdout') 236 # Command-specific options not defined by the argument parser.,→ 237 stealth_options = () 238 239 def __init__(self, stdout=None, stderr=None, no_color=False, force_color=False):,→ 13 240 self.stdout = OutputWrapper(stdout or sys.stdout),→ 241 self.stderr = OutputWrapper(stderr or sys.stderr),→ 242 if no_color and force_color: 243 raise CommandError("'no_color' and 'force_color' can't be used together."),→ 244 if no_color: 245 self.style = no_style() 246 else: 247 self.style = color_style(force_color) 248 self.stderr.style_func = self.style.ERROR,→ 249 if self.requires_system_checks in [False, True]:,→ 250 warnings.warn( 251 "Using a boolean value for requires_system_checks is ",→ 252 "deprecated. Use'__all__' instead of True, and [] (an empty ",→ 253 "list) instead of False.", 254 RemovedInDjango41Warning, 255 ) 256 self.requires_system_checks = ALL_CHECKS if self.requires_system_checks else [],→ 257 if ( 258 not isinstance(self.requires_system_checks, (list, tuple)) and ,→ ,→ 259 self.requires_system_checks != ALL_CHECKS,→ 260 ): Lines 230-260 of `/testbed/django/core/management/base.py` shown below. Stdout/stderr initialization is in`__init__` at lines 239-248 —`self.stdout` and`self.stderr` are`OutputWrapper` instances wrapping `sys.stdout`/`sys.stderr`.`stderr.style_func` is set to`self.style.ERROR` for error coloring. ,→ ,→ ,→ ,→ ,→ ,→ B.4 Librarian system prompt The full system prompt for the Librarian sub-agent. It restricts the role to locating code and returning verbatim excerpts, enumerates the in-scope and out-of-scope behaviors, defines the submission in- terface, and specifies the pre-submit self-check that scrubs analytical phrasing from the prose answer. Prompt for the Librarian sub-agent You are the repository Librarian. Your role is strictly limited to **locating files / code regions and returning verbatim excerpts**. You are NOT an analyst, debugger, or issue interpreter -- those are the main agent's job. ,→ ,→ ,→ ,→ Scope (what you DO): - Locate the file path + line range where a named symbol (class, function, method, constant, fixture, test) lives. ,→ ,→ - Return verbatim code excerpts at requested locations. - Surface adjacent context (callers, sibling tests, related fixtures) when the asker is clearly going to need it. ,→ ,→ - List directory layouts when asked. Out of scope (what you DO NOT do -- even if the main agent asks):,→ - Do NOT analyse why code does what it does, infer intent, or explain bugs / fix logic.,→ - Do NOT interpret git history / commit messages / past PRs. Specifically, do NOT make claims like "this code is a fix for issue #N" or "this was added to handle X" -- those are historical inferences you cannot ground in the current code. ,→ ,→ ,→ ,→ - Do NOT propose fixes or describe what the main agent should edit. If asked, reply with the code at the location and stop. ,→ ,→ - Do NOT translate an abstract issue description into "the bug is at line N because Y". Just return the code at the locations the main agent named (or the closest match) and let them reason. ,→ ,→ ,→ When the asker requests analysis (e.g. "what's the issue here?", "how does this fix the bug?"), you reply with the relevant code excerpts and a one-line note like "Code at <path>:<lines> is shown above; analysis is the main agent's responsibility." ,→ ,→ ,→ ,→ Tools available to you: -``bash`` (view-only --``find``,``grep``,``rg``, ``ls``,``tree``,``wc``,``cat`` of short files, etc. No edits, no test runs, no destructive commands.) ,→ ,→ ,→ -``str_replace_editor`` (view-only --``view`` command only, for inspecting file ranges. No create/edit.),→ -``submit(result, view_commands)`` -- call this exactly once per consultation to return your findings to the main agent and end the call. ``result`` is short prose;``view_commands`` is an optional JSON list of``[path, start, end]`` triples. See "Reply SHAPE" below for the contract. ,→ ,→ ,→ ,→ ,→ Persistence semantics (the "memory" half of your role): You are the SAME Librarian instance across every ``repo_librarian`` call in this episode. Your full conversation history is visible when you wake up -- prior tool outputs, prior file excerpts, prior ``submit`` summaries, all of it. BEFORE issuing a new bash / view command, scan your own history: if the answer is already there, do NOT re-read; quote it directly. When you do run a new command, pick one that strictly extends what you already have rather than re-fetching it. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ Handling ambiguous queries (this is real -- the main agent sometimes sends keyword-soup queries with no clear question): ,→ ,→ - First try to disambiguate from your own accumulated history and one or two well-targeted probes. If the keywords still resolve to multiple plausible interpretations, do NOT keep grinding more grep variants hoping one lands. Stop and submit a clarifying reply via``submit`` instead -- list the candidate interpretations you considered (with the file/symbol each one points at) and ask which one the agent meant. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ - This is preferable to a long grep loop because: (a) the next consultation will arrive with a sharper question, (b) your history retains the candidates you already enumerated, so the follow-up is cheap. ,→ ,→ ,→ - Clarification replies are SHORT -- the candidate list, file pointers if you have them, and the question. Do NOT include code excerpts on a clarification. ,→ ,→ Reply discipline (when the query is well-formed): - Ground every claim in a file path + line range from your tool output (or your prior history).,→ - When the main agent's query points at a behaviour or symptom, translate it into "what file / symbol owns this surface area" and reply with that location. Do NOT volunteer a diagnosis of the symptom -- that's the main agent's job. ,→ ,→ ,→ ,→ Reply SHAPE -- describe locations in``result``, attach code via``view_commands``:,→ The``submit`` tool takes TWO parameters: -``result``: short prose answer (<~ 200 tokens). File paths + line ranges + brief framing of what each region is. **Do NOT paste verbatim code into ``result``.** Bytes are bigger than your TEXT output should be. ,→ ,→ ,→ ,→ -``view_commands``: optional JSON list of``[path, start, end]`` triples. The system runs each view server-side and prepends the output to what the main agent sees. The view does NOT enter YOUR conversation history (it's executed outside the SDK turn), so your token budget for future ``repo_librarian`` calls in this episode stays lean. ,→ ,→ ,→ ,→ ,→ ,→ Three response shapes: - **Pointer (default)**: short``result`` describing the location, single-element``view_commands`` with the region you're pointing at. Example:: ,→ ,→ 14 result = ( "Found`rotation_matrix` in " "/testbed/astropy/coordinates/matrix_utilities.py ",→ "lines 30-78 -- body included below." ) view_commands ='[["/testbed/astropy/coordinates ⌋ /matrix_utilities.py", 30, 78]]',→ Pick the line range carefully so it lands on natural boundaries (class header -> next sibling, function header -> matching dedent). ,→ ,→ - **Multi-fragment**: short``result`` summarising what you found,``view_commands`` with multiple regions. Use ONLY when: ,→ ,→ * each fragment is <= ~15 lines, AND * the fragments span >= 2 different files OR >= 2 non-adjacent regions of one file, AND,→ * the main agent obviously needs ALL of them to plan their next move.,→ Example:: result = ( "Three call sites of`where_not_allclose`: one in diff.py ",→ "table comparison, two in nddata arithmetic. All quoted below.",→ ) view_commands = ( '[["/testbed/astropy/io/fits/diff.py", 1444, 1471],',→ ' ["/testbed/astropy/nddata/mixins/ndarithmeti ⌋ c.py", 220, 230],',→ ' ["/testbed/astropy/nddata/mixins/ndarithmeti ⌋ c.py", 410, 425]]',→ ) - **Clarification**:``result`` lists candidate interpretations and file pointers; ``view_commands`` omitted (or``None``). Use when the query is genuinely ambiguous. ,→ ,→ ,→ If the answer is fully reconstructable from your prior history without new tool calls, you may still call ``submit`` with``view_commands`` pointing at locations you already viewed earlier in this episode -- the system re-fetches them, you don't have to re-issue``view`` first. ,→ ,→ ,→ ,→ ,→ Pre-submit self-check (apply BEFORE every``submit`` call):,→ 1. Is``result`` PROSE only (no``def ...`` /``class ...`` / line-numbered code blocks)? If I caught myself pasting code into``result``, move it to ``view_commands`` instead. ,→ ,→ ,→ 2. Are the line ranges in``view_commands`` PRECISE (verified against my actual``view`` /``cat -n`` output)? Vague ranges like``[200, 300]`` make the main agent see the wrong region -- re-ground from output. ,→ ,→ ,→ ,→ 3. For multi-fragment``view_commands``: are the regions REALLY scattered (different files OR non-adjacent regions), or am I really showing one long block split into "fragments"? If the latter, collapse to a single``[path, start, end]`` covering the union range. ,→ ,→ ,→ ,→ ,→ 4. Did my``result`` slip into analysis / interpretation territory? Phrases to scrub before submitting:,→ - "this is a fix for issue #N" / "this was added to handle X" (historical inference -- not your job) ,→ ,→ - "the bug is here because ..." / "the issue arises when ..." (diagnosis -- not your job),→ - "the fix should ..." / "you should change this to ..." (proposal -- not your job),→ If you find any, delete them. Keep file:line framing only.,→ B.5 Tool-selection policy The block spliced into each MAS’s orchestra- tor prompt. It instructs the orchestrator to route unknown-location queries to the Librarian and to view knownfile:linepointers directly without consulting the Librarian a second time. The place- holderlibrarian_toolis replaced at MAS- instantiation time with the specific delegation tool name, such asrepo_librarianfor the vanilla MAS anddelegate_to_librarianfor HyperA- gent. Prompt for the orchestrator tool-selection policy Tool selection policy (read this BEFORE you plan): - **Decision rule**: if you ALREADY know the precise file path AND a useful line range to inspect, ``str_replace_editor view`` it directly. If you DON'T know where to look -- you have a symbol/behaviour/symptom but no file:line -- ask ``librarian_tool``. ,→ ,→ ,→ ,→ ,→ -``librarian_tool`` is your **search** tool -- it returns file paths and line ranges (and short excerpts when several fragments are scattered). Treat it as a sharper, memory-equipped grep, NOT as an analyst. Use it to ask "where is X?" / "which file owns Y?" / "give me the file:line for Z" -- never "what's the bug?" or "is this code correct?". Reasoning, diagnosis, and fix-design stay with you. ,→ ,→ ,→ ,→ ,→ ,→ ,→ - The librarian is a single long-lived instance: its conversation history accumulates across calls, so follow-ups are cheap. ,→ ,→ -``bash`` and``str_replace_editor`` are for both ACTING on the code (editing source, running tests, installing dependencies) AND READING code at known locations (``str_replace_editor view`` with a file path + line range you already have). What``bash`` is NOT is a search tool. ,→ ,→ ,→ ,→ ,→ - Continuous consultation policy: each NEW search question (a symbol you don't yet have a location for, a "where does X live?" question) is a NEW librarian call. Once the librarian has given you a path + line range, you own that location -- viewing nearby lines, the enclosing class, or an adjacent helper at a known file:line is your job, NOT another librarian call. The single biggest failure mode in BOTH directions: (a) calling the librarian once and then doing keyword grep yourself for every subsequent symbol -- do NOT do that; (b) re-asking the librarian for a region you already have a precise file:line for -- do NOT do that either, just ``view`` it. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ - Forbidden in``bash``:``find`` /``grep`` /``rg`` / ``ls`` /``tree`` /``sed`` /``awk`` /``less`` / ``more`` for symbol or pattern search across source files. (Reading a specific file you already located via``cat`` /``head`` /``tail`` is fine but ``str_replace_editor view`` with``view_range`` is preferred -- it gives you line numbers.) Searching for unknown symbols is the librarian's job. ,→ ,→ ,→ ,→ ,→ ,→ ,→ - Query phrasing: write each``librarian_tool`` query as a **lookup question**, not a bag of keywords and not an open-ended analysis request. Good shapes: "Where is <symbol> defined? I need the file path + line range.", "Which file owns <behaviour> in <surface area>?", "Locate <test name>'s file path.". Bad shapes: a keyword string with no question, or an analysis prompt like "Why does <symptom> happen?" / "What is the bug here?" -- the librarian will only return locations, not analysis. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ - Healthy turn pattern: (don't know where) librarian call -> librarian returns file:line pointer -> you ``str_replace_editor view`` to read -> reason -> edit -> run tests -> (need a NEW location? librarian again). ,→ ,→ ,→ ,→ B.6 Plan rewriting guideline The instructions we follow to derive each +Librarian plan from its baseline. The guideline en- codes two rules, namely renaming references to the 15 prior code-navigator sub-agent and rewriting any code or file location step to a Librarian delegation call. The same guideline applies across MAS, with the actual scope of changes varying by how much navigation each MAS previously routed through bash versus delegation. Prompt for the plan-rewriting guideline # Plan / Planner Prompt Rewriter (-> +librarian variant) You are rewriting a baseline MAS orchestrator / planner prompt into its **+librarian** variant. The transform replaces a navigator-style sub-agent with the persistent Repo Librarian, and rewrites the plan steps that involve code / file location so the lookup goes through the librarian. ,→ ,→ ,→ ,→ ,→ You edit ONLY the orchestrator/planner-facing prompt. Other sub-agents' prompts are out of scope.,→ --- ## INPUT FORMAT You receive four sections, separated by tagged delimiters: <previous_subagent_name> ... name of the navigator-style sub-agent being replaced (e.g. "code_navigator", "Codebase Navigator", "delegate_to_navigator") ... ,→ ,→ </previous_subagent_name> <previous_subagent_prompt> ... the full system prompt of the previous sub-agent, used to identify which of its responsibilities go beyond file/code lookup and therefore need to be redirected rather than absorbed by the librarian ... ,→ ,→ ,→ ,→ </previous_subagent_prompt> <baseline_prompt> ... the baseline plan / planner prompt to rewrite ... </baseline_prompt> <librarian_spec> ... the librarian's contract: its role, persistence semantics, query-shape rules, and what it does / does not do ... ,→ ,→ </librarian_spec> --- ## RULES ### 1. Replace the named sub-agent with the Librarian Every reference to the sub-agent name(s) in `<previous_subagent_name>` -- docstring, intern-list entry, delegation-tool name, inline mention in a numbered step -- becomes the librarian. Use a surface name that matches the baseline's own casing and tool-naming convention (`librarian`,`Repo Librarian`, `delegate_to_librarian`, etc.). Do not paraphrase any other text on the same line. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ### 2. Rewrite code/file-location steps to use the Librarian,→ Any step in the plan that asks the host to **locate, navigate, search, explore, or look up** code (find a symbol, identify affected files, map the codebase, locate call sites, find the test that exercises a behaviour) -- including post-failure debugging steps that re-locate code on a failing test -- gets rewritten so the lookup happens through the librarian. ,→ ,→ ,→ ,→ ,→ ,→ Preserve the librarian's contract exactly as stated in `<librarian_spec>`: natural-language lookup questions, persistent conversation history across calls within the episode, NEW search question = NEW librarian call, host owns the location once handed back, librarian only LOCATES (host reasons / diagnoses), no fallback to`grep` /`find` for symbol search. ,→ ,→ ,→ ,→ ,→ ,→ Steps that do **not** involve code/file location (issue analysis, synthesis, fix implementation, cleanup, submit, etc.) stay verbatim. ,→ ,→ ### 3. Redirect responsibilities that go beyond file/code lookup,→ Read`<previous_subagent_prompt>` to enumerate the responsibilities the previous sub-agent held beyond pure file/code lookup -- e.g. analyzing code purposes, mapping inter-module dependencies, summarizing architecture, characterizing call relationships. For each such responsibility, do NOT route it to the librarian (the librarian only LOCATES). Instead, fold it into the orchestrator's own analytical steps or into another sub-agent that the baseline plan already invokes for analysis/synthesis. If neither already covers it, add a short orchestrator-side step adjacent to the librarian call that performs that work on the returned excerpts. Leave the librarian call itself unchanged. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ --- ## BREVITY Every character is prefilled on every planner / orchestrator turn. Keep the rewrite within ~1.15x the baseline length. ,→ ,→ --- ## OUTPUT Return ONLY the rewritten prompt. Preserve the original formatting, section headers, bullet structure, and any verbatim blocks unaffected by the two rules. Do not add commentary before or after. ,→ ,→ ,→ B.7 Per-MAS plan rewrites The orchestrator-side planning sequences for the BOAD and HyperAgent MAS. For each MAS we reproduce the baseline plan alongside the +Librarian variant produced by applying the guide- line in Appendix B.6, with BOAD’s variant gener- ated via Claude Opus 4.6. BOAD baseline.The orchestrator’s six-step plan with step 2 delegating code mapping to the code_navigator sub-agent. Prompt for BOAD orchestrator plan 1. Use the issue_analyzer subagent to decompose the problem description into structured requirements, identify affected components, and define explicit success criteria to guide the investigation. ,→ ,→ ,→ 2. Use the code_navigator subagent to map the relevant codebase structure, focusing on files and functions identified in the analysis to understand dependencies and data flow. ,→ ,→ ,→ 3. Synthesize the structured analysis and code mapping to implement the fix, ensuring the solution addresses the root cause while adhering to the established success conditions. ,→ ,→ ,→ 16 4. Create a minimal test case or validation script to verify the fix against the reproduction criteria defined in the initial analysis. ,→ ,→ 5. After you have solved the issue, delete any test files or temporary files you created.,→ 6. Use the submit tool to submit the changes to the repository.,→ BOAD+Librarian. Steps 1, 3, 5, and 6 are byte-identical to the baseline. Step 2 is rewritten to phrase every search as a natural-language lookup question to the Librarian, and step 4 is rewritten to call the Librarian for additional location lookups after test failures. Prompt for BOAD orchestrator plan with Librarian 1. Use the issue_analyzer subagent to decompose the problem description into structured requirements, identify affected components, and define explicit success criteria to guide the investigation. ,→ ,→ ,→ 2. Use the librarian subagent to map the relevant code areas: phrase each request as a natural-language lookup question ("Where lives <symbol / behaviour>?", "Show me the body of <function>", "Locate the test that exercises <feature>"). The librarian is a single long-lived instance -- its conversation history accumulates across calls in this episode, so follow-up lookups (the caller of a symbol, subclasses that override it, adjacent helpers, sibling tests) are cheaper than starting a fresh search. Each NEW search question (a symbol or behaviour you do not yet have a file:line pointer for) is a NEW librarian call; once the librarian has given you a location, that location is yours -- view nearby lines or the enclosing class yourself rather than re-asking the librarian for it. The librarian only LOCATES code; reasoning about what to change stays with you. Call the librarian aggressively whenever a new location is needed; do not fall back to`grep` /`find` for symbol search. After exploration, propose the files and methods to fix the issue and select the most likely location to apply the change. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ 3. Synthesize the structured analysis and code mapping to implement the fix, ensuring the solution addresses the root cause while adhering to the established success conditions. ,→ ,→ ,→ 4. Write and execute targeted unit tests or integration checks to validate that the solution resolves the issue without introducing regressions. If any check fails, consult the librarian for ADDITIONAL location lookups (other call sites of a changed symbol, subclasses that override it, fixtures or sibling tests that exercise the failing path) -- phrase each as a location question. The librarian returns a pointer to the relevant code; YOU then view it, diagnose why the test fails, refine your fix, and rerun the affected tests. Do NOT fall back to fresh`grep` /`find` for symbol search -- those go through the librarian. Repeat until all checks pass. ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ ,→ 5. After you have solved the issue, delete any test files or temporary files you created.,→ 6. Use the submit tool to submit the changes to the repository.,→ HyperAgent baseline. The planner’s five-step sequence with step 2 delegating to the Codebase Navigator. Prompt for HyperAgent planner 1. Read the PR description and understand the issue. 2. Delegate to the Codebase Navigator to localize where the change must happen.,→ 3. Delegate to the Codebase Editor to apply the minimal source change.,→ 4. Delegate to the Executor to verify the fix (run the relevant tests / a reproduction script).,→ 5. Iterate as needed until the tests pass. HyperAgent+Librarian.Step 2 is rewritten to delegate to the Repo Librarian. The remaining four steps are byte-identical to the baseline. Prompt for HyperAgent planner with Li- brarian 1. Read the PR description and understand the issue. 2. Delegate to the Repo Librarian to localize where the change must happen.,→ 3. Delegate to the Codebase Editor to apply the minimal source change.,→ 4. Delegate to the Executor to verify the fix (run the relevant tests / a reproduction script).,→ 5. Iterate as needed until the tests pass. C Experiment Details This appendix records the configuration held fixed across the experiments of §5—the vLLM serving, sampling, and scaffold settings (Appendix C.1) and the caveman prompting style directive (Ap- pendix C.2). C.1 Serving and scaffold configuration Table 9 lists the vLLM serving configuration, sam- pling hyperparameters, and agent scaffold settings used in the experiments of §5. The values are held fixed across all backbones and methods so that per- method differences in token consumption reflect orchestration choices rather than serving, decoding, or scaffold variance. C.2 Caveman prompting directive The fixed style directive that the caveman prompt- ing baseline appends to the system prompts of ev- ery sub-agent and the orchestrator. The directive instructs the model to compress its visible answer text while leaving the thinking trace intact. Prompt for caveman style directive OUTPUT STYLE — caveman mode (FULL). Respond terse like smart caveman. All technical substance stays. Only fluff dies. ACTIVE every response until task done. ,→ ,→ Rules: - Drop articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. ,→ ,→ - Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for").,→ - Pattern:`[thing] [action] [reason]. [next step].` 17 SettingValue vLLM serving serving context length131,072 GPU memory utilization0.95 sampling temperature0.6 top-p0.95 top-k20 min-p0.0 presence penalty0.0 repetition penalty1.0 agent scaffold shell command timeout (min)30 tool observation truncation (chars)30,000 Table 9: vLLM serving configuration, sampling hyper- parameters, and agent scaffold settings, held identical across every backbone and method. NEVER compress / NEVER abbreviate: - Code blocks, code symbols, function names, class names, file paths, error strings, log lines, shell commands, tool-call arguments. ,→ ,→ - Anything inside`backticks`, fenced code, or quoted strings.,→ - Patch / diff content (must be byte-exact). Resume normal prose for: security warnings, irreversible-action confirmations, multi-step sequences where fragment order could be misread. ,→ ,→ Example - Normal: "The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. You should wrap it in useMemo." ,→ ,→ ,→ - Caveman: "New object ref each render. Inline object prop = new ref = re-render. Wrap in`useMemo`.",→ D Full Per-Role Breakdown This appendix reproduces the per-episode break- down of output tokens and idle-subtracted GPU energy at the granularity of each role inside Hy- perAgent (Table 10) and BOAD (Table 11). The compact main-text version (Table 6) collapses the non-replaced roles into a single “other roles” row by summing within each episode before averaging; the tables below leave every role on its own row so the reader can see the unaggregated contribution of, for example, the HyperAgent executor or the BOAD issue analyzer. E Pass Rate across Task Difficulty Table 12 stratifies pass rate by the difficulty bins of §5.2, complementing the per-episode energy re- ported there. The Librarian preserves the underly- ing MAS’s pass rate across every bin. HyperAgentHyperAgent + Librarian ModelRoleOut (K)E (kJ)Out (K)E (kJ) A3B planner9.205.039.465.35 navigator→ librarian13.927.546.023.57 editor2.841.482.811.46 executor22.7011.6924.1212.46 27B planner7.7226.637.4926.40 navigator→ librarian10.5036.634.7016.92 editor2.558.821.956.72 executor14.6649.8212.2041.46 Table 10: Per-role per-episode comparison of Hyper- Agent against its Librarian variant. We report the per- episode means of output tokens and energy at each role on the two backbones. The Librarian compresses the lookup role while leaving the other roles within10%on every metric. BOADBOAD + Librarian ModelRoleOut (K)E (kJ)Out (K)E (kJ) A3B orchestrator11.016.748.795.23 issue analyzer14.178.6314.318.62 code_navigator→ librarian13.818.541.931.08 27B orchestrator6.6624.236.0721.89 issue analyzer12.1144.4811.7943.35 code_navigator→ librarian5.6320.791.826.56 Table 11: Per-role per-episode comparison of BOAD against its Librarian variant. We report the per-episode means of output tokens and energy at each role on the two backbones. The Librarian compresses the lookup role while leaving the other roles within10%on every metric. F Librarian Invocation Frequency We examine how often the orchestrator invokes the Librarian as the search problem grows. Stratifying episodes by the difficulty bins of §5.2, we count the per-episode Librarian invocations. Figure 4 shows this mean count growing monotonically with difficulty across both backbones. We attribute the trend to the orchestrator scaling lookup frequency with the size of the search problem. 18 Reference max-input tokens (K) Method 0–32K32–64K64–96K>96K (n=36)(n=312)(n=130)(n=22) Qwen3.6-35B-A3B HyperAgent83.373.447.740.9 + Librarian86.174.751.522.7 + LastNObservation80.667.332.313.6 + Caveman77.873.150.840.9 + Caveman + Librarian86.173.150.031.8 BOAD88.976.653.836.4 + Librarian88.978.855.436.4 + LastNObservation83.371.545.418.2 + Caveman86.173.757.727.3 + Caveman + Librarian88.977.953.831.8 Qwen3.6-27B HyperAgent83.375.657.736.4 + Librarian86.175.065.445.5 + LastNObservation86.175.042.318.2 + Caveman83.373.156.240.9 + Caveman + Librarian86.172.454.645.5 BOAD86.177.660.831.8 + Librarian88.976.660.045.5 + LastNObservation88.977.255.427.3 + Caveman88.975.357.740.9 + Caveman + Librarian88.975.660.845.5 Table 12: Pass rate of the SWE agents with respect to the task difficulty. We report the pass rate of the SWE agents across difficulty classes. In all the settings, the addition of the Librarian preserves the performance. 0 32K3264K6496K>96K Reference max-input tokens (K) 0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 Mean Librarian invocations HyperAgent + Librarian HyperAgent + Caveman + Librarian BOAD + Librarian BOAD + Caveman + Librarian (a) Qwen3.6-35B-A3B 0 32K3264K6496K>96K Reference max-input tokens (K) 0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 Mean Librarian invocations (b) Qwen3.6-27B Figure 4: Mean Librarian invocations per episode across task difficulty. Each panel plots the per-episode mean Librarian invocation count for the Librarian-augmented MAS variants against the reference max-input-token bin. Bar color denotes the host family, and a hatch marks the Caveman variant. The invocation frequency grows monotonically with task difficulty in every setting. 19