Microsoft Withdrew FastContext. Here’s How the Community Is Running It Locally

A practical guide to the 4B repository-exploration model, the research behind it, and the community mirrors that support MLX, LM Studio, Ollama, and llama.cpp

On June 30, 2026, the authors of Microsoft’s FastContext paper withdrew it from arXiv, stating that the article involved “some product IP issues” and needed to be “withdrawn and re-approved.”

Around the same time, Microsoft’s GitHub repository and official Hugging Face model listings became inaccessible.

The notice does not identify the specific intellectual-property concern. It does not say whether the problem involved the paper, source code, model weights, product information, licensing, or Microsoft’s internal release-approval process. Anything more specific remains speculation.

But the project did not disappear completely.

Community members preserved copies of the source repository, model weights, and converted formats. Today, FastContext can still be studied and run locally through several unofficial mirrors—including on Apple Silicon with MLX, LM Studio, Ollama, or llama.cpp.

That matters because the idea behind FastContext is more interesting than the circumstances of its withdrawal:

Finding code and fixing code may not need to be done by the same model.

What FastContext is

FastContext is not a general-purpose coding assistant. It is a specialized repository explorer.

You give it a question such as:

Where is authentication middleware applied to incoming requests?

FastContext explores the current repository using three read-only tools:

• Read retrieves selected file contents.
• Glob discovers paths matching a pattern.
• Grep searches file contents using ripgrep-style queries.

It can request multiple searches or reads in a single exploration turn, refine its approach based on the results, and return a compact citation block:

<final_answer>
/repo/src/middleware/auth.py:24-67
/repo/src/server/router.py:108-141
/repo/tests/test_auth.py:52-93
</final_answer>

A primary coding agent can then inspect those locations without repeating the complete search process.

The intended division of labor is straightforward:

Main coding agent
       |
       | "Find the code responsible for X"
       v
FastContext explorer
       |
       | Read / Glob / Grep
       v
Repository
       |
       | File paths and line ranges
       v
Main coding agent

FastContext finds the evidence. The larger model decides what the evidence means and how the code should change.

The problem FastContext was designed to solve

Repository exploration consumes more of a coding agent’s context than it first appears.

In the last full version of the FastContext paper, the researchers analyzed 300 GPT-5.4-high Mini-SWE-Agent trajectories on SWE-bench Multilingual.

They found that reading files and searching code accounted for:

• 56.2% of tool-use turns
• 46.5% of the main agent’s tokens

The agent reached its first source-code edit at turn 8.47 on average. The median trajectory spent six sequential turns and made 15.5 exploration tool calls before the first edit.

Unresolved tasks also involved more exploration before the first edit: 8.34 turns on average, compared with 6.67 for resolved tasks.

That does not prove that exploration caused the failures. More difficult tasks naturally require more investigation. But it illustrates how much work can accumulate in a model’s context before it changes a single line.

A typical coding agent might:

1. Search broadly for a feature name.
2. Open several irrelevant files.
3. Search for a related class or function.
4. Follow imports into another module.
5. Discover that the initial assumption was wrong.
6. Repeat the process from a different starting point.
7. Finally locate the implementation.

Even if the agent eventually succeeds, all those dead ends may remain in its conversation history. FastContext moves that exploration into a separate context and sends only the selected evidence back to the main agent.

Why FastContext is more than a wrapper around grep

Read, Glob, and Grep are not novel tools. The model’s exploration behavior is the important part.

A useful repository explorer must learn how to:

• Begin with broad but nonredundant searches
• Translate a natural-language issue into likely code symbols
• Choose between path discovery and content search
• Revise its hypotheses after a failed search
• Read enough surrounding code to verify a result
• Recover from incorrect repository assumptions
• Return narrow file-and-line citations instead of a vague explanation

The FastContext researchers trained models ranging from 4B to 30B parameters.

Training happened in two stages:

1. Supervised fine-tuning: The models learned from reference exploration trajectories, including broad first-turn searches, multi-turn evidence gathering, and precise citation generation.
2. Reinforcement learning: The explorer was rewarded for identifying relevant files and lines, using bounded multi-call exploration, and producing the expected final-answer format.

The paper reports that the 4B reinforcement-learned explorer improved or tied the 4B supervised model across all nine end-to-end configurations. In some settings, the 4B-RL model also outperformed the larger 30B supervised model.

That does not mean a 4B model is generally more capable than a 30B model. It suggests that a smaller model trained for a narrow task can sometimes outperform a larger model that received less task-specific optimization.

What the paper actually reported

The headline result was a reduction of up to 60.3% in main-agent token consumption, alongside end-to-end benchmark improvements of as much as 5.5 percentage points.

Both figures require context.

The 60.3% figure covers the main agent

