NanoResearch: a nine-stage autonomous research pipeline that submits its own GPU jobs

The problem NanoResearch targets: papers written without experiments

The README draws a line between tools that produce text and tools that produce evidence. Its comparison table lists literature search, experiment design, code generation, GPU execution, result analysis, figure generation, paper writing, resumability and per-stage model routing as separate rows, and marks GPU execution as absent from conventional AI writing tools. The stated purpose is that every datum, table and figure in the output paper comes from an experiment that actually ran, described in the README as coming from real training logs and experimental results rather than LLM invention. That is a narrower and more checkable promise than general writing assistance. The audience is implied by the surrounding material: the pipeline expects GPU access, either on a local machine or on a SLURM cluster, and it produces a full workspace with code, data, figures and a .tex file. Researchers who want a fast first draft grounded in a runnable baseline, and teams generating benchmark batches across several topics, are the people this is built for. Someone who only needs prose about existing literature is not.

Nine stages, one workspace: how the pipeline is wired

The pipeline diagram in the README is linear and explicit: IDEATION, PLANNING, SETUP, CODING, EXECUTION, ANALYSIS, FIGURE_GEN, WRITING, REVIEW, followed by exported paper.pdf, paper.tex, references.bib, figures, code and data. Each stage has a documented job. IDEATION searches the literature, looks for gaps, proposes hypotheses and collects citations that must appear. PLANNING converts the idea into an experimental blueprint covering datasets, baselines, metrics and ablations. SETUP prepares the repository, dependencies, models and datasets. CODING generates a runnable project including training scripts, data processing and model definitions. EXECUTION runs the training, with automatic retry and debugging. ANALYSIS parses logs and metrics into structured evidence. FIGURE_GEN builds architecture, comparison and ablation plots. WRITING produces the LaTeX from that evidence plus citations. REVIEW reads each section, flags problems and revises. Two design choices stand out. The first is that the artifact of a run is a workspace rather than a document, which is what makes the audit use case possible. The second is per-stage model routing, listed as a differentiator, meaning the pipeline can send different stages to different models rather than binding the whole run to one. Literature search is documented as using OpenAlex and Semantic Scholar. The README also mentions an Evo self-evolution pipeline in its table of contents, but the supplied material does not describe what it does, so treat that as unverified.

Getting it running: Python 3.10, a config file and the CLI

The repository is Python and the badge states Python 3.10 or newer. The README's quick start section is the entry point for installation, and the CLI reference section documents the command surface, but the supplied excerpt does not include the literal install command or the exact flag names, so those need to be read from the repository rather than guessed at here. What the material does establish: there is a configuration section, and the settings that matter are the per-stage model routing and the execution target, since the badges list execution as local or SLURM. The CLI has two presentation modes. The non-TUI mode is a conventional streaming log, which the README recommends for redirection and script integration. The TUI mode is a full-screen panel layout with status regions, intended for interactive monitoring. There is also a Claude Code mode and a Feishu bot integration, both documented in their own sections of the README. Output lands in a workspace containing paper.pdf, paper.tex, references.bib, figures, code and data. Resumability is claimed for any stage, which matters because a failed training run partway through a long pipeline would otherwise mean starting over.

The execution stage is where the real constraints live

Everything upstream of EXECUTION is text generation. EXECUTION is the stage that touches hardware, and it is also where the pipeline's cost and failure modes concentrate. The README says the stage runs training on a local GPU or a SLURM cluster with automatic retry and debugging. Retry logic is a reasonable response to generated code that fails on the first attempt, which is the normal case for code written without execution feedback. But retry against a cluster means repeated queue waits, and a debugging loop that cannot converge burns GPU hours without producing anything. The comparison table lists resumability as a differentiator, which suggests the authors expect interrupted runs. There is a second constraint that the README does not address in the supplied text: nothing here describes a compute budget, a wall-clock cap, or a spend limit on the execution stage. A pipeline that decides its own experiments and then submits them can queue work larger than the operator intended. If you run this, the first thing to control is what EXECUTION is allowed to submit, not what WRITING produces.

Where the generated paper will and will not hold up

The REVIEW stage is described as automatically reviewing each section, detecting problems and revising. That is a self-review by the same class of system that wrote the text. It is useful for catching structural gaps and inconsistent terminology, and it is not a substitute for peer review, because the reviewer shares the writer's blind spots. The claim that figures and tables trace back to real logs is the stronger part of the pitch, and it is also the part a reader can check: the workspace keeps code, data and logs alongside the .tex, so a table can be traced to the run that produced it. Citations are the weakest link. IDEATION is documented as collecting required references through OpenAlex and Semantic Scholar, which grounds the search in real indexes, but nothing in the material describes a verification step that confirms each cited work supports the sentence it is attached to. Treat the bibliography as a starting list to check by hand. The README's FAQ section exists and is the right place to look for known issues before trusting a run.

NanoResearch against a general coding agent

The obvious alternative is a general-purpose coding agent driven by hand: you write the experiment plan, ask the agent for training code, run it yourself, paste the logs back, ask for plots, then ask for a paper. The difference is not model quality, it is where the state lives. With a general agent, the plan, the code, the logs and the draft live in a conversation, and reproducing the run means reconstructing the conversation. NanoResearch fixes the sequence as nine named stages and writes each stage's output into a workspace directory, which is what makes the audit and batch use cases in its application list possible. The trade is flexibility. A general agent can be asked to skip planning and go straight to a quick replication; the fixed pipeline has to be walked through its stages, or resumed from a later one. The same trade applies against a fully manual workflow, where the researcher keeps control of every decision at the cost of doing the plumbing. NanoResearch is the right shape when the value is in the workspace and the repeatability, and the wrong shape when the value is in a single unusual experiment that does not fit the nine-stage mold.

Maintenance, licence and what to check before you commit

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it means the pipeline can be vendored into an internal tool without a legal review cycle. It also means no warranty, so a failed cluster job or a bad citation is your problem, not the authors'. This is not legal advice; read the LICENSE file in the repository for the operative text. On maintenance, the repository is not archived and the last push recorded is 2026-08-25. The only listed release is a static assets release from 2026-03-19, which suggests the project is distributed from the main branch rather than through versioned releases. That has a practical consequence: pinning to a tag is not an option if the only tag is an asset drop, so a reproducible deployment means pinning to a commit hash and re-checking after upstream changes. The pipeline also depends on external services for literature search and on whichever model providers the config routes to, so an upstream API change can break a stage independently of this repository. Before adopting, run one topic end to end on the smallest dataset you can find, with the non-TUI log mode so the output can be captured, and confirm that the EXECUTION stage's retry behavior terminates rather than looping.

Editorial conclusion

Adopt NanoResearch if you have GPU capacity or a SLURM cluster and you want reproducible experiment workspaces for prototype validation or benchmark batches, and you are willing to treat the generated LaTeX as a draft rather than a submission. Do not adopt it if you need a paper today, have no compute, or expect the review stage to catch fabricated citations. Before committing, verify the model routing keys under the config section, confirm whether your cluster path uses the local or SLURM execution mode, and read the FAQ for the current list of known issues.

Official sources

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