In partnership with

No account required. It launched five days after Anthropic's Claude Science, explicitly positioning itself as the open alternative: "One company shouldn't own the tools the rest of us discover with, or decide who gets to."

SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | July 16th 2026

The default assumption in AI-powered scientific research is that you pick a platform, accept its model, and work within its constraints. Anthropic's Claude Science runs exclusively on Claude models. You do not get to route specific steps to DeepSeek for cost efficiency, or to a local fine-tuned biology model that your institution trained on proprietary data, or to anything that is not Anthropic's inference stack. The model and the research environment are bundled together.

OpenScience's bet is that this bundling is the wrong architecture for science. Researchers at different institutions have different regulatory constraints, different cost budgets, and different trust relationships with different model providers. A biology lab in the EU may not be able to send patient-adjacent data to US cloud providers. A genomics team at a pharmaceutical company may have domain-specific fine-tunes that outperform any frontier model on their specific assay types. Science infrastructure that locks the model locks the workflow.

OpenScience separates the two. The research environment is open, auditable, and extensible. The model is whatever you want it to be, changed per request from a selector in the workspace. Your data stays on your machine. The skills are readable TypeScript and Python files you can read, fork, and extend without a pull request to the vendor.

Scope: OpenScience's architecture (local server + browser workspace + agent runtime + tool layer + skills system), the skills and databases surface, the Atlas managed layer, the security model, and the competitive context against Claude Science and The AI Scientist. Not covered: the Nature paper on retrieval-augmented synthesis in depth, or the detailed Atlas billing and wallet mechanics.

What It Actually Does

OpenScience runs a local server that hosts the workspace UI, the agent runtime, and the tool layer. The browser workspace communicates with the server over HTTP and SSE (server-sent events, a one-way streaming protocol for real-time agent output). The server binds to 127.0.0.1 only, with a Host and Origin allowlist. There is no remote mode.

Quick start:

# Install globally and open workspace
npm install -g @synsci/openscience
openscience

# Or run without installing
npx synsci

# Point at a specific project directory
openscience ~/code/my-protein-folding-project

# Set your own API keys; requests go directly to the provider
export ANTHROPIC_API_KEY=sk-ant-...
export OPENAI_API_KEY=sk-...
export GEMINI_API_KEY=...
openscience

# Atlas optional managed layer
openscience login     # connect Atlas for managed models + persistent research graph
openscience wallet    # check balance
openscience status    # see what you are connected to
openscience logout    # disconnect Atlas, BYOK still works

Agents available:

Agent

Purpose

research

Default agent, runs the full loop

biology

Specialist: protein targets, UniProt, PDB, Ensembl, clinical biology

physics

Specialist: physics simulations, computation

ml

Specialist: model training, evals, PEFT, TRL, DeepSpeed

Critique sub-agent

Peer-review pass on the agent's own outputs

Literature-review sub-agent

Dedicated search + synthesis pass

Plan mode (read-only)

Generates a plan without executing it

The Architecture, Unpacked

The local-first, no-remote-mode design is the data governance decision. Every API call goes directly from your machine to the provider. OpenScience never sees your data or your keys. The Atlas layer is a convenience (managed models, shared research graph) not a data route.

The Code, Annotated

Snippet One: Project Configuration and Custom Agent Setup

// .openscience/openscience.json — project-level config
// Source: openscience.sh/docs (schema: openscience.sh/config.json)
// Design intent: configuration is the extensibility layer.
// Custom agents, commands, tools, and themes load from this directory.
// The agent runtime reads project config, merging it with global ~/.config/openscience/openscience.json
// ← This layered config design means per-project settings never pollute other projects.

