FastContext: Why Coding Agents Waste Half Their Tokens on Repo Search

TL;DR

Microsoft and Shanghai Jiao Tong University published FastContext on June 12, 2026, showing that coding agents spend 56.2% of their tool-use turns just reading and searching code before writing a single edit. Their fix: a dedicated exploration subagent that handles all repo navigation and passes back concise file-path-and-line-range citations. The open-source 4B parameter variant improved GPT-5.4’s SWE-bench Multilingual score by 3 points while cutting token consumption 26%, and on SWE-QA it halved token use. Larger explorer configurations pushed gains to +5.5 points and 60% token savings. Code and weights are on GitHub.

The Problem Every Coding Agent User Knows

If you’ve used Cursor, Claude Code, or GitHub Copilot agent mode on a real repository, you’ve watched this happen: you describe a bug, and the agent spends the next two minutes reading file after file, running grep queries, opening modules it doesn’t need, then finally getting around to the actual fix. I noticed this pattern repeatedly in my OpenCode vs Claude Code vs Cursor comparison — every tool exhibited the same exploration bloat. The exploration phase feels like watching someone flip through an entire encyclopedia to answer a question about page 42.

I’ve been using Claude Code on a Go monorepo with about 300 files for a few months now. The pattern is consistent: the agent opens 15-20 files per task, reads most of them top to bottom, and only touches 2-3 of them in the final diff. The rest were reconnaissance. That reconnaissance isn’t free. It eats context window, slows down responses, and on API-priced tools, it eats your wallet. Under the hood that reconnaissance is just the agent calling file-reading tools in a loop; I walk through the mechanics in how to build an AI agent in Go.

The FastContext paper puts hard numbers on what we’ve all been experiencing, and then shows that a tiny specialist model can do the reconnaissance better and cheaper than the frontier model doing it inline.

56% of Tool Turns Are Just Looking Around

The FastContext team analyzed 300 GPT-5.4 trajectories on SWE-bench tasks. The breakdown was stark.

Out of an average 17.72 tool-use turns per task, 9.96 were reading and searching. The agent ran nearly six sequential exploration turns before making its first edit. On unresolved tasks, that number climbed to 8.34 turns of exploration versus 6.67 on resolved ones. More exploration didn’t help. The agents that struggled kept searching without converging.

This lines up with what the SWE-Pruner team found in their own analysis of Claude Sonnet 4.5 on SWE-bench Verified: read-type operations consume 76.1% of total tokens in agentic coding tasks. The main agent carries every file snippet it ever opened in its growing context window, and that snowball effect means late-stage edits happen against a context polluted with irrelevant code.

The cost is concrete. On GPT-5.4, a direct SWE-bench Multilingual run costs $282.47 for 300 tasks. Nearly half of that goes to the model reading files it will never edit. For the broader picture of how fast SWE-bench scores have moved, see our Stanford AI Index 2026 breakdown.

FastContext’s Fix: Separate the Explorer From the Solver

The core idea is simple: stop making the expensive frontier model do the file exploration. Instead, hand that job to a small, purpose-trained specialist.

FastContext exposes three read-only tools to the explorer model:

• Read: open a file (or a specific line range)
• Glob: discover file paths matching a pattern
• Grep: regex search across the repo

When the main coding agent needs to understand the codebase, it issues a natural-language query to FastContext instead of running its own searches. FastContext fires parallel tool calls, gathers evidence across multiple turns, and returns a compact answer: just file paths and line ranges, no full file contents.

Main Agent → "Where is the URL routing logic for /api/users?"
FastContext → /src/routes/api.py:42-58, /src/middleware/auth.py:12-30
Main Agent → (reads only those 47 lines, edits what it needs)

The main agent never sees the 30 files FastContext opened and discarded during its search. Its context stays clean. The 4B explorer model runs at a fraction of the cost per token, and because it issues parallel tool calls, the wall-clock time is comparable to a single frontier-model exploration step.

This separation of concerns mirrors how experienced developers work. A senior engineer doesn’t read every file in the repo before making a change. They grep for the function name, check the callers, read the relevant tests, and then write the fix. FastContext trains a model to do exactly that.

How They Trained a 4B Model to Search Codebases

The training pipeline has two phases.

Phase 1: Supervised Fine-Tuning

The team generated 2,954 high-quality exploration trajectories using Claude Sonnet 4.6 as a reference model. These trajectories were decomposed into three skill categories:

