Four Open-Source Deep Research Agents, Tested Honestly

Open-source deep research agents are the self-hosted answer to the deep-research modes that every major AI vendor now ships — a program that plans a set of research questions, runs them against the web or your own documents, and returns a long, cited report instead of a chat reply. Four projects dominate the conversation, and they are routinely compared as if they were interchangeable.

They aren’t interchangeable. GPT-Researcher is a report-generation building block. LangChain’s Open Deep Research is an orchestration graph you are expected to reconfigure. Stanford’s STORM is a pre-writing system that produces outlines, not answers. Local Deep Research exists so that no query ever leaves your machine. Picking one by star count is how teams end up six weeks into the wrong architecture.

This guide profiles all four against the same four questions: what it actually does, how alive the project is, what a report costs, and where it falls short of a vendor deep-research mode. Every figure is attributed to the project that published it, and the ones we could not independently corroborate are labeled as such rather than quietly repeated.

The category was defined by the vendors. OpenAI’s deep research mode in ChatGPT launched on a browsing-and-analysis-optimized version of o3, took roughly five to thirty minutes per report, and was framed by OpenAI as accomplishing in tens of minutes what would take a human many hours. That framing set the expectation everything else in the category is measured against: not a faster search box, but a slow, deliberate, multi-source synthesis job.

The commercial shape matters as much as the technical one. Per the April 2025 update logged on OpenAI’s deep research page, the full mode became quota-metered on ChatGPT consumer plans — 25 full-mode queries a month on Plus, Team, Enterprise and Edu, 250 on Pro and 5 on Free, with overflow falling through to a lighter, cheaper o4-mini-powered tier. We covered the product side of Google’s equivalents in our Deep Research Max agentic agency playbook and the broader Gemini Deep Research guide.

Open-source projects attack that shape from two directions at once. They remove the quota — you pay your own model and search bills instead of a fixed allowance — and they remove the black box, which is the part that matters for regulated work. Every project in this guide ships under MIT or Apache-2.0, which means self-hosting, forking and commercial deployment carry no license negotiation. What they do not remove is engineering effort, and that is the cost nobody budgets for.

GPT-Researcher (assafelovic/gpt-researcher) has 28,868 stars and 3,911 forks against 191 open issues at the time of writing, Apache-2.0, created in May 2023 and most recently pushed on July 18, 2026. That three-year run matters: it predates the vendor deep-research modes it is now compared against.

Its architecture is a clean three-role split. A Planner Agent turns the brief into a set of research questions. Execution Agents crawl the web in parallel, one per question. A Publisher Agent aggregates the findings into the final report. The README credits the Plan-and-Solve paper (arXiv 2305.04091) and the original RAG paper (arXiv 2005.11401) as direct influences — and, notably, cites STORM’s paper (arXiv 2402.14207) as an influence on its multi-agent workflow. That lineage point is worth holding onto for section 04.

Output is deliberately long-form: the project states that reports exceed 2,000 words and cite more than 20 web sources, with export to PDF, Word and Markdown, plus optional AI-generated inline images via Google Gemini. MCP integration lets a run blend public web results with GitHub repositories, databases and internal APIs, which is the feature that turns it from a research toy into something you can point at your own corpus alongside a conventional RAG layer.

Two timing figures circulate for this project and they describe different things. The project site quotes 30 to 60 seconds for deep research and 2 to 5 seconds for quick search. The README separately describes a dedicated Deep Research mode that does tree-like exploration with configurable depth and breadth, and puts that at roughly five minutes and about $0.40 per task on o3-mini-class models. Both are project-stated. If you are budgeting, budget for the tree-search number, not the headline latency.

LangChain’s Open Deep Research (langchain-ai/open_deep_research) carries 12,520 stars and 1,771 forks under an MIT license at the time of writing, and it is the most actively maintained project in this comparison — its most recent push landed within days of this writing. The README describes it as a simple, configurable, fully open-source deep research agent that works across many model providers, search tools and MCP servers, with performance the maintainers describe as on par with many popular deep research agents.

The pipeline is four stages orchestrated in LangGraph: a Researcher Agent running iterative search, a Summarization component, a Compression module that fits the accumulated findings back into a usable context, then Report Generation. Both agentic and structured processing modes are exposed. Model choice runs through LangChain’s universal init_chat_model() API, so any provider that supports structured outputs and tool calling drops in — the same substitutability that makes LangChain’s open-source agent-workflow tooling attractive to teams that refuse to be locked to one model vendor.

Retrieval defaults to the Tavily search API, with native web search available for OpenAI and Anthropic models and full MCP compatibility for private sources. That default is the single biggest hidden cost in this whole category, and section 07 puts a number on it.

That 15% relative jump from a model swap is the most useful single data point in this guide. It says the orchestration graph is not the whole story — a meaningful share of output quality is bought at the model layer, which means any comparison of these projects that holds the model constant is measuring the harness, and any comparison that does not is measuring both at once. Most published roundups do not say which they did.

STORM (stanford-oval/storm) is the outlier in every direction. It carries 30,813 stars and 2,887 forks under MIT at the time of writing — the highest star count in this set — and its most recent push was September 30, 2025, roughly ten months before this guide was published. Nothing about that is a verdict on code quality. It is a warning about the assumption that stars indicate momentum.

It is also the only project here that started as academic research rather than a tool. STORM stands for Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking, comes out of Stanford’s OVAL lab, and was published at NAACL 2024. Its subject is the pre-writing stage of long-form article creation, which is a genuinely different problem from report generation: it discovers diverse perspectives on a topic, simulates conversations in which writer-personas holding those perspectives question a topic expert grounded in trusted web sources, and curates the result into an outline before a single sentence of the article is drafted.

