FastContext: Training Efficient Repository Explorer for Coding Agents
Abstract: LLM coding agents have achieved strong results on software engineering tasks, yet repository exploration remains a major bottleneck: locating relevant code consumes substantial token budget and pollutes the agent's context with irrelevant snippets. In most agents, the same model explores the repository and solves the task, leaving exploratory reads and searches in the solver's history. We present FastContext, a dedicated exploration subagent that separates repository exploration from solving. Invoked on demand, FastContext issues parallel tool calls and returns concise file paths and line ranges as focused context. FastContext is powered by specialized exploration models spanning 4B--30B parameters. We bootstrap them from strong reference-model trajectories and refine them with task-grounded rewards for broad first-turn search, multi-turn evidence gathering, and precise citation generation. Across SWE-bench Multilingual, SWE-bench Pro, and SWE-QA, integrating FastContext into Mini-SWE-Agent improves end-to-end resolution rates up to 5.5\% while reducing coding-agent token consumption up to 60\%, with marginal overhead. These results show that repository exploration can be separated from solving and handled effectively by specialized models. Code and data: https://github.com/microsoft/fastcontext
Summary
- The paper introduces a decoupled exploration subagent that separates repository search from solution synthesis.
- It employs a two-stage training pipeline with supervised fine-tuning and reinforcement learning to optimize file-line citation accuracy and token efficiency.
- Experimental results show up to a 5.5% accuracy improvement and a 60.3% token cost reduction across challenging benchmarks.
FastContext: Efficient Repository Exploration for Coding Agents
Motivation and Problem Analysis
LLM coding agents have escalated in capability across multi-file software engineering tasks, yet repository exploration remains a major efficiency and accuracy bottleneck. Existing mainstream agents typically use the same large model instance for both exploratory read/search operations and final solution synthesis. This tightly coupled pipeline leads to excessive context pollution (irrelevant intermediate snippets) as well as inflated inference costs, because many exploratory tool calls—file reads, glob searches, regex queries—consume a significant fraction of the main agent's token budget. Empirical trajectory analysis of GPT-5.4-high with Mini-SWE-Agent on SWE-bench Multilingual demonstrates that exploratory actions (reading/searching) account for over 56% of all tool-use turns and nearly half of all main-agent tokens.
Figure 1: Trajectory breakdown highlighting exploration actions as the main cost in tool-use turns and prompt-token budgets.
A further inefficiency is sequential exploration: before executing even the first code edit, most agents require upwards of six sequential turns, resulting in token expenditure that directly impacts overall deployment cost and increases the risk of prompt saturation and information loss.
FastContext: Design and Training
FastContext is proposed as a dedicated repository exploration subagent, explicitly decoupling exploratory operations from the critical path of solution execution by the main coding agent. It exposes three language-agnostic tools: Read (file/line access), Glob (pattern-based file discovery), and Grep (regex code/text search). Invocation returns a compact, structured set of file paths and line ranges as relevant evidence, bypassing the need for the main agent to accumulate large amounts of noisy exploratory context.
Figure 2: FastContext architecture. Left: Integration in agent loops. Right: Internal structure with parallel tool invocation and final compact citations.
The training pipeline is two-stage:
- Supervised Fine-Tuning (SFT): Construction utilizes 2954 exploration samples decomposed into broad first-turn parallel search, multi-turn evidence gathering, and precise citation finalization. This supervision regime moves beyond path-only annotation to expose the model to full exploration trajectories aligned with practical agent workflows.
- Reinforcement Learning (RL): Task-derived, patch-localization reward directly optimizes for accurate, minimal file-line citation coverage, penalizing malformed or over-broad evidence and incentivizing bounded, parallelized exploration. The SFT-initialized explorer is further aligned by RL using a mix of file- and line-level F1 objectives.
Figure 3: SFT loss and RL reward curves. SFT provides initialization; RL further aligns explorers with end-task rewards.
Experimental Results
Efficiency and Success Rates
Integrating FastContext into Mini-SWE-Agent substantively raises end-to-end resolution rates across SWE-bench Multilingual, SWE-bench Pro, and SWE-QA, while reducing token cost. The most compelling improvements are seen on the hardest tasks (SWE-bench Pro): for GPT-5.4, accuracy increases up to 5.5% and main-agent token usage drops by up to 60.3% (on SWE-QA).
Figure 4: SWE-bench Multilingual and SWE-QA tradeoff: FastContext yields higher benchmark scores at significantly lower token consumption.
Figure 5: Per-instance total-token distributions for GPT-5.4 on SWE-bench Multilingual with and without FastContext.
Explorer-augmented agents shift the entire per-instance token distribution downward, demonstrating broad efficiency gains.
Figure 6: Decomposition of GPT-5.4 main-agent token usage by action. FastContext removes nearly all context bloat from exploratory reads/searches.
Cost audit shows that explorer tokens, even when externally served, constitute a negligible share (≤2%) of end-to-end inference budget.
Figure 7: System cost breakdown highlighting subagent (FastContext) overhead as marginal compared to main-agent cost savings.
Standalone Exploration Performance
On SWE-bench Verified, FastContext outperforms prior exploration agents (RepoSearcher, LocAgent, Agentless, OrcaLoca, CoSIL) both at file granularity (F1 73.7 for 30B-SFT, 71.5 for 4B-RL) and module/function coverage. The RL-trained 4B model is competitive with much larger models, indicating that the reward-aligned compact explorer can serve as a highly efficient, plug-and-play module.
Ablation and Trade-Offs
- RL-trained small explorers (4B) rival or surpass larger SFT-only versions (30B), validating the effectiveness of the downstream localization reward.
- FastContext consistently dominates same-model exploration in both token efficiency and benchmark completion rates.
Implications and Future Directions
FastContext demonstrates that repository exploration should be handled by specialized, modular subagents rather than through monolithic agent trajectories. The empirical results indicate that separating exploration from task-solving yields compounding gains in both accuracy and efficiency, with minimal model serving overhead—even for large-scale repositories or high-difficulty benchmarks.
This modularization paradigm invites further research into compositional agent architectures, scalable delegation contracts, and cross-task transferability of exploration behaviors. Moreover, the fact that 4B explorers can reach close to frontier-model accuracy after RL suggests that efficient model specialization (rather than generic LLM scaling) is a promising avenue for real-world deployments.
Potential Directions
- Integration with larger, long-horizon agent frameworks beyond Mini-SWE-Agent.
- Extending the paradigm to sub-4B explorations models (1.7B, 0.6B) to further minimize deployment cost.
- Investigating higher semantic granularity context extraction (e.g., functionality-level retrieval) and combining with verification strategies.
- Adapting exploration policies to interactively update evidence based on main-agent feedback loops.
Conclusion
FastContext demonstrates that explicit, trainable repository exploration subagents can both decrease inference cost and improve main-agent effectiveness in LLM code-agent frameworks. The modular contract—supporting both efficient broad search and precise context delivery—enables accurate, cost-effective, and robust agentic workflows for multi-file software engineering tasks. This approach underscores the strategic importance of modularization and specialization in future agentic software engineering systems, and establishes a concrete pathway for hybrid LLM agent architectures to decouple search and synthesis behaviors for improved performance.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What this paper is about (big picture)
The paper introduces FastContext, a smart “scout” for AI coding assistants. When an AI needs to fix a bug or answer a question about a big codebase (a large folder full of many code files), it first has to find the right files and lines to look at. That search usually eats up lots of the AI’s “reading budget” and clutters its memory with unnecessary code. FastContext acts as a separate, lightweight helper that quickly searches the repository and hands back only the most relevant file paths and line ranges. This makes the main coding agent more accurate and much more efficient.
The main goals and questions
- Can we split “exploring the codebase” from “solving the problem” so the main AI focuses only on the important parts?
- Can a small, specialized exploration helper find the right files and lines faster and cleaner than having the big main model do everything?
- Will this separation improve success on real coding tasks and cut down the number of tokens (the AI’s limited “words and reading space”) used?
How it works (methods in simple terms)
Think of a school project where you have a researcher and a writer:
- The researcher (FastContext) digs through books to find the exact pages and paragraphs you need.
- The writer (the main coding agent) reads only those parts to write a clear answer or fix a problem.
Here’s what FastContext does:
- It uses three simple, safe tools (read-only):
- Read: open a file with line numbers.
- Glob: list files that match a pattern (like “find all files ending in .py in the tests folder”).
- Grep: search text across files (like looking for a function name or error message).
- It runs several searches in parallel (at the same time) to save time.
- It returns a short list of “evidence,” like: /src/router.py:42-58 /tests/test_router.py:101-119 This is like giving the writer the exact pages and lines to check, plus a quick note about why they matter.
How they trained FastContext:
- Supervised fine-tuning (SFT): They showed FastContext many examples of good exploration—how to start broadly, refine the search step by step, and end with precise file-and-line citations. Think of this like learning by imitation from strong examples.
- Reinforcement learning (RL): They gave it a score based on how well its final answer matched the files and lines that were actually changed in the correct fix (from real patches). It also got small bonuses for good habits (like smart parallel searches) and penalties for messy or overly long outputs. Think of this like practicing with feedback: “You found the right place—great!” or “Too vague—try again.”
Benchmarks they used:
- SWE-bench Multilingual and SWE-bench Pro: realistic tasks where the AI needs to fix issues in real codebases.
- SWE-QA: questions about a codebase that require finding and understanding the right code parts.
What they found (results and why they matter)
- Better success rates: Adding FastContext to a standard coding agent increased problem-solving accuracy by up to 5.5% on tough benchmarks.
- Big token savings: The main agent used up to 60% fewer tokens (less reading/writing), especially on code-question tasks. This means faster responses and lower cost.
- Small helper, big impact: Even a compact 4-billion-parameter FastContext (small by modern AI standards) worked very well, especially after RL.
- Cleaner context: Instead of dumping lots of code into the main agent’s memory, FastContext gives short, focused citations (files + line ranges). This reduces confusion and helps the main agent reason better.
- Strong standalone explorer: When tested just on “find the right places in code,” FastContext matched or beat other exploration methods at finding the correct files, modules, and functions related to the fix.
Why this matters (implications)
- Modular coding agents: Splitting “explore” from “solve” makes AI coding assistants more efficient and easier to improve. You can upgrade the explorer without changing the solver, and vice versa.
- Lower cost, faster runs: Because the main agent reads less, you spend fewer tokens and get answers more quickly.
- More reliable reasoning: Focused evidence reduces distractions, so the main agent is less likely to chase the wrong idea.
- Practical and reusable: FastContext is designed as a lightweight component that other agent systems can plug in to improve their code-search step.
- A path to smaller helpers: The training recipe (SFT + RL) shows you can build effective, compact explorers—opening the door to even smaller, cheaper helpers in the future.
In short, FastContext is like giving your AI coder a skilled librarian: it quickly brings the right books and pages, so the AI can spend its energy understanding and fixing the problem instead of wandering the stacks.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The following list summarizes what remains missing, uncertain, or unexplored in the paper, phrased to guide concrete follow-up work:
- Generalization beyond Mini-SWE-Agent: How does FastContext integrate with other scaffolds (e.g., SWE-agent, OpenHands, Agentless) that have different tool schemas, memory policies, or subagent orchestration? Provide plug-in adapters and evaluate cross-framework portability.
- Invocation policy learning: When should the main agent invoke FastContext versus proceed directly? Develop and evaluate learned or heuristic gating policies, especially for “easy” tasks where subagent overhead might not pay off.
- End-to-end cost beyond tokens: Report and compare total wall-clock time, CPU/IO load, GPU utilization, and dollar cost (including subagent overhead) under varying repository sizes and hardware. Validate the “marginal overhead” claim with latency breakdowns.
- Parallel tool-call scheduling: Ablate and optimize the degree of parallelism, batching, deduplication, and backoff strategies; quantify how concurrency affects I/O bottlenecks, latency, and accuracy.
- Scaling to very large or atypical repos: Stress-test on monorepos, deep directory trees, vendor/third-party folders, large binary/auto-generated files, and submodules. Analyze robustness to timeouts and I/O limits.
- Toolset minimalism vs language awareness: Compare Read/Glob/Grep to language-aware tools (ctags, LSP, AST parsers, LSIF) across typed vs dynamic languages. Identify conditions where language-aware signals notably improve localization.
- Read-only constraint: Many issues require dynamic signals (e.g., failing tests, build logs, runtime traces). Evaluate whether incorporating lightweight, read-only proxies or controlled test execution into exploration improves performance.
- RL reward design sensitivity: The reward mixes file/line F1, a parallelism bonus, and format penalties. Ablate each term, test alternative weights/thresholds, and evaluate stability across RL seeds and optimizers.
- RL supervision source bias: Using patch-derived locations may bias the explorer toward edit sites rather than root-cause contexts (e.g., tests or call sites). Explore alternative or augmented labels (test failure stacks, blame history, commit messages).
- RL data scale and coverage: Only 400 prompts are used for RL. Measure scaling curves with larger and more diverse RL sets, per-language/domain coverage, and their impact on generalization (especially to QA tasks).
- SWE-QA alignment: RL uses patch-derived labels; SWE-QA has no patch supervision. Investigate QA-specific rewards (e.g., evidence recall against gold rationales) and whether patch-grounded RL transfers.
- Standalone vs end-to-end comparisons: The paper benchmarks standalone localization but does not integrate competing explorers (graph-based, search-based) as subagents in the same main-agent pipeline. Run head-to-head end-to-end cost/accuracy comparisons under a shared orchestration.
- Multi-turn reinvocation and memory: Define strategies to cache exploration results, reuse repository maps across invocations, and handle line-number drift after edits. Evaluate benefits of persistent explorer memory.
- Robustness to filesystem edge cases: Assess behavior under mixed encodings, symlinks, path normalization across OSes, case sensitivity, ignored files (.gitignore), and nested repositories/submodules.
- Adversarial or pathological repos: Evaluate resilience to “regex bombs”, huge auto-generated logs, intentionally misleading paths, and resource exhaustion attacks. Define sandboxing and rate-limiting policies.
- Per-language and per-task breakdowns: Provide fine-grained analyses by language, repository size, task type (local vs cross-file, refactor vs logic bug), and failure modes where FastContext helps or harms.
- Dependence on main-agent strength: Results focus on strong frontier models (GPT-5.4, GLM-5.1, Kimi-K2.6). Evaluate with mid-size and smaller open-source main agents (≤30B) to understand when exploration yields the most gain.
- Explorer size floor: The smallest explorer is 4B. Experiment with 1.7B/0.6B models, distillation, and quantization; report latency/accuracy trade-offs and memory footprints for practical deployment.
- Compositionality with compression/pruning: Measure additive or synergistic effects when combining FastContext with context-pruning/compression methods (e.g., SWE-Pruner, LongCodeZip) and with retrieval-augmented generation.
- Failure analysis of citations: Systematically categorize errors (missed files, overly narrow/overbroad ranges, redundant citations) and their impact on downstream solving. Develop calibration methods for the number and length of line ranges.
- Early stopping and budget control: Learn when the explorer has “enough” evidence. Evaluate stop criteria, adaptive budgets, and confidence measures to avoid unnecessary tool calls.
- Benchmark and judge bias: SWE-QA uses GPT-5.4 as the judge while GPT-5.4 is also a main agent in some runs. Re-evaluate with diverse, independent judges and ensure decontamination across all benchmarks.
- Reproducibility and data release: The SFT traces rely on a frontier model (Sonnet 4.6). Release detailed prompts, traces, and RL data splits; document any non-public assets to enable reproducible training.
- Coverage vs causal relevance: Patch-derived evaluation may not capture causally relevant evidence (e.g., tests or configuration). Construct and release benchmarks with human-annotated causal evidence to assess true discovery quality.
- Orchestration under long-context main agents: Assess whether benefits persist when the main agent has very large context windows or strong built-in retrieval, and how memory policies (rolling windows vs full histories) moderate gains.
- Model scaling laws and RL at larger scales: The 30B model is only SFT’d. Test RL at 30B (or larger/MoE) to quantify the marginal value of capacity vs post-training, and identify scaling regimes with the best cost–benefit.
- Caching and I/O engineering: Evaluate repository-level caching of grep/glob results across runs and instances; quantify speedups and trade-offs in freshness vs performance.
- Industrial datasets: Validate on private/industrial repos with heterogeneous build systems (Bazel, Maven, Gradle), polyglot codebases, and CI/test infrastructure to assess deployability.
Practical Applications
Overview
FastContext introduces a lightweight, specialized exploration subagent that decouples repository navigation from problem-solving in coding agents. It uses parallel, read‑only tools (Read, Glob, Grep) and returns compact file-and-line citations, improving end-to-end task success (up to +5.5%) while reducing main-agent token usage (up to −60%) across SWE-bench Multilingual/Pro and SWE-QA. Below are practical, real-world applications organized by immediacy, with sectors, potential tools/products/workflows, and key dependencies.
Immediate Applications
The following applications can be deployed now with moderate integration effort, using the provided code and models (4B–30B; 4B as practical deployment target).
- Focused-context IDE/Editor extension
- Sectors: Software development, DevTools
- Tools/Products/Workflows: VS Code/JetBrains extension that invokes FastContext to return “evidence lists” (file:line ranges) for issues, TODOs, and questions; LSP middleware that pre-selects context for completions and refactors
- Dependencies/Assumptions: Read-only repository access; local or remote 4B model serving; minimal adapter to the tool schemas; prompt templates for common dev tasks
- Subagent augmentation for coding assistants
- Sectors: DevTools vendors (Copilot-like), Enterprise developer platforms
- Tools/Products/Workflows: “Explorer” microservice called before patch synthesis; orchestrator that gates main LLM context by citations; fallback to same-model exploration if subagent is unavailable
- Dependencies/Assumptions: Agent framework that supports subagent calls (e.g., Mini-SWE-Agent/OpenHands); cost/latency budget for small-model inference; routing policy when evidence is empty or low-confidence
- CI test failure triage bot
- Sectors: DevOps/QA
- Tools/Products/Workflows: GitHub Actions/GitLab CI job that ingests failing logs/stack traces and returns likely culprit files/lines for the failing job; posts results as PR comments
- Dependencies/Assumptions: Access to build artifacts/logs and repo snapshot; simple prompt adapters for logs; guardrails for noisy logs
- PR review auto-context generator
- Sectors: DevOps, Code Review
- Tools/Products/Workflows: Bot that annotates PRs with impacted areas and supporting citations (tests, entry points, API call sites), enabling focused review and checklists
- Dependencies/Assumptions: Diff metadata; repository at PR head; rate-limited API usage
- Repository-level Q&A assistant for internal portals
- Sectors: Engineering knowledge management
- Tools/Products/Workflows: ChatOps bot (Slack/MS Teams) that answers “Where is X implemented?” or “How does module Y work?” with grounded file:line citations and tiny snippets
- Dependencies/Assumptions: Read-only repo access; answer synthesis can use the cited excerpts to minimize token use
- Open-source issue triage helper
- Sectors: Open-source communities
- Tools/Products/Workflows: GitHub App that replies on new issues with top-k relevant files/lines and rationale; improves maintainer response time
- Dependencies/Assumptions: Responsible disclosure and disclaimers; rate limits; owner opt-in; configurable confidence thresholds
- SAST/AppSec alert localization and remediation aid
- Sectors: Application Security
- Tools/Products/Workflows: SAST console plugin that refines broad alerts to exact file:line evidence and the surrounding code context to speed fixes
- Dependencies/Assumptions: Mapping SAST alert metadata to prompts; careful handling of sensitive code; human-in-the-loop verification
- Onboarding navigator for new engineers
- Sectors: HR/Training for engineering teams
- Tools/Products/Workflows: “Code navigation playbook” queries (ownership, initialization paths, config flows) answered with citations; integrated into learning modules
- Dependencies/Assumptions: Access to representative build/test targets; curated prompt library for common onboarding tasks
- Token budget and cost-control gateway
- Sectors: Any enterprise using frontier LLMs for coding assistance (finance, healthcare, retail)
- Tools/Products/Workflows: API sidecar that enforces “explore-first” policy; reduces main LLM context to cited spans; per-team dashboards on token savings and success rates
- Dependencies/Assumptions: Observability hooks; routing logic for when to bypass exploration (e.g., trivial edits); cost accounting
- Academic baseline for decoupled agent research
- Sectors: Academia, R&D labs
- Tools/Products/Workflows: Open training data/recipes for SFT+RL on exploration; reproducible evaluations on SWE-bench/SWE-QA; ablation-friendly module for comparing main-agent methods under controlled context
- Dependencies/Assumptions: Compute for small-model training; adherence to benchmark licenses; standardized scoring and path normalization
- Offline local repo explorer (daily developer use)
- Sectors: Individual developers, SMBs with privacy constraints
- Tools/Products/Workflows: CLI/TUI tool that returns file:line citations for tasks without internet; leverages
ripgrepand local 4B model - Dependencies/Assumptions: Local hardware (consumer GPU or performant CPU with quantization); fits within memory; repository fits local disk
Long-Term Applications
These require further research, scaling, or productization beyond the paper’s current scope (e.g., larger repos, more tools, cross-repo reasoning, or new data/benchmarks).
- Enterprise-scale monorepo navigator
- Sectors: Big Tech, Finance, Automotive
- Tools/Products/Workflows: Sharded parallel exploration, hierarchical indexing, code ownership graphs; load-aware subagent farms
- Dependencies/Assumptions: Scalable indexing and caching; workload-aware parallelism; evaluation on million-file repos
- Cross-repo impact analysis and migration planning
- Sectors: Microservices/platform engineering
- Tools/Products/Workflows: Subagent that traces API changes across services and versions; suggests migration waves with precise call-site citations
- Dependencies/Assumptions: Cross-repo dependency graph; build system/BOM integration; multi-repo authentication
- Smart test selection and generation
- Sectors: DevOps/QA
- Tools/Products/Workflows: Use citations to propose minimal test subsets or synthesize targeted tests; integrate with CI to cut runtime
- Dependencies/Assumptions: Historical coverage and flakiness data; guardrails for test validity; feedback loops from CI outcomes
- Fully modular autonomous patching loops
- Sectors: DevTools, Enterprise IT
- Tools/Products/Workflows: Explorer → planner → editor → verifier architecture with explicit contracts and memory; subagent orchestration policies
- Dependencies/Assumptions: Reliable validators/sandboxes; rollback strategies; reward design that balances recall vs. precision across stages
- CVE response and vulnerability backporting at scale
- Sectors: Security, OSS foundations, Vendors
- Tools/Products/Workflows: Map CVE advisories to affected files/lines across versions; propose minimal patches and backports with citations
- Dependencies/Assumptions: CVE/NVD data integration; version-aware indexing; high-precision mapping to avoid false positives
- Spec-to-code traceability and compliance artifacts
- Sectors: Healthcare, Automotive, Aerospace (safety-critical), Government
- Tools/Products/Workflows: Generate traceability matrices linking requirements/docs to file:line citations; attach to audits and model cards
- Dependencies/Assumptions: Document ingestion and alignment; policy frameworks (e.g., ISO 26262, SOC 2, EU AI Act); human review
- On-device exploration with smaller models (≤1.7B)
- Sectors: Privacy-sensitive enterprises, Regulated industries, Edge/air-gapped
- Tools/Products/Workflows: Distilled/quantized explorers that run on laptops/edge servers while preserving benefits of line-range citations
- Dependencies/Assumptions: Model compression/distillation research; acceptable recall with tight compute/memory budgets
- Multimodal exploration (logs, traces, runtime telemetry, UI)
- Sectors: SRE, Mobile/Frontend, Observability platforms
- Tools/Products/Workflows: Combine code exploration with profiling traces, APM spans, and UI snapshots to localize issues end-to-end
- Dependencies/Assumptions: VLM or event-schema integration; data privacy and secure pipeline for telemetry; robust alignment of signals
- Product and data governance policies for subagent interfaces
- Sectors: Enterprise IT, Procurement, Policy-makers
- Tools/Products/Workflows: Standardized “exploration contract” (file:line citations, read-only tools); vendor-neutral benchmarks and SLAs for token efficiency and grounding
- Dependencies/Assumptions: Community consensus; certification suites; adoption by IDE/agent vendors
- Sustainability and cost governance dashboards
- Sectors: Enterprise FinOps, ESG reporting
- Tools/Products/Workflows: Attribute token and energy savings to exploration-first workflows; carbon reporting per repo/team
- Dependencies/Assumptions: Reliable telemetry; accepted conversion factors from tokens/compute to energy and emissions
- Requirements-to-implementation discovery for product teams
- Sectors: Product/Program management
- Tools/Products/Workflows: Map user stories/bug reports to concrete code regions and owners; plan incremental delivery with grounded scope
- Dependencies/Assumptions: Story/issue templates; ownership metadata; robust natural language alignment to code constructs
Notes on Feasibility and Risks
- The subagent uses read-only tools and returns compact citations, which can reduce token cost and context noise, but precision/recall trade-offs must be tuned to avoid missing critical files or overwhelming the main agent.
- RL reward depends on patch-derived labels; real-world issues without clean patches may require alternative supervision (e.g., human labels, test locality, coverage signals).
- Scaling to monorepos and cross-repo tasks likely needs indexing, caching, and richer tools (AST queries, build graphs).
- Reported gains are on public benchmarks with strong main models; outcomes may vary in proprietary stacks, languages, and workflows.
- Governance: clear logging, auditability, and privacy policies should accompany deployment, especially where sensitive code is involved.
Glossary
- Agent trajectory: The sequence of actions and tool interactions an agent executes while solving a task. "repository exploration remains a costly part of current agent trajectories"
- Decontaminated evaluations: Benchmark evaluations designed to avoid training-data leakage and contamination. "harder, multilingual, and decontaminated evaluations"
- Delegation contract: The explicit input/output interface that defines how the main agent delegates work to a subagent and what it expects back. "The main text focuses on the delegation contract and training recipe"
- End-to-end resolution rates: The proportion of tasks fully solved by the system from input to final outcome. "improves end-to-end resolution rates up to 5.5\%"
- Exploration subagent: A specialized helper agent focused solely on repository exploration rather than solution generation. "We present FastContext, a dedicated exploration subagent that separates repository exploration from solving."
- File-and-line citations: Compact references to specific files and line ranges that serve as focused evidence for the solver. "returns grounded file-and-line citations as compact context."
- Final answer block: The formatted output segment listing the explorer’s final file paths and line ranges. "The output contract is a compact final answer block containing file paths and line ranges"
- Frontier model: A state-of-the-art large model used as a strong reference or main solver. "frontier-model prompt-token usage"
- Glob: Pattern-based file-path matching used to discover files by name or structure. "Glob for path discovery"
- Grep: Regular-expression-based search over repository text. "Grep for regex search over repository text."
- GRPO: A policy-optimization algorithm used in reinforcement learning to refine the explorer. "optimize with GRPO"
- Line ranges: Consecutive line number intervals within a file that localize relevant code regions. "file paths with line ranges as focused context."
- Localization accuracy: How precisely the system identifies the files/lines implicated by a task or patch. "patch-derived localization accuracy"
- Main agent: The primary coding agent responsible for solving the issue end to end. "We use main agent to refer to the coding agent responsible for solving the task"
- Mini-SWE-Agent: A minimal coding-agent framework used as the main-agent scaffold in experiments. "integrating FastContext into Mini-SWE-Agent improves"
- Parallel tool calls: Executing multiple tool invocations concurrently within a single agent turn. "issues parallel tool calls"
- Patch-derived reference locations: Ground-truth file and line targets extracted from the final patch for evaluation or supervision. "patch-derived reference locations"
- Path normalization: Standardizing file-path formats before computing overlap or metrics. "after path normalization"
- Read-only tools: Tools that inspect but do not modify the repository (e.g., Read, Glob, Grep). "explores the target repository with read-only tools"
- Reinforcement learning (RL): Training with rewards to align the model’s behavior with task outcomes. "followed by reinforcement learning (RL) to align the returned evidence"
- Repository exploration: Searching and reading a repository to locate relevant files and code regions. "repository exploration remains a major bottleneck"
- Repository-level question answering: Answering questions that require navigating and understanding multi-file codebases. "repository-level question answering"
- Supervised fine-tuning (SFT): Training on demonstration data to initialize the exploration policy. "supervised fine-tuning (SFT) to initialize exploration behavior"
- SWE-bench Multilingual: A benchmark suite of multilingual software-issue resolution tasks. "Across SWE-bench Multilingual, SWE-bench Pro, and SWE-QA"
- SWE-bench Pro: A more challenging suite of long-horizon software-engineering tasks. "Across SWE-bench Multilingual, SWE-bench Pro, and SWE-QA"
- SWE-bench Verified: A benchmark subset used for evaluating patch localization against verified references. "standalone patch-localization benchmark on SWE-bench Verified"
- SWE-QA: A benchmark for repository-level code question answering. "Across SWE-bench Multilingual, SWE-bench Pro, and SWE-QA"
- Token budget: The allowable or consumed number of tokens, tied to cost and context size. "consumes substantial token budget"
- Tool-use turns: Interaction steps in which the agent invokes external tools. "tool-use turns"
- Top-level directory listing: A listing of files and folders at the repository root used to guide exploration. "top-level directory listing"
- Workspace metadata: Auxiliary information about the repository environment provided to the agent. "workspace metadata"
Collections
Sign up for free to add this paper to one or more collections.