OpenResearch: a local-first workspace that turns Claude Code, Codex, OpenCode or Cursor into research agents

What OpenResearch actually solves for agent-driven experiments

Coding agents are good at editing files and bad at remembering why. A session that changes a training script, launches a run and reads the loss curve leaves no durable link between the diff, the command and the result unless you build one by hand. OpenResearch is aimed at that gap. The README describes it as a local-first workspace for research agents and autoresearch, and the loop it claims to close is explicit: propose an idea, change the code, launch an experiment, inspect the evidence, decide what to try next.

The intended user is someone who already runs an agent in a terminal and wants the surrounding bookkeeping handled: independent sessions per research direction, an experiment tree in git, and an archive of the commit each run was recorded against. It is not a notebook replacement and it is not a paper-writing tool. It is infrastructure for people whose research output is code plus runs.

How the orx CLI, git worktrees and the local SQLite store fit together

The repository is a Rust workspace whose binary is named orx, with the package name openresearch-cli in Cargo.toml. Two dependencies describe the architecture better than any diagram. rusqlite is pulled in with the bundled feature, which compiles SQLite from source, and the README states that OpenResearch runs on 127.0.0.1 with a local SQLite store. Projects, conversations, experiments, runs, logs, code and artifacts therefore live on your machine by default; creating a project or launching a run does not publish your code.

The second clue is portable-pty plus axum and rust-embed. The dashboard is a single-page app embedded in the binary and served by an axum router, and the agent sessions are driven through a pseudo-terminal. That is why orx up opens a browser UI at a fixed loopback address instead of shipping a separate server process.

Isolation is per direction, not per project. The README says each research direction gets an independent agent session and an isolated git worktree, and that every run receives an immutable archive of its recorded commit. So the unit of parallel work is a worktree, and the unit of record is a commit snapshot. Multiple agents can explore different directions at once while the experiment tree preserves their lineage.

The same committed source snapshot can run locally, over SSH, or on Slurm, Kubernetes, Ray, Hugging Face Jobs, Modal, Tinker, and managed OpenResearch compute. Publishing the repository is not required. The harness and model are selected per session, which is what lets Claude Code, Codex, OpenCode and Cursor sit behind one interface.

Installing the orx CLI and running your first project

The README gives one install path for macOS and Linux: a shell script from openresearch.sh piped into sh, followed by the up command. macOS 11 or later is listed as supported. Windows is a separate beta download that requires Git for Windows, documented in docs/windows.md.

curl -LsSf https://openresearch.sh/install.sh | sh
orx up

After orx up finishes, the local dashboard is served at http://127.0.0.1:4791. Open that address in a browser. If nothing answers, the CLI is the first thing to check, since the dashboard is embedded in the same binary rather than installed separately.

To make the agents aware of the workspace, install the skill into the supported coding agents:

orx install-skills

The README does not spell out which directories that command writes to, so treat it as a change to your agent configuration and review it before running it inside a repository you care about. Once the skill is in place, the common commands are short and read like a filesystem browser over your own work:

orx projects
orx project view <project-id>
orx runs <project-id>
orx logs <run-id>
orx exp run <experiment-id>

For literature, orx discover keyword <query> searches by keyword and orx paper <arxiv-id-or-doi> resolves a single paper. Run orx --help or orx <command> --help for the complete interface, since the README only lists a subset. A demo directory named demo/nanochat exists in the repository if you want something to point the tool at before committing your own work.

Running the workspace next to remote GPUs, and the exposure that comes with it

The remote mode is the most interesting command in the README and also the one with the clearest warning attached. The pattern is to run the workspace next to remote GPUs while using the browser on your laptop:

orx up --remote user@host

SSH config aliases and custom ports are supported. The README then states plainly that the remote service binds to loopback and has no application-level authentication, so other users on that host can reach it. That is not a footnote. On a shared cluster login node, loopback binding protects you from the public internet but not from colleagues with accounts on the same machine. If your threat model includes other users on that host, this mode is the wrong tool until you put your own access control in front of it. The README does not document an authentication option, so there is nothing to configure here.

The second constraint is the managed path. An openresearch.sh account is described as being used only for service-owned capabilities such as organizations and managed OpenResearch compute. If you want everything to stay off the vendor entirely, local and self-hosted compute are the options, and an account is not required for them.

Telemetry, and what the release builds send

