FastContext: Training Efficient Repository Explorer for Coding Agents
Shaoqiu Zhang, Maoquan Wang, Yuling Shi, Yuhang Wang, Xiaodong Gu, Yongqiang Yao, Tori Gong, Sheng Chen, Rao Fu, Anisha Agarwal, Spandan Grag, Gabriel Ryan, Colin Merkel, Yufan Huang, Shengyu Fu
FastContext delegates repository exploration to a specialized subagent, reducing main-agent token costs by up to 60%.
How can we reduce the token-heavy repository exploration bottleneck in LLM coding agents by offloading search to a specialized, lightweight subagent?
Coding agents spend nearly half their token budget and many sequential turns just searching for relevant code, often polluting their context with irrelevant snippets that hinder reasoning. FastContext is a dedicated exploration subagent that separates repository search from the main solver: it performs parallel tool calls and returns only a compact list of file paths and line ranges as focused evidence. Integrating this subagent into Mini-SWE-Agent improves end-to-end resolution rates by up to 5.5% while cutting main-agent token consumption by up to 60% across major benchmarks.
Paper Primer
FastContext functions as a runtime delegation mechanism: the main agent invokes the explorer with a natural-language query, and the explorer uses read-only tools (READ, GLOB, GREP) to gather evidence. The core move is the output contract: the explorer compresses its findings into a structured `<final_answer>` block, acting like a librarian who retrieves only the relevant pages rather than the entire bookshelf.
FastContext significantly improves end-to-end resolution accuracy.
Evaluations on SWE-bench Pro show GPT-5.4 resolution rates increasing from 46.0% to 51.5%.
Delegating exploration drastically reduces main-agent token consumption.
On SWE-QA, main-agent token usage dropped by 60.3% for GPT-5.4 compared to direct solving.
The authors train the explorer in two stages: Supervised Fine-Tuning (SFT) on reference-model trajectories to learn tool-use patterns, followed by Reinforcement Learning (RL) using task-grounded rewards to align the explorer's citations with the code regions actually needed to fix the issue.
Why is a separate subagent necessary instead of just letting the main agent search more efficiently?
Main agents often accumulate irrelevant context during long, sequential exploration turns, which pollutes their history and forces them to reason over noisy data. Delegating this to a specialized subagent keeps the main agent's context clean and focused on the actual fix.
Does the explorer's own token usage negate the savings achieved by the main agent?
No; the explorer's overhead is minimal. In a conservative API-based cost audit, the explorer accounted for only 2.1% of the total system token cost, while the net system-wide savings remained substantial.
Repository exploration should be treated as a modular, trainable component of coding agents. By offloading navigation to a lightweight explorer, developers can improve both the accuracy and the cost-efficiency of their agentic workflows.
The Repository Exploration Bottleneck
FastContext isolates repository search to cut cost and boost coding‑agent accuracy.
Coding agents excel at software‑engineering tasks, yet they spend a large share of their compute re‑processing repository contents. The same model that solves the problem also performs exhaustive reads and searches, polluting its context with irrelevant snippets and inflating token budgets.
When a coding agent must locate the right file or function, it first scans many unrelated parts of the codebase, consuming tokens that could otherwise be spent on reasoning about the actual fix.
Preliminary analysis of Mini‑SWE‑Agent trajectories confirms the bottleneck: agents start editing only after turn 8.47 on average, after six sequential exploration turns and roughly 15.5 tool calls. Unresolved instances require even more pre‑edit exploration (8.34 turns vs. 6.67 for resolved), highlighting the cost of noisy search.
**Figure 1.** SWE-bench Multilingual and SWE-QA score versus main-model token usage, where FastContext shifts coding agents toward a better score–token tradeoff: cost less and archive more.
**Figure 2.** Trajectory analysis of GPT-5.4-high with Mini-SWE-Agent. Left: reading and searching dominate both tool-use turns and frontier-model prompt-token usage across the full trajectory. Right: before the first edit, agents execute many exploration tool calls across multiple sequential exploration turns, motivating an exploration component that can issue parallel tool calls outside the main solver trajectory.
The cost‑performance tradeoff in coding agents improves when repository exploration is delegated to a specialized subagent.
Performance and Efficiency Results
FastContext slashes main‑agent token usage while boosting benchmark success.
We evaluate FastContext on three end‑to‑end benchmarks (SWE‑bench Multilingual, SWE‑bench Pro, SWE‑QA) using Mini‑SWE‑Agent as the terminal scaffold and three main agents (GPT‑5.4, GLM‑5.1, Kimi‑K2.6). For each main agent we compare direct solving with FastContext‑augmented runs, including same‑model exploration and trained explorers (30B‑SFT, 4B‑SFT, 4B‑RL). Token counts and turns are reported for the main‑agent trajectory only.
FastContext raises end‑to‑end success, with GPT‑5.4 gaining +5.5 points on SWE‑bench Pro.
Table 1 shows the score rising from 46.0 to 51.5 when FastContext is added.
**Figure 4.** Breakdown of GPT-5.4 main-agent total tokens before and after adding FastContext with the FC-4B-RL explorer. Each panel compares direct solving against FastContext-augmented solving on one benchmark, with tokens grouped by action category. FastContext substantially reduces main-agent context consumption, especially from file reading and code search, while adding only a small FastContext invocation overhead.
Ablation studies reveal that trained FastContext explorers dominate same‑model exploration. For GPT‑5.4 on SWE‑bench Multilingual, same‑model exploration scores 73.3 with 379 k tokens, whereas 30B‑SFT reaches 75.0 with 356 k tokens and 4B‑RL attains 74.7 with 338 k tokens.
**Figure 5.** Per-instance GPT-5.4 main-agent total-token distributions on SWE-bench Multilingual. Each panel compares direct solving against one FastContext-augmented setting.
Standalone exploration quality is measured on a patch‑localization benchmark (Table 2). FastContext variants achieve the highest F1 scores at file and module granularity (e.g., 73.71 % file‑level F1 for 30B‑SFT), confirming that the end‑to‑end gains stem from better evidence recovery. RL fine‑tuning further improves the compact 4B explorer, especially in recall.
FastContext delivers sizable token reductions while simultaneously raising task success.
Training the Explorer
Training pipeline and data for SFT and RL stages, with ablation insights.
This section details how the two training stages—Supervised Fine‑Tuning (SFT) and Reinforcement Learning (RL)—are built, what data they consume, and how the reward shaping drives the final policy.
After the explorer policy is warmed up with SFT, RL fine‑tunes it to maximize a task‑specific reward that balances citation quality, tool usage, and parallelism constraints.
How does Task‑Grounded Policy Refinement differ from a vanilla RL fine‑tuning run?
Standard RL typically optimizes a single scalar reward (e.g., task success) and ignores output format. Here the reward is augmented with a hard penalty for malformed citations and a modest bonus for keeping parallel tool calls between three and six, which directly enforces the citation‑format constraints required at inference time.
Construct the SFT corpus (2,954 rows) by extracting top‑level directory listings, tool schemas, and multi‑turn messages from Sonnet 4.6 exploration traces.
Train the 4 B and 30 B explorers on the SFT data for three epochs using Adam with learning rate $10^{-5}$, cosine decay to $10^{-6}$, warmup fraction 0.1, weight decay 0.1, and no dropout.
Convert the distributed SFT checkpoints to HuggingFace format for downstream RL initialization.
Build the RL corpus (400 prompts) by pairing each query with a
Run RL rollouts with the same tool set, allowing up to eight model turns, temperature 1.0, and 16 sampled trajectories per prompt; collect raw reward and format‑penalty signals.
Fine‑tune the policy with GRPO (global batch size 32, rollout batch size 2, 1,000 rollout steps) using Adam with learning rate $10^{-6}$, clipping $0.2$–$0.28$, and no entropy bonus.
**Figure 6.** Training curves for the reported FastContext models. Left: supervised fine-tuning loss during policy initialization. Right: reinforcement-learning reward during task-grounded policy refinement.
System Integration and Accounting
FastContext is wired into Mini‑SWE‑Agent to off‑load costly repository searches.
Coding agents waste most of their compute re‑processing tokens during inefficient repository exploration. FastContext eliminates this waste by delegating the broad search to a lightweight sub‑agent, letting the main solver focus on concise evidence.
It is a coding assistant that keeps the heavy‑weight reasoning model lean by calling FastContext for a one‑shot repository lookup and then operating only on the returned file snippets.
How does Mini‑SWE‑Agent differ from a standard coding agent that embeds repository search directly?
Standard agents interleave search tokens with their own reasoning, inflating the context window each turn. Mini‑SWE‑Agent isolates the search in FastContext, so the main model never carries the large, noisy search transcript; it only sees a distilled evidence list, dramatically reducing token load.
Task 1: main‑agent uses 150 k tokens for its own reasoning.
FastContext call adds 102 k tokens (100 k prompt + 2 k completion) to the sub‑agent log.
Task 2: main‑agent uses 140 k tokens; FastContext adds another 102 k tokens.
Total main‑agent tokens = 290 k; total explorer tokens = 204 k.
Because only the main‑agent tokens count toward the primary cost metric, the system saves 204 k tokens of frontier‑model context.
The explorer’s token overhead is isolated from the main model’s context budget, so even frequent calls barely affect the primary cost accounting.
This table compares the token usage and API costs for different components of a system, showing the total augmented cost and the net savings achieved.
The interface is deliberately asymmetric: the explorer spends its own turns searching broadly, while the main solver sees only a compact evidence list and can proceed with focused reads. Token accounting therefore measures only the main‑agent trajectory, which is the metric of interest for frontier‑model efficiency.
End-to-End Case Studies
FastContext slashes API cost and token use across real‑world bug fixes.
FastContext cuts the API cost of a GPT‑5.4 run by \$73.55 (≈26 % lower) on SWE‑bench Multilingual.
Figure 7 shows direct‑agent cost $282.47 versus \$208.92 with FastContext.
We now examine three concrete bug‑fix trajectories to see how FastContext reshapes token consumption and exploration effort.
FastContext reduces main‑agent tokens by 258 k (≈46 % drop) on the fastlane__fastlane‑20975 issue.
Tokens fall from 560.8 k to 302.8 k after FastContext provides three focused file‑line ranges.
FastContext trims main‑agent tokens by 626.3 k (≈73 % drop) on sharkdp__bat‑2201.
Tokens shrink from 856.7 k to 230.4 k; API calls fall from 30 to 17; read/search commands from 37 to 24.
When FastContext returns overly broad evidence, main‑agent tokens rise by 1.56 M (≈76 % increase) on gohugoio__hugo‑12448.
Tokens increase from 2.045 M to 3.604 M; read/search commands climb from 83 to 170.
**Figure 7.** Cost audit for GPT-5.4 on SWE-bench Multilingual. Main-agent bars use the provider-recorded GPT-5.4 API cost in the direct and 4B-RL-augmented trajectory logs. The 4B-RL subagent bar is a counterfactual serverless estimate from its measured token usage and a \$0.20 / 1M-token 4B–16B pricing tier; in our deployment the 4B explorer is served locally, so this per-token API cost is not incurred.
Related Work and Context
We recap the premise and survey related coding‑agent and context‑refinement work.
FastContext offloads repository search to a lightweight subagent, cutting token waste and boosting downstream accuracy.
Coding agents follow a reasoning‑and‑acting loop inspired by the ReAct pattern, using tools to browse, edit, and validate code.
A full‑stack agent that iteratively localizes bugs, generates patches, and runs tests.
Decomposes issue resolution into separate localization, generation, and validation stages.
Uses a single model to perform both retrieval and editing without an explicit agent controller.
Integrates a language model with a tool‑use interface for end‑to‑end code repair.
Open‑source framework exposing a generic shell‑and‑editor loop for code tasks.
Product that lets developers invoke a coding‑assistant via a CLI.
Early LLM‑based code completion system that also supports limited tool use.
Command‑line interface exposing Copilot’s generation capabilities for scripts and patches.
Integrated development environment with an agent that can run searches, edits, and tests.
Beyond the monolithic loop, many works focus on retrieving or compressing repository context before generation.
Iteratively retrieves relevant files and generates code completions at the repository level.
Compresses long codebases into a dense representation for downstream generation.
Encodes extensive code contexts into a fixed‑size vector for fast lookup.
Structure‑aware localization that exploits abstract syntax trees to find relevant files.
Graph‑based method that models code dependencies to improve retrieval.
Context‑guided module that refines retrieved snippets before generation.
Trains a code‑search agent to quickly locate relevant files.
Regex‑style search tool integrated into coding agents.
Test‑time search that expands the agent’s view of the repository.
Replays past search trajectories to guide current exploration.
Prunes irrelevant code snippets from the agent’s context window.
Enhanced pruning that learns a relevance model from downstream tasks.
Benchmark suite measuring how agents explore large repositories.
The agent alternates between reasoning (writing a natural‑language plan) and acting (invoking a tool), using the model’s own output as both thought and command.
Conclusion: FastContext, a lightweight explorer, supplies the main agent with concise file‑line evidence, cutting token use and raising success rates across benchmarks.
Limitations: we evaluated only with Mini‑SWE‑Agent and strong backbones; smaller main models and alternative orchestration schemes remain open.
Ethics: all data are public, no new human subjects were collected, and usage respects repository licenses.
Standalone Exploration Evaluation
Evaluates FastContext and baselines on a reproducible localization benchmark.
We assess FastContext and several prior localization scaffolds on the standalone exploration benchmark, measuring file‑, module‑, and function‑level precision, recall, and F1.
**Table 4.** Standalone exploration evaluation protocol. We follow the CodeScout benchmark setting for patch-derived file/module/function targets, while adapting predictions from FastContext's file-line citation format.
Baseline systems differ in the granularity of predictions they emit; FastContext adapts its file‑line citations to all three levels via a deterministic adapter that maps line ranges to enclosing symbols.
Risks and Limitations
FastContext speeds up exploration but introduces safety and privacy concerns that must be mitigated.
FastContext acts as a read‑only repository exploration subagent; it never edits files, executes fixes, or submits patches directly. Nonetheless, by improving exploration it can indirectly empower coding agents that do modify code, raising the risk of buggy or insecure changes if deployed without human oversight.
To contain this risk we recommend integrating FastContext with standard software‑engineering safeguards: mandatory patch review, automated test execution, and repository‑specific access controls that limit what code can be altered.
FastContext returns compact file‑line citations, which can cause the Main Agent to place excessive trust in an incomplete view of the codebase. Missing tests, call sites, or configuration files may lead to edge‑case failures or incorrect fixes.
Our experiments mitigate this by keeping the Main Agent responsible for reading the retrieved evidence, reproducing the change, editing the code, and validating the fix, rather than allowing the explorer to modify the repository directly.
When deployed on private codebases, repository exploration can expose proprietary implementation details. Accordingly, model serving and logging must follow the same privacy and access‑control policies applied to the primary coding agent.
All benchmark repositories and public code used in our study serve purely research purposes; we do not employ them for production maintenance or decision‑making about repository owners.
Artifacts produced—trained exploration models, prompt templates, execution trajectories, and derived evaluation data—are released for reproducibility under the licenses of the underlying datasets and repositories.
The data we process originates from public open‑source repositories and established software‑engineering benchmarks; it may contain usernames, emails, or commit metadata, but we do not collect new human‑subject data or attempt to infer private attributes.
Incidental offensive language present in issue reports or comments is retained only insofar as it appears in the benchmark snapshots; we report aggregate results and avoid reproducing raw user discussions.
We employed AI assistants in three limited roles: polishing the manuscript text, generating supervised fine‑tuning (SFT) trajectories with Sonnet 4.6, and acting as the LLM‑as‑judge (GPT‑5.4) for SWE‑QA evaluation. No AI was used to create benchmark labels or replace human verification of reported outcomes.
SWE-bench Pro Subset
Defines the 200‑instance SWE‑bench Pro subset used for evaluation.
We evaluate on a fixed 200‑instance subset of SWE‑bench Pro. The full records are released in tmp/subset-pro.jsonl; each JSON line includes the original task fields and the corresponding `instance_id` listed below.