They trained on Qwen3-4B-Instruct and Qwen3-Coder-30B-A3B backbones with assistant-token-only loss masking, a learning rate of 1e-5, and 3 epochs. The SFT stage teaches the model the basic mechanics: how to use the tools, how to format citations, and how to explore efficiently.

Phase 2: Reinforcement Learning

SFT produces a model that explores, but imprecisely. The RL stage closes that gap.

They built a 400-prompt RL training set from patch-based tasks and ran GRPO optimization on top of the SFT checkpoint. The reward function combines four signals:

1. File-level F1: did the explorer find the right files?
2. Line-level F1: did it pinpoint the right line ranges within those files?
3. Parallel-call bonus: reward for issuing multiple tool calls per turn (efficiency signal)
4. Format penalties: deductions for empty outputs, overly long responses, malformed citations, and excessive fan-out (exploring too many files without converging)

Each training prompt generated 16 sampled trajectories with a maximum of 8 turns each. The optimizer ran at a learning rate of 1e-6.

The RL stage is what separates FastContext from a naive “use a smaller model for search.” Without it, the model explores broadly but imprecisely. With it, the 4B model learns to prioritize high-signal files and converge faster.

Results: Less Money, Better Code

The paper tested FastContext as a drop-in subagent for three frontier models (GPT-5.4, GLM-5.1, Kimi-K2.6) across three benchmarks.

End-to-End Resolution Rates

The FC-4B-RL column shows the open-source 4B model. The “Same-Model Explorer” column uses GPT-5.4 itself as the explorer — that configuration scores higher on SWE-bench Pro (+5.5 vs +2.5) but costs far more per run because the explorer is a frontier model. On SWE-bench Multilingual, the 4B model actually outperformed same-model exploration (+3.0 vs +1.6). SWE-bench Pro tests harder, multi-file problems where exploration quality has a bigger impact.

Token Consumption Reduction

The nearly 50% token reduction on SWE-QA with GPT-5.4 is the standout number. Every single combination showed savings, ranging from 9.4% (Kimi-K2.6 on SWE-bench Pro) to 49.8%. Same-model exploration pushed savings even further on SWE-QA (60.3%), but at frontier-model pricing for the explorer itself — the 4B model achieves most of the savings at a fraction of the cost.

The Dollar Math

For 300 SWE-bench Multilingual tasks with GPT-5.4:

• Direct run: $282.47
• With FastContext-4B-RL: $208.92 (main agent) + $4.52 (explorer overhead) = $213.44
• Net savings: $69.03 per run, about 24%

The explorer overhead is negligible. At serverless pricing of $0.20 per million tokens, the 4B model processes 22.58 million tokens across 162 invocations for $4.52 total. The frontier model’s reduced token bill dwarfs that cost.

The Surprise: 4B Beats 30B

The most counterintuitive result: FastContext-4B-RL consistently matched or outperformed FastContext-30B-SFT, despite being 7.5x smaller.

On standalone file-level F1 (SWE-bench Verified), the 30B model scored 73.71 versus the 4B-RL’s 71.48. That gap looks meaningful on paper, but it didn’t translate to better end-to-end performance. On GLM-5.1 SWE-bench Pro, the 4B-RL explorer produced a 22.5% resolution rate versus 20.0% for the 30B-SFT explorer.

The RL training was the difference. Without RL, the 4B-SFT model lagged well behind the 30B-SFT model. With RL, the 4B model learned to compensate for its smaller capacity by being more precise in its search strategy. It issued fewer but better-targeted tool calls, converged faster, and wasted less of the main agent’s attention on marginal results.

This is a pattern that keeps showing up in LLM research: a small model trained with the right objective outperforms a larger model trained with a weaker one. We saw the same dynamic in Claude Fable 5’s SWE-bench Pro results, where training methodology mattered more than raw parameter count. The 4B-RL model is trained to optimize for downstream task resolution. The 30B is trained only to find relevant files, an intermediate objective that doesn’t perfectly correlate with the end goal.

What This Means if You Use Coding Agents

FastContext is a research prototype. You can’t plug it into Cursor today. But the findings have practical implications for anyone paying for AI-assisted coding.

If your coding agent bill seems high, about half of it is the model reading code it will never edit. The cause is structural: frontier models used as coding agents have no separation between “understanding the codebase” and “writing the fix,” so they carry all their reconnaissance in context. The paper quantifies what most of us already suspected.