Official release builds send opt-out, coarse usage events tied to a random installation ID. The README is specific about what is excluded: code, prompts, file contents or paths, repository names, tokens, emails, and project and experiment identifiers. Source and development builds do not send analytics at all, which means a build from the repository behaves differently from the binary you download.

Three controls exist, and the first two are worth running once so you know which state you are in:

orx telemetry off
orx telemetry status
orx <command> --no-telemetry

The per-command flag is the useful one for scripted runs, since it does not depend on a setting persisted earlier. The README does not describe how to verify the claim about excluded fields from the client side, so the honest position is that you are trusting the description rather than auditing it.

Where OpenResearch is the wrong choice

The experiment tree is git-native, so every direction you explore costs a worktree and a commit. That is a reasonable trade for a project with a few parallel hypotheses. It is a poor fit for exploratory work where nothing is worth committing yet, because the lineage the tool provides comes from commits that exist. If your research loop is one long interactive session in a single checkout, the worktree isolation buys you nothing and the extra structure is overhead.

Multi-user collaboration is the sharper boundary. The README frames local ownership as a feature, and the remote mode has no application-level authentication. There is no documented story for two researchers sharing one workspace safely on a shared host, and the README does not document rollback of a run or an experiment, so plan for that gap before you rely on the tree as an undo history.

Finally, the agent choice is real but not free. Claude Code, Codex, OpenCode and Cursor are all listed as supported harnesses, with the harness and model selected per session. Connecting a local model is documented separately in docs/local-models.md, which covers LM Studio, oMLX, Ollama, or a custom endpoint with OpenCode. If your harness of choice is not one of those four, the integration does not exist.

How it compares with a hosted experiment tracker

Weights & Biases and similar hosted trackers answer a different question. They assume a training script that already runs, and they collect metrics from it into a service you query from anywhere. The code stays in your repository and the record of the run lives on their infrastructure. OpenResearch inverts that: the record lives in a local SQLite store on 127.0.0.1, the agent session is the thing being orchestrated, and the run is tied to a commit snapshot rather than to a metrics stream.

The practical difference shows up in two places. First, offline work: a hosted tracker needs network access to log, while the README states that creating a project or launching a run does not publish your code. Second, scope: a tracker will not propose an idea or edit the code, and OpenResearch will not give you a hosted comparison view across a team. If you need the second, the local-first design is a cost rather than a benefit.

A plain git branch plus a shell script is the other alternative, and it is closer than it looks. You get worktree isolation with git worktree add and an immutable record with the commit hash. What you do not get is the agent session, the experiment tree, or the CLI commands that tie a run to its logs and artifacts. Whether that is worth a dependency depends on how often you actually run parallel directions.

Licence, maintenance and upgrade cost

The repository is MIT licensed, and Cargo.toml declares license = "MIT" for the openresearch-cli package. That is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and permission notice are preserved. The repository also ships a LICENSE file at the top level. This is a description of the licence text, not legal advice; if you are redistributing the binary or embedding the code, read the LICENSE file and the notices it requires yourself.

The release cadence is fast and recent. v0.2.2, v0.2.3 and v0.2.4 all landed within the four days before 2026-09-17, and the last push to main was on 2026-09-17. Three patch releases in four days is a normal pattern for a young tool, but it also means the CLI surface can move between minor versions. The README points at orx --help as the authoritative interface, which is the right habit to keep: pin a version you have verified rather than tracking latest.

Upgrade cost is mostly local. The state is a SQLite store and git worktrees, both of which you control, so a bad upgrade does not strand data in a vendor account. The unknown is schema migration, which the README does not document. Back up the store before upgrading if the projects in it matter.

Editorial conclusion

Adopt OpenResearch if you already drive Claude Code, Codex, OpenCode or Cursor and you want experiment lineage, parallel worktrees and run logs kept on your own disk rather than in a hosted notebook. Skip it if you need a multi-user service: the remote dashboard binds to loopback with no application-level authentication, so anyone with an account on that host can reach it, and the README does not document rollback or access control. Before committing a project, install the CLI, run orx up, confirm the dashboard answers on 127.0.0.1:4791, and check where the SQLite store lands on your filesystem.

Frequently asked questions

Official sources

1. alphaXiv/OpenResearch on GitHub
2. License: MIT
3. Project website
4. README
5. Releases