OpenScience: A Local, Model‑Agnostic Lab Notebook and Agent Workbench for Secure R&D

A local lab notebook that can call any model: OpenScience arrives

Labs and R&D teams have been choosing between three awkward options: stitch together brittle scripts, hand sensitive data to a managed vendor, or spend engineering hours building reproducible pipelines. OpenScience tries to avoid that trade-off. It is an open-source, model-agnostic research workbench that runs on your machines, exposes a browser workspace backed by an agent runtime, and ships a large library of editable skills and scientific connectors.

What OpenScience is, and what it ships

OpenScience is an Apache‑2.0 project from Synthetic Sciences that runs locally. The workspace UI, agent runtime, and tool layer live on your infrastructure, and session artifacts and provenance are stored on disk. Those design choices matter if your team cares about compliance, reproducibility, or IP.

Model-agnostic routing: each request can be sent to any model you configure, cloud frontier models or local weights, via a per-request selector.
Bring‑your‑own‑key (BYOK): you supply provider API keys and the runtime routes requests from your environment to the provider; per the README, “Bring-your-own-key usage is always free and is never gated, Atlas only meters the models it serves.”
Extensible skills and connectors: the project includes an editable skills library and connectors to scientific databases. The repository’s skills/ directory listed 290+ skills as of 2026-07-01, and the docs list UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex, Semantic Scholar and “around 30 more” database connectors.
Optional managed layer (Atlas): an opt‑in service that offers curated frontier models, cloud compute, and a persistent research graph billed from a prepaid wallet.

“OpenScience keeps the workflow open, the models swappable, and the data local.”, Synthetic Sciences / OpenScience README

How it feels and how to get started

Installation is low friction for developers:

npm install -g @synsci/openscience
openscience
or: npx synsci

On first run you can point the workspace at Atlas, plug in your provider keys, or use local/demo models. The runtime gives you a real file tree, an editor, a terminal, session history, inline renderers for molecules, structures, and genomes, and several agent variants. There is a default research agent plus specialist biology, physics, and ML agents, with critique and literature-review sub-agents.

“Skills” are modular agent actions. They mix prompt templates, TypeScript hooks, and tooling the agent uses to interact with files, shells, cloud APIs, and scientific databases. LSP means Language Server Protocol, editor language features. MCP refers to the Model Context Protocol, an integration surface for external tool and context servers.

Where OpenScience fits

Think of OpenScience as infrastructure, not a polished product. Compared with a curated commercial offering it trades UX polish for auditability, vendor freedom, and the option to run or route models locally. That trade favors regulated labs, academic teams that must keep data local, and groups that run private weights on their GPU clusters.

Security, governance, and licensing caveats

There are explicit, practical limits you must accept:

The agent is not a sandbox. The README warns:

“The agent is not sandboxed; the permission system keeps you aware of what the agent is doing; it is not an isolation boundary. Run inside a container or VM if you need isolation.”
BYOK ≠ private model telemetry. Keeping keys on your machine reduces credential-exfil risk, but it does not prevent provider-side logging, telemetry, or model training-data retention. Verify provider logging and retention policies and prefer private deployment options where required.
Model licensing matters. The codebase is Apache‑2.0, but weights and third‑party models may carry non‑Apache terms, like noncommercial clauses or export restrictions. Confirm license terms for every model or for any managed model Atlas offers before production use.

Practical mitigations: run OpenScience in an isolated container or VM, enforce network egress controls, integrate secret management and least‑privilege access for keys, implement prompt redaction or filtering where needed, and add automated tests for critical skills.

Quick adoption checklist, run a safe POC

Environment: spin up a disposable VM or container with no access to production systems.
POC tasks (minimal):
- Literature fetch: have an agent pull and summarize an arXiv paper.
- Reproducible run: run a short training loop on a toy dataset and persist artifacts and provenance to disk.
- Database query: query UniProt or PDB for an entry and render the structure inline.
Observability tests: unit tests for skills, canary prompts, session-level audit logs, cost alarms tied to provider keys, and artifact validation checks to detect hallucinated outputs.
Procurement checklist for Atlas: request model licensing details, pricing and billing cadence, data retention and telemetry policies, uptime SLA, and support response targets.

Decision rule for leaders

OpenScience is a good choice if your team has engineering ops and security capacity, must keep data local, or needs the freedom to run custom or open weights. It is less suitable for small teams that want a turnkey, fully managed, enterprise‑graded UX without investing in runtime isolation, governance, and observability.

Key questions (short, honest answers)

Can I keep my data and keys on-prem?

Yes. OpenScience is designed to run locally and uses a bring‑your‑own‑key model so API keys stay on your environment; however, provider-side logging and telemetry remain possible, confirm provider policies.
Does it cover the full research loop, literature to write-up?

Yes. It supports literature review, hypothesis generation, code and experiment execution, analysis, and write‑up, and stores session provenance on disk.
How many skills and connectors are included?

The project’s skills/ directory listed 290+ skills as of 2026-07-01, and the docs reference around 30 additional scientific database connectors (examples: UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex, Semantic Scholar).
Is the agent sandboxed and safe to run on production machines?

No. The README explicitly says the agent is not an isolation boundary; you should run it in a container or VM and implement network and secret controls for production use.
Do I have to use Atlas?

No. Atlas is optional; use it for curated frontier models and cloud compute if you want convenience, but verify pricing, model licensing, and SLAs before relying on it for regulated work.