Local Deep Researcher: an Ollama and LMStudio research loop that runs on your own machine

The gap Local Deep Researcher fills: a research loop you can watch

Most research assistants are a black box behind an API. Local Deep Researcher takes the opposite position. The README describes a cycle: generate a web search query from a topic, gather results, summarise them, reflect on the summary to find knowledge gaps, generate a new query for those gaps, and repeat for a user-defined number of cycles. The output is a markdown summary with the sources used. The intended user is someone who already has a local model server running and wants the reasoning trace, not just the answer. Because the loop runs through LangGraph, you can watch each step in LangGraph Studio rather than waiting for a single response. That is the whole pitch: observability of an iterative research process, on hardware you control.

How the search, summarise and reflect cycle is wired

The repository is a Python package named ollama_deep_researcher under src/, packaged by setuptools and declared in pyproject.toml. The runtime is LangGraph, with langgraph>=1.1.0 as the core dependency, plus langchain-community, langchain-ollama and langchain-openai. Search backends are separate dependencies: duckduckgo-search, tavily-python, and an httpx and markdownify pair that suggests page fetching and HTML-to-markdown conversion when FETCH_FULL_PAGE is enabled. The agent graph is driven by a Configuration class in configuration.py, and the README states that environment variables take precedence over that class. Configuration priority is explicit in the README: environment variables first, then the LangGraph UI configuration, then the defaults in the Configuration class. That ordering matters in practice, because a value you set in the Studio UI will be silently overridden by a stale .env entry. The number of iterations is bounded by MAX_WEB_RESEARCH_LOOPS, which defaults to 3. Each loop costs one or more model calls, so that number is also your main cost control.

Installing Local Deep Researcher and running a first research topic

The README starts from a clone and a copy of the example environment file. The second command creates the .env that python-dotenv loads, because langgraph.json points at that file.

git clone https://github.com/langchain-ai/local-deep-researcher.git
cd local-deep-researcher
cp .env.example .env

You need a model server before the agent can do anything. With Ollama, the README shows pulling a model such as deepseek-r1:8b, then pointing the environment at the service. The Ollama endpoint defaults to http://localhost:11434 if OLLAMA_BASE_URL is not set.

ollama pull deepseek-r1:8b

The same values go into .env, where they take precedence over the defaults in the Configuration class:

LLM_PROVIDER=ollama
OLLAMA_BASE_URL="http://localhost:11434"
LOCAL_LLM=model

Launching the server on macOS, Windows and Docker

On macOS the README recommends a virtual environment and then launches the LangGraph dev server through uv, which is fetched by the install script. On Windows the same result comes from pip and the langgraph CLI. The Dockerfile uses python:3.11-slim, installs uv with pip, exposes port 2024, and runs the equivalent uvx command with --host 0.0.0.0. When the server starts, the README says you should see a Ready line, an API on http://127.0.0.1:2024, docs at http://127.0.0.1:2024/docs, and a LangGraph Studio Web UI link. Open that link, set the topic in the configuration tab, and the run appears as a graph you can step through. Firefox is the recommended browser for the Studio UI; Safari users may hit mixed content warnings because the Studio page is HTTPS while the local server is HTTP.

python -m venv .venv
source .venv/bin/activate
curl -LsSf https://astral.sh/uv/install.sh | sh
uvx --refresh --from "langgraph-cli[inmem]" --with-editable . --python 3.11 langgraph dev

On Windows the README uses pip instead of uvx:

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e .
pip install -U "langgraph-cli[inmem]"
langgraph dev

Search backends and the FETCH_FULL_PAGE trade-off

DuckDuckGo is the default search tool and needs no API key, which is why the quickstart works out of the box. Tavily, Perplexity and SearXNG are alternatives selected through SEARCH_API and their respective keys. SearXNG defaults to http://localhost:8888 and is the only option that keeps the search layer local alongside the model. FETCH_FULL_PAGE defaults to false in the README quickstart but is set to True in .env.example, so a fresh clone and a fresh copy of the example file do not behave identically. Fetching full pages gives the summariser more to work with, at the cost of slower loops and more tokens pushed through a local model. The README does not document caching of fetched pages, so repeated loops over the same results re-fetch them. That is the kind of detail that decides whether a three-loop run finishes in a few minutes or much longer on a laptop.

Where Local Deep Researcher breaks: JSON output and model size

The most concrete limitation is stated in the README itself. Some steps require structured JSON output, and some models cannot produce it. The README names DeepSeek R1 7B and DeepSeek R1 1.5B as examples that struggle, and says the assistant falls back to another mechanism when that happens. A fallback path is better than a crash, but it also means the run you get is not the run the graph was designed around, and the README does not describe what the fallback does differently. The second constraint is tool calling. The 8/6/25 update added support for tool calling and gpt-oss, with a warning that gpt-oss models do not support JSON mode in Ollama and that use_tool_calling must be selected in the configuration instead. If you are running a small model on modest hardware, expect to spend time on model selection before the research loop is useful. Local Deep Researcher is also the wrong tool when you need a hosted product with a stable interface: the package version in pyproject.toml is 0.0.1, and the README does not document rollback or upgrade procedures.

How it compares with GPT Researcher

GPT Researcher is the closest widely used alternative, and the difference is architectural rather than cosmetic. GPT Researcher is built around a planner and executor pair that produces a report through a fixed pipeline, and its documentation centres on running it as a Python package or a service with a hosted model provider. Local Deep Researcher is a LangGraph graph first: the loop is the product, and the LangGraph Studio UI is the intended interface. It also commits to local inference through Ollama or LMStudio. If you want a report generator you call from a script, GPT Researcher fits that shape better. If you want to watch the reflection step decide what to search next, and you want the model to stay on your machine, Local Deep Researcher is the more direct fit. The cost profile differs too: a local loop trades API spend for GPU time and wall-clock latency.

Editorial conclusion

Adopt Local Deep Researcher if you already run Ollama or LMStudio and want the search, summarise, reflect loop visible in LangGraph Studio rather than hidden behind a hosted API. Skip it if you need a polished end-user product, or if your only available models cannot emit structured JSON and you have no way to load a larger one. Before committing, verify that your chosen model produces the required JSON output, and check whether you need tool calling instead: the README warns that gpt-oss models do not support JSON mode in Ollama and that use_tool_calling must be selected for them.

Frequently asked questions

Official sources

1. Issues
2. langchain-ai/local-deep-researcher on GitHub
3. License: MIT
4. README