Local Deep Research: agentic search that runs on your own GPU
~95% on SimpleQA (e.g. Qwen3.6-27B on a 3090). Supports all local and cloud LLMs (llama.cpp, Ollama, Google, ...). 10+ search engines - arXiv, PubMed, your private documents. Everything Local & Encrypted.
At a glance
- What is it?
- Local Deep Research is a Python research assistant that chains local or cloud LLMs to ten-plus search backends and stores everything in an encrypted SQLCipher database. The README claims around 95 percent SimpleQA accuracy for a fully local Qwen3.6-27B setup on a single RTX 3090, and the install path is genuinely short, but the search backend and the LLM endpoint are both things you have to stand up yourself.
- Who is it for?
- Adopt Local Deep Research if you already run Ollama or llama.cpp on a machine with an AVX-capable CPU and you want research output that never leaves your network, plus a SQLCipher database you can query later. Do not adopt it if you want a managed service, if you cannot run SearXNG or another supported backend, or if you are on Docker Desktop and unwilling to work around the host networking problem.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is the retrieval loop, not the model
Running a capable model locally stopped being the hard part. What most self-hosted setups still lack is the loop around the model: issue a query, read several sources, decide what is still missing, issue a follow-up query, and attach citations to the final answer. Hosted deep research products do that work for you, at the cost of sending your questions, your documents and your reading list to someone else's servers. Local Deep Research targets that gap specifically. The README describes it as an "AI-powered research assistant for deep, agentic research" that performs research "using multiple LLMs and search engines with proper citations." The audience is narrow and identifiable: people who run a home server or workstation, already have Ollama or another OpenAI-compatible endpoint, and want the retrieval trace stored locally rather than in a vendor account. The topics list confirms the intent, mixing arxiv, pubmed, searxng and self-hosted with encryption and home-automation.
How the agentic loop and the encrypted store fit together
The architecture visible in the README has three moving parts. First, a model endpoint: any local or cloud LLM, with Ollama, llama.cpp, Google and OpenAI all named. Second, a search layer, described as ten or more engines including arXiv, PubMed, Brave and SearXNG, plus the option to search your private documents. Third, a persistence layer built on SQLCipher, which the README advertises as an encrypted database and which the pip install notes say ships as pre-built wheels so no compilation is needed. The web UI on port 5000 is the front door; the research process itself is a Python application that drives the model against the search backends and writes results into that encrypted store. The claim attached to this design is a benchmark result: roughly 95 percent on SimpleQA with n=500, and 77 percent on xbench-DeepSearch with n=100, both reported for a fully local Qwen3.6-27B configuration on a single RTX 3090. The README frames this as the first open-source project to report those numbers fully local on one GPU, and points to a benchmark dataset on Hugging Face rather than to a reproducible harness in the repository. That distinction matters if you intend to treat the number as a purchasing decision. The dataset is public; the exact run configuration that produced it is not described in the material I have, so treat the figure as a claim to reproduce, not a specification.
Three install paths and the environment variables that matter
The README gives three routes. The Docker run recipe starts Ollama on port 11434, pulls gpt-oss:20b, starts SearXNG on port 8080, then starts the application container with host networking, a named volume, and two environment variables: LDR_DATA_DIR set to /data, and LDR_SEARCH_ENGINE_WEB_SEARXNG_DEFAULT_PARAMS_INSTANCE_URL set to http://localhost:8080. That second variable is doing more than pointing at a URL. The README states that since v1.10.3, private or localhost engine URLs are blocked by default, and passing the value through this variable both pins the address and marks it operator-approved. It also becomes read-only in the web UI. The documented alternative is an origin allowlist, described in docs/SearXNG-Setup.md. The Docker Compose path is a single curl of docker-compose.yml followed by docker compose up -d, with docker-compose.gpu.override.yml layered on for NVIDIA on Linux. The pip path is pip install local-deep-research followed by python -m local_deep_research.web.app, and the README is explicit that you still need Ollama or any OpenAI-compatible endpoint plus SearXNG running alongside it. Two platform caveats are stated outright. Host networking only works on native Linux; on Docker Desktop it silently fails to publish port 5000 and leaves localhost pointing at the LDR container itself, so the container cannot reach Ollama or SearXNG. And LDR needs an AVX-capable CPU, Intel Sandy Bridge or AMD Bulldozer from 2011 onward. There is also an escape hatch for encryption trouble: export LDR_BOOTSTRAP_ALLOW_UNENCRYPTED=true falls back to standard SQLite.
Where the setup breaks, and what it costs you
The failure modes here are mostly environmental, and they are documented rather than hidden, which is worth noting. The host networking issue on Docker Desktop is the sharpest one: the container starts, the port does not publish, and the reason is not obvious from the outside. The README sends you to a FAQ entry with a working docker run recipe for Windows and WSL2, so a workaround exists, but the default command in the quick start is wrong for a large fraction of desktop users. The AVX requirement quietly excludes older hardware, and the README's own note trails off mid-sentence about scientific Python dependencies, so the exact boundary is not fully spelled out. PDF export on Windows needs Pango installed separately. The SearXNG allowlisting behaviour added in v1.10.3 is a security improvement that also creates a migration step for anyone who upgraded from an earlier version with a private engine URL configured. On the encryption side, the fallback to plain SQLite is a single environment variable away, which means the security property depends on the operator not taking the easy path when SQLCipher misbehaves. None of these are reasons to avoid the project. They are reasons to read docs/installation.md, docs/SearXNG-Setup.md and docs/faq.md before you start rather than after something fails.
The alternative: hosted deep research versus this
The obvious comparison is a hosted deep research feature from a model vendor. The difference is not answer quality, which I cannot compare from the material here. The difference is where the retrieval trace lives. A hosted product runs the search loop on infrastructure you do not control, using a search index you did not choose, and returns a report. Local Deep Research runs the loop against backends you configure, which is why arXiv, PubMed, SearXNG and private documents are all first-class options rather than fixed integrations. That matters most when your sources are internal documents or when the queries themselves are sensitive. It matters less if you just want a good summary of public web pages, because you will spend time running Ollama, running SearXNG, and debugging container networking to get a result a hosted tool would return in one request. A second comparison is to a plain retrieval-augmented generation stack you assemble yourself: embeddings, a vector store, a prompt template. That approach gives you full control and no agentic query reformulation. Local Deep Research's value is precisely the multi-step search loop with citations, plus the encrypted store, packaged so you do not write it. If you already have a RAG pipeline you like, the overlap is smaller than it looks.
Maintenance, licensing and the release cadence
The project is MIT licensed, which permits commercial use, modification and redistribution with the licence text retained. I am not giving legal advice; if you plan to ship this inside a product, read the MIT terms and check the licences of the dependencies you pull in, since SQLCipher and the scientific Python stack carry their own. The release history shows v1.10.5, v1.10.6 and v1.10.7 within roughly six weeks in August 2026, and the repository was pushed as recently as September 2026. That cadence is a real maintenance consideration in both directions: fixes arrive quickly, and patch-level releases land often enough that pinning a version is sensible for anything you depend on. The v1.10.3 allowlisting change is the concrete example of why. A behavioural change to search engine URL handling shipped inside the 1.10 line, so an unattended upgrade can alter how your configured engine is treated. The upgrade cost itself is low for the Docker path (pull the new image, keep the volume) and for pip (reinstall the package), but you should read the release notes for the 1.10.x series before moving, because the search engine configuration surface is where the changes have been landing.
Who should run this, and what to check first
This fits a specific operator: someone with a Linux box or a home server, an AVX-capable CPU, a GPU they are willing to dedicate to a 27B-class model, and a preference for keeping research queries on their own network. It also fits anyone whose sources are private documents plus arXiv or PubMed, since those are named backends rather than afterthoughts. It does not fit someone on Docker Desktop who wants a five-minute install and no troubleshooting, someone without the hardware to run a local model at useful quality, or someone who only needs occasional summaries of public pages. If you are in the first group, the order of operations is: confirm AVX support, stand up Ollama and SearXNG, then run the container with LDR_DATA_DIR and LDR_SEARCH_ENGINE_WEB_SEARXNG_DEFAULT_PARAMS_INSTANCE_URL set correctly, and only then decide whether to reproduce the SimpleQA figure on your own hardware. The benchmark dataset on Hugging Face is the place to start if that number is what brought you here.
Editorial conclusion
Adopt Local Deep Research if you already run Ollama or llama.cpp on a machine with an AVX-capable CPU and you want research output that never leaves your network, plus a SQLCipher database you can query later. Do not adopt it if you want a managed service, if you cannot run SearXNG or another supported backend, or if you are on Docker Desktop and unwilling to work around the host networking problem. Before installing, verify three things: that your CPU supports AVX (Intel Sandy Bridge or AMD Bulldozer and newer, per the README), that your chosen search engine URL is reachable from inside the container, and that you have a plan for the LDR_SEARCH_ENGINE_WEB_SEARXNG_DEFAULT_PARAMS_INSTANCE_URL value, because since v1.10.3 a private or localhost engine URL is blocked unless you pass it through that variable or set up an origin allowlist.
Community notes