FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification MELIKA SEPIDBAND, JIHO SHIN, SONG WANG, and HADI HEMMATI, York University,

arXiv:2611.13241v1 [cs.SE] 9 Nov 2026

Canada LLM-based coding agents such as Claude Code can resolve real-world repository issues, but their iterative interaction loop can be expensive. For example, a single repair may consume millions of tokens as an increasingly long trajectory is replayed at every model call. Existing approaches reduce this cost primarily by limiting, compressing, or selectively avoiding information and actions within the repair process. We investigate a complementary question: Can an agent reason about a repair at an abstract program level, rather than repeatedly operating over raw source code, to reduce both the exploration needed to identify a repair and the repeated checking needed to verify it afterward? We present FlowPlan, an abstraction-guided repair approach that structures localization, planning, and verification around per-function control-flow or data-flow graphs. The agent first localizes the candidate fault location on the program abstraction and expresses the intended repair as explicit graph deltas before modifying the concrete source. After the edit, FlowPlan reconstructs the same abstraction and compares the observed structural change with the planned one. Then, a verification checks the complete repair before termination. This process makes repair intent explicit before editing and provides a machine-checkable criterion for whether the intended structural change has been made. Across all six benchmark–model settings, FlowPlan does not significantly change resolution rate relative to the vanilla agent while reducing token consumption in every setting, significantly in five of six settings. With Claude Haiku 4.5, it uses only 0.46–0.47× the baseline tokens on SWE-bench Pro, 0.32–0.35× on SWEbench Verified, and 0.68–0.74× on SecBench; with Sonnet 5, it uses 0.72–0.76×, 0.73–0.74×, and 0.92–0.94×, respectively. The smaller reduction on SecBench reflects its substantially shorter baseline trajectories, which leave less accumulated context and post-edit work to eliminate. Overall, FlowPlan achieves the largest token reduction among the compared methods in three of the six settings and ties the strongest compared method in a fourth. Trajectory analysis shows that FlowPlan saves tokens by replacing much of the costly post-edit re-reading and testing with explicit verification and reducing per-call context. The main remaining challenges are precise fault localization and complete repair planning. CCS Concepts: • Software and its engineering → Software maintenance tools; Software verification and validation. Additional Key Words and Phrases: Coding agents, token efficiency, control-flow graph, data-flow graph, program repair

1

Introduction

LLM-based coding agents have emerged as a practical approach to repository-level software engineering tasks. Given an issue, agents such as Claude Code [4], SWE-agent [41], and OpenHands [37] search repositories, inspect source files, edit code, and execute tests to produce a patch. This capability, however, can require substantial inference cost. In our baseline runs, with Claude Haiku 4.5 on SWE-bench Pro, the vanilla Claude Code consumes an average of 3.7 million tokens per issue, 98% of which are cache reads. This cost comes directly from the agentic loop: each model call replays the conversation accumulated so far, and every tool observation enlarges it. Repair cost therefore has two drivers: the number of model calls and the context each call replays. Recent work reduces this cost in several directions. AgentDiet prunes accumulated trajectories using a second model [38]. EET retrieves prior experience and encourages earlier termination [14]. SHERLOC performs a dedicated localization stage before repair [36]. To Run or Not to Run removes Authors’ Contact Information: Melika Sepidband, melikasp@yorku.ca; Jiho Shin, shinjiho@yorku.ca; Song Wang, wangsong@yorku.ca; Hadi Hemmati, hemmati@yorku.ca, York University, Toronto, Canada.

2

Sepidband et al.

test execution [21]. SeeRepo replaces part of textual repository exploration with a visual repository graph [25]. These methods target different sources of overhead, but generally reduce or compress context or eliminate actions from the source-level repair process, leaving the agent to repeatedly inspect source code to determine where and how to edit and whether the repair has succeeded. In this work, we investigate a different direction grounded in a fundamental software-engineering principle: program abstraction. Software engineering uses abstractions to expose task-relevant program properties while suppressing lower-level details that need not be considered at every reasoning step. Control-flow graphs (CFGs), for example, expose how execution moves between program blocks, while data-flow graphs (DFGs) expose how values propagate from definitions to uses. We ask: Can using program abstraction before editing the source code reduce a coding agent’s token consumption? A coding agent reasons over source code and the context accumulated through its tool interactions. Even after locating the relevant code, it may continue reading files, inspecting diffs, and running tests while deciding how to repair the issue and when the repair is complete. We introduce FlowPlan, an abstraction-guided repair approach that uses a per-function CFG or DFG as the working level for localization, planning, and post-edit verification. Before editing, the agent anchors the candidate fault location to an element of the abstraction and expresses the intended repair as explicit graph deltas, such as adding a guard, changing a branch condition, or introducing a definition–use relation. The agent then performs the source edit using its editing tools. Afterward, FlowPlan reconstructs the same abstraction from the modified program and compares the observed structural change with the planned one. The abstraction therefore serves not merely as a compact view of code, but as the level at which the agent expresses its repair intent before editing and verifies afterward whether the resulting source change matches that intent. Figure 1 illustrates this distinction on an issue from SWE-bench Pro. Both the vanilla Claude Code and FlowPlan identify the correct file at their second model call, so the difference is not initial file localization. The baseline then spends 27 additional calls exploring related tests and fixtures before making its first edit at call 29, followed by another 21 calls repeatedly testing and checking the patch. It ultimately resolves the issue in 50 calls and 2.70M tokens. In contrast, FlowPlan focuses the repair on the CFG of the relevant function: it identifies the candidate faulty block, states the intended structural change, edits the source, and verifies that the resulting CFG matches that plan. It resolves the same issue in 17 calls and 0.53M tokens. This example reflects a broader pattern: on SWE-bench Pro with Claude Haiku 4.5, approximately two-thirds of the baseline’s tokens are consumed after the first substantive edit through repeated re-reading, diff inspection, and testing. FlowPlan organizes this process in four phases: locate, plan, edit-and-check, and verify. A final verification checks the complete repair before termination. Note that FlowPlan does not replace or restrict the agent’s ordinary file, search, editing, or shell tools. The agent can still fall back to them when additional context is needed. We evaluate FlowPlan with Claude Code and two models, Claude Haiku 4.5 and Claude Sonnet 5, on three benchmarks: SWE-bench Pro [10] and SWE-bench Verified [29] for Python program repair, and SecBench [17] for C/C++ security patching. We evaluate 158, 218, and 169 instances, respectively, sized for a 95% confidence level and a 5% margin of error. To place FlowPlan among recent token-reduction approaches, we survey 171 papers from twelve 2026 software-engineering and machine-learning venues and reproduce five methods using the same instances, models, Claude Code build, and accounting scheme while retaining their implementations, prompts, and thresholds. Across the six benchmark–model settings, FlowPlan does not significantly change resolution relative to the vanilla agent while reducing token consumption in every setting, significantly so in five of six. With Claude Haiku 4.5, it uses 0.46–0.47× the baseline tokens on SWE-bench Pro, 0.32–0.35× on SWE-bench Verified, and 0.68–0.74× on SecBench; with Sonnet 5, it uses 0.72– 0.76×, 0.73–0.74×, and 0.92–0.94×, respectively. The smaller reduction on SecBench reflects its

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

3

Issue (ansible, SWE-bench Pro) On AIX, the hardware facts report the number of cores as processor_count and the SMT threads as processor_cores, and never set processor_threads_per_core or processor_vcpus. The issue names neither the file nor the function.

Both agents open aix.py at call 2 Vanilla (Claude Code) Open aix.py (call 2)

FlowPlan

Explore tests and fixtures: 17 searches, 4 test attempts, package install

After the edit: re-run tests 9 times, write 5 mock test scripts

First edit (call 29)

STOP 50 calls 2.70M tokens resolved

CFG excerpt of AIXHardware.get_cpu_facts (12 blocks in total)

B4 L64

for line in out.splitlines()

B9 L72

cpu_facts['processor_count'] = int(i)

F

T B10 L81

data = out.split(' ')

B11 L84

return cpu_facts

F

FAULT

Locate: open aix.py (call 2), view the CFG, pin the fault to B9

Plan: predict no change to the graph

Edit, then Check: the graph did change

Re-plan: change the structure of B9; Edit; Check: matches the plan

Verify: passes → STOP 17 calls 0.53M tokens resolved

Fig. 1. Motivating example from SWE-bench Pro (ansible-a6e671db). Both agents identify the correct file at call 2, but their subsequent trajectories differ. The baseline continues repository exploration and repeated post-edit checking. FlowPlan instead focuses the repair on the control-flow graph (CFG) of the relevant function. B4–B11 denote basic blocks, L64–L84 denote line number, and T/F denote true/false control-flow branches. It anchors the candidate fault location to a block, plans the intended CFG change, edits the code, and stops once the updated CFG matches that plan. Both agents resolve the issue, but FlowPlan reduces the trajectory from 50 to 17 model calls and from 2.70M to 0.53M tokens.