{
  "model": {
    "default": "claude/claude-opus-4-6",
    // ← Per-project default model; overrideable per-request from the workspace selector
    // ← Switching costs nothing at the config level: one key change = different provider
    "fallback": "deepseek/deepseek-v4-pro"
    // ← Fallback route if primary provider rate-limits or fails
    // ← Most scientific workloads are bursty; having a fallback is operationally important
  },

  "agents": {
    // ← Custom agent definitions load from .openscience/agents/
    // ← Built-in agents: research, biology, physics, ml
    // ← Here we add a domain-specific agent for a drug discovery project
    "drug_discovery": {
      "description": "Protein target identification and binding affinity analysis",
      "instruction": "You are a computational drug discovery specialist...",
      "tools": ["uniprot", "pdb", "chembl", "pubchem", "shell", "edit"],
      // ← Only expose the tools this agent needs
      // ← Keeps the tool surface narrow; reduces chance of spurious tool calls
      "skills": ["mol_docking", "pafnucy", "cheminformatics"]
      // ← skill packs are loaded by name from .openscience/skills/ or bundled skills
    }
  },

  "skills": {
    // ← Skills are TypeScript or Python files that the agent can invoke
    // ← All 250+ bundled skills are readable + forkable from the repo
    "custom_paths": ["./skills/proprietary"]
    // ← Private skills in your repo; never sent to any provider
  },

  "permissions": {
    // ← Permission system: controls what the agent can do
    // ← NOT a sandbox (README explicitly says this); a visibility layer
    "allow": ["shell", "edit", "mcp"],
    "confirm": ["cloud_compute"]
    // ← Cloud compute requires confirmation before dispatching
    // ← This prevents the agent from accidentally spinning up expensive GPU jobs
  }
}

The skills as TypeScript/Python files that live in your repo are the extensibility property that matters most. You can add a private skill for your institution's proprietary assay analysis pipeline, point the config at it, and the agent picks it up without any code changes to the OpenScience core. The alternative in a closed system is waiting for the vendor to add your use case to their skill catalog.

Snippet Two: Per-Request Model Routing and the Research Loop

// openscience SDK usage: per-request model routing + research loop
// Source: openscience.sh/docs + tooling/sdk/js (TypeScript SDK, generated from OpenAPI contract)
// Design intent: model is a parameter at call time, not a global config.
// This is the core architectural difference from Claude Science (model-locked)
// and from most AI coding tools (single model per session).

import { OpenScienceClient } from "@synsci/openscience";

const client = new OpenScienceClient({
  // ← Client connects to the local server (127.0.0.1); never to a remote
  serverUrl: "http://localhost:20128",  // default port
});

// Open a session in a specific project directory
const session = await client.sessions.create({
  workingDirectory: "/home/user/drug-discovery-project",
  agent: "biology",  // ← use the biology specialist agent
});

// Run a research task — model specified per-request
const result = await client.messages.create({
  sessionId: session.id,

  // ← THIS is the key: model is per-request, not per-session
  // You can run literature review on claude-opus (best at synthesis),
  // then switch to deepseek-v4-pro for code generation (cheaper per token),
  // then switch back to claude-opus for the write-up.
  // Claude Science cannot do this — all steps run on Claude.
  model: "anthropic/claude-opus-4-6",

  content: `
    Identify the top 5 protein targets for non-small-cell lung cancer
    that have structural data in PDB and binding data in ChEMBL.
    For each target:
    1. Query UniProt for function and disease associations
    2. Query PDB for available crystal structures
    3. Query ChEMBL for known bioactive compounds (IC50 < 100nM)
    4. Summarize binding pocket characteristics
    Return a ranked table by druggability score.
  `,
});

// Agents stream output back to the workspace as they run
// Each chunk is a tool call result, a reasoning step, or a partial write-up
for await (const chunk of result.stream()) {
  if (chunk.type === "tool_call") {
    // ← Tool calls are visible: you can see exactly what the agent queried
    // UniProt query for EGFR → response → agent reasoning → ChEMBL query → ...
    // This is provenance that a closed system cannot offer
    console.log(`Tool: ${chunk.tool} Input: ${JSON.stringify(chunk.input)}`);
  } else if (chunk.type === "text") {
    process.stdout.write(chunk.text);
  }
}

// Switch model for the next step — code generation is cheaper on DeepSeek
const codeResult = await client.messages.create({
  sessionId: session.id,
  model: "deepseek/deepseek-v4-pro",  // ← one flag change; same session
  // ← CHEAPER: DeepSeek V4-Pro at fraction of Claude Opus cost per token
  // ← for code generation where the synthesis quality is less critical
  content: "Write a Python script to run AutoDock Vina on all PDB structures found above",
});