The reported reduction applies to the main coding agent’s trajectory—not total system inference.

The explorer still consumes tokens and compute. FastContext does not make repository exploration disappear; it moves that work to a separate model.

That distinction is particularly relevant for local inference. If the explorer runs on your Mac, its tokens no longer carry a per-token API charge. The main agent also receives a cleaner context containing fewer failed searches and irrelevant file reads.

The maximum did not come from the local 4B model

The maximum 60.3% reduction occurred in a GPT-5.4 same-model exploration configuration on SWE-QA. It should not be presented as the expected result of running the 4B model locally.

The trained FastContext models still achieved substantial reductions. In the GPT-5.4/SWE-QA experiments, the 4B variants reduced main-agent token use by roughly 49–50%.

Results varied across main agents and benchmarks, with smaller reductions on some software-engineering tasks.

The evaluation scope was limited

The end-to-end experiments used Mini-SWE-Agent with selected main models and three benchmark families:

• SWE-bench Multilingual
• SWE-bench Pro
• SWE-QA

The results do not automatically transfer to Claude Code, Cursor, Copilot, Codex, or a custom internal agent. Those systems may use different context-management, search, caching, and subagent strategies.

The paper’s findings are promising, but they are not a universal guarantee.

Why the paper was withdrawn

The arXiv history provides a clear timeline:

• June 12, 2026: Version 1 published
• June 17: Version 2 published
• June 18: Version 3 published
• June 30: Version 4 replaced the paper with a withdrawal notice

The notice says:

“The current article involves some product IP issues and needs to be withdrawn and re-approved.”

Earlier HTML versions remain accessible through arXiv’s version history, but the current paper is formally withdrawn and no current PDF is available.

The wording “withdrawn by Shaoqiu Zhang” identifies the arXiv submitter. It does not establish that Zhang made the decision alone or that the other authors disagreed.

It also does not imply research misconduct, fabricated results, or copyright infringement. “Product IP issues” is too broad to support any of those conclusions.

As of this writing, Microsoft has not restored the original public repository or model listings, and no re-approved paper has replaced the withdrawn version.

How the community preserved FastContext

FastContext now exists as a collection of community-maintained artifacts rather than one authoritative distribution.

The main surviving pieces include:

These mirrors are not interchangeable in purpose.

The CAMV1234 repository is useful as a preservation copy. The Manjunath fork adds practical changes for local serving. The Hugging Face repositories provide model weights in formats optimized for different runtimes.

None should be treated as an official Microsoft release.

A note about provenance and trust

Running a withdrawn model from community mirrors carries risks that do not exist with a maintained official release.

Before using it in a sensitive environment:

• Inspect the repository and recent changes.
• Pin a specific Git commit.
• Verify model-file hashes where possible.
• Do not expose the local API server to the public internet.
• Test on a non-sensitive repository first.
• Remember that read-only tools can still read secrets.
• Avoid repositories containing production credentials or private keys.
• Treat community benchmark claims as anecdotal unless independently reproduced.

The repository tools do not edit files, but “read-only” does not mean “risk-free.” The model process can inspect any accessible content within the configured working directory.

Running FastContext on Apple Silicon

Apple Silicon is a practical target because MLX is designed around Apple’s unified-memory architecture.

For most users, the MLX 8-bit conversion is the most balanced option:

• Approximately 4.3 GB of model files
• Smaller than the roughly 8.1 GB BF16 checkpoint
• Compatible with LM Studio and mlx-lm
• Large enough to avoid the most aggressive quantization

A 16 GB Mac is a reasonable starting point, but model size is not the full runtime requirement. The inference engine, prompt state, application overhead, and KV cache also consume memory. A larger context length increases that usage.

The 4-bit MLX model is approximately 2.1 GB, but its model card warns of degraded path grounding in maintainer testing. Those tests were informal and have not been independently reproduced here.

Install the command-line dependencies

Install Homebrew if it is not already available, then run:

brew install uv ripgrep hf

This installs:

• uv, which manages the Python environment
• ripgrep, which FastContext’s Grep tool requires
• hf, the current Hugging Face command-line client

The FastContext repository requires Python 3.12 or newer. uv can manage the required Python version.

Install the FastContext CLI

For preservation and research, the CAMV1234 mirror is the closest community copy of the original repository.

For the local Mac configurations below, the compatibility fork is more practical because it includes fixes for local OpenAI-compatible servers:

git clone https://github.com/manjunathshiva/fastcontext.git
cd fastcontext
uv tool install .

Confirm the installation:

fastcontext --help

Using this fork does not mean its maintainer created FastContext. It is a community-maintained copy with local-runtime changes layered on the withdrawn Microsoft project.

Choose a runtime

