OpenScience: AI Workbench for Scientific Research (Claude Science Alternative)

OpenScience is a free, open-source alternative to Claude Science that runs the entire scientific research loop on your device.

You feed it a research goal, then work inside a local browser workspace where the agent can read papers, plan research steps, write code, run experiments, inspect results, and draft findings.

The workspace combines a file tree, editor, terminal, scientific database tools, model routing, agents, and session history.

You can use your own model API keys, connect Atlas-managed models, or start with the demo-model route during first setup.

Visit OpenScience

You already have a research question and a folder full of half-read papers. You want something to pull the relevant literature, write the analysis script, run it, and hand you a draft write-up.

Right now you do each step by hand, across six browser tabs and a Jupyter notebook. That is the job OpenScience is built for.

You type a goal into the workspace, and the agent works through the loop: it reads, it codes, it runs experiments against real compute, it checks the scientific databases directly, and it writes up what it found.

Features

Runs literature review, hypothesis generation, code, experiments, analysis, and write-up in one continuous session.
Includes a default research agent plus biology, physics, and ml specialists, each with a critique sub-agent and a read-only plan mode.
Bundles 250+ skills covering DeepSpeed and PEFT training runs, dataset work, cheminformatics, molecular and clinical biology, LaTeX and figure generation, and cloud compute through Modal and Tinker.
Queries around 30 scientific databases directly, including UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex, and Semantic Scholar.
Opens as a browser workspace with a file tree, editor, terminal, and inline rendering for molecules, structures, genomes, and plots.
Extends through LSP integration, MCP servers, plugins, custom agents and commands, and a TypeScript SDK.
Filters provider credentials out of subprocess environments and redacts them from output, according to the project’s security notes.

OpenScience vs Claude Science

OpenScience and Claude Science both target scientific research workflows, but they fit different access models.

OpenScience is the more open route. It is Apache-2.0 open source, runs from a local CLI, opens a browser workspace, and supports bring-your-own-key model access

Claude Science is Anthropic’s scientific workbench for Claude users. It is designed around the Claude ecosystem, scientific artifacts, lab infrastructure, managed compute paths, curated scientific connectors, and reviewer-style checks.

	OpenScience	Claude Science
Access	Open source, no account required for BYOK use.	Beta access for Claude Pro, Max, Team, and Enterprise users.
Model route	Model-agnostic BYOK, plus optional Atlas managed models.	Built around Claude.
Install and control	CLI-first local workbench with browser workspace.	Claude app/workbench for scientific users.
Best fit	Researchers who want open-source control, local setup, provider choice, and command-line workflows.	Researchers already using Claude who want Anthropic’s managed scientific environment.
Extensibility	Agents, skills, MCP, ACP, plugins, custom commands, and SDK paths.	Claude Science skills, connectors, reviewer agents, and lab infrastructure integrations.
Cost boundary	OpenScience is free software; model calls may cost money through providers or Atlas.	Access depends on eligible Claude plans and any related compute or program terms.
Safety boundary	Local agent is not sandboxed; use a container or VM for isolation.	Runs in the Claude Science environment with user infrastructure and Claude’s product controls.

How to Use OpenScience

Install OpenScience globally:

npm install -g @synsci/openscience

Or launch it without a global install:

npx synsci

Set a provider key for BYOK usage:

export ANTHROPIC_API_KEY=<your-provider-key>

Use the equivalent environment variable for your provider, or use interactive provider sign-in:

openscience auth

Open the workspace:

openscience

Open a specific project folder:

openscience ~/code/my-project

In the browser workspace, choose or confirm a model route, then enter a narrow research goal.

Example first task:

Review the notes in this project, find the strongest related papers, create a small analysis script, run it on the available data, and summarize the result with any generated plots or files.

After the run, inspect the file tree, generated code, terminal output, rendered objects, session history, and written result. Then verify model and skill availability:

openscience models
openscience skill list

Use the workspace for visible research sessions. Use openscience run for terminal tasks, automation, scripts, JSON output, or one-shot research commands.

Command Reference

Setup and Verification

openscience --version / openscience -v

Prints the installed version. Run it after installation, upgrade, or troubleshooting. Then check models and skills with openscience models and openscience skill list.

openscience --help

Prints top-level CLI help. Run it to inspect the command list on the installed version.

openscience <command> --help

Prints help for one command. Run it when you need exact local flags for your installed version.

openscience --print-logs

Streams agent diagnostics to stderr. Use it during troubleshooting, support work, or failed runs.

openscience --log-level <level>

Changes the log threshold. Use it when troubleshooting output needs more or less detail.

Workspace and Local Server Commands

openscience

Starts the local server and opens the browser workspace in the current directory. Use it for the main interactive research workflow.

openscience ~/code/my-project

Starts the workspace with a specific project folder as the root. Use it when files, notes, code, and sessions should stay with an existing project.

openscience web

Starts the server, opens the browser workspace, and prints the URL. Use it when you want an explicit web command instead of the bare shortcut.

openscience web --port <port>

Starts the workspace on a selected local port. Use it when the default port conflicts with another local process.

