Deep Research Web UI: A Nuxt Front End for Iterative, Cited Web Research
(Supports DeepSeek R1) An AI-powered research assistant that performs iterative, deep research on any topic by combining search engines, web scraping, and large language models.
At a glance
- What is it?
- AnotiaWang's Deep Research Web UI wraps search providers and OpenAI-compatible models in a browser interface that plans queries, reads source pages and produces a cited report. The interesting part is not the report, it is the evidence panel and the two deployment modes.
- Who is it for?
- Adopt it if you want a self-hosted research front end where every claim in the output can be traced back to a retrieved excerpt, and you already hold keys for an OpenAI-compatible model plus Tavily, Firecrawl, fastCRW or Google PSE. Do not adopt it if you need a purely static deployment with server-held keys, since the README states Server Mode requires an SSR/Nitro runtime and is unavailable in static builds.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, 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 gap between a chat answer and a report you can audit
Asking a model a research question produces fluent prose with no way to check where any sentence came from. Deep Research Web UI attacks that specific gap. The README describes the product as turning a research question into a cited report: it plans searches, browses the web, verifies findings against real source pages, and lets you inspect and follow up on every citation. The audience is anyone who has to defend the output of a research run: analysts, technical writers, engineers evaluating a vendor, or a team that wants an internal research tool without sending queries through a hosted SaaS. Because it is a TypeScript/Nuxt application that runs in a browser or as a container, the same code serves both a public demo and a private instance behind a company firewall. The distinguishing feature is not the report generation, which many tools now do. It is the insistence that a citation be backed by an excerpt that was matched against retrieved content, with search summaries and page text labelled separately. That is a narrower and more honest promise than most research assistants make.
How a run actually flows: plan, search, read, cite
The README describes the pipeline in feature terms rather than as an architecture diagram, but the pieces are named. A run starts from a question, plans searches, browses the web, and verifies findings against real source pages. Search results are visualised as a tree so you can see which query led where, and the tool supports searching in different languages. Two mechanisms matter for quality. The first is focused search: queries are separated from time and source filters, result relevance is checked, and the tool retries once with a revised query when evidence is insufficient. The second is on-demand full-page reading: when search snippets are not enough, it fetches full source pages to extract verbatim evidence, sharing a token and request budget across the whole research run. That shared budget is the constraint that keeps a run from spiralling into unbounded scraping. The project also states it uses plain prompts instead of newer, less widely supported features like Structured Outputs, explicitly so it works with providers that have not caught up with the latest OpenAI capabilities. That choice buys provider breadth and costs you the stricter output contracts that structured outputs give.
The evidence panel is the part worth evaluating
Most of the interface is conventional. The evidence panel is not. After a run finishes you click a [1]-style citation or the Inspect evidence and follow up control, and the panel shows each finding's source, retrieval time and excerpt. The README is unusually careful here: a new excerpt is only saved once it is matched against retrieved content, search summaries and page text are labelled separately, and a matched excerpt does not by itself prove the finding, so you are told to read it in context. That last sentence is the most credible line in the documentation, because it refuses to overclaim. Follow-ups are scoped rather than open-ended. You type what you want to verify, for example a request to find the latest official pricing and confirm eligibility terms, and the tool searches at most two directions in one round and updates only the Markdown blocks that cite that finding, with tables and lists updated as whole blocks. On success the new evidence and updated report are saved as a separate history entry, leaving the original unchanged. On failure, cancellation, or when no matching excerpt is found, the original report is preserved. That failure behaviour is a deliberate design decision and it is the right one for auditability.
Getting it running: two modes, one container command
The README separates deployment into Client Mode and Server Mode. Client Mode keeps configuration and API requests in the browser, which suits static deployments such as EdgeOne Pages or pnpm generate. Server Mode puts keys in server-side environment variables so users never enter them, and the README states this requires an SSR/Nitro runtime such as the Docker image and is not available in purely static deployments. The recommended path is a single docker run with environment variables: NUXT_PUBLIC_SERVER_MODE set to true, NUXT_AI_API_KEY, NUXT_WEB_SEARCH_API_KEY, NUXT_PUBLIC_AI_PROVIDER set to openai-compatible, NUXT_PUBLIC_AI_MODEL set to a model name, and NUXT_PUBLIC_WEB_SEARCH_PROVIDER set to tavily, all published on port 3000 from the anotia/deep-research-web:latest image. The alternative is copying .env.example to .env and passing --env-file. Optional variables include NUXT_AI_API_BASE and NUXT_WEB_SEARCH_API_BASE for providers that need a custom base URL. For Client Mode the command is the same image without the environment variables. A self-built image is a git clone, a cd, a docker build and a docker run. The README also lists providers: OpenAI-compatible endpoints, ApiSmart, SiliconFlow, InfiniAI, DeepSeek, OpenRouter, Requesty, Ollama and LiteLLM on the model side, and Tavily, Firecrawl, fastCRW and Google PSE on the search side. Tavily is noted as offering 1000 free credits per month.
Where it breaks: budgets, static hosting and licence opacity
Three limitations are visible in the material. The first is cost control. Full-page reading and multi-round search consume tokens and search credits, and while the README says a token and request budget is shared across the run, it does not document how to set that budget. If you cannot tune it, you are trusting a default you cannot see. The second is the deployment split. Server Mode, the mode where users do not handle keys, is exactly the mode that cannot run on static hosting, so a team that wants EdgeOne Pages or a static CDN must fall back to Client Mode and distribute keys to users. That is a real constraint, not a footnote. The third is licensing. The repository metadata supplied here does not state a licence, and the README does not discuss one. For an internal tool that may not matter; for anything redistributed or embedded in a product, it is the first thing to resolve. A fourth, softer issue is the plain-prompt approach. It widens provider support, but it also means output shape depends on the model's willingness to follow format instructions, and the README does not describe a fallback when a model ignores them.
How it differs from GPT Researcher and similar agent stacks
GPT Researcher is the obvious comparison point: a Python agent that runs the same broad loop of planning searches, scraping pages and assembling a cited report, usually driven from a script or a small API rather than a browser application. The difference is where the work happens and who operates it. GPT Researcher is a research pipeline you embed in your own code and schedule. Deep Research Web UI is an interactive surface: the tree visualisation, the citation click-through, the evidence panel with retrieval timestamps, and the follow-up flow that rewrites only the blocks citing a finding and saves the result as a new history entry. That follow-up behaviour, with the original report preserved on failure, is a workflow feature rather than an agent feature, and it is the strongest argument for choosing this project over a scriptable alternative. The trade-off runs the other way too: a Python pipeline is easier to run headlessly on a schedule or inside CI, while this project is built around a person sitting in front of a browser. If your requirement is unattended batch research, the interactive design is overhead rather than value.
Maintenance, upgrades and what the release history suggests
The release list shows v1.1.9 in April 2025, v1.2.0 in July 2025 and v1.2.1 in September 2026, with the last push to the default branch in September 2026. That is a slow but non-zero cadence, and the gap between v1.2.0 and v1.2.1 spans more than a year, so anyone deploying should expect to pin a version rather than track a fast-moving main branch. Upgrading a Docker deployment is a pull of anotia/deep-research-web:latest plus a restart, which is cheap, but the README notes that older history entries still load and that findings without a saved excerpt are labelled accordingly. That backward compatibility for stored history is the detail that matters on upgrade, because history lives in the browser rather than in a server-side database. The README's own advice follows from that: history is stored in your browser, so export research you want to keep. Treat browser storage as the system of record at your peril. On licence, the material does not state one, so no conclusion about redistribution or commercial use can be drawn from it; check the repository before depending on it.
Editorial conclusion
Adopt it if you want a self-hosted research front end where every claim in the output can be traced back to a retrieved excerpt, and you already hold keys for an OpenAI-compatible model plus Tavily, Firecrawl, fastCRW or Google PSE. Do not adopt it if you need a purely static deployment with server-held keys, since the README states Server Mode requires an SSR/Nitro runtime and is unavailable in static builds. Before committing, verify the licence, which the repository metadata does not state, and confirm that the model you intend to use behaves acceptably with plain prompts rather than structured outputs.
Community notes