DeepScientist: a local-first autonomous research studio you can interrupt

The grunt work DeepScientist is aimed at

The README frames the problem in terms of what it calls low-leverage work: papers that arrive faster than anyone can turn them into a next-step plan, baseline repositories that break on environment and dependency issues before real work starts, results scattered across terminals and notes, and figures and drafts living in separate tools. That is a fair description of how a lot of applied research actually fails. Not from a shortage of ideas, but from the cost of re-establishing context every time you come back to a project.

The target user is someone who already has a research objective and wants an agent to carry the repetitive parts of the loop: restoring a repository, preparing an environment, tracking which failures were resolved, proposing the next hypothesis, branching and comparing. The README explicitly positions this against one-shot AI Scientist style systems and autoresearch tools, and against research chatbots that summarize papers and hand the work back. If your actual need is a literature summary, this is a much larger machine than you want.

One repo per quest, and why that shapes everything

The organising unit is the quest. The README's tagline is "One repo per quest", and the state that persists between rounds lives in tasks, files, branches, artifacts and memory rather than in a conversation buffer. That is the single design decision that separates it from chat-based tools: context is not something the model has to remember, it is something on disk that can be read again.

The README names three mechanisms that drive the loop. Findings Memory accumulates what previous rounds concluded. Bayesian optimization proposes the next configuration to try. The Research Map is described as a structure that keeps growing from every round, and the package description calls the whole thing "a research map that keeps growing from every round". Failed routes are kept rather than deleted, which is unusual and, if it holds up in practice, is the most defensible part of the design. Most automation throws away negative results because they are expensive to store and awkward to summarize. Keeping them is what makes a later round cheaper than the first.

The system is local-first by default: code, experiments, drafts and project state stay on your own machine or server. A web workspace, a TUI workflow for remote servers, and connector surfaces for Weixin, QQ, Telegram, WhatsApp, Feishu and Lingzhu/Rokid are documented as ways to watch and steer the same effort. The repository also ships an AISB directory and a separate AISB v0.0.1 release tag, though the README does not explain what AISB stands for or what it contains.

Installing DeepScientist and launching a first quest

There are two documented paths. The npm package is @researai/deepscientist and it requires Node 18.18 or newer and npm 9 or newer, per package.json. Installing it globally puts four command aliases on your PATH: ds, ds-cli, resear and research, all pointing at bin/ds.js.

npm install -g @researai/deepscientist

After that, the daemon is started through the package script. The README describes a 15-minute local setup, and the pyproject file pins Python 3.11 or newer, so a Python interpreter in that range needs to be present before the daemon will do useful work.

ds daemon

The repository also ships install.sh at the top level, exposed as the install:local npm script, for a source checkout rather than a global install.

git clone https://github.com/ResearAI/DeepScientist.git
cd DeepScientist
bash ./install.sh

For the first real use, the README points at docs/en/02_START_RESEARCH_GUIDE.md under the label "Launch Your First Project". The stated inputs are a core paper, a GitHub repository, or a natural-language research objective, and the output is what the README calls an executable quest. Provider setup has its own documents per runner: docs/en/15_CODEX_PROVIDER_SETUP.md, docs/en/24_CLAUDE_CODE_PROVIDER_SETUP.md, docs/en/27_KIMI_CODE_PROVIDER_SETUP.md and docs/en/25_OPENCODE_PROVIDER_SETUP.md. Read the one matching your runner before launching, because the runner is what actually executes the work.

The optional dependencies in package.json tell you which runners ship by default when you install from npm: @anthropic-ai/claude-code, @openai/codex and opencode-ai. Kimi Code is listed in the README's built-in runner line but does not appear in that optional dependency block, so its setup path is worth checking in the Kimi document rather than assuming parity.

Where the design gets thin

The README is long on what DeepScientist does and short on what happens when it goes wrong. It does not document rollback. It does not document what a quest costs in tokens, wall-clock time or disk, even though it advertises going deep through "thousands of experiment validations". That phrase is the most consequential claim in the document and it arrives without a resource estimate attached.

The failure mode follows from the architecture. A local-first system that keeps failed paths as assets accumulates state, and nothing in the README describes a pruning or garbage collection policy for quests that have been abandoned. If you run many quests, the storage question is yours to answer. The human takeover feature is presented as a strength, and it is, but it also means the system expects a human to notice when a run has drifted. There is no described mechanism for deciding on its own that a quest should be stopped.

The wrong tool test is straightforward. If you need a hosted service with a support contract, this is not it. If you want reproducible results without maintaining a Python 3.11+ environment and a Node 18.18+ environment on the same machine, the dependency surface is real. And if your research does not involve running code, the baseline reproduction and experiment branching machinery is dead weight.

DeepScientist against autoresearch-style systems

The README draws its own comparison against one-shot AI Scientist and autoresearch-style systems, and the difference it claims is durability of state. A one-shot system produces a paper from a prompt and the run ends. DeepScientist keeps tasks, files, branches, artifacts and memory as persistent objects, so a second round starts from the first round's residue rather than from zero.

That is a genuine architectural difference, not a marketing one. It changes the failure profile. One-shot systems fail loudly and cheaply: you get a bad paper and you discard it. A persistent-state system fails quietly and expensively, because a wrong conclusion written into Findings Memory can influence every subsequent round. The README's answer to that is human takeover and visibility through the web workspace, Canvas, files and terminal, which is a reasonable answer but places the burden of detecting drift on you.

The connector list is the other axis of comparison. Weixin, QQ, Telegram, WhatsApp, Feishu and Lingzhu/Rokid connectors mean progress updates can reach you where you already are, which matters for long-running work on a remote server. Most comparable tools assume you are watching a terminal.

Maintenance, licence and the cost of upgrading

The repository is not archived and the last push was on 2026-06-28, which is under three months before today. Releases have been frequent: v1.6.0 on 2026-05-13, an AISB v0.0.1 tag on 2026-04-13, and v1.5.17 on 2026-04-07. The README notes a May 12 update adding Claude Code, OpenCode, Kimi Code, BenchStore and science evidence workflows in v1.6.0, so the project is still adding runner integrations rather than only fixing them.

The licence is Apache-2.0 in both package.json and pyproject.toml, and there is a separate TRADEMARK.md at the top level. Apache-2.0 permits commercial use and modification with the usual notice and patent terms. The trademark file is the part to read before you ship anything that carries the DeepScientist name, since trademark terms sit outside the copyright licence and are frequently stricter than people assume. That is not legal advice; read the file.

Upgrade cost is concentrated in the runner integrations. The optional dependencies pin specific major versions of the agent runners, and package.json maps the ink dependency to a fork, npm:@jrichman/[email protected]. When a runner changes its interface, that pin is what breaks. The version numbers in package.json and pyproject.toml are both 1.6.0, so the two halves are released together, which simplifies upgrades but means a Python-only install and an npm install can drift if you pin them separately.

Editorial conclusion

Adopt DeepScientist if you already run research experiments on a machine you control and you want the failed branches, environment fixes and reproduction notes to survive between rounds. Do not adopt it if you want a hosted service, a one-shot paper summarizer, or a tool that hides its reasoning behind an API. Before committing, verify that your preferred runner is actually supported by the version you install, that your Python is 3.11 or newer, and that you are willing to read the BenchStore YAML reference, since that file format is how the system records what counts as evidence.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ResearAI/DeepScientist on GitHub