The published evaluation is the strongest independent-ish evidence in this category. STORM’s generated articles were reported as 25 percentage points more likely to be judged well-organized and about 10 percentage points broader in topic coverage than the best baseline method it was compared against, and Wikipedia editors confirmed the pre-writing output was helpful. There is a live, no-signup demo at storm.genie.stanford.edu, and a follow-on system, Co-STORM, extends the idea toward collaborative human-AI research — though the project page names it without detailing its added mechanics, so treat Co-STORM specifics as under-documented.

Local Deep Research (LearningCircuit/local-deep-research) is the only project here whose primary axis is privacy rather than report quality. Its README positioning is unambiguous: an AI research assistant you control, run locally for privacy, using any LLM, building your own searchable knowledge base — you own your data and see exactly how it works.

The recommended stack is Ollama for model serving, SearXNG as a self-hosted meta-search layer, and the project’s own web UI on top, deployable via Docker, Docker Compose or a plain pip install local-deep-research. It reaches 10 or more search engines including arXiv, PubMed and your own private documents, runs against local or cloud models through llama.cpp, Ollama and others, and stores results in SQLCipher-encrypted storage. The hardware floor is modest: an AVX-capable CPU — Intel Sandy Bridge or AMD Bulldozer, 2011 or newer — or ARM64.

The README also carries an accuracy headline of roughly 95% on SimpleQA, and the claim string names its own hardware pairing: a Qwen3.6-27B-class model on a single RTX 3090. That is self-reported and inseparable from that specific configuration. Read it as evidence that a well-configured local stack is not obviously hopeless on short factual retrieval — not as a portable accuracy number you can quote to a stakeholder.

The roundups in this category rank on stars or on prose impression. Neither tells you whether the project has been touched this quarter. The table below pairs the star count with the maintenance signal for every project surveyed — which is precisely the pairing that makes STORM’s profile legible, and the reason we built the roster this way rather than sorting by popularity.

Star counts, forks, licenses and last-push dates were read from each project’s GitHub repository at the time of writing. Two counts are marked page-sourced because the API was rate-limited during the research pass and the figure came from the repository page instead — they are directionally right and deliberately kept out of any headline claim. Two projects have no captured last-push date for the same reason; the absence is recorded rather than guessed.

Read the table as two distinct clusters. GPT-Researcher and Open Deep Research are engineering products with maintenance cadence to match. STORM and the smaller peers are reference implementations of ideas — enormously useful to read, riskier to build a production dependency on. This is the same split you see in the wider open-source agent ecosystem, mapped in our open-source agent-projects map and its sibling deep dives on agent memory layers and browser and computer-use agents.

“Free and open source” describes the license, not the run. A deep research agent spends money in three places: model tokens, search API calls, and the engineering time to keep the thing working. The first two are quantifiable from published figures. The third is the one that decides whether self-hosting was worth it.

Search is the cost most teams miss, because it is invisible until the invoice arrives. Tavily — the default backend for both GPT-Researcher and Open Deep Research — lists pay-as-you-go search credits at $0.008 each at the time of writing, discounted to $0.005 per credit on its Growth tier at 100,000 credits for $500 a month, with a free allowance of 1,000 credits a month. A basic search costs one credit, an advanced search two, and a deep-research-style call can consume anywhere from 4 to 250 credits depending on how deep the run goes.

Line those three up and a pattern falls out that neither project states directly: a researched question, done properly, costs somewhere between roughly twenty cents and a couple of dollars all in. That is the number to plan against. It also explains the shape of the vendor quotas — 25 full-mode queries a month on a consumer plan is a sensible allowance if each one carries that kind of marginal cost, and it tells you exactly where self-hosting starts to pay: at volumes far above what a subscription meters, or at data sensitivities a subscription cannot accept.

The forward view is that this band compresses rather than disappears. Model prices per token have fallen steadily and the harness overhead is mostly search calls, which have their own pricing floor. What is more likely to change is where the work happens: as smaller local models get good enough for the summarize-and-compress middle of these pipelines, the expensive frontier model gets reserved for planning and final synthesis, and the per-report cost drops without the report getting worse. Local Deep Research is already built for that architecture. The others would need to be configured into it.

Being honest about this is the whole point of the guide. A vendor deep-research mode gives you a tuned prompt stack, a rendering layer, retry and failure handling, and a research corpus reached through infrastructure you do not operate — for a fixed monthly allowance rather than a metered bill that scales with curiosity. None of the open-source projects here ships that experience out of the box, and pretending otherwise sets teams up for a disappointing first week.

The gap is narrowest where the job is well-specified and the sources are yours. Feed a self-hosted agent your own document corpus, your own crawl of a competitor set, or a private database through MCP, and it will beat a vendor mode that cannot see any of that. The gap is widest on open-ended, unfamiliar-domain questions where the vendor’s tuning and infrastructure do the heavy lifting — which is also, unhelpfully, the kind of question people use to evaluate these tools.

There is a middle path worth naming. Prompt discipline moves the output quality of any of these systems more than the choice between them does; the structure we use for scoping a research run is the same one in our deep-research website audit prompt method, and it transfers unchanged to a self-hosted agent. Get the brief right first, then argue about the harness.

Four jobs, four defaults. The only wrong move is choosing by popularity, because the popularity ranking and the maintenance ranking in this category point in different directions.

Whichever you pick, run the same evaluation you would run on a vendor: ten questions you already know the answers to, scored by a human on citation accuracy and coverage, before anything reaches a client deliverable. That evaluation is also the thing that tells you whether the harness or the model is your limiting factor — and if it is the model, the cheapest fix is a configuration change, not a migration. We build exactly this kind of comparative eval into our agentic SEO engagements and, for teams standing up an internal research capability, our AI transformation work.