substantially shorter baseline trajectories, which leave less accumulated context and post-edit work to eliminate. FlowPlan achieves the largest token reduction among the compared methods in three of the six settings and ties the strongest compared method in a fourth. Trajectory analysis shows that FlowPlan saves tokens by reducing the context replayed per call and by replacing much of the costly post-edit re-reading and testing with explicit verification. The main remaining challenges are precise fault localization on the graph and complete repair planning. This work makes the following contributions: • An abstraction-guided repair approach for coding agents. FlowPlan uses per-function control- and data-flow graphs as the level at which the agent localizes the candidate fault, expresses the intended repair as graph deltas, and verifies after editing whether the resulting source change produces the planned structural transformation. • A repair policy with an explicit completion criterion. A four-phase locate–plan–editand-check–verify policy structures how the agent uses the abstraction throughout the repair and uses graph-delta verification to determine when the intended change has been made, reducing otherwise open-ended post-edit checking. • A controlled comparison of token-reduction methods. We survey 171 papers from twelve 2026 venues and reproduce five applicable token-reduction methods alongside FlowPlan on three benchmarks and two models under the same agent environment and accounting scheme, measuring task success and token consumption broken down into input, output, cache-read, and cache-write tokens.

4

Sepidband et al.

• An analysis of protocol correctness and the sources of token savings. We evaluate each stage of the FlowPlan protocol against the reference repair and decompose token consumption by trajectory phase, model calls, and context per call, identifying where the savings arise and when they diminish. 2

Background and Related Work

2.1

Agentic Software Engineering

LLM-based coding agents solve repository-level software engineering tasks by interleaving model inference with tool use. Systems such as SWE-agent [41], OpenHands [37], AutoCodeRover [43], and Claude Code [4] allow the model to search and read repositories, edit files, and execute shell commands. After each tool call, the resulting observation is added to the conversation, and the model chooses the next action until it decides that the task is complete. Benchmarks such as SWE-bench [15], SWE-bench Verified [29], SWE-bench Pro [10], and SecBench [17] evaluate these agents on real repository issues and vulnerabilities by testing their final patches. This iterative interaction pattern also drives the agent’s token consumption. Because each model call receives the conversation accumulated so far, token usage grows with both the number of calls and the amount of context replayed at each call. Prompt caching can reduce the monetary cost of repeatedly processed prefixes, but it does not reduce the number of tokens processed. 2.2

Code Representations and Program Abstractions

A code representation makes program structure that is implicit in source text explicit, with different abstractions preserving different relations. Abstract syntax trees (ASTs) represent the syntactic structure of code, including declarations, expressions, and their nesting relationships [28]. Call graphs capture potential calling relationships between functions, while dependency graphs capture coarser-grained relations such as imports and dependencies among files or modules. Repositorylevel representations often combine several such relations to support code navigation, retrieval, and localization [5, 8, 24, 25, 30, 32, 33]. In contrast, control-flow and data-flow graphs characterize behavior within a program unit: a control-flow graph (CFG) represents the possible execution paths between basic blocks [2], while a data-flow graph (DFG) represents how values propagate from definitions to uses; program dependence graphs combine control and data dependences [11]. These are longstanding software-engineering abstractions used in program analysis and compilation. They have also been incorporated into modern code-analysis and learning systems: code property graphs combine syntactic, control-flow, and data-flow information for vulnerability analysis [40], GraphCoder retrieves completion context using statement-level control-flow and dependence relations [23], and learned code models incorporate flow information as input [1, 9, 13, 44]. 2.3

Claude Code, Skills, and MCP Tools

Claude Code is Anthropic’s command-line coding agent. Its built-in interface provides tools such as Read, Edit, Write, Bash, Grep, and Glob. In headless execution, it also reports input, output, cache-read, and cache-write tokens. We use two Claude Code extension mechanisms. First, the Model Context Protocol (MCP) [3] allows an external server to expose additional tools. Their names, descriptions, and input schemas become part of the model’s prompt prefix, and their outputs are returned as ordinary tool observations. Second, a skill packages instructions that are inserted into the conversation when invoked. FlowPlan uses an MCP server for its flow-graph tools and a skill for its repair policy (Section 3). Because MCP tool descriptions occupy the prompt prefix on every call, they contribute to token consumption even when a tool is not invoked.

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

5

Table 1. Comparison of the reproduced token-reduction methods. Stage indicates where the method intervenes in the repair trajectory. Program view is the representation exposed to the repair agent. Abstract plan indicates whether the intended repair is explicitly expressed over that representation before editing. Aux. LLM indicates additional model calls outside the main repair loop (EET uses them only offline to construct its experience base). Stop indicates whether the method provides an explicit completion criterion. Method

Stage

Program view

SHERLOC [36] AgentDiet [38] SeeRepo [25] EET [14] No-execution [21]

before repair after each step exploration start, key steps testing

file tree, imports – repository graph – –

– – – – –

✓ ✓ – offline –

– – – soft –

FlowPlan (ours)

locate, plan, verify

per-function CFG/DFG

✓

–

✓

2.4

Abstract plan Aux. LLM Stop

Token Reduction for Agentic Software Engineering

Scope and comparator selection. To identify recent approaches for comparison, we survey papers published or accepted in 2026 at twelve software-engineering and machine-learning venues: ICSE, FSE, ASE, TSE, TOSEM, NeurIPS, ICLR, ICML, AAAI, EMNLP, ISSTA, and ACL. The search was completed on 9 September 2026. For the two journals, TSE and TOSEM, which publish continuously, the search covers the papers that appeared or were accepted in 2026 up to that date. Among 171 confirmed papers, 27 treat reducing the tokens, context, cost, or interaction length of a software-engineering agent as a central contribution, and 18 release official implementations. We exclude approaches whose primary contribution is a trained model or that require model internals unavailable through Claude Code, such as token log-probabilities. Thus, we reproduce five approaches that intervene at distinct points of the repair trajectory: SHERLOC [36], AgentDiet [38], SeeRepo [25], EET [14], and To Run or Not to Run [21], hereafter No-execution. Table 1 summarizes where each method intervenes and how it differs from FlowPlan. SHERLOC [36] (EMNLP 2026) reduces pre-repair exploration through a dedicated localization agent whose findings are passed to the repair agent; we reproduce its two-stage workflow in Claude Code and include both sessions in the token accounting. AgentDiet [38] (FSE 2026) periodically uses a second LLM to rewrite and compress the accumulated trajectory; we reproduce its trigger, acceptance rule, and reflection prompt, and include the auxiliary reflection calls in the reported tokens. SeeRepo [25] (ASE 2026) replaces part of textual repository exploration with an ASTderived graph queried as images; we expose its graph builder and renderer through MCP, retain its prompting behavior, and evaluate it only on Python because the released implementation supports that language. EET [14] (ACL 2026 Findings) retrieves prior repair experience and uses confidence estimates after key events to encourage earlier termination; we retain its retrieval and stopping mechanisms. To avoid leakage, its experience base contains trajectories only from instances outside our evaluation sample: for SWE-bench Pro and SecBench, we construct it from disjoint baseline instances, while for SWE-bench Verified, we use the authors’ released non-overlapping experience base. Finally, To Run or Not to Run [21] (ISSTA 2026) reduces agent interaction by prohibiting program execution during repair; we reproduce this condition by adding the released no-execution instruction to the task prompt and withholding project dependencies. For SecBench’s C/C++ projects, we adapt only the language-specific components necessary to preserve each method’s intervention. Other related directions. The reproduced methods represent broader approaches to reducing agent cost. Context-management methods compress or selectively retain trajectory history, sometimes using learned policies [16, 19, 22, 35]. General-purpose prompt-compression techniques

6

Sepidband et al.

1 Locate Flow-graph tools

flow_of

Abstract level

Generate graph

per-function CFG or DFG

CFG or DFG of the candidate function

flow_locate

Anchor fault

pin the candidate fault on a graph element

2 Plan

3 Edit and check

4 Verify

flow_plan

flow_check

flow_verify

Plan deltas

intended repair as typed graph deltas

Check edit

rebuild the graph; observed vs. planned EXACT

CFG blocks and control flow DFG definitions and their uses

SAME_FAMILY

issue or crash report

all planned deltas matched no unplanned edits

MISMATCH

candidate fault

planned: add_guard

passes → stop

observed retry

Source-code level

Input

Verify plan

Find candidate function

from the issue description or crash report fallback: ordinary search and read tools

Edit source v = load(k) + if v is None: + return None return v.name

Output

verified, non-empty patch

Fig. 2. Overview of FlowPlan. Columns show the four repair phases, while rows separate the flow-graph tools, abstract representation, and source code. The agent localizes the fault on a CFG or DFG, plans the repair as graph deltas, edits the source, and verifies that the observed graph changes match the plan.

instead reduce individual prompts [18, 31]. Localization methods shorten repository exploration through dedicated search agents or learned retrieval policies [6, 26, 39], building on earlier work such as AutoCodeRover, OrcaLoca, and LocAgent [5, 42, 43]. Repository representations expose structural views of a code base to support navigation and reasoning [5, 24, 30, 32], while program graphs have also been widely studied as learned representations of source code [1, 13]. Finally, orthogonal work studies resource allocation rather than reducing context or actions within an unconstrained repair trajectory: fixed or adaptive turn budgets constrain how much interaction a task receives [12], budget-aware agents learn to estimate whether sufficient resources remain [20], and test-time scaling allocates computation selectively across candidate solutions [27]. FlowPlan differs primarily in how the program representation is used. Existing repository representations are typically introduced to support code discovery or navigation. After the relevant code is found, repair reasoning returns to source text. In FlowPlan, the per-function CFG or DFG serves as the abstraction on which the agent localizes the candidate fault, formulates the intended structural change, and later verifies the effect of the concrete source edit. The representation therefore supports both pre-edit reasoning and post-edit verification, rather than only retrieval. Among the reproduced methods, EET also targets termination, but it relies on the agent’s selfreported confidence, whereas FlowPlan checks whether the observed program change matches the previously stated repair intent. 3

