Open-source project
ymx10086/ResearchClaw avatar
ymx10086/ResearchClaw

The ResearchClaw quickstart clones a repository under a different owner

ResearchClaw is a personal AI assistant built for research: fast to set up, easy to run locally or in the cloud, and ready to integrate with the chat apps you already use. With extensible skills, it helps you streamline literature review, note-taking, experiment tracking, and paper writing—end to end.

313 stars36 forksPythonNOASSERTION

At a glance

What is it?
ResearchClaw is a local-first runtime for research work that persists project, workflow, task, and artifact state across chat threads and terminals, exposes it over eight channels, and routes to nine provider types. It is declared Alpha, names its own remaining gaps, and ships a Python package with a separately built web console.
Who is it for?
ResearchClaw suits a researcher whose work currently evaporates into chat transcripts and shell history, because the state chain from project to artifact is persisted and exposed identically through a console, messaging channels, cron jobs, and control-plane APIs. It does not suit someone expecting a finished research operating system, since the classifier says Alpha and the project names evidence-matrix quality and claim-evidence validation as open gaps.
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 180 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The quickstart clones a repository under a different account

The install instructions are three lines, and the first one names an owner that does not match the repository.

bash
git clone https://github.com/MingxinYang/ResearchClaw.git
cd ResearchClaw
pip install -e .

The clone URL points at one account while the repository hosting this documentation, and its project pages, sit under another. A reader who copies the command literally gets a different repository than the one describing it.

That is not the only metadata mismatch. Repository metadata reports no detected license, the marker used when one cannot be inferred, while the package manifest declares Apache-2.0 and a license file is present at the root. Anyone checking licensing for compliance should read the file rather than the index field.

The release names are unusual for the same reason. The two tags are not semantic versions: one is named Pto with a version marker of V1.1, the other Product with V1.0. There is no tag you can sort or compare, and the last recorded push is 2026-04-04.

So the surface of this project has a few rough edges around it. None of them stop the code from running; all of them make provenance harder to establish than it should be.

Initialization writes a working directory and a separate secret directory

The second quickstart step is one command with two flags, and both matter.

bash
researchclaw init --defaults --accept-security

It creates two directories with different names and different purposes: a working directory under the user's home for research state, and a secret directory beside it with a distinct prefix. Splitting them is a design decision rather than a naming quirk, because anything holding credentials should not sit in the same tree as the artifacts a system writes continuously.

It also writes four bootstrap Markdown files into that workspace: a soul file, an agents file, a profile file, and a heartbeat file. Those names imply that the agent runtime reads its own instructions and persona from disk, which is what makes the state portable between machines.

The security flag is the part to notice. Accepting is a separate act from running with defaults, so a deployment that wants the directories without the security posture has to choose.

This matters more than it looks for a local-first tool, because the whole premise is that the workspace outlives the session. Anything sensitive written into the working directory stays there after the process exits.

Eight channels are built in, and voice is one of them

The channel list is longer than most assistants of this kind ship, and the mix is deliberate rather than Western-only.

Built-in channels are the console, Telegram, Discord, DingTalk, Feishu, iMessage, QQ, and voice. Three of those are messaging platforms common in East Asia, which lines up with a project that also maintains a Chinese README and a Chinese contributing guide.

The stated point of having them is not convenience but state continuity. The problem being solved is that it is hard to hand work over between web, terminal, and messaging surfaces, and the answer is that the same research state is exposed through the web console, the IM channels, cron jobs, sessions, and control-plane APIs.

Voice being included matters for a different reason: it implies the runtime has to handle non-text input alongside text, which affects the agent loop rather than just the integration list.

Alongside channels sit MCP client management and custom channels, so the built-in set is a floor rather than a ceiling. A channel is not just a transport here, since the state it exposes is the same objects the console edits.

Nine provider types exist and the example names a fifth kind of thing

Provider configuration has a guided route and a direct one, and the direct one exposes the vocabulary.

bash
researchclaw models add openai --type openai --model gpt-5 --api-key sk-...

Three values are being passed where you might expect two: a provider name, a type, and a model. Separating them is what allows several models per provider, which the feature list describes alongside provider routing and fallback chains.

The types supported in code today are named as a list: openai, anthropic, gemini, ollama, dashscope, deepseek, minimax, other, and custom. The last two are the escape hatches, and having both is a small sign of care, since an endpoint that is OpenAI-compatible but hosted by someone else needs a path that is neither a named vendor nor a special case.

Three regional providers appear alongside the two Western ones and a local runtime, which is the same pattern as the channel list.

The interactive alternative is a single config command, and it is the route a first-time user is pointed at before the direct form is shown.

The console is a separate build and the backend serves it only if present

The service is started with an explicit host and port.

bash
researchclaw app --host 127.0.0.1 --port 8088