The per-request model switch is not a feature. It is the architectural constraint that makes OpenScience viable as a multi-institution tool. An institution running a 200-step drug discovery pipeline will not pay Claude Opus prices for every step. The synthesis and write-up steps may justify frontier model cost. The data preprocessing and boilerplate code generation steps do not.

It In Action: Drug Discovery Research Session, End to End

Input: "Identify and rank protein targets for non-small-cell lung cancer with known inhibitors and structural data."

Step 1: Literature review (biology agent, Claude Opus 4.6, ~18 minutes)

Agent: research (read-only plan mode first)

PLAN:
  1. Query OpenAlex: "NSCLC protein targets 2020-2026" → 847 papers retrieved
  2. Query Semantic Scholar: citation-based prioritization → top 23 papers
  3. Literature-review sub-agent: synthesize top 23 → hypothesis generation

OUTPUT AFTER PLAN APPROVAL:
  Top targets identified: EGFR, ALK, ROS1, KRAS G12C, MET Exon 14
  Each with primary citation, mutation frequency, and approved drug status

Step 2: Database queries (biology agent, parallel tool calls)

Agent calls tools in parallel:
  UniProt → EGFR [P00533]: function, disease associations, PTMs
  UniProt → ALK [Q9UM73]: function, disease associations
  PDB → EGFR crystal structures: 387 structures → filtered to human, apo + Type I inhibitor
  ChEMBL → EGFR bioactive compounds: IC50 < 100nM → 1,847 compounds
  PDB → ALK crystal structures: 42 structures → kinase domain with lorlatinib
  ChEMBL → ALK bioactive compounds: IC50 < 100nM → 312 compounds
  ... (KRAS G12C, ROS1, MET in parallel)

TOTAL DATABASE CALLS: 14 queries across 4 databases
WALL TIME: ~3 minutes (parallel execution)
vs manual: 6 hours (sequential browser queries + data extraction)

Step 3: Structural analysis (ml agent, DeepSeek V4-Pro for code, then run locally)

Agent switches to ml agent + DeepSeek V4-Pro:
  Writes Python script: extract binding pocket residues from PDB files
  Runs script in workspace terminal
  Computes druggability scores per target (pocket volume, hydrophobicity, charge)

Inline render: protein structure visualization appears in workspace
  (molecule renderer, no external service required)

Cost of this step at DeepSeek V4-Pro pricing vs Claude Opus:
  ~80% lower per-token cost for code generation steps

Step 4: Write-up (research agent, Claude Opus 4.6)

Agent generates:
  - Ranked table: EGFR > KRAS G12C > ALK > ROS1 > MET
    (by druggability score: pocket volume, compound count, clinical validation)
  - LaTeX report draft via paper writing skill
  - Figure: binding affinity distribution per target (matplotlib, rendered inline)

OUTPUT FILE: ./outputs/nsclc_targets_analysis.tex (ready for journal submission format)

Benchmark comparison (community benchmark, r/bioinformatics, July 2026):

Task

Manual

OpenScience

Claude Science

Literature search

12 hours

18 minutes

22 minutes

Multi-database query

6 hours

10 minutes

12 minutes

Report generation

3 hours

4 minutes

5 minutes

Weekly research throughput

3 questions

40 questions

32 questions

Monthly cost (BYOK vs subscription)

N/A

$200-500

$600-4,800

Why This Design Works, and What It Trades Away

The local-first, no-remote-mode architecture is the correct call for scientific research. Hypothesis data, unpublished results, and patient-adjacent data cannot leave institutional networks in many regulatory environments. Any scientific AI tool that requires data to pass through a third-party server is unusable for a meaningful fraction of the research community. OpenScience's design, where every API call goes directly from your machine to the model provider and the workspace server never sees your data, makes it deployable in environments where Claude Science cannot go.

The per-request model routing is the cost-efficiency mechanism. Frontier model pricing varies by 5-10x between providers and between models within a provider. A 200-step research pipeline that routes synthesis and reasoning steps to a frontier model and code generation to a cheaper model can cost 60-80% less than running all steps on the same expensive model. Claude Science cannot do this. OpenScience does it with a single flag change per request.

The 250+ skills as readable, editable TypeScript and Python files are the institutional customization mechanism. A genomics lab can add a skill that wraps their internal alignment pipeline. A cheminformatics team can add a skill for their proprietary QSAR models. These skills stay in the project repo, load from the .openscience/ config directory, and never need to be submitted to the vendor for inclusion.

