Half of a coding agent's token bill often goes to finding code, not editing it.
Microsoft's FastContext paper (June 2026) traces GPT-5.4 agent runs: reading and searching account for 56.2% of tool-use turns and 46.5% of main-agent tokens. Every exploratory grep and full-file read stays in the solver's history, polluting later reasoning with haystack snippets whose only useful output is often one line number.
FastContext separates exploration from solving. A dedicated subagent explores with read-only tools, runs parallel searches in its own context, and returns compact file:line citations. The main agent never sees the messy search trail.
The delegation contract
Main coding agent │ │ natural-language query ▼ FastContext explorer (4B–30B) │ parallel Read / Glob / Grep │ (read-only, separate trajectory) ▼ <final_answer> block: paths + line ranges │ ▼ Main agent edits with focused evidence
The explorer cannot modify files or submit patches. Only the final evidence block enters the main trajectory. Internal tool observations log to subagent files under .fastcontext/.
That asymmetry is the efficiency win. A baseline agent that opens twelve 1,500-token files carries ~18,000 tokens of raw source. FastContext reads the same files externally and returns ~12 citations at ~40 tokens each (~480 tokens). The paper's up to 60.3% main-agent token reduction on SWE-QA is mostly "the haystack never landed on the desk that matters."
Results on Mini-SWE-Agent
Integrated into Mini-SWE-Agent across SWE-bench Multilingual, SWE-bench Pro, and SWE-QA:
| Outcome | Best reported delta |
|---|---|
| End-to-end success | Up to +5.5 points (GPT-5.4 on SWE-bench Pro) |
| Main-agent tokens | Up to 60.3% reduction (GPT-5.4 on SWE-QA) |
| Explorer overhead | ~2.1% of total API cost in one audited run |
The compact FC-4B-RL model often matches or beats the larger FC-30B-SFT explorer while using fewer tokens. On GLM-5.1 SWE-bench Pro, 4B-RL reached 22.5 vs 20.0 for 30B-SFT in their table.
Standalone localization metrics also improve: trained explorers recover patch-relevant files and symbols more accurately than small-model baselines without the FastContext recipe.
Training recipe: SFT then task-grounded RL
FastContext models span 4B–30B parameters (Qwen3-4B-Instruct and Qwen3-Coder-30B backbones). Training:
- Supervised fine-tuning on strong reference trajectories (broad first-turn search, multi-turn gathering, citation format)
- Reinforcement learning with rewards tied to file-level and symbol-level F1 against ground-truth patch locations
Weights are open on Hugging Face, including microsoft/FastContext-1.0-4B-SFT and RL-tuned variants. Code and data live at github.com/microsoft/fastcontext.
CLI usage
fastcontext \ --query "Where is authentication enforced and where should retry logic change?" \ --max-turns 6 \ --traj .fastcontext/trajectory.jsonl \ --citation
| Flag | Role |
|---|---|
--query | Natural-language exploration request |
--max-turns | Cap explorer turns before forcing final answer |
--citation | Return only the <final_answer> block |
--traj | JSONL log for debugging explorer behavior |
Mini-SWE-Agent integration wraps this as fastcontext -q "..." --format concise inside the task container. Main-agent prompts tell the solver when to delegate (cold-start exploration, failed direct search) and when to skip (issue already names the file).
Why harness design matters more than model hype
Matt Mayer's independent work showed the same model scoring 77% in Claude Code and 93% in Cursor on identical tasks. Harness effects of 5–40 percentage points appear across studies. FastContext is harness architecture: treat exploration as a trainable component with its own eval, not an implicit cost inside every solver loop.
That aligns with what I see shipping RAG and agent search for clients. Teams buy vector databases while the agent loop policy and tool delivery path (inline vs file-based results) dominate accuracy. The grep-vs-vector paper on LongMemEval found similar harness swings.
FastContext does not replace good repo maps or spec files. It replaces "frontier model reads thirty files sequentially" with "small specialist returns six line ranges."
Cost math (conservative API estimate)
On one GPT-5.4 SWE-bench Multilingual run (300 tasks), the main agent invoked 4B-RL 162 times. Subagent logs recorded 22.58M tokens. Priced at Fireworks serverless tier ($0.20/M tokens), explorer API cost was about $4.52. Main-agent cost fell from ~$282.47 to ~$208.92. Total with explorer ~$213.44, still saving ~$69 per run.
Self-hosted 4B on a single GPU approaches zero marginal cost beyond electricity. The paper's intended deployment is local explorer + frontier solver.
Limitations I would plan for
- Explorer mistakes still happen. Community testers report occasional wrong citations. Verify line ranges before large refactors.
- Tool outputs are capped to keep interactions responsive. Huge monorepos may need tighter queries.
- Not a drop-in for Cursor or Claude Code yet. Integration targets Mini-SWE-Agent and custom pipelines that can shell out to
fastcontext. - Exploration quality depends on query specificity. "Find the bug" loses to "Find where HTTP retry budget is enforced for outbound CRM sync."
Bottom line
Repository search should be a first-class, optimizable subsystem. FastContext proves a 4B explorer can beat a frontier model doing its own grepping, while cutting main-agent context pollution.
If your agent bills are high and traces show endless read/search loops, benchmark delegation before buying a bigger context window. Sometimes the fix is a librarian, not a longer desk.
Want help wiring exploration subagents into your agent harness with evals that measure end-to-end task success, not recall@k alone? Book a free discovery call.