FlowPlan

Figure 2 summarizes FlowPlan. Its central design is to perform key repair decisions at an abstract program level rather than directly over source text. Given a candidate function, a flow-graph engine constructs a per-function CFG or DFG that exposes the structural relations relevant to the repair (Section 3.1). The agent localizes the candidate fault and plans the intended repair on this abstraction before editing the concrete source. Five tools maintain the connection between the abstract repair

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

7

Table 2. The five FlowPlan tools exposed to the agent. A server provides either CFG or DFG views. The tool interface and repair policy are identical across representations. Tool

Role

flow_of Resolve a function through the symbol index and return its CFG or DFG with source locations. flow_locate Anchor the candidate fault to a validated graph element and suggest nearby valid candidates when the reference is invalid. flow_plan Record the intended repair as typed graph deltas and snapshot graph fingerprints from HEAD. flow_check Recompute an edited function’s graph and compare the change with its planned delta. flow_verify Verify the complete repair plan and detect modified functions that were not in the plan.

plan and the source changes that follow (Section 3.2), while a four-phase policy organizes their use from localization through final verification (Section 3.3). The tools are attached to an otherwise vanilla Claude Code session through the Model Context Protocol (MCP) [3]. The agent retains its file-reading, search, editing, and shell tools throughout the repair. FlowPlan therefore does not replace source-level interaction. Instead, the CFG or DFG provides an abstract working representation for localization, planning, and verification, while the agent can return to the source or execute commands whenever additional information is needed. 3.1

Per-Function Program Abstraction

FlowPlan constructs program abstraction at the granularity of individual functions. Rather than encoding the entire repository as a graph, the flow-graph engine constructs an on-demand view of the function currently under investigation. This keeps the abstraction focused on the local structure needed for repair while omitting unrelated repository content, so the agent can reason about the candidate fault and intended change before modifying the source code. For a control-flow graph (CFG), the view contains the function’s basic blocks, their source locations, and the control-flow edges between them. Edges are annotated with their roles, such as true, false, loop, return, or raise. For a data-flow graph (DFG), the view records variable definitions and the uses reached by each definition, together with their source locations. For Python, both views are derived from the abstract syntax tree. For C and C++, they are extracted from a code-property graph constructed with Joern and restricted to functions relevant to the crash stack. Each view also induces a canonical fingerprint. For a CFG, the fingerprint captures the normalized block and edge set. For a DFG, it captures the multiset of definition–use relations. FlowPlan records the fingerprint of the original function and recomputes it after the source is edited. The difference between these fingerprints defines the observed graph delta: the structural change that the edit actually introduced. Because the repair plan is expressed using the same graph vocabulary, the observed delta can be compared directly with the planned graph delta specified by the agent. Symbol index. To construct a requested abstraction, FlowPlan must first map the function reference supplied by the agent to a concrete source definition. Before each session, it therefore builds a repository-level symbol index from the instance’s base commit using tree-sitter. Each entry stores its name, qualified name, kind, file, and line range in SQLite. The index is built once per repository commit, outside the agent session and without model calls. 3.2

Flow-Graph Tools

Table 2 summarizes the five tools exposed to the agent. Together, they span the repair from initial localization to final verification. They also link the fault the agent identifies, the change it intends to make, and the structural change its edit produces.

8

Sepidband et al.

Localization. flow_of takes a function name, optionally qualified by a file, resolves it through a repository-level symbol index, and returns the corresponding flow view. Because resolution is symbol-based, an agent that already knows a candidate function from the issue description or crash report can inspect its structure without first performing a textual repository search. After inspecting the view, the agent calls flow_locate to identify the fault location: the graph element that it believes must change to repair the issue. Depending on the selected abstraction, this site may be a basic block, an edge, a definition–use relation, or a source line. flow_locate validates the supplied reference against the generated graph. This validation does not prevent the repair from proceeding when the agent localizes incorrectly. If the supplied reference is invalid, flow_locate records the attempt and returns the three nearest valid candidates so that the agent can correct the reference. After two unsuccessful attempts, the location is retained but marked as unverified. We therefore treat localization as an observable reasoning decision rather than a hard execution constraint: localization errors remain measurable without artificially terminating the repair. Planning. Once a fault location has been selected, flow_plan records the intended repair as one or more typed graph deltas. Each delta identifies the target function, an anchor line, the fault location it addresses, a rationale, and the structural operation the agent expects the edit to induce. For CFGs, the operation vocabulary includes add_guard, remove_branch, change_condition, and rewire_edge. For DFGs, operations describe additions, removals, or movements of definition– use relations. Two operations apply independently of the selected representation. no_flow_change represents a repair that modifies the source without changing the chosen flow graph. Such a delta therefore includes a source anchor against which the edit can still be checked. add_function represents a repair that introduces a function absent from the original program. When a delta is first recorded, FlowPlan snapshots the fingerprint of its target function from the repository’s HEAD state, rather than from the current working tree. This distinction is important because the agent may edit the file before invoking flow_plan. Using the version-controlled state ensures that verification still compares the final program against the pre-repair structure. Planning is cumulative rather than destructive. Subsequent calls to flow_plan merge new deltas by function and append the plan to history instead of replacing the previous plan. This preserves re-planning decisions and allows us to reconstruct how the agent’s intent evolved during the trajectory. Verification. After an edit, flow_check reconstructs the graph from the current working tree and compares its fingerprint with the snapshot of the original function. This comparison yields the observed graph delta, which is then evaluated against the corresponding planned delta. The comparison produces one of three graded outcomes. exact indicates that the planned structural operation is directly present in the observed graph delta. same_family indicates that the edit produces the intended structural effect through a related operation. For example, an edge rewiring may produce the effect anticipated by a planned condition change. mismatch indicates that the observed graph change does not match the planned delta. This graded comparison avoids treating structurally equivalent implementations as failures solely because their low-level graph operations differ. flow_verify applies the same comparison to the repair plan before termination. It additionally audits the working tree for modified functions that are absent from the plan, ensuring that verification covers the patch rather than only the most recently checked function. For an add_function delta, no original fingerprint exists at HEAD. The verifier therefore extracts the new function from the current version of its anchor file and succeeds if a valid fingerprint can be constructed.

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

3.3

9

Four-Phase Repair Policy

The graph abstraction and tools do not by themselves determine when the agent should localize, commit to a plan, or decide that the repair is complete. FlowPlan therefore operationalizes the abstraction-guided repair with a four-phase repair policy: locate, plan, edit-and-check, verify. The policy is delivered as a Claude Code skill, /flowfix, whose instructions are expanded into the initial user message. The skill is generated from a common source across benchmarks and graph views, stored outside the target repository, and verified by the evaluation harness to ensure that it is loaded in every run. The four phases are: (1) Locate. The agent first identifies the most likely faulty function using evidence already available in the issue description or crash report and calls flow_of to inspect its graph. If the view does not expose the fault, the agent may fall back to its standard search and file-reading tools, select another candidate function, and inspect its graph. Once a candidate is chosen, the agent anchors the candidate fault location using flow_locate. (2) Plan. Before editing, the agent calls flow_plan and expresses the intended repair as one or more graph deltas. The plan must cover every function the agent expects to modify and associate each delta with the fault location it is intended to address. This makes the intended structural effect explicit at the abstract level before the source code is changed. (3) Edit and check. The agent makes the smallest source edit intended to produce the planned delta and invokes flow_check on the modified function. The tool reconstructs the abstraction and checks whether the concrete edit produced the planned structural change. If the result is mismatch, the policy allows one additional edit-and-check attempt. If the second check still does not match the plan, the agent may revise the plan once before continuing. (4) Verify. Before terminating, the agent invokes flow_verify over the complete repair plan and modified working tree. If verification fails, the policy permits one corrective edit followed by one final verification. A successful verification together with a non-empty patch is the policy’s completion criterion. The policy is intentionally advisory rather than mechanically enforced. No runtime hook forces the agent to invoke a particular tool, disables its native tools, or prevents it from terminating. Instead, we record whether the agent follows each phase as part of the trajectory analysis. This preserves the behavior of the underlying coding agent while allowing the abstraction to guide its repair process without imposing a constrained execution environment. The retry limits bound the additional interaction introduced by verification. A failed check or verification should trigger a bounded attempt to reconcile the implementation with the plan, not restart an open-ended repair loop. Allowing one edit and, when necessary, one re-planning step allows the agent to recover from a mismatch while limiting the interaction that verification itself can introduce. 3.4

Why FlowPlan Is Expected to Reduce Cost

FlowPlan targets two costly parts of an agent trajectory. Before editing, reasoning over a focused per-function abstraction can reduce repeated repository exploration and the source context accumulated in the trajectory. After editing, comparing the reconstructed abstraction with the planned graph deltas provides an explicit completion criterion that can reduce repeated source inspection, diff checking, and testing. RQ3 evaluates whether these mechanisms explain the observed token savings.

