u14app/deep-research: a local-first research report generator that talks to almost any LLM
Use any LLMs (Large Language Models) for Deep Research. Support SSE API and MCP server.
At a glance
- What is it?
- This Next.js app orchestrates a thinking model and a task model to produce a research report in the browser, with optional SSE and MCP interfaces for programmatic use. It is a good fit if you already have an API key and want the report to stay on your machine; it is a poor fit if you need a managed, auditable research pipeline.
- Who is it for?
- Adopt it if you want a self-hosted research report generator that accepts Gemini, OpenAI, Anthropic, Deepseek, Grok, Mistral, Azure OpenAI, OpenRouter or Ollama keys and keeps the result in browser storage. Do not adopt it if you need server-side persistence, multi-user accounts or a reproducible audit trail, because the README states all data is processed and stored locally.
- 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 last received commits 89 days ago.
- What is it written in?
- Mainly JavaScript, 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 window and a research report
A single LLM call produces a paragraph. A research report needs search results pulled in, a plan, several rounds of writing, and a final edit. u14app/deep-research exists to run that loop without you wiring it together by hand. The README frames the output as an "in-depth research report in just a few minutes" and the feature list claims a figure of about 2 minutes, which is the project's own marketing rather than a measured benchmark; treat it as an order of magnitude, not a promise.
The intended user is someone who already holds an API key for a model provider and does not want to build a search-plus-synthesis pipeline. The README's recommended path is a free Gemini API key plus one-click deployment. A second audience is programmatic: the project exposes an SSE API for using it as a research service and an MCP server for calling it from other AI tools. That second audience is what separates this from a chat UI with a long system prompt.
Two models, one report: the thinking and task split
The architecture the README describes rests on a division of labour between what it calls "Thinking" and "Task" models. The thinking model handles the part that benefits from slower reasoning, and the task model handles the mechanical work, with the stated goal of balancing depth against speed. The README also says you can switch research models, and that you can refine or adjust content at any stage and re-run research from that stage. That last point matters more than it sounds: a pipeline that can restart from an intermediate stage is a different design from one that regenerates everything when you change a sentence.
Around that core sit several named subsystems. A local knowledge base accepts uploaded text, Office and PDF files. An artifact editor offers two modes, described as WYSIWYM and Markdown, and can adjust reading level, article length and full-text translation. A knowledge graph can be generated in one click. Research history is preserved so previous results can be revisited and extended. Multi-key payload is listed as a way to improve API response efficiency, though the README does not explain the rotation policy, so how keys are selected is not something I can confirm from the supplied material.
The privacy claim is architectural, not just a policy statement: the README says all data is processed and stored locally, in the browser. That is the single most consequential design decision here, and it is also the source of the main limitation discussed below.
Getting it running: clone, env file, dev server
The README gives a conventional Next.js setup. Node.js 18.18.0 or later is recommended, and pnpm, npm or yarn all work. The commands are:
git clone https://github.com/u14app/deep-research.git cd deep-research pnpm install cp env.tpl .env.local pnpm dev
The environment file step is the one that trips people up. The README says you need to modify env.tpl into .env, or create a .env file, and it distinguishes two copies: cp env.tpl .env.local for development and cp env.tpl .env for production. After pnpm dev the app is served at http://localhost:3000.
For configuration beyond the template, the README documents one variable explicitly: NEXT_PUBLIC_MODEL_LIST. It takes a comma-separated list of model names, and prefixing a name with a hyphen disables it, for example -existing-model-name. The README states plainly that this custom model list only works in proxy mode. If you are running in a mode that calls the provider directly from the browser, expect the variable to be ignored. The README does not enumerate the other keys in env.tpl, so I cannot list them here without guessing.
Deployment follows the same shape. Vercel is a one-click clone flow. Cloudflare is supported but requires following docs/How-to-deploy-to-Cloudflare-Pages.md rather than a button, which is a meaningful difference in effort.
Search providers and LLM providers are separate plug points
The provider list is unusually wide, and it is worth separating into two axes because they solve different problems. On the model side the README names Gemini, OpenAI, Anthropic, Deepseek, Atlas Cloud, Grok, Mistral, Azure OpenAI, any OpenAI-compatible endpoint, OpenRouter and Ollama. On the search side it names Searxng, Tavily, Firecrawl, fastCRW, Exa, Bocha and Brave.
The reason both lists exist is stated directly: web search support lets models that do not have built-in search use it anyway. That is the practical value of the search axis. A local Ollama model has no browsing capability of its own, but paired with a search provider it can still ground a report in retrieved pages. The same applies to any OpenAI-compatible endpoint you point at your own inference server.
Ollama's presence is the clearest signal of intent. Combined with the local storage claim, it means the whole pipeline can in principle run without sending prompts to a third party, provided your search provider is also self-hosted. Searxng is the obvious candidate for that role, since it is the only self-hostable engine in the list. If you pick Tavily, Exa, Bocha, Brave or Firecrawl instead, your queries leave your machine even though your report does not.
Where the design bites: local storage is not a shared workspace
Storing everything in the browser is a deliberate trade, and it has costs the README does not dwell on. A report lives in one browser profile on one machine. Open the app on a second device and the research history is not there. Clear site data and it is gone, because there is no server-side copy to restore from. There is no mention of export to a durable format in the material I have, and no mention of accounts, sharing or permissions.
That rules out several real use cases. A team that wants a shared research library cannot get one from this design. Anyone who needs a reproducible audit trail, where you can point at the exact search results and model outputs behind a claim, has no described mechanism for it. And the knowledge base inherits the same constraint: uploaded PDFs and Office files are processed locally, so a large corpus is bounded by what the browser can hold and index.
There is a second, subtler failure mode. The README's privacy claim depends on where the model call happens. It offers both local and server-side API calling options, and the custom model list only applies in proxy mode. If you deploy to Vercel or Cloudflare and route calls through a server function, prompts and retrieved content pass through that function. The data may still not be persisted, but it is not accurate to describe the whole path as local. Read the deployment mode before repeating the privacy line to anyone who cares about it.
Alternatives, and what actually differs
The obvious comparison is a general research agent built into a chat product, such as the deep research modes offered by the major model vendors. The difference is control over the pieces. A vendor's research mode picks the model, the search index and the storage for you, and you cannot swap in Ollama or point it at Searxng. u14app/deep-research makes each of those a configuration choice. The cost is that you own the deployment, the keys and the failure modes.
A second comparison is building the loop yourself on top of an agent framework. That gives you full control over persistence, retries and evaluation, and it is the right answer if you need an auditable pipeline. What you would be rebuilding is the specific combination this project already ships: the thinking and task model split, stage-level re-research, the artifact editor with its two modes, the knowledge graph, and the SSE and MCP surfaces. Whether that saved work is worth the loss of control depends on whether browser-local storage is acceptable for your use case. If it is not, the framework route is the honest choice, not a patched version of this one.
Licence, releases and what upgrading costs you
The project is MIT licensed, which permits personal and commercial use, and the README states that explicitly. MIT also means no warranty and no obligation on the maintainer to support your deployment. That is a normal open source arrangement, not a legal opinion, and if you are embedding this in a product you should have your own counsel read the licence rather than take my summary.
On maintenance, the release cadence visible in the material is uneven. v0.9.20 landed in May 2025 and was tagged "Support API and MCP". v0.10.0 followed in September 2025, and v0.11.0 in February 2026. The last push to the repository is dated June 2026, after the most recent release, so work is continuing between tags. The version numbers are still in the 0.x range, which usually signals that interfaces are not frozen. If you build against the SSE API or the MCP server, pin a version and read the release notes before moving, because a minor bump in a 0.x project can change behaviour.
Upgrade cost also depends on how you deployed. A Vercel one-click deployment tracks the repository, so upgrades arrive as new commits and you re-verify your environment variables after each one. A Cloudflare Pages deployment depends on the documented procedure in docs/How-to-deploy-to-Cloudflare-Pages.md, which you will need to re-follow rather than re-click. Neither path is expensive, but neither is automatic in the way a managed service would be.
Editorial conclusion
Adopt it if you want a self-hosted research report generator that accepts Gemini, OpenAI, Anthropic, Deepseek, Grok, Mistral, Azure OpenAI, OpenRouter or Ollama keys and keeps the result in browser storage. Do not adopt it if you need server-side persistence, multi-user accounts or a reproducible audit trail, because the README states all data is processed and stored locally. Before committing, verify three things yourself: that your chosen search provider is on the supported list (Searxng, Tavily, Firecrawl, fastCRW, Exa, Bocha, Brave), that NEXT_PUBLIC_MODEL_LIST is set if you want a custom model list, since the README says it only works in proxy mode, and that your deployment target is Vercel or Cloudflare Pages.
Community notes