Open Science Desktop: a local-first AI research workbench built on Tauri, MCP and agent skills

The gap Open Science Desktop fills: research runs that leave a paper trail

Most AI research tools end a session with a chat transcript. The figure you generated, the notebook you ran, the environment it ran in, and the model output that produced it are scattered across a terminal, a browser tab and a downloads folder. Open Science Desktop is aimed at people who need those pieces to stay connected: the README describes the project as connecting "agents, notebooks, files, figures, reports, runs, and review into one auditable desktop workflow."

The target user is a researcher or research engineer who works on a laptop or workstation and wants the agent to produce inspectable artifacts rather than prose. The README states that the bundled ai4s-agent chains specialist skills end to end (explore, survey, experiment, write) and that each stage drops a real artifact into the workspace. That is a different contract from a chat assistant. It is also a different contract from a hosted notebook service, because sessions, data, provenance, notebooks and run records live in local folders and, per the README, nothing leaves by default.

The project also positions itself explicitly as an open-source alternative to Claude Science and similar AI-for-science workbenches. If your institution blocks hosted research agents, or your data cannot leave the machine, that positioning is the whole reason to look at it.

How the workbench is put together: Tauri shell, osd-core server, OpenCode sidecar

The Cargo workspace root explains the architecture better than the README does. There are three crates and the split is deliberate. crates/osd-core holds the server: workspace paths, the OpenCode sidecar, the opencode config, projects and runs, and the HTTP gateway. It depends on no Tauri, so it runs on a machine with no display. apps/desktop/src-tauri is the desktop shell with Tauri commands and the GUI-only features (kernel, Jupyter, browser, ssh, ACP, dialogs). crates/osd-cli is the osd binary: the same server without a window, plus a client for it and for a running desktop's gateway.

The comment in Cargo.toml gives the reason for the split in plain terms: a Tauri app cannot run headless because tao calls gtk::init() on Linux, which needs a display, and webkit2gtk is not installed on a compute node. So the core is its own crate rather than a feature flag. That is a design decision with consequences. It means the headless path is not a stripped-down reimplementation; it is the same server the desktop app runs.

On the JavaScript side, the root package.json names the workspace ai4s-workbench at version 0.5.2 and routes every script through a single desktop filter, so pnpm dev, build, test, typecheck and lint all resolve to @ai4s/desktop. The UI is described as talking through packages/sdk to a bundled, pinned OpenCode sidecar. That pinning matters for reproducibility and it also means your model provider has to be reachable through that sidecar rather than through an arbitrary SDK of your choosing.

Installing Open Science Desktop and running a first session

The README's install section is the entry point; the desktop app ships an installer for macOS, Windows and Linux, and the osd command ships inside that installer. According to the release notes for 2026-08-18, osd puts itself on your PATH on first launch, and on a server the archive needs nothing installed.

For a source build, the repository is a pnpm workspace with a Cargo workspace alongside it. Node 20 or newer is required and the package manager is pinned, so the first commands are the toolchain check and the dependency install:

node --version   # must be >= 20
pnpm install

With dependencies in place, the dev script from the root package.json starts the desktop app through the @ai4s/desktop filter:

pnpm dev

The README gives a first real use in the form of two slash commands. /plan lays out an execution plan before the agent touches a file, and /goal fixes the objective, constraints and acceptance criteria the agent then works toward. Setting a goal first is the difference between an agent that wanders and one whose output you can check against a stated criterion.

On a machine with no display, the same workbench starts as a server. The 2026-08-18 release notes describe osd server as starting the whole workbench, including the workspace, the agent runtime and the same web UI:

osd server

From there the notes give osd session send with a --wait flag for driving the session from a script or another agent, and name osd model, osd auth and osd approval as the terminal commands for models, keys and approvals.

Provenance and run records: what reproducibility actually means here

The claim worth scrutinising is "reproducible by construction." The README says local, SSH/Slurm, Modal and notebook-batch runs are captured as reproducible run records rather than loose terminal scrollback, and that figures, tables, reports, notebooks and run outputs link back to the exact code, inputs, environment, model output and conversation that produced them.

That is a stronger guarantee than a saved script, because it captures the environment and the model output alongside the code. It is weaker than a container digest in one respect: the documentation does not state that a run record pins package versions or a filesystem image, only that the environment is among the linked items. If your definition of reproducibility requires bit-identical re-execution, verify what the record actually stores before you rely on it for a publication.

