The Open-Source Claude Science Has Arrived: Zero Dependencies Is Just the Beginning

The Peking University–Yuankong AI Agent Joint Laboratory recently open-sourced a research Agent designed to rival Claude Science. Released under the MIT License, the project’s core runtime has no third-party package dependencies and comes with more than 30 research Skills covering literature processing, data analysis, life sciences, academic writing, scientific visualization, remote computing, and more.

Put simply, it attempts to bring work that researchers previously carried out across browsers, Jupyter, RStudio, SSH terminals, and manuscript editors into a single Agent workflow capable of autonomous planning and tool use.

The most noteworthy aspect of this project is not that it is “yet another free Claude Science,” but that it does not lock research capabilities to Claude or any particular subscription service. The model handles reasoning, Skills define specialized workflows, and the lab’s own servers handle execution—the three are separated into replaceable modules.

For developers who need to integrate DeepSeek, GLM, GPT, Claude, or local models, this architecture is clearly more practical than a closed research workbench.

Not a Chatbox for Science, but a Research Task Executor

There are plenty of “AI for Science” projects, but many products still take the form of chatbots: researchers upload a few PDFs, the model provides summaries, and then generates text that looks like a paper based on prompts.

These tools can save reading time, but they struggle to become part of real research workflows. The reason is straightforward: research requires more than language generation. It also requires searching databases, running code, inspecting data, invoking domain-specific software, recording parameters, and ensuring that results are reproducible.

This is where the line is drawn between a chatbot and a research Agent.

After receiving a task such as “analyze mutations related to a particular target and generate publication-ready figures,” it should not simply produce an answer from the model’s memory. Instead, it should complete an execution chain like the following:

1. Break down the research question and confirm the species, data sources, and analytical criteria;
2. Search papers and specialized databases;
3. Download or read structured data;
4. Generate and execute Python, R, or command-line scripts;
5. Check missing values, sample sizes, and statistical methods;
6. Create figures while preserving the code and parameters;
7. Organize citations and clearly distinguish conclusions supported by data from those that are merely inferred;
8. Output reports and intermediate artifacts, rather than only a chat response.

This is also the fundamental reason Claude Science has attracted attention: Anthropic did not try to “teach Claude to become a scientist.” Instead, it brought Claude Code’s planning, tool use, file operations, and remote execution capabilities into research scenarios.

This open-source project follows a similar approach, while opening up key components and lowering the deployment barrier.

“Zero Dependencies” Does Not Mean Nothing Needs to Be Installed

The project’s claim of “zero dependencies” can easily be misunderstood.

It generally means that the core Agent runtime relies as much as possible on the language’s built-in standard capabilities. Users do not need to install a long list of Python packages first, nor do they need to set up complex vector databases, message queues, or container orchestration systems. For developers, this means fewer version conflicts and code that is easier to audit and migrate.

A typical streamlined structure might look something like this:

research-agent/
├── agent/              # Task planning, context, and tool orchestration
├── skills/             # 30+ research Skills
│   ├── literature/
│   ├── genomics/
│   ├── protein/
│   ├── single-cell/
│   ├── figures/
│   └── remote-compute/
├── workspace/          # Data, scripts, and experimental artifacts
├── config.example      # Model and execution environment configuration
└── main                # Core entry point

But a “zero-dependency core” absolutely does not mean that every research task can be completed on a bare machine.

If a Skill needs to run single-cell analysis, it may still require Scanpy, Seurat, or the appropriate R environment. Protein structure prediction still requires model weights, GPUs, containers, or remote APIs. Connections to external resources such as PubMed, UniProt, PDB, and GEO may also be subject to network availability, credential requirements, and API rate limits.

A more accurate interpretation is: the Agent itself does not force users to adopt a massive infrastructure stack, but each scientific task still has its own domain-specific dependencies.

This is actually a sensible design. The dependencies of research software cannot be eliminated by magic. What can be done is to isolate them within Skills and execution environments, rather than turning the entire Agent into a monolithic environment that consumes tens of gigabytes after installation and collapses whenever it is upgraded.

More Than 30 Skills—But the Number Is Not What Matters

The project comes with more than 30 research Skills. Based on the areas disclosed so far, its capabilities are mainly concentrated in the following categories:

• Literature workflows: Search, screening, reading, citation organization, and review generation;
• Life science data processing: Genomics, protein structures, single-cell analysis, and related database tasks;
• Scientific computing: Writing and running analysis scripts, and processing experimental data and statistical results;
• Publication-quality visualization: Generating figures, preserving plotting code, and modifying figures based on natural-language instructions;
• Research writing: Organizing methods, experimental results, figure captions, and references;
• Remote computing: Running computationally intensive tasks through SSH, cluster schedulers, or cloud GPUs;
• Process logging: Saving tool calls, execution logs, file artifacts, and cost information.

However, the number of Skills is not a particularly meaningful metric.

A Skill can be no more than a page of prompts, or it can encapsulate data validation, command execution, failure retries, and result verification. Splitting one workflow into ten Skills naturally increases the headline number, but it does not make the system more capable.

What really matters is whether each Skill answers four questions:

• When should it be invoked? Are the trigger conditions clearly defined?
• What should it invoke? Are the tools, parameters, and input formats explicit?
• How is success determined? Is there result validation, rather than treating a command’s exit as completion?
• What happens if it fails? Can it retry, fall back to an alternative, or communicate uncertainty to the researcher?

A Skill can be understood as a “standard operating procedure” for the Agent. An ordinary prompt merely tells the model to “act professionally.” A real Skill tells it what to check first, what to run, what to produce, and under which circumstances it must stop and ask a human for confirmation.

Whether this project can eventually develop an ecosystem therefore depends on whether the community contributes verifiable research workflows or merely large numbers of renamed Markdown prompts.

The MIT License Matters More Than “Free”

The project is released under the MIT License, which means developers and organizations may use, modify, distribute, and integrate it into commercial products, provided that the relevant copyright and license notices are retained.

This is especially important for research Agents.

University laboratories, hospitals, and pharmaceutical companies are generally reluctant to hand their data directly to external SaaS providers. Medical images, patient information, unpublished experimental results, and candidate drug structures may all involve privacy, intellectual property, or compliance requirements. Even if a research assistant running exclusively in a vendor’s cloud uses a more capable model, it will still struggle to enter these environments.

The MIT License, combined with a lightweight core, allows teams to deploy the Agent on their own workstations or servers, keeping data and computation local while sending only the necessary context to model services. When paired with a local model, fully on-premises operation is theoretically possible.

This is also the greatest structural advantage of the open-source implementation over Claude Science: it may not offer the same level of product maturity, but it gives organizations much greater control.

Of course, the MIT License only addresses software licensing, not data licensing. Research databases, full-text papers, model weights, and third-party APIs may still be governed by their own terms of use. Before using the project in production, companies must not interpret “the project is MIT-licensed” as meaning that “the entire research data chain can be used commercially without restriction.”

Replaceable Models Are the Real Cost Lever

Closed research platforms can easily create lock-in: workflows are designed around a particular model, tool protocols follow that model, and historical records and team assets remain on the vendor’s platform. If model pricing changes or the service becomes unavailable, migration costs can rise rapidly.

An open-source research Agent, by contrast, can treat the model as a reasoning backend rather than as the entire product.

Developers can assign different models to different tasks:

• Use a long-context model to read papers and experimental records;
• Use a model with stronger coding capabilities to write analysis scripts;
• Use a lower-cost model for initial literature screening and formatting;
• Use a local model to process sensitive data;
• For critical conclusions, switch to a more capable model for cross-review.

This type of routing mechanism is particularly valuable for research. A review task involving hundreds of papers can consume a large number of tokens. If every step is assigned to the most expensive model, costs will be substantial. Tasks such as data cleaning, literature classification, and citation formatting do not require a flagship model every time.

Developers in China must also consider model API access and network availability. If the project uses an OpenAI-compatible API format, switching between services becomes much easier. Aggregation platforms such as OpenAI Hub can also serve as multi-model access layers without requiring changes to each Skill’s invocation logic.

However, it is important to note that API compatibility only solves the question of “how to send requests.” It does not guarantee that different models will behave identically when using tools. Claude, GPT, Gemini, and DeepSeek still differ significantly in structured output, long-horizon task planning, error recovery, and adherence to tool parameters. A truly robust Agent needs schema validation, timeout controls, and an execution state machine outside the model itself.