10

4 4.1

Sepidband et al.

Experimental Setup Research Questions

We evaluate FlowPlan through the following research questions: • RQ1 (Effectiveness and cost). How does FlowPlan affect task success and token consumption relative to the vanilla coding agent? • RQ2 (Comparison with prior token-reduction methods). How does FlowPlan compare with existing token-reduction methods when they are evaluated on the same instances, models, agent environment, and accounting scheme? • RQ3 (Mechanism analysis). How reliably does each stage of the FlowPlan protocol perform its intended role, and where in the agent trajectory do the token savings arise? 4.2

Agent and Models

We use Claude Code version 2.1.220 with two models that differ in capability and price: Claude Haiku 4.5 and Claude Sonnet 5, both configured with low reasoning effort. Each benchmark instance is executed in a fresh headless Claude Code session for every method–model configuration, preventing conversational state from carrying across runs. Each method is run once per instance. Our baseline is the vanilla Claude Code with its default tool interface. Reproduced methods retain this interface unless their design introduces additional tools or stages (Section 2.4). For FlowPlan, we attach the flow-graph server through MCP and prepend the /flowfix skill that implements the four-phase policy in Section 3.3. CFG and DFG are evaluated as separate FlowPlan configurations. 4.3

Benchmarks

We evaluate on three benchmarks spanning repository-level Python repair and C/C++ security patching. For each benchmark, we draw a sample sized for a 95% confidence level and a 5% margin of error [7], using a fixed random seed selected before observing any experimental outcome. SWE-bench Pro [10] contains 266 public Python instances from ansible, openlibrary, and qutebrowser repositories. Our 158-instance sample contains 57, 55, and 46 instances, respectively. SWE-bench Verified [29] is the human-validated subset of 500 SWE-bench [15] instances. Our 218-instance sample spans eleven repositories, and the most frequent are django (95 instances), sympy (33), and scikit-learn and sphinx (17 each). SecBench [17] contains vulnerabilities in C/C++ projects accompanied by OSS-Fuzz sanitizer reports and proof-of-concept inputs. Given the repository and failure information, the agent must modify the program so that the proof-of-concept input no longer triggers the sanitizer while preserving behavior. We evaluate 169 of the 300 instances in the benchmark’s evaluation split. Every evaluated method receives the same task description for a given instance. For SWEbench Pro, we pass the problem_statement, requirements, and interface fields. For SWE-bench Verified, we pass the problem_statement. For SecBench, we pass the original bug report and the sanitizer report. No arm receives the reference patch or the names of the fail-to-pass tests. We evaluate every generated patch using the benchmark’s official evaluation harness. For SWEbench Pro and Verified, an instance is resolved when all fail-to-pass tests pass while the pass-to-pass tests continue to pass. For SecBench, an instance is resolved when the benchmark harness no longer observes the target sanitizer failure on the proof-of-concept input. Each session is capped at 80 turns, $2, and 25 minutes on SWE-bench, and 40 turns, $1.50, and 25 minutes on SecBench, following the benchmark evaluation settings [10, 17]. These limits are well above typical baseline usage and therefore act mainly as safeguards against unusually long runs. The same limits apply to all methods, and runs that reach a cap are graded on the patch produced at that point.

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification FlowPlan (ours)

prior methods

Claude Sonnet 5

Claude Haiku 4.5

SWE-bench Pro FlowPlan CFG

0.47

FlowPlan DFG

0.46

° not significant (permutation test, Holm)

SecBench

SWE-bench Verified

0.68

0.32

0.74 0.81

No-execution

0.35

0.68

EET

0.90

SHERLOC

0.93°

0.71 1.05°

FlowPlan CFG

0.72

0.94°

0.76

0.92°

No-execution

0.79 0.99°

0.96° 0.5×

0.73 0.74

0.75×

0.56

0.95°

1.13°

AgentDiet

0.25×

1.13

0.81

0.90°

SeeRepo

0.79

not run

FlowPlan DFG EET

0.85

1.04° 1.11

SeeRepo

SHERLOC

0.90 1.33

0.82

AgentDiet

11

1.10°

0.86°

0.89°

0.89°

0.93°

not run 1×

1.25×

0.25×

0.5×

0.75×

1×

1.08° 1.25×

0.25×

0.5×

0.75×

1×

1.25×

Fig. 3. Token consumption of each method relative to the vanilla agent, by benchmark (columns) and model (rows). Tokens include input, output, cache-read, and cache-write tokens. The baseline is 1×, and values below 1× (bars to the left) indicate fewer tokens. Faded bars and values marked ◦ do not differ significantly from the baseline under a paired permutation test of the mean difference with Holm correction. SeeRepo supports only Python and is therefore not evaluated on SecBench.

4.4

Metrics

For each session, we measure task success and token consumption. Task success indicates whether the generated patch resolves the benchmark instance under its official evaluation harness. Token consumption is the sum of four provider-reported components across all model calls required by a method: input tokens, cache-write tokens, cache-read tokens, and output tokens. Input tokens are uncached prompt tokens, cache-write tokens are prompt tokens newly stored in the cache, cache-read tokens are prompt tokens retrieved from the cache, and output tokens are generated by the model. Our accounting includes auxiliary calls, such as separate localization or reflection stages, when required by a method. We report the mean and median total tokens per instance and the mean of each token component. For comparison across methods, we normalize each method’s mean total tokens by the mean of the vanilla agent on the same instances; for example, a ratio of 0.45×means that the method uses 45% as many tokens as the baseline. All comparisons are paired by benchmark instance and two-sided. We compare task success using McNemar’s exact test. Because our primary token metric is the mean, we compare token consumption using a paired permutation test on the mean per-instance difference. Under the null hypothesis, method labels are exchangeable within each instance; we therefore randomly swap each paired observation and recompute the mean difference over 200,000 permutations. The 𝑝-value is the proportion of permuted differences at least as extreme in absolute value as the observed difference [34]. Because we compare every method in every benchmark–model setting, we apply the Holm–Bonferroni correction across all 40 token comparisons. 5 Results Table 3 reports task success and token consumption, broken down into input, output, cache-read, and cache-write tokens, for all methods, while Figure 3 compares their token ratios directly.

12

Sepidband et al.

Table 3. Task success and token consumption of FlowPlan and reproduced token-reduction methods using Claude Code at low reasoning effort. Baseline is vanilla Claude Code. Resolve rate is the percentage of resolved instances. Token columns report mean tokens per instance in thousands; Total median and Total mean aggregate the four token categories. Ratio is the method’s Total mean divided by the baseline Total mean on matched instances. Bold marks the lowest ratio per benchmark-model setting. Ratios are compared using paired two-sided permutation tests with Holm correction over 40 comparisons (𝑝 < 0.05); ◦ denotes non-significance, and † a significant resolution difference under McNemar’s exact test. SHERLOC includes localization and AgentDiet reflection calls. EET uses disjoint baseline trajectories or the released experience base for SWE-bench Verified. SeeRepo is Python-only and therefore omitted on SecBench. Claude Haiku 4.5

Method

Claude Sonnet 5

Tokens per instance (thousands)

Tokens per instance (thousands)

Resolve Input Output Cache Cache Total Total rate (%) read write median mean

Ratio Resolve Input Output Cache Cache Total Total rate (%) read write median mean

SWE-bench Pro (𝑛 = 158) Baseline 43.0 0.3 No-execution 48.1 0.2 EET 46.2 0.3 SHERLOC 48.1 0.3 AgentDiet 40.5 131.3 SeeRepo 44.9 0.3

16.8 14.1 17.0 18.0 109.2 18.5

FlowPlan CFG FlowPlan DFG

46.8 46.2

0.3 0.3

14.6 1,660 14.4 1,616

SecBench (𝑛 = 169) Baseline No-execution EET SHERLOC AgentDiet SeeRepo

29.0 31.4 31.4 32.5 29.0 –

0.1 0.1 0.1 0.1 46.6 –

FlowPlan CFG FlowPlan DFG

30.8 29.6

3,528 3,715 – 2,803 3,027 0.81 × 3,084 3,357 0.90 × 3,174 3,472 0.93 × ◦ 3,011 3,060 0.82 × 3,911 4,123 1.11 ×

52.5 50.6 63.3† 58.2 51.9 56.3

<0.1 <0.1 <0.1 <0.1 37.6 <0.1

6.5 5.7 6.3 7.3 11.7 6.0

1,118 874 1,112 964 1,192 1,074

27.8 25.5 27.7 62.5 55.5 30.2

850 1,152 – 613 905 0.79 × 843 1,146 0.99 × ◦ 807 1,034 0.90 × ◦ 1,067 1,297 1.13 × ◦ 874 1,111 0.96 × ◦

80.6 82.8

1,412 1,755 0.47 × 1,351 1,713 0.46 ×

56.3 <0.1 57.0 <0.1

6.9 7.3

798 838

30.3 30.6

616 657

835 0.72 × 876 0.76 ×

4.0 3.5 4.2 7.9 30.8 –

734 28.9 491 26.4 770 29.2 902 108.8 651 65.8 – –

501 767 – 422 521 0.68 × 572 803 1.05 × ◦ 884 1,018 1.33 × 645 794 1.04 × ◦ – – –

37.9 39.1 37.9 41.4 37.3 –

