NanoResearch ships two dependency lists and the second one is short

Two dependency lists exist and one of them is missing a declared package

The project manifest and a plain requirements file both enumerate the runtime dependencies, and they are not the same list. The manifest declares thirteen. The requirements file lists twelve. The package that is in the first and absent from the second is the YAML parser, and the manifest pins it with a lower bound like everything else. There is nothing subtle about the omission; it is one line. What makes it more than cosmetic is which file the instructions tell you to use. The quick start clones the repository and installs the project in editable mode with its development extra, which resolves from the manifest, not from the requirements file. So the file nobody is told to use is the file that is wrong, and it will stay wrong until someone runs a tool that diffs the two, because nothing in the build reads it. It is also the kind of drift that gets caught the moment someone installs for a different reason than the documented one.

The section that proves the figures are real contains no figures

The page opens with a claim worth believing if it is true: that the tool actually runs computational experiments, submits the generated code to a GPU cluster, collects real results, generates the figures, and outputs a complete LaTeX paper whose every number, table and chart comes from an experiment that ran rather than from a model's invention. It makes that claim three times in three places, including in the headline callout and in a comparison table. Then it presents the evidence, and the evidence is four tables. Each table has two or three cells. Each cell contains a caption and a line break. None of them contains an image. So the section whose stated purpose is 论文实测展示, the display of figures measured from real runs, renders as a grid of empty labelled boxes, and the closing note asserting that the figures were generated by the pipeline and sourced from real training logs is attached to nothing. The claim could still be true. On this page, it is unevidenced.

The execution stage edits its own code and resubmits, twice

This is the part that separates the project from a writing tool, and it is one bullet in a list. When a training run fails, the pipeline analyses the error log, fixes the code and re-executes. The configuration sets the retry budget to two by default, and the stage also submits batch scripts to a cluster, monitors job status, detects local GPUs, and streams logs and metrics as the run progresses. It can switch between local and cluster execution automatically depending on task complexity, and the default profile is a quick local one. Put the three facts together and you have a system that writes training code, runs it on real hardware, reads the failure, rewrites the code, and spends more compute, up to a configurable limit. That is the honest version of autonomous research, and it is also the part with the largest blast radius: the cost of a bad suggestion is measured in GPU hours rather than in a wrong sentence.

The resume command ships an unsubstituted placeholder

Resumability is a headline feature: any stage can be recovered, and there is a dedicated command for it.

nanoresearch resume --workspace ~/.nanoresearch/workspace/research/{session_id} --verbose

The workspace argument ends in a brace expression that nothing on the page tells you how to fill. The export command beside it has the same placeholder in the same position, and so does the launch example in the verification step. So the three commands that constitute the practical workflow of a long run all carry an unresolved template variable, and a reader has to infer both what the session identifier is and where it is printed. Given that the export step is the one that produces the paper, this is an unfortunate place for the documentation to be eliding its own argument. A dry-run command is provided for verification, which is the right mitigation, though the page does not point out that it is also the way to discover the workspace path.

The only release in the repository is a bundle of static assets

The release history has one entry and its name is assets, with a description of static assets. It is dated in March and it is not a version. Meanwhile the project manifest reads zero-point-one-point-zero, and there is no tag anywhere in the list that corresponds to it. So the releases page is being used as a deployment bucket for the web front end rather than as a version history, which means there is no tag to pin, no changelog to diff between versions, and no way to ask the repository which commit you have. For a tool whose selling point is reproducibility, and whose stated use case includes generating reproducible experiment results in batch, that is a gap worth noticing. The last commit to the default branch came at the end of August, so the branch is moving while the release surface is not.

Per-stage temperature is the real routing mechanism

The comparison table claims multi-model collaboration where other tools have a single model, and the mechanism it describes is routing by stage. The configuration makes that concrete, because each stage carries its own model, temperature, token ceiling and timeout. Ideation runs at a temperature of one half. Planning drops to two tenths. Code generation drops again to one tenth. All three carry the same token ceiling of sixteen thousand and the same ten-minute timeout. So the multi-model claim is really two claims: you may route stages to different models, and the project lowers temperature monotonically as it moves from ideas to code, which is a sensible default for a pipeline whose output is executable. What is not documented is which model names are valid, what the temperature knob does at each stage in practice, or whether the same model can be used throughout, since the example simply repeats your own model in all three places.

Four front ends over one engine, including an MCP server at the top level

The pipeline is reachable four ways, and the repository layout shows it. There is a command line, which itself has two presentations: a full-screen panel interface and a plain streaming log, the latter chosen for redirecting and for script integration, with the stated reason that the plain form suits automation. There is a mode for working inside a coding agent. There is a messaging bot for a Chinese workplace chat platform. And there is a server directory at the top level for the Model Context Protocol, which means the whole research pipeline can be driven by an external tool rather than only by its own CLI. That is a broader surface than the quick start suggests, and it is the reason the repository has both a CLI entry point declared in the manifest and a top-level server package. It also means there are four places where a bug in the same stage logic would show up.

An unexplained training extra sits outside the described scope

The manifest declares three optional dependency groups and two of them are obvious. The development group brings a test framework, its async plugin and an HTTP mocking library. The mathematics group brings a computer algebra library. The third does not match anything in the visible description: it pulls a deep learning framework, a transformers library, a parameter-efficient fine-tuning library, an accelerator library and a safetensors reader, under the name sdpo. Nothing on the page explains what sdpo stands for or what it enables, and the dependency list is large enough that installing it is not a small decision. The core dependency set is otherwise modest and readable, thirteen packages covering schemas, one provider client, HTTP, parsing, templating, plotting, a CLI framework, terminal output, the protocol server, imaging and PDF handling. The mismatch between that tidy core and one unexplained training stack is the thing to ask about.

Editorial conclusion

NanoResearch is worth reading for the execution stage, because a pipeline that actually runs the experiment and refuses to fabricate the numbers is rarer than the marketing around it suggests. Two things to weigh before you point it at a cluster. It edits its own code and re-submits when a training run fails, with a configurable retry count, so the blast radius of a bad suggestion is a compute budget rather than a wrong paragraph. And its own claims are unevenly supported: the assertion that every figure comes from a real run is repeated three times, while the section meant to demonstrate it contains only labels.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. OpenRaiser/NanoResearch on GitHub
4. README
5. Releases