Git worktrees give each agent an isolated experiment branch
OpenResearch treats an experiment as code plus recorded evidence. Each research direction gets its own agent session and Git worktree, while the experiment tree records parentage and results. A run receives an archive of the committed snapshot that produced it. This is a better fit for code-driven research than a chat transcript because a later reader can connect an agent's claim to its branch, log, diff, output file, and run state.
The dashboard and orx CLI support Claude Code, Codex, and OpenCode. Commands list projects and runs, open logs, create experiment nodes, launch compute, and fetch papers. The bundled skill also tells an agent how to write reports, figures, and papers into a durable artifacts directory. OpenResearch supplies the operating structure; the selected coding agent still supplies the reasoning and code changes.
Local projects need no account and open on port 4791
Running orx up starts the local dashboard at 127.0.0.1:4791 with a SQLite store. Creating a project or launching a local run does not require an OpenResearch account and does not publish the repository. The README says projects, conversations, runs, logs, code, and artifacts stay on the machine for the local path. An account is reserved for organizations, instance provisioning, and managed OpenResearch compute.
Compute choices are broad. The same committed source snapshot can run locally, over SSH, or through Slurm, Kubernetes, Ray, Hugging Face Jobs, Modal, Tinker, and the hosted service. That list describes adapters rather than free capacity. Researchers still need the corresponding machines, credentials, schedulers, quotas, and model access. The useful promise is a shared experiment record across those backends, not removal of their operational requirements.
What happened when we ran it
Our sandbox installed 213 Rust packages in 20 seconds and built commit f584d5a in 92 seconds. The source checkout was 7.7 MB, with 344 files and roughly 110,729 lines. Six CI workflow files were present. We found no Dockerfile and no top-level tests directory, which is worth noting for deployment expectations but does not imply that tests are absent from a Rust codebase.
The test command ran for 264 seconds and passed all 1,338 tests with 0 failures. That is the clearest result among the four projects in this review batch. It covers the repository's own test suite in our fresh unprivileged container with 3 CPUs and 12 GB of RAM. We did not run a scientific workload, rent remote compute, compare agent models, or measure the quality of generated hypotheses.
Build and test together took 356 seconds after installation, so source validation is slower than the one-line binary installer suggests. The result is still strong: there was no compiler failure, test failure, or skipped test count in the supplied measurement. Teams extending the Rust service or its embedded web UI can start from a reproducible green checkout instead of first repairing the toolchain.
Four experiment rules protect comparisons from agent drift
The bundled OpenResearch skill imposes 4 cardinal rules. A completed node freezes permanently; every node inherits the same run command and environment; variants change committed code rather than command-line knobs; and the experiment tree should descend through winners instead of collecting endless children at the root. These constraints address a familiar problem in agent research: an agent can make two runs incomparable while still producing plausible charts and prose.
That method has a cost. A researcher accustomed to quick environment-variable sweeps must encode each variant in tracked code or configuration and create a child node. Repairing a run is allowed only when it answered nothing; a disappointing result remains a result. This is disciplined and auditable, but teams need to accept the model before adoption. Fighting it with ad hoc shell commands would keep the interface while discarding the reason to use it.
Remote mode trusts every user on the host
The orx up --remote user@host path puts the service beside remote GPUs while the browser stays on the laptop. The remote process binds to loopback, yet the README explicitly says it has no application-level authentication. Other users on that host can reach it. On a single-user machine that may be acceptable. On a shared university server, lab workstation, or multi-tenant bastion, it is a direct reason to walk away or add isolation outside OpenResearch.
Autoresearch also changes the threat model. An agent can propose an idea, edit code, launch a run, inspect evidence, and choose another experiment. Worktrees limit accidental branch overlap, but they do not make arbitrary experiment code safe. Credentials available to the agent or job, network access, compute budgets, and destructive commands still need controls from the selected harness and execution environment. Git lineage helps explain what ran after the fact; it is not a sandbox.
Version 0.1.117 moves quickly and still excludes Windows
GitHub listed 537 stars, 45 forks, and 7 combined issues and pull requests. The last push was August 31, 2026, and the latest release was v0.1.117 from August 28. That same version appears in the measured Cargo manifest. The project is young, but active maintenance, 6 CI workflows, and 1,338 passing tests support more confidence than the 0.1 label alone would suggest.
Platform coverage remains narrower than compute coverage. Prebuilt release files target Apple Silicon and Intel macOS plus ARM64 and x64 MUSL Linux. The README gives CLI installation only for macOS and Linux, and issue 207 asks for Windows support. Official release builds also send coarse opt-out analytics under a random installation ID. OpenResearch is ready for a serious pilot on its documented platforms, provided the team secures remote hosts and agrees to its experiment discipline.