<0.1 <0.1 <0.1 <0.1 18.3 –

4.7 4.1 4.5 6.0 5.7 –

653 526 619 523 548 –

23.5 22.0 23.1 57.6 37.1 –

459 382 459 380 453 –

681 – 552 0.81 × 646 0.95 × ◦ 587 0.86 × ◦ 609 0.89 × ◦ – –

0.1 0.1

8.8 9.2

466 504

414 457

42.0 <0.1 39.6 <0.1

6.0 5.7

606 594

29.9 29.3

503 492

642 0.94 × ◦ 629 0.92 × ◦

SWE-bench Verified (𝑛 = 218) Baseline 61.0 0.3 No-execution 57.3 0.2 EET 62.8 0.3 SHERLOC 60.1 0.3 AgentDiet 58.3 94.5 SeeRepo 61.9 0.3

12.0 9.3 12.2 13.1 72.3 13.7

3,351 50.9 2,384 41.0 2,998 66.2 2,756 117.7 2,416 128.0 3,782 59.5

73.9 75.2 77.1 73.9 76.6 76.1

<0.1 <0.1 <0.1 <0.1 9.6 <0.1

3.5 2.3 3.8 4.1 4.5 3.7

781 429 856 665 708 840

18.5 15.5 19.8 43.3 26.1 25.1

578 264 600 340 521 553

803 – 447 0.56 × 879 1.10 × ◦ 713 0.89 × ◦ 749 0.93 × ◦ 869 1.08 × ◦

FlowPlan CFG FlowPlan DFG

9.4 1,021 10.2 1,108

70.6 <0.1 73.4 <0.1

4.2 4.2

560 573

20.7 20.8

407 379

585 0.73 × 598 0.74 ×

5.1

58.7 56.4

0.2 0.2

3,634 63.6 2,955 57.6 3,249 91.2 3,317 137.4 2,639 180.3 4,033 72.0

Ratio

47.9 51.1

60.7 67.2

523 0.68 × 565 0.74 ×

3,381 3,414 2,395 2,434 2,823 3,076 2,773 2,887 2,579 2,710 4,102 3,856

– 0.71 × 0.90 × 0.85 × 0.79 × 1.13 ×

710 1,091 0.32 × 765 1,185 0.35 ×

RQ1: Effectiveness and Cost

FlowPlan preserves task success. Across the twelve FlowPlan configurations (two graph views across six benchmark–model settings), resolution differences relative to the vanilla agent range from −4.6 to +4.5 percentage points, with no consistent direction. For example, with Claude Haiku 4.5, CFG increases resolution from 43.0% to 46.8% on SWE-bench Pro and from 29.0% to 30.8% on SecBench, but decreases it from 61.0% to 58.7% on SWE-bench Verified. DFG shows the same mixed pattern. None of the CFG or DFG differences are statistically significant under McNemar’s exact test. Thus, within the power of our evaluation, the token reductions reported below are not accompanied by evidence of a systematic gain or loss in repair success. FlowPlan reduces token consumption in every setting, with the largest reductions on longer trajectories. Both graph views use fewer tokens than the baseline in all twelve comparisons. With Claude Haiku 4.5, FlowPlan uses only 0.46–0.47× of the baseline tokens on SWE-bench

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

13

Pro and 0.32–0.35× on SWE-bench Verified. With Sonnet 5, it uses 0.72–0.76× on SWE-bench Pro and 0.73–0.74× on SWE-bench Verified. SecBench shows smaller reductions: 0.68–0.74× with Claude Haiku 4.5 and 0.92–0.94× with Sonnet 5. Ten of the twelve reductions are statistically significant under the paired permutation test after Holm correction (𝑝 < 0.001). The only nonsignificant comparisons are CFG and DFG with Sonnet 5 on SecBench. The pattern is consistent with the amount of trajectory available to eliminate: the largest reductions occur on the long Claude Haiku 4.5 SWE-bench sessions, whereas the smallest occur on the short Sonnet 5 SecBench sessions. CFG and DFG exhibit similar trends across the six settings, with neither abstraction consistently outperforming the other in resolution or token consumption. Reduced cache reads drive the token savings. Cache reads account for 96–98% of the vanilla agent’s tokens across all settings because each model call replays the accumulated conversation from the prompt cache. Accordingly, most of FlowPlan’s token reduction comes from fewer cache-read tokens. With Claude Haiku 4.5, cache reads fall to 0.44–0.46× of the vanilla agent on SWE-bench Pro, 0.30–0.33× on SWE-bench Verified, and 0.64–0.69× on SecBench. In contrast, cache-write tokens increase because the /flowfix skill, MCP tool descriptions, and returned graph views add new context to the session. These additional tokens offset only a small fraction of the cache-read savings on SWE-bench Pro and Verified (at most 1.3% and 1.5%, respectively), but a larger fraction on SecBench (9–16%). On SecBench, output tokens also increase because FlowPlan requires the agent to explicitly state its repair plan and graph deltas. Because SecBench trajectories are shorter, this additional overhead offsets a larger portion of the cache-read savings, resulting in smaller overall token reductions. RQ1. FlowPlan reduces token consumption across all benchmark–model settings without a statistically significant change in resolution. The reductions are significant in all but the Sonnet 5 SecBench setting, where shorter trajectories leave less room for savings. Most of the savings come from reduced cache reads. 5.2

RQ2: Comparison with Prior Token-Reduction Methods

FlowPlan provides the strongest token reductions in most settings. Figure 3 places methods on one scale. With Claude Haiku 4.5, FlowPlan uses 0.46–0.47× of the baseline tokens on SWE-bench Pro, compared with 0.81× for the strongest reproduced alternative, and 0.32–0.35× on SWE-bench Verified, compared with 0.71×. On SecBench, CFG and No-execution use 0.68× of the baseline tokens. With Sonnet 5, CFG remains lowest on SWE-bench Pro at 0.72×, while No-execution is lower on SWE-bench Verified and SecBench, where it’s the only statistically significant reduction. Overall, FlowPlan’s advantage is most pronounced on the longer Claude Haiku 4.5 trajectories. No-execution is the strongest prior method, while extra model calls and context limit the savings of others. No-execution significantly reduces token consumption in all six settings (0.56– 0.81×) and uses fewer tokens than FlowPlan in two settings, both with Sonnet 5. The remaining methods provide smaller or less consistent savings. SHERLOC’s localization stage and AgentDiet’s reflection and history-rewriting steps introduce model calls and cache writes, offsetting much of the context they remove; their total token use ranges from 0.85–1.33× and 0.79–1.13× of the baseline, respectively. EET remains close to the baseline (0.90–1.10×) and significantly reduces tokens only with Claude Haiku 4.5 on the two SWE-bench benchmarks, while SeeRepo uses 0.96–1.13× of the baseline. These results indicate that token reduction depends not only on shortening the repair context, but also on avoiding extra calls and cache updates that can cancel out those savings. The largest savings come from reducing repeated interactions rather than adding preprocessing. The two methods with the strongest overall token reductions, FlowPlan and No-execution,

14

Sepidband et al.

Issue (django-13089, SWE-bench Verified). The database cache backend sporadically fails with ’NoneType’ object is not subscriptable in _cull. Step Tool call and result Category Function localization Graph construction Graph-element localization Repair planning Plan realization Final verification

flow_of(_cull): CFG of DatabaseCache._cull, the function the fix changes 6 blocks, 7 edges, faithful to the source (excerpt below) flow_locate(db.py:272): block B5, which subscripts the fetched row

right function first faithful graph on the buggy element

flow_plan: add_guard on DatabaseCache._cull at line 272 adds if row is not None; flow_check: add_guard as planned, exact flow_verify: all deltas matched, no unplanned edit; the agent stops

matches the reference matches the plan resolved

B2 L256 if self._cull_frequency == 0: T→B3, F→B4 B4 L259 connection = connections[db] T→B5, F→exit B5 L266 cull_num = num // self._cull_frequency →exit Cost. FlowPlan: 10 model calls, 0.19M tokens. Baseline: 45 model calls, 2.32M tokens (also resolved).

Fig. 4. A session in which every protocol step is correct (FlowPlan CFG, Claude Haiku 4.5). Each step is judged against the reference patch, which adds the same guard.

both reduce substantial portions of the agent’s interaction trajectory, but in different ways. Noexecution removes repeated program execution, whereas FlowPlan uses a focused program abstraction for pre-edit reasoning and returns to the same abstraction after editing to verify the intended change. By contrast, SHERLOC, AgentDiet, and SeeRepo introduce additional localization, compression, or representation machinery whose overhead can offset the context they save. Resolution is largely unchanged across the compared methods. EET with Sonnet 5 on SWEbench Pro is the only reproduced configuration whose resolution differs significantly from the baseline, increasing from 52.5% to 63.3% (𝑝 = 0.002). No other method–benchmark–model combination shows a statistically significant resolution difference. The token comparisons can therefore generally be interpreted without a corresponding statistically detectable change in task success, with this EET result as the exception. RQ2. FlowPlan achieves the largest token reduction in three of the six benchmark–model settings and ties No-execution in a fourth. Its advantage is most pronounced on the longer Claude Haiku 4.5 trajectories. No-execution is the strongest reproduced alternative and outperforms FlowPlan in the two remaining settings, both with Sonnet 5. Overall, methods that eliminate repeated agent interactions provide larger end-to-end savings than methods whose context reductions require substantial auxiliary computation. 5.3

