OpenSeeker: a search agent released with its training data

What OpenSeeker is and what was released

OpenSeeker is an open-source search agent system that claims to democratise access to frontier search capabilities by fully open-sourcing its training data.

The framing is about data rather than weights. The stated key achievement is that OpenSeeker represents the first work by a purely academic team to achieve state-of-the-art performance on frontier search benchmarks while simultaneously open-sourcing the full training data.

Two versions are available. The first, released on 2026-03-17, open-sourced all data and models, and used 11.7K training examples to fine-tune Qwen3-30B-A3B-Thinking-2507, scoring 48.4 percent on BrowseComp-ZH, 29.5 percent on BrowseComp, 74.0 percent on xbench-DeepSearch and 59.4 percent on WideSearch. The second, released on 2026-05-12, is described as achieving state-of-the-art performance across four benchmarks among 30B-scale ReAct-based search agents with simple supervised fine-tuning, at 46.0 percent on BrowseComp, 58.1 percent on BrowseComp-ZH, 34.6 percent on Humanity's Last Exam and 78.0 percent on xbench, which the project says surpasses even Tongyi DeepResearch, trained with a heavy continued pretraining plus supervised fine-tuning plus reinforcement learning pipeline.

So the two papers are the v1 and v2 arXiv entries, and the assets are on Hugging Face: a dataset for the v1 data and supervised fine-tuned 30B models for both versions.

The interesting claim is the last comparison. Beating a system trained with reinforcement learning using simple supervised fine-tuning on published data is a statement about the data, and that is the contribution a reader is being offered.

Setting up the environment and running the first evaluation

The installation is a clone, a conda environment and a requirements file, and it is shared between the two versions.

# Clone repository
git clone https://github.com/rui-ye/OpenSeeker.git
cd OpenSeeker

# Create conda environment
conda create --name openseeker python=3.10
conda activate openseeker
pip install -r requirements.txt

The model is then deployed as a server. For the first version, the model repository is cloned from Hugging Face, the MODEL_PATH in run_openseeker.sh is edited to point at the downloaded directory, and the server is started with bash run_openseeker.sh. The model download step needs git-xet, which the documentation installs with brew install git-xet followed by git xet install.

The search and evaluation APIs are then configured by editing setup_env.sh with your endpoints and keys and sourcing it.

# Edit setup_env.sh with your API endpoints and keys
source setup_env.sh

Answer generation and scoring are two separate scripts, and the second version uses a different generation entry point with the same evaluator.

python3 eval/generate_answer.py \
    --dataset_path data/your_dataset.jsonl \
    --out_dir outputs/openseeker_v1 \
    --max_workers 100

python3 eval/eval.py \
    --data_path outputs/openseeker_v1/result_tool200.jsonl \
    --max_workers 20

The output file name, result_tool200.jsonl, carries a hint about the tool configuration used, which is the kind of detail that matters when you are trying to reproduce a number and finding that your tool budget differs.

The three tools and the shape of the codebase

The source tree is small enough to read in an afternoon, and the project structure listing shows the whole of it.

The eval/ directory holds the evaluation script, the two answer generation scripts, one for the first version and one for the second, and prompt.py with the prompt templates. The src/ directory holds the core, with a separate LLM tool interface module per version, llm_tool_openseeker.py and llm_tool_openseeker_v2.py, a config directory containing a chat template in Jinja form, and a tools directory.

The tools directory has three files in it. search.py is the search tool, visit.py is the web visit tool, and e2b_sandbox_tools.py holds the E2B sandbox tools, which are for the second version. At the top level there is the model server startup script, the environment variable template, and the README.

So the agent is a ReAct loop over three tools, and the version difference is in the tool interface and in the presence of the sandbox. The v2 setup documentation asks you to configure the search, visit, scorer and E2B sandbox APIs, while the v1 setup mentions the search and evaluation APIs. The scorer is the piece that grades a candidate answer, and the sandbox is what lets the agent run code rather than only read pages.

That distinction is the substantive difference between the two versions, and it is why the v2 tool budget matters: a sandbox is a billed resource and a source of nondeterminism that the v1 agent did not have.

The requirements file confirms the stack. It pins exact versions for aiohttp, httpx, openai, pydantic, numpy, pillow, tiktoken, jsonschema, tqdm and the rest, and the ones that are not obvious tell you the design. qwen-agent at 0.0.34 is the agent loop library, tavily-python is the search backend, Wikipedia-API is a knowledge tool, e2b and e2b-code-interpreter are the sandbox, dashscope is a model provider, and Jinja2 with a chat_template.jinja is the prompt templating.

Where OpenSeeker is the wrong choice

The first limitation is that this is a research artefact rather than a product. The agent needs a search API, a visit API, a scorer and, for the second version, a sandbox, all of which are paid services you configure with your own keys. The setup script exists precisely because the project cannot supply them.