What OpenScience trades away:

The agent is not sandboxed. The README states this explicitly: "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." For any production research environment, container deployment is required. This is not a limitation unique to OpenScience, but it is a real operational overhead that Claude Science's managed environment does not impose on users.

Quality depends on the model you route to. OpenScience's documentation recommends Claude Opus 4.6 and GPT-5.4 for best results. A team that routes all steps to a weak local model will get weak results. The environment amplifies model capability; it does not substitute for it.

At 24 stars and 5 days post-launch, the ecosystem is early. The bundled skills are comprehensive, but the community skill registry that would make OpenScience a platform rather than a tool is not yet built.

Technical Moats

The 30+ scientific database connectors as native agent tools. UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex, Semantic Scholar, and 22 more are queryable directly by the agent without any user configuration. Building correct, rate-limit-aware, authentication-handling connectors for 30+ databases with different API designs is months of work. The community can extend this list by contributing connectors, but the baseline coverage required significant domain expertise to assemble.

The inline scientific renderers. The workspace renders molecules, protein structures, genomic data, and plots inline in the browser without external services. A researcher who runs a molecular dynamics simulation can see the structure in the workspace immediately, without copying files to a separate viewer. This requires protocol-specific rendering logic for each data type that is not trivially assembled.

The skills architecture as an open contribution target. Every skill is a TypeScript or Python file. Every skill can be read, understood, forked, and extended. This means the quality of the skills layer can compound with community contributions in a way that a closed platform's skill catalog cannot. The AI Scientist (arXiv:2408.06292, Sakana AI, 2024) showed that automated science systems can produce papers at $15 each that exceed ML conference acceptance thresholds. OpenScience's skills architecture is what that kind of automated loop would need as its execution layer: a library of verified domain tools the agent can compose into novel protocols.

Insights

Insight One: The 250 vs 60 skills comparison with Claude Science is real but misleading. OpenScience ships more skills partly because the skills are simpler to contribute: they are TypeScript and Python files with no vendor review process. Claude Science's 60 curated skills may be more thoroughly validated and more reliably useful for the average researcher. The right metric is not skill count but skill quality and coverage on the specific tasks a team does most. A computational biology team that uses OpenScience's 250 skills and finds 12 of them relevant to their work has not gotten a 4x productivity improvement over Claude Science's 60 skills. They have gotten the same productivity improvement with a larger maintenance burden from the 238 skills they never use. The skills count is a marketing number. The real question is whether the skills your domain needs are in the set, and whether they are reliable.

Insight Two: The "any model" claim needs qualification. OpenScience routes to 75+ providers and supports local models. But the research quality the workspace produces is a direct function of the model it uses for synthesis and reasoning. The community benchmarks show OpenScience at 40 research questions per week vs Claude Science at 32. But those benchmarks were run with comparable models. A team running OpenScience on a free tier model to avoid API costs will not reproduce these numbers. The open model routing is architecturally correct, but it places the model selection burden on the user. Claude Science removes that burden by making the choice for you. For researchers who are not ML engineers, the "any model" flexibility may be more confusing than helpful in practice. This is the core tradeoff the product has not yet resolved.

Surprising Takeaway

Claude is listed as one of the five contributors to the OpenScience project on GitHub. An open-source AI research workbench that positions itself as the open alternative to Claude Science was built in part by Claude Code as a contributing agent. The repo contains both CLAUDE.md and AGENTS.md, following the same dual-audience pattern as FlashInfer, Mooncake, OmniRoute, Meetily, and Handy. The tools that run the research loop are themselves built by the tools that run the research loop. OpenScience is not yet a recursive science system, but the authorship pattern suggests that the boundary between "AI tool for scientists" and "AI tool built by AI tools" has already been crossed at the implementation level, not just as a research concept.

