Twenty-three stages turn one topic into many review obligations
AutoResearchClaw divides a research job into 23 stages across scoping, literature, synthesis, experiment design, execution, analysis, writing, and citation verification. The output can include a Markdown draft, conference-style LaTeX, BibTeX, experiment code, charts, peer reviews, and a verification report. That is a serious attempt to make an agent's work inspectable. It also creates many places where a plausible artifact can be methodologically wrong while still looking complete.
The project supports 6 human intervention modes, ranging from full automation to step-by-step review. Its co-pilot path pauses around hypothesis work, experiment design, and paper drafting, while gate stages can approve or reject progression. Researchers should start there. A rejected design can roll the pipeline back, and generated artifacts are versioned across refinement or pivot loops. Those controls make mistakes easier to catch; they do not turn model judgment into peer review.
A 911 MB install is the smallest part of a real run
Our fresh Python 3.12 container installed 156 packages in 50 seconds and occupied 911 MB. The build passed in 5 seconds. The checkout itself contained 756 files, about 131,080 source lines, and 52.6 MB. Our scan found a tests directory, no Dockerfile, and 0 CI workflow files. That last result only describes the checked-out repository structure; it does not show whether maintainers run checks elsewhere.
A useful run then needs a model. The configuration accepts an OpenAI-compatible endpoint and API key, or an ACP agent such as Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode, or Kimi CLI. Literature collection uses OpenAlex, Semantic Scholar, and arXiv, with optional web paths through Tavily or scraped search. LaTeX is needed for compiled conference output. Domain profiles may add Qiskit, COBRApy, remote GPU access, or a collider service.
What happened when we ran it
Our sandbox built AutoResearchClaw in 5 seconds after the 50-second install. Pytest completed in 156 seconds with 2,951 passed, 0 failed, and 56 skipped. Pip-audit reported 0 known vulnerabilities among the installed Python dependencies. These are strong repository-mechanics results for commit be4ba47, measured with 3 CPUs and 8 GB of RAM in an unprivileged Debian container.
We did not ask the pipeline to produce a paper, call a model, collect literature, compile LaTeX, or execute a generated scientific experiment. The 2,951 passing tests therefore establish that the tested code paths behaved as expected in our box. They say nothing about novelty, citation relevance, experimental validity, statistical power, or whether a resulting argument deserves publication. Any review that converts this test result into a claim about research quality would be overstating what the run measured.
Generated experiments need an execution policy before the first prompt
The default example uses a local Python sandbox with an allowlist and a 4,096 MB memory limit. Other documented modes include Docker, SSH to a remote machine, and domain-specific agents. Docker can auto-install detected dependencies and offers network policies from none to full. The OpenCode path can generate files, run fixes, and retry execution. These are useful controls, yet every path is still executing code proposed by a model.
A lab should decide where generated code may run, which imports and networks are allowed, what data it can read, and who reviews dependency additions. The repository's absence of a Dockerfile means users cannot point to one project image as the defined isolation boundary. The setup command checks Docker and LaTeX, while the actual experiment configuration decides what is enforced. An unprivileged disposable container with no production credentials is a sensible baseline for evaluation.
Paper type and search reliability still have open edges
Open issue 320 asks AutoResearchClaw to distinguish empirical, systematic-review, PRISMA, theoretical, and technical-document papers. That request matters because these forms require different evidence collection and reporting methods. A 23-stage empirical workflow should not silently stand in for a systematic review protocol. Until the interface represents the requested type, users need to encode the method in the topic, configuration, custom prompts, approval stages, and final human checks.
Literature discovery also depends on external behavior. Issue 321 says the optional scholarly scraper is blocked fairly quickly during unattended runs and proposes Serply as a keyed Google Scholar backend. The core path still names OpenAlex, Semantic Scholar, and arXiv, and the configuration permits API keys for higher limits or optional search. Researchers should retain the query log, verify every included reference at its primary source, and record which database and cutoff produced the corpus.
The default cost ceiling is unlimited until you change it
AutoResearchClaw can call models across literature screening, multi-agent debate, code generation, repair, analysis, review, revision, and verification. The documented human-in-the-loop configuration sets cost_budget_usd to 0, which means no limit. Parallel tasks default to 3, experiment optimization can run up to 10 iterations, and repair can add 3 cycles. Those defaults describe capability, not an estimate of what one paper costs.
Version v0.5.0 was released on May 20, 2026, adding domain profiles and ARC-Bench. GitHub showed a last push on August 19, 14,241 stars, and 6 combined open issues and pull requests when fetched. Recent August work included agent reasoning controls, debate changes, and a proposed search backend. The project is active, while its own call for testers is a fair maturity signal. Use the 23 stages to organize research labor, then make a qualified human accountable for every result that leaves the lab.