openscience web --cors <origin>

Allows an extra CORS origin for the workspace server. Keep this limited to controlled local integration work.

openscience serve

Starts the local server without opening a browser. Use it for headless local operation or long-running server sessions.

openscience serve --port <port>

Starts the headless server on a selected local port. Use it when an attach workflow needs a predictable local URL.

openscience serve --cors <origin>

Adds an allowed CORS origin to the headless server. Treat it as a local integration option, not public hosting.

One-Shot Runs and File Context

openscience run [message..]

Sends one prompt from the terminal, streams the result, and exits. Use it for scripts, CI tasks, terminal research checks, or quick project analysis.

openscience run "Profile train.py and find the input-pipeline bottleneck"

openscience run -f <path> "..." / openscience run --file <path> "..."

Attaches a local file to the prompt. Use it for papers, data files, diffs, scripts, notebooks, or molecular structures.

openscience run "Set up a DFT optimization for this structure" -f data/sample.cif

openscience run --model <provider/model> "..."

Uses a specific model for one terminal run. Use it when a task needs a selected provider route.

openscience run --variant <tier> "..."

Selects a reasoning-effort tier when the chosen model supports it. Available tiers depend on the model.

openscience run --agent <agent> "..."

Runs a prompt with a selected agent. Use it for research, biology, physics, ml, plan, or a custom agent.

openscience run --command <command> "..."

Runs a configured custom command with the message as arguments. Use it after defining custom command behavior.

openscience run --title <title> "..."

Sets a title for the created session. Use it to keep terminal-created sessions easy to identify.

openscience run --format json "..."

Emits JSON event lines. Use it when scripts need tool-use events, text, errors, or structured run output.

openscience run --format json "Summarize the experiment in results/" > summary.json

openscience run --port <port> "..."

Sets the local port for a throwaway server used by a terminal run. Use it when local port control matters.

Sessions, Continuation, Attach, Export, and Import

openscience session list

Lists recent sessions. Use it to find session IDs and previous research threads.

openscience session list -n <count>

Limits the number of sessions shown. Use it when the session list is long.

openscience session list --format json

Prints the session list in JSON. Use it when scripts need session IDs or metadata.

openscience run -c "..." / openscience run --continue "..."

Continues the most recent session. Use it when the last session is the correct thread.

openscience run -s <session-id> "..." / openscience run --session <session-id> "..."

Continues a specific session by ID. Use openscience session list first when you need the ID.

openscience run --attach <url> "..."

Sends a prompt to a running local server. Use it with openscience serve or an existing workspace server. It does not attach files.

openscience export <session-id>

Writes a full session as JSON to stdout. Redirect it to a file for archive, support, handoff, or reproduction notes.

openscience export <session-id> > session.json

openscience export

Opens an interactive session picker before export. Use it when you do not want to copy a session ID manually.

openscience import <file>

Imports a session JSON file. Use it to move a session to another machine or restore an exported transcript.

openscience import session.json

Models, Providers, and Billing

openscience auth

Starts interactive provider sign-in. Use it when you prefer guided provider setup over environment variables or the Credentials panel.

openscience logout [provider]

Logs out of a connected provider. Use it to remove local provider connection state.

openscience models

Lists configured providers and models. Run it after provider setup, Atlas connection, catalog refresh, or first installation.

openscience models <provider>

Lists models for one provider. Use it when you need model IDs for a selected provider.

openscience models --verbose

Shows more model metadata where available. Use it for model inspection, not as static pricing copy.

openscience models --refresh

Refreshes the local model catalog. Use it when model availability looks stale.

openscience models --flat

Prints one provider/model ID per line. Use it in scripts or when copying a model ID into --model.

openscience billing show

Shows credit and recent managed-route usage in Atlas-connected mode. Use it to inspect managed-model spending.

openscience billing topup

Opens the top-up flow for Atlas credit. Use it when managed-model access needs more wallet balance.

Atlas Connection Commands

openscience connect login

Connects the local device to Atlas through a browser flow. Use it for Atlas managed models, synced credentials, spend controls, or research graphs.

openscience connect login --key <atlas-cli-key>

Connects with a CLI key. Use it on headless or CI machines.

openscience connect login --no-browser

Starts a headless login flow. Use it on machines without a browser.

openscience connect status

Shows the current Atlas connection state. Use it to check account, device, synced credentials, default model, and credit state where available.

openscience connect sync

Re-pulls synced service credentials from Atlas. Use it after changing dashboard-managed credentials.

openscience connect devices

Lists authenticated devices. Use it to audit machines connected to Atlas.

openscience connect logout

Disconnects the current device from Atlas. BYOK use remains available after logout.

Agents

openscience agent list

Prints the available agent roster. Use it before selecting an agent in the workspace or with run --agent.

openscience agent create

Scaffolds a custom agent interactively. Use it to create a recurring specialist role with its own prompt, tool set, routing policy, and mode.

openscience agent create --path <path>

Writes the agent definition to a specific path. Use it to choose project-local or user-global storage.

openscience agent create --description "<text>"