Binding to the loopback address by default is a local-first default rather than an accident, and the interface is then opened on that address.

The wrinkle is what happens on a source install. If the page reports that the console is not found, the frontend has not been built, and the fix is three commands in the console directory: install, then build. The backend then serves the built output automatically when the directory exists, which means there is no configuration step and no flag for it.

So a Python-only installation produces a running service with no interface until someone installs a Node toolchain. The package lock file sits at the repository root even though the frontend lives in its own subdirectory, which suggests the two build systems share one root convention.

That split is why the deploy directory exists separately. Container images can build both halves without asking a user to discover the two-step.

Alpha is declared in three places and the gaps are named

The project states its own status twice in different registers, and the packaging declares it a third time.

The package classifier is development status 3, Alpha. The prose says it is still an Alpha project but no longer just a platform shell. The second clause is doing real work, because the next sentence lists what the code now actually contains: a minimal research workflow runtime, a claim and evidence graph, experiment tracking, blocker remediation, and a project dashboard.

Then it names four remaining gaps: evidence-matrix quality, stronger claim-evidence validation, richer external execution adapters, and submission and reproducibility packaging.

Read in order, that is a project that has finished its plumbing and is now short on research rigor. The last two gaps are integration and packaging rather than modelling, which suggests the hard part was never inference.

The state model underneath matches that description. Work persists as a chain from project to workflow to task to artifact, with notes, claims, evidence, drafts, and reminders hanging off it. A claim and evidence graph is exactly the structure an evidence matrix needs, so the first listed gap is about the quality of what fills the graph rather than the graph itself.

The ecosystem is stage-based and one repository is a map of everything else

ResearchClaw is positioned as a runtime inside a wider organization, and the companion repositories are divided by research stage rather than by feature.

Five of them are described identically as authoritative skills for a stage: idea generation for turning vague interests into defensible directions, literature discovery for auditable search and survey writing, research design for method formalization and evaluation design, experiments for reproduction and ablation traceability, and paper writing for drafting, LaTeX workflows, and submission checks.

The sixth is different in kind. A landscape map is described as the map for AI-native research systems, workflow modules, benchmarks, surveys, datasets, and meta resources, and it is framed as the discovery layer for adjacent tools beyond this project.

The recommended pairing is explicit and conservative: ResearchClaw plus one or two stage repositories for whichever stage is being pushed now, with the map for finding things outside the set.

That is a sensible way to stage adoption, and it also means the runtime is close to useless alone for a paper, since the writing and evidence stages live next door. Each companion carries its own conditions for use, phrased as a situation rather than a feature, which makes the division easier to act on.

Editorial conclusion

ResearchClaw suits a researcher whose work currently evaporates into chat transcripts and shell history, because the state chain from project to artifact is persisted and exposed identically through a console, messaging channels, cron jobs, and control-plane APIs. It does not suit someone expecting a finished research operating system, since the classifier says Alpha and the project names evidence-matrix quality and claim-evidence validation as open gaps. Before you clone, note that the quickstart command points at a different owner than the repository, and confirm which one you actually want.

Frequently asked questions

How do I install and initialize ResearchClaw?

Clone the repository, change into it, and run `pip install -e .`, then initialize with `researchclaw init --defaults --accept-security`. That creates a working directory and a separate secret directory under your home, plus bootstrap Markdown files including SOUL.md, AGENTS.md, PROFILE.md, and HEARTBEAT.md. Start the service with `researchclaw app --host 127.0.0.1 --port 8088`.

Which model providers does ResearchClaw support?

The provider types in code today are openai, anthropic, gemini, ollama, dashscope, deepseek, minimax, other, and custom. You can configure one interactively with `researchclaw models config` or add it directly, for example `researchclaw models add openai --type openai --model gpt-5 --api-key sk-...`, and the runtime supports multiple models per provider with fallback chains.

What does the ResearchClaw Research page let me do?

Create a project, inspect workflows, claims, and reminders, view execution health and recent blockers, and dispatch, execute, or resume remediation work. The underlying state is a chain from project to workflow to task to artifact, with notes, claims, evidence, drafts, and reminders.

Why does ResearchClaw report that the console is not found?

The frontend is not built in a source installation. Build it once with `cd console`, `npm install`, and `npm run build`; the backend then serves the built directory automatically when it exists, with no extra configuration.

Which channels does ResearchClaw support?

Console, Telegram, Discord, DingTalk, Feishu, iMessage, QQ, and voice are built in, with MCP client management and custom channels also available. The same research state is exposed through the web console, IM channels, cron jobs, sessions, and control-plane APIs.

Official sources

  1. Issues
  2. Project website
  3. README
  4. Releases
  5. ymx10086/ResearchClaw on GitHub
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.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/ymx10086-researchclaw.svg)](https://hysenlabs.com/projects/ymx10086-researchclaw)