The practical benefit is auditability within a project. When a figure looks wrong three weeks later, the link back to the conversation and the inputs is the fastest path to the cause. The cost is storage and bookkeeping: every run writes a record, and long projects accumulate them. The README does not document a retention or garbage-collection policy for run records.

Where Open Science Desktop is the wrong tool

The local-first design is a constraint, not a bonus, in several situations. If your team needs a shared, hosted workspace where several people open the same session from different machines, this is not that. The README's remote access story is a token-authenticated gateway that serves the desktop UI to a browser on your LAN or phone, loopback by default and LAN opt-in. That is remote viewing and remote driving of your own machine, not multi-tenant collaboration.

The model-agnostic claim also has an edge. The UI talks through packages/sdk to a bundled, pinned OpenCode sidecar. Pinning is good for reproducibility, but it means the set of providers you can use is the set the sidecar supports, not every provider with an HTTP API. The README does not enumerate the supported providers.

Two more gaps are visible in the repository itself. The licence metadata is inconsistent: the GitHub repository reports NOASSERTION, the README badge and the package.json and Cargo.toml manifests all say MIT. That is usually a licence-file detection problem rather than a different licence, but it is the kind of thing a procurement or legal review will stop on. And the root package.json carries pnpm overrides with a security comment naming brace-expansion, js-yaml and nanoid advisories reached through transitive dependencies. Those overrides exist because the dependency tree does not resolve safe versions on its own, and the comment says to keep each override on its existing major line until it does. Anyone building from source inherits that maintenance work.

How it differs from JupyterLab with an AI extension

The obvious alternative for a local, notebook-centric research workflow is JupyterLab plus an assistant extension. The difference is where the agent sits. In JupyterLab the notebook is the primary object and the assistant is a helper inside it; the agent has no notion of a project, a run record or a stage pipeline. In Open Science Desktop the README describes the notebook as one artifact among several, alongside figures, reports, runs and review, all linked to the session that produced them.

That shows up in the feature list. Named projects group sessions, and two layers of persistent memory (global and per-project) carry context between them. A long conversation compacts itself as it approaches the model's context window. The README also describes split-pane tiling with a different model per pane, and an Agent Client Protocol integration that works in both directions: you can drive Codex, Gemini CLI, Claude Code or another ACP agent from inside the app, or drive Open Science itself from Zed, JetBrains or Neovim.

JupyterLab wins on ecosystem maturity and on the number of people who already know it. Open Science Desktop wins if your unit of work is a multi-stage research project rather than a single notebook, and if you want the run record and the provenance link to be first-class rather than something you assemble yourself. The examples directory, with examples/bci-trends and examples/climate-trends, is where to look for what a finished project is supposed to contain.

Licence, releases and the cost of keeping up

The manifests declare MIT: package.json has "license": "MIT" and the Cargo workspace package section sets license = "MIT". The README badge says MIT. The GitHub repository metadata says NOASSERTION, which typically means the platform could not classify the LICENSE file automatically. Treat that as something to read yourself rather than as a contradiction to resolve by assumption; this is not legal advice, and the LICENSE file at the repository root is the document that governs.

Release cadence is visible from the tags: v0.5.0 on 2026-08-19, v0.5.1 on 2026-08-28, v0.5.2 on 2026-09-08, with the last push to master on 2026-09-10. That is a fast-moving project, and the version numbers are aligned across package.json and the Cargo workspace at 0.5.2. Fast releases mean upgrade cost is real: the Cargo.lock and pnpm-lock.yaml both exist, so a source build is reproducible at a commit, but moving forward means re-running pnpm install and a Rust build against a tree whose transitive overrides are still being managed by hand.

The headless path lowers that cost for server deployments. Because osd-core has no Tauri dependency, an osd server on a compute node does not need webkit2gtk or a display, which is the part of the stack most likely to break on a cluster.

Editorial conclusion

Adopt it if you run long, artifact-heavy research sessions and want the provenance trail, the project memory and the headless osd server in one install. Do not adopt it if you need a hosted, browser-only tool or a signed build pipeline that the repository does not document. Before committing, verify three things on your own machine: that a run record reproduces from the captured environment, that the licence file's actual terms match the MIT claim in the manifests, and that your chosen model provider works through the pinned OpenCode sidecar.

Frequently asked questions

Official sources

1. ai4s-research/open-science on GitHub
2. Issues
3. Project website
4. README
5. Releases