Small specialist models are viable for exploration. The FastContext-4B-RL model is open-source on Hugging Face. It runs on a single consumer GPU. If you’re building an agent framework or maintaining a self-hosted coding assistant, you can integrate it now. The GitHub repo includes the training code and the Mini-SWE-Agent integration.

Then there’s the context pollution angle. Agents that explored more on unresolved tasks (8.34 turns vs. 6.67) were failing because their context was so full of irrelevant snippets that the frontier model’s attention degraded. FastContext fixes this by keeping the main agent’s context clean: it only sees the 47 lines it needs, not the 3,000 lines the explorer scanned.

The RL training recipe is the real contribution. SFT alone produces a decent explorer. RL makes it good enough to replace a frontier model. The multi-agent error cascade research we covered earlier showed how subagent failures propagate — FastContext sidesteps that risk by keeping the explorer read-only with a narrow tool set. The reward function (file-level and line-level F1 combined with efficiency bonuses and format penalties) is a template for training other specialist subagents. If someone builds an equivalent for “test-case identification” or “dependency analysis,” the same training recipe should apply.

A companion paper from the same month, SWE-Explore, independently benchmarks how different exploration strategies affect downstream repair. Their finding echoes FastContext: file-level localization is already strong for modern methods, but line-level precision and context efficiency are the axes that actually move resolution rates. The two papers together make a strong case that exploration is becoming a first-class research problem in coding agents.

FAQ

How much does FastContext cost to run?

The 4B-RL model processes about 140K tokens per invocation on average. At serverless pricing ($0.20/M tokens), that’s roughly $0.03 per task. For a 300-task SWE-bench run, the total explorer overhead was $4.52. On consumer hardware, a 4B parameter model fits on a single GPU with 8GB VRAM, so self-hosting cost approaches zero outside electricity.

Can I use FastContext with Claude Code or Cursor today?

Not directly. FastContext is integrated with Mini-SWE-Agent in the paper’s experiments, and the open-source code targets that framework. Integrating it with commercial tools like Cursor or Claude Code would require those tools to support external subagent delegation, which neither currently exposes. If you’re building your own agent pipeline (e.g., using the Anthropic API or OpenAI API directly), the GitHub repo has the integration code.

Does FastContext work for languages other than Python?

SWE-bench Multilingual includes tasks in multiple languages, and FastContext improved resolution rates across the board on that benchmark. The exploration skills (file reading, grep, glob) are language-agnostic. The trained model may have a slight bias toward Python patterns from the SFT training data, but the RL stage uses task-grounded rewards that don’t depend on language-specific heuristics.

Why does a 4B model outperform a 30B model?

RL training optimizes the 4B model directly for the downstream task (does the main agent resolve the issue?), while the 30B model was only trained with SFT (does the explorer find the right files?). File-level recall is a necessary but not sufficient condition for task resolution. The 4B-RL model learns to return compact, precisely scoped context that helps the main agent, even if it finds slightly fewer relevant files overall. The training objective drove the outcome more than raw model size.

How does this compare to just using a longer context window?

Longer context windows don’t solve the problem. The FastContext paper itself shows that agents with more exploration turns on unresolved tasks (8.34 vs 6.67) performed worse, because the extra context degraded attention quality. FastContext’s advantage is selectivity: it passes back only the signal. The main agent’s context stays focused, which improves both accuracy and response speed.

Sources

• FastContext: Training Efficient Repository Explorer for Coding Agents — arXiv:2606.14066 — original paper this post summarizes
• microsoft/fastcontext — GitHub — open-source code, training pipeline, and Mini-SWE-Agent integration
• FastContext-1.0-4B-RL — Hugging Face — pre-trained model weights
• SWE-Explore: Benchmarking How Coding Agents Explore Repositories — arXiv:2606.07297 — companion exploration benchmark from the same month
• SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents — arXiv:2601.16746 — independent analysis showing 76.1% of agent tokens go to read-type operations

Bottom Line

FastContext reframes repo exploration as a trainable, separable component rather than an implicit cost buried inside a monolithic frontier model. The practical takeaway is blunt: every major coding agent today — Claude Code, Cursor, Copilot, Windsurf — is doing exploration and solving in the same context, and that design choice is costing users roughly half their token budget. Microsoft just showed that a 4B model with the right RL recipe can do the exploration part better than GPT-5.4 does it inline, at a fraction of the cost. The code and weights are on GitHub. Someone is going to integrate this into a production coding tool within the next quarter, and when they do, the agents that still explore inline will feel like they’re running with the parking brake on.