Coding agents spend a surprising amount of their work just figuring out where the relevant code lives. In the new FastContext paper and project repo (GitHub, Hugging Face), Microsoft and Shanghai Jiao Tong University argue that this exploration step should be treated as its own problem instead of being bundled into the main solving agent.
That sounds like a small architectural change, but it addresses a real bottleneck: when the same model both searches the repository and writes the fix, its context fills up with irrelevant file snippets, failed hypotheses, and partially useful notes. FastContext is a specialized subagent for repository exploration that returns only the file paths and line ranges the main agent needs. The result is a cleaner workflow and, in their evaluation, less token use and better end-to-end task performance.
Why repository exploration is a separate problem
Modern software tasks are rarely about a single file. A bug report might refer to a failing test, but the cause could sit in a utility module, a configuration file, or a code path that is only reachable after several layers of indirection. Before an agent can patch anything, it has to answer questions like: Which files are relevant? What symbols are connected? Where is the source of truth?
FastContext’s authors measured this directly on trajectories from Mini-SWE-Agent. In their analysis, reading and searching consumed 56.2% of all tool-use turns and 46.5% of the main agent’s total tokens. That is a lot of compute spent not on reasoning about a fix, but on localizing evidence. Worse, all of that exploratory text stays in the solver’s history unless the system is designed to separate the two stages.
This is the key idea behind FastContext: instead of asking one model to do everything, let one model specialize in exploration and another specialize in solving.
What FastContext actually does
FastContext is a lightweight exploration subagent. It takes a natural-language issue description or a request for repository context, then performs read-only tool calls such as Read, Glob, and Grep in parallel. Rather than returning long summaries, it emits a compact set of file paths and line ranges that the solver can use as focused context.
That design matters for two reasons.
First, it limits context pollution. The main agent does not need to carry around every exploratory dead end. It gets a smaller evidence bundle, which makes subsequent reasoning easier.
Second, it changes the search strategy. FastContext is trained to do broad first-turn search, then multi-turn evidence gathering, and finally precise citation generation. The paper says the explorer models span 4B to 30B parameters, which is a useful reminder that this job does not automatically require the biggest available model. The task is narrow enough that a well-trained smaller model can be effective.
How the training loop is organized
The paper describes a two-stage training process.
The first stage is supervised fine-tuning. The authors bootstrap the explorer from strong reference trajectories, then filter examples into three kinds of behavior:
- Parallel tool calls for broad initial search
- Multi-turn trajectories for evidence gathering
- Line-range outputs for precise citations
That is a practical way to teach the model not just what to look for, but how to look for it.
The second stage is reinforcement learning with task-grounded rewards. Instead of rewarding fluent prose, the system rewards localization quality and structured exploration behavior. In other words, it is optimized to find the right code and return usable pointers, not to explain itself at length.
This is a pattern worth noticing. Many agent systems try to improve performance by making the solver smarter. FastContext instead improves the interface between search and solving. That often gives a better return on investment than increasing solver size alone.
What the evaluation suggests
FastContext was evaluated on SWE-bench Multilingual, SWE-bench Pro, and SWE-QA. According to the arXiv paper and the project GitHub repo, integrating FastContext into Mini-SWE-Agent improved end-to-end resolution rates by up to 5.5% while reducing coding-agent token consumption by up to 60%.
That combination is the interesting part. Many systems can be made cheaper by sacrificing quality, and many systems can be made better by spending more tokens. FastContext aims for both: less main-agent context and better task completion. The project page on Hugging Face summarizes the same result from the community side, which makes the claim easier to track across venues.
The paper also reports that the explorer performs well as a standalone localization model. That is important because it means the gains are not only due to a different prompt format or a hand-tuned pipeline. The subagent itself appears to learn a useful skill: quickly narrowing a repository down to the files and lines that matter.
What this means for coding-agent builders
FastContext points toward a broader design principle for agentic software engineering: separate finding from fixing.
For builders, that suggests a few practical lessons:
- Treat repository search as a first-class task. Search is not just a prelude to coding. It is a core capability with its own failure modes.
- Return evidence, not transcripts. The solver usually needs file paths and line numbers more than it needs the full exploration history.
- Train for the interface. If a downstream model needs structured evidence, train the upstream model to produce exactly that structure.
- Measure token economy alongside task success. A good coding agent should not only solve problems, but do so without filling the context window with noise.
The most useful part of FastContext is not that it adds yet another agent. It shows that agent systems can improve when we stop forcing one model to serve every role. A search specialist, even a small one, can make the main solver faster and more reliable.
That is a sensible direction for software engineering agents: smaller responsibilities, cleaner boundaries, and evidence that is easier for the next stage to consume.
Top comments (0)