One workspace covers papers, code, and experiments
OpenScience starts a local server and opens a browser workspace with files, an editor, terminal access, sessions, and scientific previews. Its Research agent can query literature and scientific databases, write programs, run them on permitted compute, inspect outputs, and prepare a written result. The README lists 311 bundled skills and around 30 database integrations, spanning machine learning, biology, physics, and chemistry.
The application is broader than a paper chatbot. A Hono backend runs the agent loop and tool layer, while a SolidJS front end presents the project. Provider routing supports hosted keys, eligible ChatGPT access, local models, and optional paid Ace routes. MCP servers, plugins, custom agents, commands, and project skills can extend it. That breadth makes OpenScience attractive for mixed work, though each added runtime or connector enlarges the environment a lab must understand.
A free account is required even with your own model key
The install command is simple: install the npm package globally or launch it through npx synsci. First launch links a free Synthetic Sciences account and leaves a revocable device credential on the machine. A model still has to come from somewhere. Users can provide API keys, connect eligible ChatGPT or Codex access, use a local model, or fund the optional Ace wallet.
Account linking matters to a local-first evaluation. The current README says local sessions continue without managed services after the device is connected, while enhanced search, managed models, synced credentials, and private research graphs depend on Synthetic Sciences. It also says Use my data is enabled after sign-in and uploads the full research trajectory, including prompts, model responses, tool calls, and results, with credentials redacted. A lab should inspect and set that control before opening confidential work.
What happened when we ran it
Our sandbox installed commit 2ecaa76 in 91 seconds, adding 799 packages and occupying 870 MB. The build completed successfully in 81 seconds. The checkout was already 84.5 MB, with 4,776 files and roughly 463,014 lines of source. We found 9 CI workflow files and workspace configuration, but no root Dockerfile or tests directory.
The test command did not finish within the 900-second limit. Its last output showed passing session usage and compaction cases. Several persistence cases took about 3 to 5 seconds apiece, including managed handoff-file behavior and preservation of command controls. The log tail contained no failing assertion, and it also did not provide a completed total. The accurate result is a timeout, not a pass or a failure count.
That long run changes the maintenance calculation. A clean install and build prove the monorepo can be assembled in our 3-CPU, 8 GB Debian container. They do not prove every workspace flow, model provider, scientific connector, sandbox backend, or platform binary. Teams should identify a smaller pre-merge set for their own deployment while retaining a scheduled full run with enough time to finish.
The sandbox limits commands but does not make code safe
OpenScience can run shell commands, edit files, access scientific services, and launch compute. New local installs use an approval mode with native containment where available. On macOS that means Seatbelt, and on Linux it means bubblewrap. The documented sandbox test checks whether containment is working. Host and Origin allowlists protect the localhost server, which is not designed for remote exposure.
The security guide draws firm limits. Windows has no sandbox backend, and neither native backend is a full virtual machine. External MCP servers sit outside the stated trust boundary. The README advises a container or VM for hostile code, which is the right standard for downloaded repositories, untrusted datasets with active formats, or model-generated commands that reach unfamiliar tools. Human approval remains a policy control rather than proof that execution is harmless.
Research contracts can stop before evidence is reconciled
Issue 334 describes a concrete workflow failure in v2.0.31. One automatic contract continuation can be followed by a stop even when work remains repairable or a compute job is still active. The report also says artifacts registered directly through the ArtifactStore API may be missing from the session trace, causing a required result to appear absent despite durable storage.
That issue does not show that every research run loses evidence. It does show why the workspace cannot be the final scientific arbiter. A finished answer should point to immutable artifacts, executable code, source papers, environment details, and review results that a person can inspect outside the conversation. For costly experiments, add explicit checkpoints before the agent moves from computation to interpretation.
Active releases favor current users over frozen deployments
GitHub recorded a push on August 26, 2026, and release v2.0.45 was published the same day. The repository had 3,342 stars and 18 combined issues and pull requests when fetched. Nine CI workflows cover areas including code scanning, end-to-end work, package tests, catalog checks, and publishing. This is an active project with a fast release pace, rather than a settled scientific instrument.
OpenScience earns a trial when a lab already expects to supervise an agent and wants its papers, programs, terminals, and artifacts visible together. The 900-second test timeout and 870 MB dependency footprint make casual source maintenance less appealing. Pin a release, verify the sandbox on each host, disable unwanted sharing, and define what evidence a human must accept before a generated result leaves the workspace.