Where Does It Fall Short of Claude Science?

Open source does not automatically mean better.

Claude Science has the advantage that Anthropic can control the model, Agent runtime, tool protocols, and user-facing product simultaneously. It can optimize deeply around Claude’s capabilities and provide more complete multi-agent collaboration, artifact presentation, context management, and permission controls.

The open-source version offers flexibility and auditability, but the trade-offs are equally clear:

1. Configuration Costs Are Shifted to Users

Not subscribing to a commercial platform does not mean there are no costs. Model quotas, database permissions, GPUs, cluster environments, and various scientific software packages all need to be provisioned and maintained by the team.

2. Skill Quality May Be Inconsistent

Research methods are not ordinary office templates. An incorrect statistical assumption, database field mapping, or unit conversion can invalidate an entire analysis pipeline. Community-contributed Skills need versioning, test data, and review by domain experts.

3. Reproducibility Still Requires Engineering Support

Preserving chat history alone is far from sufficient. A rigorous research workflow must record at least:

• Model name and version;
• System prompts and Skill versions;
• Tool and software package versions;
• Input data sources and checksums;
• Random seeds and runtime parameters;
• Scripts, logs, and intermediate files;
• Manual modifications and approval records.

Otherwise, if the Agent generates a beautiful figure but cannot answer “which data and which code produced this figure,” it remains nothing more than a demo product.

4. Scientific Correctness Cannot Be Left to the Model to Validate Itself

Having another Agent act as a Reviewer can reduce basic errors, but it cannot replace peer review. If two Agents use the same model and similar context, they may share the same biases, ultimately creating a closed loop in which the system “generates its own claims and proves them itself.”

Critical conclusions still require verification against raw data, independent recalculation with separate tools, and confirmation by researchers.

What It Will Replace First Is Not Scientists, but Window Switching

In the short term, research Agents will not autonomously complete reliable drug discovery, nor will they solve complex scientific problems from a few prompts. Their most realistic value today lies in eliminating repetitive operations and the manual transfer of context across research workflows.

For example, researchers would no longer need to manually copy database results into a spreadsheet, export a CSV from that spreadsheet, open Python to clean the data, and finally paste the resulting figure into a paper. An Agent could complete all of these steps in a unified workspace while preserving every intermediate file.

This may not sound as exciting as “AI discovers a new law of nature,” but it is far more likely to deliver genuine productivity gains.

For developers, this open-source release also points to a direction worth following: the next phase of Agent competition will not be only about whose model has more parameters, but about who can better organize task specifications, tool interfaces, execution environments, and traceable artifacts.

Models will continue to change, research databases will be updated, and computing environments will migrate. Only when Skills and experimental processes become truly portable assets can research Agents avoid becoming obsolete whenever a model vendor changes its products.

Our Assessment

At present, this open-source version of Claude Science is better understood as an extensible foundation for research Agents than as a complete workbench capable of directly replacing mature commercial products.

“Zero dependencies, MIT, and 30+ Skills” make for strong promotional talking points, but whether it can enter real laboratories will be determined by three more mundane factors: whether it can execute reliably, whether it can reproduce experiments, and whether it can clearly tell users what went wrong when it fails.

Its significance also does not lie in proving that “the open-source community replicated Claude Science in a few days.” Product interfaces and Skill lists are easy to copy; integration with scientific databases, permission systems, long-running task recovery, result validation, and domain-specific evaluation are where the hard work lies.

Still, decoupling model providers from research workflows is already a step in the right direction. Research infrastructure should not depend on a single subscription, nor should every laboratory be required to upload sensitive data to the same cloud provider.

If the community can add standardized testing, data provenance, and reproducible execution environments to Skills, this project will become more valuable than a “free alternative.” It could become an open research capability layer accessible to many different models.

References

• GitHub: Search for Claude Scientific Skills repositories—For exploring open-source implementations, directory structures, and community-derived projects related to research Skills.
• GitHub: Search for Claude Science projects—For tracking Claude Science-related tools, integration projects, and the latest code updates.
• GitHub: AI Scientist topic—For a broader overview of the open-source ecosystem for automated research, experiment execution, and paper-generating Agents.