RQ3: Analysis

RQ1 and RQ2 establish that FlowPlan can substantially reduce token consumption without a statistically significant change in repair success. RQ3 asks why. We analyze all Claude Haiku 4.5 trajectories for both CFG and DFG views from two complementary perspectives: 1) whether each stage of the protocol performs its intended role relative to the reference patch, and 2) where tokens are consumed along the trajectory and which phases account for the savings. Does the agent follow the protocol correctly? For every session, we reconstruct the protocol decisions from the tool calls and compare each with the reference patch. Table 4 decomposes each trajectory into five observable decisions: whether flow_of reaches a function modified by the reference patch (function localization); whether the returned graph faithfully represents that function (graph construction); whether flow_locate identifies the graph element changed by the reference (graph-element localization); whether the planned graph deltas correspond to those

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

15

Table 4. RQ3: Correctness of each step of the FlowPlan protocol, judged against the reference patch (Claude Haiku 4.5; SWE-bench Pro 𝑛 = 158, SWE-bench Verified 𝑛 = 218, SecBench 𝑛 = 169). Each cell gives the number of sessions and, in parentheses, their percentage of the benchmark sample. Marks: ✓ correct, ∼ partly correct, × incorrect (deviates from the reference), ◦ not applicable because the fix lies outside what the pre-repair graph can show (new code, or no function changed), – not applicable because the step was not taken. All: the sessions of each category pooled over the three benchmarks and both graph views (𝑛 = 1,090). SWE-bench Pro Outcome Verify function localization ✓ right function first ✓ right function after search × right file, different function × different function ◦ reference only adds new code – protocol not used

CFG

DFG

SWE-bench Verified CFG

SecBench

DFG

CFG

109 (69%) 116 (73%) 120 (55%) 111 (51%) 27 (17%) 26 (16%) 58 (27%) 63 (29%) 7 (4%) 8 (5%) 11 (5%) 13 (6%) 4 (3%) 0 (0%) 14 (6%) 16 (7%) 7 (4%) 7 (4%) 15 (7%) 15 (7%) 4 (3%) 1 (1%) 0 (0%) 0 (0%)

89 (53%) 13 (8%) 24 (14%) 40 (24%) 3 (2%) 0 (0%)

DFG All 92 (54%) ✓ 842 (77%) 18 (11%) 19 (11%) × 192 (18%) 36 (21%) 3 (2%) n/a 56 (5%) 1 (1%)

Verify graph construction ✓ faithful view 108 (68%) 107 (68%) 193 (89%) 192 (88%) 143 (85%) 108 (64%) ✓ 913 (84%) ✓ faithful; reference adds new code 18 (11%) 22 (14%) 9 (4%) 13 (6%) 0 (0%) 0 (0%) × different function or empty view 20 (13%) 22 (14%) 15 (7%) 13 (6%) 26 (15%) 60 (36%) × 156 (14%) ◦ reference consists only of new code 7 (4%) 6 (4%) 1 (0%) 0 (0%) 0 (0%) 0 (0%) n/a 21 (2%) – no graph requested 5 (3%) 1 (1%) 0 (0%) 0 (0%) 0 (0%) 1 (1%) Verify graph-element localization ✓ reference-changed element × elsewhere in the graph ◦ reference inserts new code – not pinned (optional) – protocol not used or no function

80 (51%) 31 (20%) 13 (8%) 30 (19%) 4 (3%)

96 (61%) 124 (57%) 120 (55%) 42 (25%) 48 (28%) ✓ 510 (47%) 26 (16%) 68 (31%) 73 (33%) 124 (73%) 117 (69%) × 439 (40%) 13 (8%) 24 (11%) 24 (11%) 1 (1%) 1 (1%) 22 (14%) 2 (1%) 1 (0%) 0 (0%) 0 (0%) n/a 141 (13%) 1 (1%) 0 (0%) 0 (0%) 2 (1%) 3 (2%)

Verify repair planning ✓ matches reference ∼ right target, partial change × different change – no plan or no function

57 (36%) 66 (42%) 25 (16%) 10 (6%)

53 (34%) 108 (50%) 80 (51%) 21 (10%) 21 (13%) 88 (40%) 4 (3%) 1 (0%)

Verify plan realization ✓ matches plan × does not match plan – not checkable or no plan

138 (87%) 140 (89%) 207 (95%) 203 (93%) 156 (92%) 145 (86%) ✓ 989 (91%) 6 (4%) 7 (4%) 2 (1%) 6 (3%) 9 (5%) 17 (10%) × 47 (4%) 14 (9%) 11 (7%) 9 (4%) 9 (4%) 4 (2%) 7 (4%) n/a 54 (5%)

All steps agree with reference resolved

30 (19%) 16

31 (20%) 17

80 (37%) 64

99 (45%) 29 (13%) 89 (41%) 1 (0%)

69 (32%) 56

52 (31%) 52 (31%) ✓ 421 (39%) 16 (9%) 12 (7%) ∼ 224 (21%) 97 (57%) 100 (59%) × 420 (38%) 4 (2%) 5 (3%) n/a 25 (2%)

20 (12%) 11

13 (8%) 243 (22%) 7 171

induced by the reference patch (repair planning); and whether the subsequent edit matches the agent’s own plan (plan realization). For each decision, we classify a session as correct, incorrect, or not applicable. A decision is not applicable when the pre-repair graph cannot represent the reference change, such as newly introduced code, or when the agent omits an optional step; for repair planning, we additionally distinguish partly correct plans. The last column of the table pools the sessions of all three benchmarks and both graph views. Note that disagreement with the reference patch does not necessarily imply an incorrect repair: a semantically valid patch may implement the fix in a different function or through a different graph transformation. We therefore use these categories to analyze protocol behavior rather than as an alternative correctness oracle.

16

Sepidband et al.

Function localization and graph construction usually succeed, but SecBench is harder. Pooled over all sessions, function localization is correct in 77% of sessions and graph construction in 84%. On SWE-bench Pro, the agent opens a function changed by the reference patch in 86– 90% of sessions, and the returned graph faithfully represents the relevant function in 80–82%; on SWE-bench Verified, these rates are 80–82% and 93–94%. On SecBench, these rates fall to 60–65% for localization and 64–85% for graph fidelity. A major reason is the crash stack: the sanitizer identifies where the failure manifests, but the reference repair may modify a caller or another function responsible for validating the input. The agent therefore often begins from a plausible crash location even when the eventual repair lies elsewhere. Graph-element localization is the weakest localization step. Pooled over all sessions, the agent pins the graph element changed by the reference patch in only 47% of sessions. On SWEbench Pro and Verified, flow_locate identifies this element in 51–61% and 55–57% of all sessions, respectively, although this rises to 72–79% and 62–65% when the agent pins a site on a graph that actually contains the reference change. Some remaining cases cannot be pinned because the repair introduces new code rather than modifying an existing graph element. SecBench is more difficult: the agent frequently pins the crash statement reported by the sanitizer even when the repair belongs elsewhere in the function or call stack. This gap illustrates an important distinction between locating a failure symptom and locating the code that must change to remove its cause. Repair planning is also difficult, but once a plan is stated, the agent usually realizes it. On SWE-bench Pro, 78–84% of plans either match the graph change induced by the reference patch or capture part of that change in the correct function. On SWE-bench Verified and SecBench, however, 40–59% of plans describe a different graph change. Some differences reflect genuine planning errors, while others are alternative repairs: for example, 19 of the 97 SecBench CFG sessions whose plan differs from the reference still resolve the vulnerability. In contrast, plan realization is highly reliable: once a plan exists, flow_check confirms that the edit matches it in 86–95% of sessions across all three benchmarks. Pooled over all sessions, 59% of plans match the reference or are partly correct, whereas 91% of edits realize the agent’s plan. The main difficulty is therefore formulating the correct repair at the abstract level. Once that intent has been made explicit, the agent usually succeeds in carrying it out in the concrete source code. End-to-end protocol correctness is associated with substantially higher repair success. Every step agrees with the reference in 19–20% of SWE-bench Pro sessions, 32–37% of SWE-bench Verified sessions, and 8–12% of SecBench sessions, depending on graph view. These end-to-end correct trajectories resolve 53–81% of their instances, compared with 28–46% among the remaining sessions. This shows that the protocol’s intermediate decisions are meaningful indicators of whether the repair is on track. Figure 4 illustrates one such trajectory: FlowPlan identifies the relevant function, pins the faulty block, plans the guard introduced by the reference patch, verifies that the edit produces that change, and terminates after 10 calls and 0.19M tokens, compared with 45 calls and 2.32M tokens for the also-successful baseline. RQ3 (protocol correctness). The agent usually reaches a function changed by the reference patch (77% of sessions) and obtains a faithful graph of it (84%), and once it records a repair plan, the subsequent edit realizes that plan in 91% of sessions. The more difficult steps are identifying the exact graph element to change and formulating a plan that matches the reference repair. Where are the tokens spent and saved? The token cost of a session is the number of model calls times the context each call replays. To attribute it, we split every baseline session at its first edit into a localization phase and an edit-and-check phase, and assign every FlowPlan call to the protocol phase of its tool call (Figure 5).

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