TL;DR For Engineers

  • OpenScience (synthetic-sciences/openscience, Apache 2.0, v1.2.5, YC W26): model-agnostic AI workbench for scientific research. Runs the full loop: literature, hypothesis, code, experiment, analysis, write-up. 250+ skills, 30+ database connectors, 75+ model providers. Local-first, no remote mode, BYOK. Launched July 5, 2026.

  • Architecture: Browser workspace (SolidJS) ↔ HTTP+SSE ↔ Local Hono server (agent runtime + tool layer + skills + provider routing). Binds to 127.0.0.1. No remote mode. Credentials never in subprocess environments. Config: global (~/.config/openscience/openscience.json) + project (.openscience/ dir). Stack: Bun 1.3+, TypeScript 53%, Python 32.3%.

  • Skills: 250+ bundled (DeepSpeed, PEFT, TRL, molecular biology, cheminformatics, cloud compute Modal/Tinker). All readable TypeScript/Python files. Custom skills load from .openscience/skills/. TypeScript SDK for programmatic access. MCP + LSP integration.

  • vs Claude Science: 250 vs 60 skills; 75+ providers vs Claude-only; BYOK vs subscription ($200-500/mo vs $600-4,800/mo community estimate); local deployment vs cloud-only; not sandboxed vs managed environment.

  • Security: NOT sandboxed. Permission system = awareness, not isolation. Run in container/VM for production. Provider credentials filtered from subprocess environments.

Scientific AI Infrastructure Is Now a Political Choice, Not Just a Technical One

OpenScience launching five days after Claude Science is not a coincidence. The AI research workbench category is being defined right now, and the question of who controls the infrastructure that scientists do their work in has real consequences for reproducibility, data governance, and institutional independence.

Sakana AI's The AI Scientist (arXiv:2408.06292) showed in 2024 that automated science systems can produce papers at $15 each that exceed conference acceptance thresholds. Two years later, the question is not whether AI can run the research loop, but whose infrastructure runs it and on whose terms.

OpenScience's answer is: yours. The tradeoff for that answer is that you carry the operational burden of your own model selection, your own deployment, and your own skill maintenance. Whether that tradeoff is worth it depends entirely on your institution's regulatory constraints and how much you trust the alternative.

References

Explain It Like I'm New

Scientific research has always had a data problem. A molecular biologist studying a cancer target might spend 12 hours per week just searching through papers and databases before doing any actual analysis. The information exists, but it is scattered across dozens of different systems: one for protein structures, one for genetic data, one for known drugs, one for the research literature. Pulling it all together and making sense of it is a full-time job on top of the actual science.

The promise of AI research workbenches is that an AI can do that job. You describe what you are trying to understand, and the AI searches the databases, reads the papers, writes the analysis code, runs the experiments, and drafts a report, all in one continuous session.

OpenScience is an open-source implementation of that idea. The key word is "open." Most AI research tools are built by one company, run on their models, and keep your data in their infrastructure. A hospital using such a tool might be required to ensure that patient-related data never leaves the country, which makes a cloud-based AI service unusable. A pharmaceutical company might have proprietary models trained on their own compound library that are more accurate for their specific assays than any publicly available model.

OpenScience solves this by separating the research environment from the model. You install the tool on your own machine. You bring your own API keys for whatever model you want to use. Your data never passes through a third-party server. The 250+ research skills and 30+ database connectors run locally and can be extended by your own team.

The tradeoff is that you carry the operational complexity yourself. If the model you route to is weak, the results are weak. The tool does not make that choice for you. For institutions with the technical capability to manage that complexity, this is the correct tradeoff.

See It In Action

  • OpenScience GitHub Repository and README Source: synthetic-sciences/openscience | https://github.com/synthetic-sciences/openscience The README is unusually complete for a 5-day-old tool: install, quickstart, Atlas integration, security model, and architecture summary all in one page. Start here to understand the full scope before reading the ARCHITECTURE.md. The file tree also shows the monorepo structure that makes the extensibility model concrete.

  • Show HN: Open Science, open-source alternative to Claude Science Source: Hacker News | https://news.ycombinator.com/item?id=48800859 The original Hacker News submission from the Synthetic Sciences team. The comment thread includes practitioners from computational biology, ML research, and academic research environments discussing whether the model-agnostic design solves a real problem they face or creates new operational complexity.

  • OpenScience Documentation Source: openscience.sh | https://openscience.sh/docs The official docs cover the configuration schema, custom agent setup, skill authoring, and Atlas integration in more depth than the README. The config schema (openscience.sh/config.json) is worth reading to understand the full extensibility surface.

  • The AI Scientist Demo and Repository Source: SakanaAI / YouTube | https://github.com/SakanaAI/AI-Scientist The 2024 reference implementation for fully automated scientific discovery that produced conference-quality papers at $15 each. Understanding what AI Scientist does and where it stops provides the context for what OpenScience's skills system is designed to support as an execution layer.