The second is the model size. The checkpoints are 30B class, deployed as a server, which means a machine with a substantial GPU. The v1 model is a fine-tune of Qwen3-30B-A3B-Thinking-2507, and the repository ships the server script rather than a way to run it small.

The third is the evaluation dependence on external services. The score depends on which search backend you configured and how the visit tool behaves, and the generated file name in the documentation, result_tool200.jsonl, suggests the tool budget is part of the result. A number reproduced with a different tool set is not the same number, and the documentation does not spell out the exact configuration used for the headline figures.

The fourth is the release pace. The recent releases section says there are no GitHub releases, the last push was on 2026-08-26, and the news entries are dated March and May 2026. The repository is a snapshot of a research push rather than a maintained framework, and there is no versioned package on PyPI to pin against, only a requirements file with exact pins that a future commit can change.

The fifth is the licence. The licence field on the repository records no identifier, which is an unusual thing for a project publishing both models and data, and the README does not state terms either. For a dataset intended to be reused and trained on, that is the first thing to sort out.

How OpenSeeker compares with an agent framework and with a hosted research product

The comparison with a general agent framework is the practical one, and the difference in approach is that OpenSeeker ships the policy rather than the scaffolding. qwen-agent is in the requirements, so the loop mechanics, the tool calling and the message plumbing come from a library, and what this repository adds is the trained policy, the tool implementations and the evaluation harness.

That means the sensible way to use it is as a reference implementation to read and to reproduce, and to swap in your own tools. The tool interface is a small number of Python modules, so replacing search.py or visit.py with your own backend is a contained change.

The second comparison is with a hosted research product such as a commercial deep research agent. The hosted option gives you a working answer today with per-query pricing and no GPU, and it gives you no data, no training set and no way to reproduce a trajectory. OpenSeeker gives you the opposite: 11.7K training examples, two papers, a model and an evaluation harness, and a system you have to run.

The third comparison is with a self-built agent over the same APIs. With a model that is good at tool use and a handful of prompt templates, a competent team can build a ReAct loop over search and visit in a day. What that team does not get is the training data, and the data is the point here, since the claim is that simple supervised fine-tuning on published trajectories is enough to reach the reported numbers.

The fourth comparison is with the reinforcement learning route the project benchmarks against. The README is explicit that the baseline, Tongyi DeepResearch, is trained with a heavy continued pretraining plus supervised fine-tuning plus reinforcement learning pipeline, and that OpenSeeker surpasses it with simple supervised fine-tuning. If that holds, the practical implication is that the expensive part of a frontier search agent is the data and not the training algorithm, which is a claim worth taking seriously and also a claim worth trying to reproduce.

Licence, citations and what to check before you run it

The licence field on the repository records no identifier, and the README does not discuss licensing. For a project whose central contribution is a published dataset intended for other people to train on, that is a significant gap, and it is the first thing to ask about.

The project is not archived and the last push was on 2026-08-26, so the code is current as of that date. The recent releases section says there are no GitHub releases, and the assets live on Hugging Face instead, with the dataset and both model checkpoints, and the paper links in the README point to a Hugging Face papers page for the first version and an arXiv PDF for the second.

Two citation entries are given, and both are worth using as written.

@article{du2026openseeker,
  title={OpenSeeker: Democratizing Frontier Search Agents by Fully Open-Sourcing Training Data},
  author={Du, Yuwen and Ye, Rui and Tang, Shuo and Zhu, Xinyu and Lu, Yijun and Cai, Yuzhu and Chen, Siheng},
  journal={arXiv preprint arXiv:2603.15594},
  year={2026}
}

The second is OpenSeeker-v2: Pushing the Limits of Search Agents with Informative and High-Difficulty Trajectories, at arXiv 2605.04036, with a slightly different author list.

Three things to check before you run anything.

The licence of the data and the weights, which is not stated and which matters more here than for most research code.

The tool configuration behind the reported numbers, since the generated file names carry a tool budget and the headline figures were produced with a particular set of endpoints that the setup script expects you to fill in.

And the scale of the run. A 30B checkpoint server, an evaluation with up to a hundred workers and a paid search and sandbox API per query is a research budget, not a smoke test, so the first thing to try is the evaluator on a small dataset before anything else.

Editorial conclusion

OpenSeeker suits a research group that wants to study how frontier search agents are trained rather than to build one, and that values the 11.7K published training examples as much as the released checkpoints. It is the wrong tool for a product team that wants a working search assistant today, since the agent needs paid search, visit, scorer and sandbox APIs configured before it does anything, and the models are 30B class. Before you start, read the paper and the data card, because the release is a research artefact whose headline numbers depend on the tool configuration the setup script asks you to supply.

Frequently asked questions

Official sources

1. Issues
2. PolarSeeker/OpenSeeker on GitHub
3. README