SWE-bench Pro (n=158) 1.20M

Baseline

SWE-bench Verified (n=218) 3.71M, 54 calls

2.42M

1.15M

0.55M

0.96M

1.76M, 41 calls (0.47×)

0.48M

0.48M

FlowPlan DFG

0.54M

0.93M

1.71M, 40 calls (0.46×)

0.47M

0.57M

1M

2M

3M

4M

5M

0M

3.41M, 55 calls

2.19M

FlowPlan CFG

0M

17

1M

1.09M, 33 calls (0.32×) 1.19M, 34 calls (0.35×) 2M

3M

4M

SecBench (n=169) 0.36M

Baseline FlowPlan CFG

0.21M

FlowPlan DFG

0.24M

0M

0.2M

0.36M 0.19M 0.17M

0.4M

0.77M, 15 calls

0.52M, 17 calls (0.68×) 0.56M, 18 calls (0.74×) 0.6M

0.8M

Mean tokens per session, by phase Localization Verification Planning Other calls Edit and check

1M

Fig. 5. RQ3: where tokens are consumed (Claude Haiku 4.5, both FlowPlan views). Mean tokens per session are decomposed by trajectory phase. Baseline sessions are split at the first edit. FlowPlan calls are assigned to their protocol phase. Labels report total tokens, mean model calls, and the ratio to the baseline.

Most SWE-bench savings arise after the first edit. In the vanilla agent, roughly two-thirds of the total tokens on SWE-bench Pro and Verified are consumed after the first substantive edit: 2.42M and 2.19M tokens per session, respectively. This post-edit tail contains about 31 additional model calls in each benchmark, during which the agent repeatedly re-reads source files, inspects the diff, executes tests, and performs further checks before deciding to stop. Because these interactions occur late in the trajectory, they are particularly expensive: each call replays accumulated context. With CFG, FlowPlan reduces this phase to 18 and 12 calls and to 0.96M and 0.48M tokens, respectively. Consequently, the post-edit phase alone accounts for 75% of the total token reduction on Pro and 74% on Verified. DFG exhibits the same pattern, consuming 0.93M and 0.57M tokens after the first edit, with 75% and 73% of its savings originating in this phase. The reduction therefore comes not merely from making individual observations smaller, but from shortening an otherwise long and increasingly expensive verification tail: once flow_check establishes whether an edit produces the planned delta and flow_verify confirms the complete plan, the agent has an explicit completion criterion instead of continuing with repeated source inspection, diff checking, and test execution. FlowPlan also reduces the exploratory prefix, while planning and verification add comparatively little overhead. With CFG, pre-edit token consumption falls from 1.20M to 0.55M on SWE-bench Pro and from 1.15M to 0.48M on Verified. The agent reaches the relevant code in fewer calls, and per-function graph observations introduce less accumulated context than repeated source-file and shell observations. The additional planning and verification phases require only 2.8–3.7 model calls and 0.08–0.17M tokens per session, less than one tenth of the tokens they ultimately save. Thus, the largest reduction does not come from making the new protocol itself cheaper, but from the larger exploratory and post-edit loops that the protocol prevents. SecBench explains when the mechanism has less room to help. The baseline SecBench trajectory is only about 15 calls long and divides its token use relatively evenly before and after the first edit. FlowPlan therefore cannot remove a long post-edit tail: planning and verification instead increase the trajectory slightly to about 17–18 calls. Its token reduction comes primarily from smaller contexts per call(about 31K tokens versus 51K for the baseline) which reduces localization and post-edit consumption to 49–68% of their baseline levels. This explains why FlowPlan still lowers mean tokens on SecBench but achieves much smaller gains than on SWE-bench, particularly with Sonnet 5, where the difference is not statistically significant.

18

Sepidband et al.

RQ3 (token savings). Most savings come from shortening the trajectory. After the first edit, flow_check and flow_verify replace much of the baseline’s re-reading, diff inspection, and testing, accounting for 75% of the reduction on SWE-bench Pro and 73–74% on SWE-bench Verified. FlowPlan also reduces pre-edit exploration, while its planning and verification cost is small relative to the savings. On SecBench, shorter trajectories leave less post-edit work to remove, so savings mainly come from reducing the context replayed by each model call. 6

Threats to Validity

Each method is run once per instance, so outcomes may be affected by model nondeterminism. We mitigate this by evaluating methods on the same instances and using paired tests (McNemar’s test for resolution and a permutation test of the mean difference for token consumption). Repeated runs would better estimate variability but would substantially increase the cost of evaluating multiple methods, models, and benchmarks. Our comparison with prior methods depends on reproduction fidelity. We retain released implementations, prompts, thresholds, and method-specific behavior where possible, but some approaches require integration or language-specific adaptation to run in a common Claude Code environment. Their absolute performance may therefore differ from the original studies, although evaluating all methods on the same instances, models, agent build, and accounting scheme supports consistent within-study comparisons. FlowPlan uses CFGs and DFGs as repair abstractions, which may omit information needed for some fixes, such as crossfunction context, semantics not captured by control or data flow, or newly introduced code. We therefore retain the agent’s ordinary source-reading, search, and execution tools when the graph is insufficient. Finally, our results are limited to Claude Code, two models from the same provider, and three benchmarks covering Python repair and C/C++ security patching. Other agents, models, reasoning settings, languages, or tasks may exhibit different trajectories and savings. Our sampling targets a 95% confidence level and 5% margin of error within each benchmark, but does not establish generalization beyond those benchmarks. 7 Conclusion We presented FlowPlan, an abstraction-guided approach that structures coding-agent repair around per-function control- and data-flow graphs. FlowPlan uses the graph as a common abstraction for fault localization, repair planning, and post-edit verification: the agent anchors the candidate fault location to the graph, expresses its intended repair as typed graph deltas, and verifies that the resulting program structure matches those deltas before terminating. Across Claude Code, two models, and three benchmarks, we find no statistically significant change in repair success relative to the vanilla agent, while FlowPlan reduces token consumption in every benchmark– model setting and significantly in five of six. With Claude Haiku 4.5, it uses 0.46–0.47× of the baseline tokens on SWE-bench Pro and 0.32–0.35× on SWE-bench Verified; with Sonnet 5, it uses 0.72–0.76× and 0.73–0.74×, respectively. It achieves the largest token reduction among the five reproduced 2026 methods in three of six settings and ties the strongest of them in a fourth. The trajectory analysis explains where these savings arise: FlowPlan reduces pre-edit exploration, and after the first edit, where explicit plan verification replaces much of the baseline’s repeated re-reading, diff inspection, and testing, it achieves 75% of its token reduction on SWE-bench Pro and 73–74% on SWE-bench Verified. The benefit is smaller on short SecBench trajectories, where there is less interaction to eliminate and the cache writes that FlowPlan adds offset a larger share of the savings. More broadly, our results suggest that reducing coding-agent cost requires controlling not only what information enters the context, but also how the repair trajectory progresses and when the agent has sufficient evidence to stop.

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

19

