Research-Claw: a local research agent with 433 academic skills
In the AI era, why can't everyone be a Principal Investigator?
At a glance
- What is it?
- Research-Claw is a self hosted research assistant that runs on your own machine, reads and writes your literature library, drafts papers, tracks arXiv in the background and pushes reports to your chat app. The data stays local and the only external dependency is the large model API you choose, but it is a heavy install with a restrictive licence and a curious version constraint.
- Who is it for?
- Research-Claw suits a researcher who wants library management, paper drafting and background arXiv monitoring in one local agent and is willing to manage a Docker stack and a large model API bill. Do not adopt it if you need permissive licensing for commercial redistribution, if you want a published npm package, or if a Node version outside the 22.16 to 22.x range is fixed in your environment.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 64 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 October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A research agent that keeps the paperwork out of your way
The pitch in the README is blunt: the researchers who define the next era should not spend their time formatting references, and a graduate student alone at a screen at two in the morning deserves the same research infrastructure as a top laboratory. Research-Claw, nicknamed the research lobster, is the local implementation of that idea.
Concretely it reads papers closely, watches arXiv while you sleep, drafts methodology sections, designs experiments, manages citations, generates figures and writes in your voice rather than its own. The library, the notes and the experimental data all live on your machine. The single external dependency is the large model API you choose, and the environment file makes that concrete by listing ANTHROPIC_API_KEY, OPENAI_API_KEY and ZAI_API_KEY as the key slots.
The audience is a working researcher, and the workflows are shaped like academic chores rather than generic chat: organizing an unclassified Zotero pile into collections with one line summaries, generating a weekly group meeting summary on Friday morning and pushing it to Telegram, Feishu, QQ or DingTalk, drafting a related work section from a proposal and experiment notes, or asking it to reproduce an arXiv paper on a local GPU. The interesting part is not that a model can write text. It is that the agent is wired to the reference manager, the arXiv feed and the terminal at the same time.
Three layers: workspace files, extension packages and a dashboard
The architecture diagram in the README splits the system into three levels. L0 is the workspace, a directory of markdown control files: SOUL.md, AGENTS.md, TOOLS.md and HEARTBEAT.md plus eight further bootstrap files. L1 is extensions, with research-claw-core as the main package. L2 is the dashboard, described as a React 18 plus Vite 6 front end with Ant Design 5 and Zustand 5, six card types, eight panels, a WebSocket RPC v3 client and 1024 i18n keys for English and Simplified Chinese. The dashboard talks to the core over ws://127.0.0.1:28789.
That layout explains a lot of behaviour. The agent persona and the operating rules live in plain markdown inside your workspace directory, so they are files you can read, version and edit rather than hidden configuration. The package.json confirms the split in code, with separate build scripts for the runtime, the dashboard and the extension packages:
"start": "bash scripts/run.sh",
"dev": "RC_LOG_PROFILE=developer concurrently \"pnpm --filter dashboard dev\" \"bash scripts/run.sh\"",
"test": "vitest run && pnpm --filter dashboard test",
"setup": "bash scripts/setup.sh",
"health": "bash scripts/health.sh",The dashboard is where the work is visible. The panel table lists chat with structured cards for papers, tasks, progress, approvals, files and monitoring summaries, plus a library panel with full text search, tags, annotations, a citation graph and reading statistics, a workspace panel with file operations and version history tracked by Git, a paper review panel, a task board that separates agent and human work with four priority levels and 48 hour deadline warnings, a monitoring panel for tracked keywords, scholars and journals, a quality control panel, an extensions panel for chat channels, skills and MCP servers, and a settings panel with a setup wizard and an endpoint probe that identifies the API protocol. The stated technical specification is React 18, Vite 6, Ant Design 5 and Zustand 5, with 2200 or more dashboard tests.
One curl command covers install, upgrade and restart
On macOS and Linux the README gives a single command that it says handles first install, version update and restart:
curl -fsSL https://wentor.ai/install.sh | bashWindows users are pointed elsewhere: a Docker one-click deployment marked as the recommended route, or a manual WSL2 installation described in WINDOWS_INSTALL.md. The Docker route is a separate path because the compose stack publishes the service on a loopback port and mounts host directories for reference manager databases, which behaves differently under WSL2.
The command hides a fair amount of work. The installer is verified by a repository script, verify:installers, which runs against the public URL https://wentor.ai/install.sh, and the package.json points pnpm at [email protected] with a prepare script that runs node scripts/prepare-package-manager.cjs. The engines field is strict: node >=22.16.0 <23. That upper bound is unusual and worth noting before you plan an upgrade path, since a Node 23 or 24 workstation will not satisfy it.
If you prefer to inspect what runs, the environment template is the place to start. Copy .env.example to .env and fill in at least one key:
ANTHROPIC_API_KEY=
OPENAI_API_KEY=
ZAI_API_KEY=The same file documents an optional HTTP_PROXY and HTTPS_PROXY pair for users behind a proxy, and a WENTOR_API_KEY with WENTOR_API_URL pointing at https://wentor.ai/api/v1 that is marked as optional and future work.
The compose stack and the four volumes that decide what survives
The Docker path is documented in docker-compose.yml, which ships a prebuilt image and lists an overseas alternative for users outside mainland China:
ports:
- "127.0.0.1:28789:28789"
environment:
- OPENCLAW_GATEWAY_TOKEN=research-clawThe service binds to 127.0.0.1 only, so the dashboard and the WebSocket RPC endpoint are reachable from the host but not from the network by default. The gateway token in the environment is set to a fixed literal in the shipped file, so if you expose this stack beyond loopback you should change it.
The volume section is the part that decides what survives, and the file itself calls it critical. The install script runs `docker rm` on every update, so any path that is not on a named volume is destroyed when the container is recreated:
volumes:
- rc-config:/app/config # API key, gateway config, .config-version
- rc-data:/app/.research-claw # RC plugin SQLite (library, tasks, monitors)
- rc-workspace:/app/workspace # Agent workspace (MEMORY.md, USER.md, files)
- rc-state:/root/.openclaw # OC state: sessions (chat history!), logs, plugins, credentialsThe comment records a past bug directly: in v0.5.2 rc-state was missing and chat history was lost on every update. That is a concrete illustration of the cost of a self managed container.
A second trap sits in the reference manager mounts, which are read only:
- ~/Zotero:/host/zotero:ro
- ~/Documents:/host/documents:roIf the host path does not exist, Docker creates an empty directory with no error and the import simply returns empty. On a machine where Zotero stores its library somewhere other than the home directory, the import appears to work and yields nothing.
433 skills, 34 agent tools and 150 MCP configurations
The breadth comes from a battery of integrations that are configured at install time without manual steps. The README counts 433 academic skills grouped into six categories: 147 discipline skills spanning more than sixteen fields from computer science to law to biology, 80 for literature retrieval with multi database search and document tracking, 62 for academic writing across paper sections and LaTeX, 52 for research methods including difference in differences, regression discontinuity, instrumental variables, meta analysis and systematic review, 48 for efficiency tools such as Terminal, Jupyter and document conversion, and 44 for data analysis in Python, R and STATA.
On top of that sit 34 agent tools spread over 18 API modules that talk directly to academic databases including arXiv, OpenAlex, CrossRef, PubMed, Unpaywall, Europe PMC, DBLP and DOAJ. A third layer is 150 ready to use MCP configurations: Zotero, EndNote and Mendeley for reference management; Telegram, Feishu, QQ, DingTalk and Slack for notifications; GitHub, Jupyter and VSCode for development; and OpenAI, Claude and various domestic model APIs for inference. The skills are published separately to npm as @wentorai/research-plugins.
The difference from assembling this yourself is packaging. You could wire arXiv to a chat bot and Zotero to a script yourself, but then every update to an API or a skill becomes your problem. Here the install wires them and the dashboard exposes them. The tradeoff is that the integration surface is large and mostly undocumented outside the README tables, so you will be reading code and config to find out what a given skill actually calls.
A reviewer model that audits answers after the fact
The quality control panel is the most distinctive design choice in the project. Its stated purpose is to guard against the confident nonsense that is the standard failure of research assistants. The mechanism is asynchronous: a separate reviewer model re-reads the main model's answer, and the findings, suggested corrections and audit status are written to a Supervisor panel. Crucially it does not block the answer and does not silently replace what was already sent.
That ordering is a design statement. Blocking every response on a second model call would double latency on every interaction, so the project chose audit after the fact for ordinary answers and reserved synchronous enforcement for tools classified as dangerous, where deterministic safety rules and a bounded deep review can either block the action outright or request human approval. Citation existence checking over the network is off by default and has to be switched on by the user, which keeps the default run local and offline apart from your model endpoint.
The same philosophy appears in the human in the loop rule. When an action touches external credentials such as an API token, is irreversible, or requires a resource decision, the agent does not proceed alone. It reports back with an analysis and a set of options and waits. The README describes this with a rate limit on a model download as the example: instead of waiting out a slow download, the agent escalates with three candidate approaches and a recommendation, and the user picks one. The consequence for you as a user is that you are a supervisor of a system that keeps proposing, not a bystander watching a pipeline.
BSL 1.1, a private package and a pinned Node range
Licensing needs care. The repository carries a LICENSE file, and the README badge reads BSL 1.1, while GitHub itself classifies the licence as a custom one it cannot categorize. Bootstrap Software Licence 1.1 is a source available licence with a conversion clause rather than a permissive open source grant, so if you intend to redistribute the software or build a hosted service on top of it, read that file before committing to the project.
The package.json marks the root package as private and versioned 0.8.3, so the core is not distributed as a consumable library. The skills are the public npm surface. The repository layout also shows a dedicated extensions directory with its own packages including a core, a dual model supervisor and a wentor-connect package, each built separately by the build:extensions script.
Maintenance history is short and recent. Releases are v0.8.3 on 2026-08-15, v0.8.2 on 2026-08-01 described as Trusted Execution and Long-Run Reliability, and v0.8.1 on 2026-07-30 with a note about a steadier install, upgrade and local research experience. The last push was on 2026-08-20. The repository is not archived. Several release notes are kept as separate markdown files in the root for versions from v0.7.0 through v0.8.2, so upgrade behavior is documented per version rather than in a single changelog.
The upgrade cost falls on the two things the project cannot control for you: the Node range and the container volumes. The engines field pins node >=22.16.0 <23 and packageManager pins [email protected], and the compose file warns that the install script removes the container on every update.
Editorial conclusion
Research-Claw suits a researcher who wants library management, paper drafting and background arXiv monitoring in one local agent and is willing to manage a Docker stack and a large model API bill. Do not adopt it if you need permissive licensing for commercial redistribution, if you want a published npm package, or if a Node version outside the 22.16 to 22.x range is fixed in your environment. Verify first that the four named Docker volumes are mounted, that your Zotero path exists on the host before the import runs, and that your chosen model endpoint is reachable before you import a real library.
Frequently asked questions
How do I install Research-Claw on macOS or Linux?
The README gives one command for macOS and Linux: `curl -fsSL https://wentor.ai/install.sh | bash`, which it says handles first install, version update and restart. Windows users are pointed to the Docker one-click deployment or a manual WSL2 guide in WINDOWS_INSTALL.md.
Does Research-Claw send my research data to a server?
The library, notes and experiment data are stored on your own machine, and the only external dependency is the large model API you choose. The .env.example file lists ANTHROPIC_API_KEY, OPENAI_API_KEY and ZAI_API_KEY as the key slots to fill.
What happens to my chat history when Research-Claw updates through Docker?
State lives in the rc-state named volume mounted at /root/.openclaw, and the compose file warns that any path not on a named volume is destroyed when the container is recreated. The file also records a v0.5.2 bug where rc-state was missing and chat history was lost on every update.
Which Node version does Research-Claw require?
The engines field requires node >=22.16.0 <23, and the package manager is pinned to [email protected] with a prepare script that runs scripts/prepare-package-manager.cjs.
How does the quality control feature review answers in Research-Claw?
A separately configured reviewer model re-checks the main model's answer asynchronously and stores the findings, suggested corrections and audit status in the Supervisor panel without blocking or replacing the reply. Dangerous tools instead get synchronous deterministic safety rules and a bounded deep review that can block the action or ask for human approval.
Can I use Research-Claw with Zotero and EndNote?
Yes. The project lists two-way integration with Zotero and EndNote for automatic classification, annotated summaries and BibTeX export, and 150 ready to use MCP configurations including Mendeley. In Docker the reference manager database is mounted read only from the host path.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wentorai-research-claw)Was this useful?