Community Conversation

  • Synthetic Sciences (@SynScience) on X https://x.com/SynScience/status/2073829478393086311 The launch announcement: "One company shouldn't own the tools the rest of us discover with, or decide who gets to." Frames the product as infrastructure independence rather than feature parity. The distinction between "better science AI" and "open science AI" is the actual thesis.

  • Hacker News thread: Show HN: Open Science, open-source alternative to Claude Science https://news.ycombinator.com/item?id=48800859 The comment thread surfaces the core tension: practitioners who need model flexibility and data locality immediately understand the value; researchers who want a polished, low-configuration tool question whether the operational burden is worth the openness. Both perspectives are represented.

  • AshutoshShrivastava (@ai_for_success) on X https://x.com/ai_for_success/status/2073831720303141362 "Same core research environment, but with zero model lock-in. OpenScience runs any model... with a single configuration flag. No vendor gatekeeping, no forced degradation, and your data stays on your own infrastructure." The most concise technical framing of the OpenScience value proposition from the community.

  • Labcritics: OpenScience vs. Claude Science https://labcritics.com/blog/2026/07/07/openscience-vs-claude-science-two-takes-on-the-ai-science-workbench/ Notes that Claude is listed among the contributors to the OpenScience project, and that Claude is one of the recommended models for best results. The tool that positions itself as the alternative to Claude was built with Claude. A nuanced framing of what "open" means when the model dependencies go deeper than the license.

OpenScience (synthetic-sciences/openscience, Apache 2.0, v1.2.5, Synthetic Sciences YC W26, launched July 5, 2026) is a model-agnostic AI workbench for scientific research that runs the full research loop, literature review through write-up, as a local-first application (browser workspace via SolidJS communicating with a local Hono server over HTTP+SSE at 127.0.0.1 with no remote mode). It ships 250+ bundled skills across ML (DeepSpeed, PEFT, TRL), computational biology, cheminformatics, and cloud compute; 30+ scientific database connectors (UniProt, PDB, Ensembl, ChEMBL, PubChem, arXiv, OpenAlex, Semantic Scholar); and model routing to 75+ providers with per-request switching via a workspace selector. BYOK: API keys stay on the user's machine and go directly to the provider; provider credentials are filtered from subprocess environments. The agent is not sandboxed: the permission system provides awareness, not isolation; container/VM deployment is required for production. Built with Bun + TypeScript (53%) + Python (32.3%); the TypeScript SDK and TypeScript/Python skills files are editable and extensible without vendor involvement. Optional Atlas layer provides managed frontier models (prepaid wallet), persistent research graph, and cloud compute but is never required. Launched five days after Anthropic's Claude Science with an explicit open-alternative positioning and 4x more skills (250 vs 60) at a fraction of the cost ($200-500/mo BYOK vs $600-4,800/mo community estimate for Claude Science), but with a sandboxed and fully managed experience as the corresponding tradeoff.

Sponsored Ad

If you enjoy practical AI insights, check out SnackOnAI and support the newsletter by subscribing, sharing, and exploring our sponsored ad — it helps us keep building and delivering value 🚀

How can AI power your income?

Ready to transform artificial intelligence from a buzzword into your personal revenue generator

HubSpot’s groundbreaking guide "200+ AI-Powered Income Ideas" is your gateway to financial innovation in the digital age.

Inside you'll discover:

  • A curated collection of 200+ profitable opportunities spanning content creation, e-commerce, gaming, and emerging digital markets—each vetted for real-world potential

  • Step-by-step implementation guides designed for beginners, making AI accessible regardless of your technical background

  • Cutting-edge strategies aligned with current market trends, ensuring your ventures stay ahead of the curve

Download your guide today and unlock a future where artificial intelligence powers your success. Your next income stream is waiting.

Get Your Guide

Recommended for you

© 2026 Snack On AI.
beehiivPowered by beehiiv