Data Availability A replication package is available at https://github.com/MelikaSepidband/FlowPlan. It contains the FlowPlan tools and the /flowfix skill, the evaluation harness, our reproductions of the five compared methods, and the benchmark samples together with the sampling seed. References [1] Miltiadis Allamanis, Marc Brockschmidt, and Mahmoud Khademi. 2017. Learning to represent programs with graphs. arXiv preprint arXiv:1711.00740 (2017). [2] Frances E. Allen. 1970. Control Flow Analysis. In Proceedings of a Symposium on Compiler Optimization (SIGPLAN Notices, Vol. 5). ACM, 1–19. doi:10.1145/390013.808479 [3] Anthropic. 2024. Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol. Accessed: 2026-06-30. [4] Anthropic. 2026. Claude Code Overview. https://docs.anthropic.com/en/docs/claude-code/overview. Accessed 2026-03-30. [5] Zhaoling Chen, Xiangru Tang, Gangda Deng, Fang Wu, Jialong Wu, Zhiwei Jiang, Viktor Prasanna, Arman Cohan, and Xingyao Wang. 2025. LocAgent: Graph-Guided LLM Agents for Code Localization. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (ACL). [6] Seunghyuk Cho, Sunghyun Choi, Jaeseung Heo, Youngbin Choi, Saemi Moon, MoonJeong Park, and Dongwoo Kim. 2026. Long Live the Librarian! A Persistent Search Sub-Agent for Energy-Efficient Multi-Agent Software Engineering Systems. arXiv preprint arXiv:2605.27787 (2026). [7] William G. Cochran. 1977. Sampling Techniques (3 ed.). John Wiley & Sons, New York. [8] Colbymchenry. 2026. Understand any codebase as a graph. https://colbymchenry.github.io/codegraph/. Accessed: 2026-06-24. [9] Chris Cummins, Zacharias V Fisches, Tal Ben-Nun, Torsten Hoefler, Michael FP O’Boyle, and Hugh Leather. 2021. Programl: A graph-based program representation for data flow analysis and compiler optimizations. In International Conference on Machine Learning. PMLR, 2244–2253. [10] Xiang Deng, Jeff Da, Edwin Pan, Yannis Yiming He, Charles Ide, Kanak Garg, Niklas Lauffer, Andrew Park, Nitin Pasari, Chetan Rane, et al. 2025. Swe-bench pro: Can ai agents solve long-horizon software engineering tasks? arXiv preprint arXiv:2509.16941 (2025). [11] Jeanne Ferrante, Karl J Ottenstein, and Joe D Warren. 1987. The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems (TOPLAS) 9, 3 (1987), 319–349. [12] Pengfei Gao and Chao Peng. 2026. More with Less: An Empirical Study of Turn-Control Strategies for Efficient Coding Agents. In Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE). arXiv:2510.16786. [13] Daya Guo, Shuo Ren, Shuai Lu, Zhangyin Feng, Duyu Tang, Shujie Liu, Long Zhou, Nan Duan, Alexey Svyatkovskiy, Shengyu Fu, et al. 2020. Graphcodebert: Pre-training code representations with data flow. arXiv preprint arXiv:2009.08366 (2020). [14] Yaoqi Guo, Ying Xiao, Jie M. Zhang, Mark Harman, Yiling Lou, Yang Liu, and Zhenpeng Chen. 2026. EET: ExperienceDriven Early Termination for Cost-Efficient Software Engineering Agents. In Findings of the Association for Computational Linguistics: ACL 2026. doi:10.18653/v1/2026.findings-acl.1652 arXiv:2601.05777. [15] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. Swe-bench: Can language models resolve real-world github issues?, 2024. URL https://arxiv. org/abs/2310.06770 7 (2023). [16] Minki Kang, Wei-Ning Chen, Dongge Han, Huseyin Inan, Lukas Wutschitz, Yanzhi Chen, Robert A. Sim, and Saravanakumar Rajmohan. 2026. ACON: Optimizing Context Compression for Long-horizon LLM Agents. In Proceedings of the International Conference on Machine Learning (ICML). arXiv:2510.00615. [17] Hwiwon Lee, Ziqi Zhang, Hanxiao Lu, and Lingming Zhang. 2026. Sec-bench: Automated benchmarking of llm agents on real-world software security tasks. Advances in Neural Information Processing Systems 38 (2026), 116342–116378. [18] Yucheng Li, Bo Dong, Frank Guerin, and Chenghua Lin. 2023. Compressing context to enhance inference efficiency of large language models. In Proceedings of the 2023 conference on empirical methods in natural language processing. 6342–6353. [19] Shuquan Lian, Juncheng Liu, Yazhe Chen, Yuhong Chen, and Hui Li. 2026. SWE-AGILE: A Software Agent Framework for Efficiently Managing Dynamic Reasoning Context. In Findings of the Association for Computational Linguistics: ACL 2026. doi:10.18653/v1/2026.findings-acl.868 [20] Yuxiang Lin, Zihan Wang, Mengyang Liu, Yuxuan Shan, Longju Bai, Junyao Zhang, Xing Jin, Boshan Chen, Jinyan Su, Xingyao Wang, et al. 2026. BAGEN: Are LLM Agents Budget-Aware? arXiv preprint arXiv:2606.00198 (2026).

20

Sepidband et al.

[21] Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, and Li Li. 2026. To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair. In Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). arXiv:2606.26978. [22] Shukai Liu, Bo Jiang, Jian Yang, Yizhi Li, Jinyang Guo, Xianglong Liu, and Bryan Dai. 2026. Context as a Tool: Context Management for Long-Horizon SWE-Agents. In Findings of the Association for Computational Linguistics: ACL 2026. doi:10.18653/v1/2026.findings-acl.1032 [23] Wei Liu, Ailun Yu, Daoguang Zan, Bo Shen, Wei Zhang, Haiyan Zhao, Zhi Jin, and Qianxiang Wang. 2024. Graphcoder: Enhancing repository-level code completion via code context graph-based retrieval and language model. arXiv preprint arXiv:2406.07003 (2024). [24] Jane Luo, Chengyu Yin, Xin Zhang, Qingtao Li, Steven Liu, Yiming Huang, Jie Wu, Hao Liu, Yangyu Huang, Yu Kang, et al. 2026. Closing the Loop: Universal Repository Representation with RPG-Encoder. arXiv preprint arXiv:2602.02084 (2026). [25] Dongjian Ma, Silin Chen, Yufei Yang, Yuling Shi, Yanfu Yan, and Xiaodong Gu. 2026. LLM Agents Can See Code Repositories. In Proceedings of the IEEE/ACM International Conference on Automated Software Engineering (ASE). arXiv:2606.14061. [26] Md Afif Al Mamun and Gias Uddin. 2026. BLAgent: Agentic RAG for File-Level Bug Localization. ACM Transactions on Software Engineering and Methodology (2026). [27] Chenhui Mao, Yuanting Lei, Zhixiang Wei, Ming Liang, Zhixiang Wang, Jingxuan Xu, Dajun Chen, Wei Jiang, and Yong Li. 2026. EGSS: Entropy-guided Stepwise Scaling for Reliable Software Engineering. In Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 29481–29499. [28] Lili Mou, Ge Li, Lu Zhang, Tao Wang, and Zhi Jin. 2016. Convolutional neural networks over tree structures for programming language processing. In Proceedings of the AAAI conference on artificial intelligence, Vol. 30. [29] OpenAI. 2024. Introducing SWE-bench Verified. https://openai.com/index/introducing-swe-bench-verified/. Accessed: 2026-09-29. [30] Siru Ouyang, Wenhao Yu, Kaixin Ma, Zilin Xiao, Zhihan Zhang, Mengzhao Jia, Jiawei Han, Hongming Zhang, and Dong Yu. 2025. Repograph: Enhancing ai software engineering with repository-level code graph. In International Conference on Learning Representations, Vol. 2025. 30098–30121. [31] Zhuoshi Pan, Qianhui Wu, Huiqiang Jiang, Menglin Xia, Xufang Luo, Jue Zhang, Qingwei Lin, Victor Rühle, Yuqing Yang, Chin-Yew Lin, et al. 2024. Llmlingua-2: Data distillation for efficient and faithful task-agnostic prompt compression. In Findings of the Association for Computational Linguistics: ACL 2024. 963–981. [32] Shahd Seddik and Fatemeh Fard. 2026. ARISE: A Repository-level Graph Representation and Toolset for Agentic Fault Localization and Program Repair. arXiv preprint arXiv:2605.03117 (2026). [33] Melika Sepidband, Jiho Shin, Song Wang, and Hadi Hemmati. 2026. How Should Agents See Code? Rethinking Code Representations for Agentic Software Engineering. arXiv preprint arXiv:2611.07286 (2026). [34] Mark D Smucker, James Allan, and Ben Carterette. 2007. A comparison of statistical significance tests for information retrieval evaluation. In Proceedings of the sixteenth ACM conference on Conference on information and knowledge management. 623–632. [35] Weiwei Sun, Lu Miao, Zhan Ling, Kang Liu, Xuesong Yao, Yiming Yang, and Jiecao Chen. 2026. Scaling LongHorizon LLM Agent via Context-Folding. In Proceedings of the International Conference on Machine Learning (ICML). arXiv:2510.11967. [36] Hovhannes Tamoyan, Sean Narenthiran, Erik Arakelyan, Mira Mezini, and Boris Ginsburg. 2026. SHERLOC: Structured Diagnostic Localization for Code Repair Agents. In Proceedings of the Conference on Empirical Methods in Natural Language Processing (EMNLP). arXiv:2606.24820. [37] Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. 2025. Openhands: An open platform for ai software developers as generalist agents. In International Conference on Learning Representations, Vol. 2025. 65882–65919. [38] Yuan-An Xiao, Pengfei Gao, Chao Peng, and Yingfei Xiong. 2026. Reducing Cost of LLM Agents with Trajectory Reduction. In Proceedings of the ACM International Conference on the Foundations of Software Engineering (FSE). doi:10.1145/3797084 arXiv:2509.23586. [39] Ke Xu, Siyang Xiao, Ming Liang, Yichen Yu, Zhixiang Wang, Jingxuan Xu, Dajun Chen, Wei Jiang, and Yong Li. 2026. FuseSearch: Learning Adaptive Parallel Execution for Efficient Code Localization. In Findings of the Association for Computational Linguistics: ACL 2026. arXiv:2601.19568. [40] Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. 2014. Modeling and discovering vulnerabilities with code property graphs. In 2014 IEEE symposium on security and privacy. IEEE, 590–604. [41] John Yang, Carlos Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (2024), 50528–50652.

FlowPlan: Reducing the Token Cost of Coding Agents with Abstraction-Guided Planning and Verification

21

[42] Zhongming Yu, Hejia Zhang, Yujie Zhao, Hanxian Huang, Matrix Yao, Ke Ding, and Jishen Zhao. 2025. Orcaloca: An llm agent framework for software issue localization. arXiv preprint arXiv:2502.00350 (2025). [43] Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Autocoderover: Autonomous program improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1592–1604. [44] Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. 2019. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks. Advances in neural information processing systems 32 (2019).

Related documents

• The Role of Agentic Instruction Categories for Code Generation: A Study of Five Python Libraries#1356757
• The Role of Agentic Instruction Categories for Code Generation: A Study of Five Python Libraries#1348915
• Evaluating Agentic Code Repair Capabilities in Distributed Systems#609283
• Evaluating Agentic Code Repair Capabilities in Distributed Systems#459635
• When Passing Tests Hides Vulnerabilities: An Empirical Study of Silent Failures in Agentic Systems#997554