There are three straightforward local paths:

1. LM Studio with MLX 8-bit — easiest graphical setup
2. mlx-lm with MLX or BF16 weights — more direct control
3. Ollama or llama.cpp with GGUF — useful if those tools are already part of your workflow

Option A: LM Studio with MLX 8-bit

Download and open LM Studio. Its current Mac requirements include Apple Silicon and macOS 14 or newer, with 16 GB or more of memory recommended.

Search for:

mlx-community/FastContext-1.0-4B-SFT-8bit

Download the MLX 8-bit model, load it, and start the local server from the Developer tab. LM Studio’s OpenAI-compatible API normally listens on port 1234.

Terminal setup with lms

LM Studio includes the lms command after the application has been opened at least once.

Download the model:

lms get mlx-community/FastContext-1.0-4B-SFT-8bit

List downloaded models:

lms ls

Copy the exact model key reported by lms ls, then load it with a stable identifier:

lms load <model-key-from-lms-ls> \
  --identifier fastcontext-local \
  --context-length 32768

Start the server:

lms server start

Configure the FastContext CLI:

export BASE_URL="http://localhost:1234/v1"
export MODEL="fastcontext-local"
export API_KEY="local"
export TEMPERATURE="0.6"
export TOP_P="0.95"
export MAX_TOKENS="4000"

Check the loaded model if the API later returns an error:

lms ps

Option B: mlx-lm

You can serve either the MLX conversion directly from Hugging Face or download the larger BF16 checkpoint.

Serve the MLX 8-bit model

The model card documents this tested dependency combination:

uv tool install "mlx-lm==0.29.1" \
  --with "transformers<5" \
  --with "mlx<0.31"

These pins reflect a known working community configuration. They are not permanent requirements, and later compatible releases may make them unnecessary.

Start the server:

mlx_lm.server \
  --model mlx-community/FastContext-1.0-4B-SFT-8bit \
  --port 8080

Configure the CLI:

export BASE_URL="http://127.0.0.1:8080/v1"
export MODEL="mlx-community/FastContext-1.0-4B-SFT-8bit"
export API_KEY="local"
export TEMPERATURE="0.6"
export TOP_P="0.95"
export MAX_TOKENS="4000"

Serve the BF16 checkpoint

Download the surviving SFT checkpoint:

hf download ShaunGves/FastContext-1.0-4B-SFT \
  --local-dir ./models/FastContext-1.0-4B-SFT

Start the server:

mlx_lm.server \
  --model ./models/FastContext-1.0-4B-SFT \
  --port 8080

For this configuration, set MODEL to the absolute path:

export BASE_URL="http://127.0.0.1:8080/v1"
export MODEL="/absolute/path/to/models/FastContext-1.0-4B-SFT"
export API_KEY="local"
export TEMPERATURE="0.6"
export TOP_P="0.95"
export MAX_TOKENS="4000"

MLX 0.31 introduced a documented server-thread stream problem in some mlx-lm combinations. If generation fails with:

RuntimeError: There is no Stream(gpu, 0) in current thread

use the pinned configuration above or check whether the upstream issue has been resolved in a newer release.

Option C: Ollama with the RL Q8 GGUF

A community GGUF conversion of the 4B-RL model is available for Ollama and llama.cpp.

Pull it with:

ollama pull hf.co/mitkox/FastContext-1.0-4B-RL-Q8_0-GGUF

The community compatibility fork documents an Ollama template problem with this model. In the maintainer’s testing, Ollama derived a template that inserted a <think> block even though the checkpoint uses the non-thinking Qwen3-4B-Instruct-2507 base model. The result was an empty response.

The documented workaround creates a wrapper model with that line removed:

{
  echo 'FROM hf.co/mitkox/FastContext-1.0-4B-RL-Q8_0-GGUF'
  echo 'TEMPLATE """'
  ollama show --template \
    hf.co/mitkox/FastContext-1.0-4B-RL-Q8_0-GGUF |
    sed '/^<think>$/d'
  echo '"""'
} > Modelfile

Register the wrapper:

ollama create fastcontext-ollama -f Modelfile

Configure FastContext:

export BASE_URL="http://localhost:11434/v1"
export MODEL="fastcontext-ollama"
export API_KEY="local"
export TEMPERATURE="0.6"
export TOP_P="0.95"
export MAX_TOKENS="4000"

This workaround comes from community testing and should be treated as runtime-specific. A later Ollama release or updated GGUF template could change the behavior.

Option D: llama.cpp

The same Q8 GGUF can be served directly with llama.cpp:

brew install llama.cpp

Start its OpenAI-compatible server:

llama-server \
  --hf-repo mitkox/FastContext-1.0-4B-RL-Q8_0-GGUF \
  --hf-file fastcontext-1.0-4b-rl-q8_0.gguf \
  -c 32768 \
  --port 8080