Supplies the intended role for the generated agent. Use it to guide the scaffolded profile.

openscience agent create --mode <primary|subagent|all>

Sets where the agent appears. primary agents lead sessions, subagent profiles work through delegation, and all supports both.

openscience agent create --tools "read,grep,glob"

Sets the tool allow-list. Use it to restrict a custom agent’s available actions.

openscience agent create --model <provider/model>

Sets the default model for that agent. Use it when a custom agent should prefer a specific provider route.

Skills

openscience skill list

Lists learned and installed skills. Use it to inspect the active skill library.

openscience skill list --all

Lists the bundled skill set by category. Use it to view the broader scientific and workflow skill surface.

openscience skill show <namespace>

Shows a namespace summary. Use it to inspect a group of related skills.

openscience skill show <namespace/skill>

Prints metadata and the full SKILL.md for a specific skill. Use it before relying on a skill in a research workflow.

openscience skill add <url> / openscience skill add gh:owner/repo

Installs skills from a public git repository. Review the safety-check output before using third-party skills.

openscience skill new <name> --description "<text>" --editor

Creates a local user skill and opens it in the editor. Use it for reusable lab procedures, review checklists, analysis steps, or domain workflows.

openscience skill edit <name>

Opens a local skill in $EDITOR. Use it to revise an existing user skill.

openscience skill validate <name>

Checks skill frontmatter and safety. Use it before regular use or sharing.

openscience skill validate <name> --strict

Fails validation on warnings. Use it when warnings should block a skill.

openscience skill set-entries <namespace> <entries>

Controls which skills in a namespace appear in the / picker. Use it to keep the workspace picker focused.

openscience skill remove <name-or-namespace>

Uninstalls a skill or namespace. Use it to remove unwanted skill entries.

Integrations: ACP, MCP, GitHub, and PR Work

openscience acp

Starts an Agent Client Protocol server for compatible editors. Use it when your editor workflow uses ACP.

openscience mcp list

Lists configured MCP servers. Use it to inspect external tool connections.

openscience mcp add ...

Adds an MCP server. Use it to connect external MCP tools.

openscience mcp remove ...

Removes an MCP server. Use it when an external tool connection is no longer needed.

openscience mcp auth ...

Authenticates an MCP server where required. Use it when a configured MCP tool needs authorization.

openscience github install

Installs or configures GitHub agent support for CI/Actions. Use it for GitHub-oriented agent workflows.

openscience github run

Runs the GitHub agent for CI/Actions. Use it inside a GitHub workflow context.

openscience pr <url>

Checks out a pull request branch and launches the agent on it. Use it for PR review, code investigation, or branch-level work. Review changes before merging.

Project, API Spec, Stats, Debug, Upgrade, Uninstall, and Completion

openscience project

Pins the Atlas project root for the current folder. Use it when Atlas project context should follow a local directory.

openscience project merge

Merges or pins Atlas project-root behavior for the current folder. Use it only when Atlas project association matters.

openscience generate

Prints the local server OpenAPI spec to stdout. Use it to inspect or integrate with the local server API.

openscience stats

Shows local token-usage and cost stats. Use it to review local usage tracking beside provider or Atlas billing.

openscience debug

Produces structured diagnostics. Use it when troubleshooting install, runtime, model, or support issues.

openscience debug paths

Shows data and config directories. Use it before editing, backing up, or removing local configuration.

openscience upgrade

Updates OpenScience. Run openscience --version afterward to confirm the installed version.

openscience uninstall

Removes the binary and local config. Use it when you want to remove OpenScience from the machine.

openscience completion <shell>

Prints a shell completion script for bash, zsh, or fish. Redirect it into your shell’s completion path when you want command completion.

Alternatives & Related Resources

Pros

Works with any model provider you choose
No account required for local use
Fully open source under Apache 2.0
Ships 250+ bundled research skills
Queries around 30 scientific databases directly

Cons

Not sandboxed; isolation is your job
No built-in citation-checking reviewer agent
Browser workspace only.

FAQs

Q: How does OpenScience compare to Claude Science?
A: OpenScience is an open-source, model-agnostic alternative to Claude Science. While Claude Science is tied to Anthropic’s models, OpenScience works with any provider using your own API keys. OpenScience also ships with over 290 research skills, more than four times Claude Science’s initial offering.

Q: Do I need an Atlas account to use OpenScience?
A: No. Atlas is Synthetic Sciences’ managed platform that provides curated models billed from a prepaid wallet, but OpenScience works entirely with your own provider API keys. Bring-your-own-key usage is always free and never gated.

Q: Is the agent sandboxed?
A: No. The permission system keeps you aware of what the agent is doing, but it is not an isolation boundary. Run OpenScience inside a container or VM if you need isolation.

Q: Can I use OpenScience with local models?
A: Yes. OpenScience works with any open-weight model you can serve via an API endpoint. The model selector lets you switch between providers and local models.

Q: What happens to my API keys?
A: Your keys stay on your machine. Requests go straight from your local server to the provider. Keys are filtered out of subprocess environments and redacted from output.