OpenResearcher: A Fully Open Pipeline for Deep Research Trajectory Synthesis

The problem OpenResearcher targets: synthesizing deep research trajectories without paying per search call

Deep research agents need long trajectories, often 100+ turns, to learn multi-step retrieval and reasoning. The README describes the OpenResearcher dataset as 96K high-quality trajectories with 100+ turns generated by GPT-OSS-120B using native browser tools. Producing that volume through commercial search APIs would mean paying per query across every turn of every trajectory, which is the cost wall the project is built to avoid. OpenResearcher replaces external search APIs with a self-built retriever over a dedicated corpus of roughly 11B tokens. The README frames this as eliminating the need for external Search APIs and significantly reducing training costs. The audience is therefore narrow and specific: researchers and engineers who want to train or distill a deep research model and who are willing to run their own retrieval stack. It is not aimed at teams that just want a hosted research assistant. The repository bundles four things that are usually scattered: the trajectory dataset, the 30B-A3B model, the distillation recipe described in the paper, and a lightweight evaluation framework. The README states the model reaches 54.8% on BrowseComp-Plus and claims it surpasses GPT-4.1, Claude-Opus-4, Gemini-2.5-Pro, DeepSeek-R1 and Tongyi-DeepResearch. Those are the project's own reported numbers, and the evaluation logs are published on Hugging Face for inspection rather than taken on faith.

How the pipeline is assembled: retriever, corpus, trajectory generation, distillation

The architecture visible in the README has four moving parts. First, a corpus of about 11B tokens published as OpenResearcher-Corpus on Hugging Face. Second, a self-built retriever that indexes that corpus and serves search results to the agent, so the agent's browser and search tools resolve against local data instead of a remote API. Third, a trajectory generator: GPT-OSS-120B with native browser tools produces the 96K trajectories, which are then published as OpenResearcher-Dataset. Fourth, a distillation step that trains the 30B-A3B model on those trajectories, with the recipe documented in the arXiv paper. The evaluation framework sits alongside this and is described as lightweight. The data flow is generator to dataset to distilled model, with the retriever as shared infrastructure for both generation and evaluation. This matters because it means the same retrieval layer you use to synthesize data is also the one you benchmark against, which keeps the training and evaluation distributions aligned. The README also notes the data was adopted by NVIDIA's Nemotron 3 Ultra and that OpenResearcher powers deep research trajectory generation in NVIDIA's NeMo Data Designer. Those are adoption claims from the project's news section, not independent measurements, but they indicate the pipeline has been used outside the originating lab.

Getting it running: environment setup, configuration, and the two benchmark paths

The README's table of contents lays out the path: Environment Setup with Installation and Deep Research Benchmarks Preparation, then Configuration, then Quick Start, then Benchmark OpenResearcher. Benchmarking has two documented routes. Example 1 is BrowseComp-Plus with a local search engine, which is the path that uses the self-built retriever. Example 2 is GAIA with the Serper API, which the README explicitly labels as no local search needed. That second example is the escape hatch: if you do not want to stand up the local corpus, you can point the harness at Serper instead. The repository also documents an Evaluation step and a Quick Commands section, and a separate optional section titled Train Your Own OpenResearcher, added in February 2026, which covers the training code. GAIA and BrowseComp-Plus are the two named benchmark integrations in the README, with BrowseComp, GAIA and xbench-DeepSearch mentioned as the broader benchmark set the model is evaluated on. What the README does not give is the exact command lines or config keys in the excerpt available here, so the concrete flags and file names need to be read from the repository itself rather than reconstructed from this description. The presence of a Gradio demo on Hugging Face Spaces means you can inspect model behaviour before installing anything locally.

The local corpus is the point and also the constraint

Running retrieval against a self-hosted index over roughly 11B tokens is the design decision that makes the cost story work, and it is the same decision that limits where OpenResearcher fits. You are trading API spend for storage, indexing time, and serving hardware. The README does not state the index size, the expected query latency, or the minimum hardware for either the retriever or the 30B-A3B model, so those numbers have to be established by whoever deploys it. A 30B-A3B model is a mixture-of-experts design, which means memory requirements depend on total parameters rather than active ones, and the README gives no serving guidance for it. The second limitation is freshness. A fixed corpus cannot answer questions about events after the corpus was assembled, so the local search path is unsuitable for time-sensitive research even though it is cheaper. That is precisely why the GAIA example uses Serper. The third limitation is licence clarity. The repository metadata shows the licence as unknown, and the README does not name a licence for the code, the dataset, or the model weights. Until that is resolved, adoption inside a commercial product carries unresolved risk. The fourth is that the headline benchmark number is self-reported, and BrowseComp-Plus is itself hosted by the same research community, so the comparison table should be read with the evaluation logs rather than instead of them.

Where it sits next to a search-API agent framework

The closest comparison is an agent framework that calls a commercial search API, for example a LangChain or LlamaIndex agent wired to Serper, Tavily or Bing. The difference is not the agent loop, which in both cases is a model deciding when to issue a search and what to do with the result. The difference is where retrieval happens and who pays for it. An API-backed agent gets fresh index coverage, no corpus to host, and per-query billing that scales with trajectory count. OpenResearcher inverts all three: fixed corpus, local hosting cost, and near-zero marginal cost per query once the index is up. For trajectory synthesis at 96K examples with 100+ turns each, the marginal cost difference is the whole argument. For a production assistant answering questions about last week, the API-backed approach is the correct one and OpenResearcher is the wrong tool. The second comparison is against using the published dataset and model without the pipeline. OpenResearcher-Dataset and OpenResearcher-30B-A3B are on Hugging Face independently of the repository, so you can fine-tune on the trajectories or serve the model without ever standing up the retriever. That is a legitimate and much cheaper adoption path if you only need the artifacts and not the synthesis machinery.

Maintenance, licensing, and what the repository does not tell you

The repository is active, with a last push in June 2026 and no releases retrieved, which means there is no tagged version to pin against. You will be tracking the main branch. The training code arrived in February 2026, four months after the initial trajectory work, so the training path is the newer and less exercised part of the repository. The evaluation logs are published separately on Hugging Face, which is useful for auditing but also means the evaluation story spans two hosting locations. On licensing, the metadata says unknown and the README does not clarify. The dataset and model are on Hugging Face under the OpenResearcher organization, and their cards are the place to check terms for the artifacts, while the GitHub repository is the place to check terms for the code. None of that is legal advice, and a licence marked unknown should be treated as unresolved rather than permissive. The paper at arXiv 2603.20278 is cited as containing the practical insights into pipeline design, so the design rationale for the retriever and the distillation recipe lives there rather than in the README. Anyone evaluating this for a team should read the paper before assuming the repository is self-explanatory.

Editorial conclusion

Adopt OpenResearcher if you need to generate or fine-tune on long-horizon deep research trajectories and want to avoid per-call search API costs. Skip it if you need a production retrieval service or cannot host the roughly 11B-token corpus locally. Before committing, confirm the licence terms on the GitHub repository and the Hugging Face dataset and model cards, and verify that the BrowseComp-Plus local search engine setup completes with your hardware.

Official sources

1. Issues
2. Project website
3. README
4. TIGER-AI-Lab/OpenResearcher on GitHub