Whether the model’s tool-call format works correctly depends on the applied chat template and the llama.cpp version. Verify the first tool-call response before relying on this path for a real workflow.

Run a repository query

Move to the root of the repository you want to explore:

cd /path/to/your/repository

Ask a narrow location question:

fastcontext \
  -q "Where does the agent execute tool calls and add the results back to its context?" \
  --citation

For a more detailed debugging view:

fastcontext \
  -q "Where is request validation implemented?" \
  --citation \
  --verbose

FastContext writes a timestamped trajectory under:

.fastcontext/

Inspect that file when the output is wrong. It can reveal whether the model failed or whether its tools never returned usable evidence.

Three local compatibility problems to watch for

The community compatibility fork documents three recurring issues.

1. A hardcoded ripgrep path

The original code expected ripgrep at:

/usr/bin/rg

Homebrew normally installs it at:

/opt/homebrew/bin/rg

The patched fork now resolves rg from the system PATH.

Verify your installation:

which rg
rg --version

2. Missing tool-call IDs

Some local OpenAI-compatible servers return tool calls with:

{
  "id": null
}

The original client expected an ID and could fail on the first tool turn. The compatibility fork generates one when the server omits it.

3. An incompatible Ollama template

The community GGUF can produce empty responses when Ollama inserts an unwanted <think> line. The wrapper model shown earlier removes it.

These are implementation and runtime problems, not evidence that the underlying paper’s results are invalid. They also do not prove that every reported hallucination came from a broken environment.

Be cautious with quantization claims

The available MLX model cards recommend the 8-bit conversion over the 4-bit version.

According to the maintainer’s informal tests on an M4 Mac:

• The 8-bit build produced accurate citations comparable to the BF16 checkpoint.
• The 4-bit build frequently lost track of repository paths and returned nonexistent citations.

Those observations are useful but limited. They come from a small, maintainer-run test rather than an independent benchmark.

The safe conclusion is:

The 8-bit MLX model is the better-documented default. The 4-bit model should be treated as experimental until broader evaluation is available.

The model cards also suggest:

export TEMPERATURE="0.6"
export MAX_TOKENS="4000"

The lower temperature is intended to reduce improvisation, while the token limit prevents an incorrect stop condition from producing an excessively long response.

Again, these are community-reported settings—not hyperparameters validated by the withdrawn paper.

Integrating FastContext with a coding agent

The CLI is only the explorer. The architectural benefit appears when a primary coding agent delegates repository discovery to it.

The workflow can be as simple as:

1. Ask FastContext where a behavior is implemented.
2. Receive file-and-line citations.
3. Have the main agent read those locations.
4. Let the main agent make and test the change.

The command contract is:

fastcontext \
  -q "Locate the code responsible for retrying failed API requests" \
  --citation

Any coding agent capable of running a shell command can use this pattern. The exact integration will depend on the agent’s skill, plugin, hook, or tool system.

A production integration should also validate the returned paths before trusting them:

• Confirm that each file exists.
• Reject citations outside the repository root.
• Verify that line ranges are valid.
• Inspect the trajectory if a citation is unsupported.
• Fall back to the main agent’s own search when necessary.

FastContext should be treated as a retrieval component, not an unquestionable source of truth.

The broader lesson

FastContext is interesting even if Microsoft never restores it.

The project tests a broader architectural idea: a coding agent does not have to be one model doing everything inside one growing context.

Repository exploration, implementation reasoning, editing, testing, and review can be separated into specialized components. Smaller local models may be useful where the task is narrow, verifiable, and dominated by tool use.

FastContext’s exact benchmark results still need independent replication, and its withdrawn status raises unresolved questions about provenance and future support. The community artifacts are fragmented, and some runtime combinations require manual fixes.

But the central idea survives those limitations:

Repository navigation is a distinct skill—and it may be possible to move much of it away from the most expensive model in the workflow.

On Apple Silicon, the surviving 4B checkpoints are small enough to make that idea practical to explore.

Disclosure: This article is a researched synthesis of the withdrawn FastContext paper, surviving community repositories and model cards, runtime documentation, and community testing. The local performance and quantization observations attributed to community maintainers were not independently reproduced for this article.

Sources and community artifacts

• Current withdrawn arXiv record
• FastContext paper, version 3
• CAMV1234 source preservation mirror
• Community local-runtime fork
• SFT BF16 weight mirror
• MLX 8-bit conversion
• MLX 4-bit conversion
• RL Q8 GGUF conversion
• ONNX conversion
• LM Studio system requirements
• LM Studio CLI documentation
• Hugging Face CLI documentation
• MLX server stream issue