Access to biological language models is no longer rare. Clean, deployable interfaces still are.

If you want a protein language model, a folding model, an inverse folding model, or a property predictor, you now have real options. Meta’s ESM work helped push protein language modeling into the mainstream. OpenFold made structure prediction infrastructure more accessible. ProteinMPNN changed how many teams think about sequence design. More recently, releases like Boltz and Chai-1 have made it even clearer that strong biological language modeling is no longer locked up behind a handful of institutions.

Serving biological language models is not the principal challenge anymore. Using them effectively for molecular design is. The hard part is no longer just getting a model onto a GPU or behind an endpoint — it’s deciding which model to use, deploying it reliably, exposing it through a usable interface, comparing it to alternatives, and integrating it into workflows that reflect real scientific constraints.

That’s the gap we want to help close, and it’s why we’re releasing open-source BioLM today: biolm-hub, a standardized, deployable catalog of open BioLMs, and biolm-sdk, a Python SDK and CLI for working with those models through one consistent interface.

The part we’re most excited about is that “one consistent interface” isn’t a small detail — it’s the whole point. The same SDK and CLI work whether you’re calling BioLM’s hosted APIs or your own self-hosted biolm-hub gateway, and BioLM itself is reachable through however your team already works: Console for an account and gateway into the platform, a terminal-first CLI, the Python SDK for models and pipelines, agent and MCP integrations for agentic design workflows, a REST API, or existing workflow tools like Nextflow and Kedro. Some people want a notebook. Some want a terminal. Some want to wire model calls into a workflow engine they already run. Open source should widen those options, not narrow them — and that only works if all of those surfaces speak the same language underneath.

Why Open Source?

We’re open sourcing BioLM because the ecosystem needs more deployable infrastructure and better standards around how biological language models are actually used. A few things matter to us here.

Transparency. If a model is going to influence scientific decisions, people should be able to inspect how it’s wrapped, served, and called, and compare its behavior across environments instead of relying on a black-box service.

Community contribution. A lot of the best work in biological language modeling happens in public, but the field still lacks shared conventions around serving, schemas, testing, documentation, and comparison. Open source gives the community a path to improve not just the models, but the tooling layer around them.

Self-managed deployment. Some organizations need control over where models run and how inference is exposed — sometimes for privacy, sometimes for internal infrastructure or compliance reasons. That should be a real option, not an afterthought.

Academic and non-commercial access. Not every lab wants a managed platform first. Many want direct access to working implementations they can inspect, modify, and run themselves, and we want biological language model adoption to grow in a way that supports that.

Better tooling and standards. What actually moves the field forward now isn’t another model release on its own — it’s the infrastructure around the models: cleaner interfaces, predictable schemas, better docs, clearer contribution paths, and better ways to connect models to real workflows. Open source is one way to do that work in public.

This release doesn’t happen in a vacuum, either. Meta’s ESM models expanded access to protein language modeling at scale. OpenFold gave the community a trainable, PyTorch-based AlphaFold2 reproduction. ProteinMPNN made inverse folding broadly accessible. Boltz and Chai-1 have kept pushing open availability in biomolecular modeling. All of that has made the space more productive — but anyone who’s tried to use several of these tools in the same workflow has run into the same wall: every model arrives with its own assumptions, its own interface, its own dependency story, its own deployment friction. That’s understandable — most model repos are built to publish a method, not provide a uniform operational surface — but it leaves every downstream user rebuilding the same layer over and over. biolm-hub is our attempt to make that layer consistent, once, for everyone.

What’s actually in the release

biolm-hub is a standardized catalog of deployable BioLMs that deploy into your own Modal account — an initial set that’s meant to grow with the community, not a fixed snapshot. It already spans a broad cross-section of open biological language modeling: protein language models like ESM2, structure prediction models like ESMFold, Chai-1, and RosettaFold3, design and inverse folding models like ProteinMPNN, ESM-IF1, and AntiFold, antibody and immune-focused models like ABodyBuilder3, IgBert, and IgT5, DNA models like DNABERT-2, and property and developability models like ThermoMPNN and TemBERTure.

The important part isn’t that these models are present — it’s that they’re exposed through a uniform surface. Every model family follows the same layout. Every deployment uses the same small set of action verbs: predict, fold, encode, generate, score, and log_prob. Schemas are standardized, errors are typed, docs are generated, and every model carries metadata on sources, licensing, and comparison context. When every model has its own one-off conventions, you’re not building with a catalog — you’re building with a pile of exceptions. biolm-hub is meant to be the opposite of that, and it’s built to stay contributor-friendly as it grows: shared layout, shared expectations, a contribution path that keeps the shape intact.

We also describe biolm-hub as agent-first, and that’s a design constraint, not a slogan. If an interface is predictable enough for an LLM or coding agent to use reliably, it’s usually better for humans too — fewer hidden assumptions, fewer ad hoc field names, fewer undocumented edge cases. An agent should be able to answer two questions cleanly: how do I call this model, and why would I use it instead of another one? That’s why the hub ships with supporting metadata and docs, not just wrappers — open BioLMs become far more useful once they’re not just callable, but comparable.

biolm-sdk is the client layer on top of all this: one Python SDK and CLI, built so it can call either BioLM’s hosted APIs or your own local biolm-hub gateway.

# in biolm-hub
bh deploy esm2
bh serve

# in biolm-sdk
biolm hub set http://127.0.0.1:8000
biolm model list

Or in Python:

from biolm import Model

result = Model("esm2-8m").encode(
    type="sequence",
    items=["MKTAYIAKQRQGHQ", "MENDELKLV"]
)

We did not want to publish a model catalog without a usable client. And we did not want a client that only worked in one deployment mode. The goal is to let users keep a stable interface while choosing the infrastructure path that fits their work.

For teams that want it managed

BioLM’s hosted platform is the fastest path to production: managed GPU-backed APIs, shared protocols and datasets, and a lot less operational overhead than standing the stack up yourself. We support several levels of hosted usage, from a free tier for individuals up through enterprise deployment — Basic to get started, Pro for individuals and teams who want finetuning and unlimited concurrent API usage, Teams for multi-seat orgs with admin controls and a priority queue, Enterprise for custom licensing and deployment, and a free Academic Program for non-commercial academic use.

Some groups will want the hosted path because it’s faster and simpler. Others will want the open path because it gives them more control. Plenty will use both at different points — the interfaces connect cleanly between them either way.

Where we go from here

This is the first batch of deployable models to be released, with additional batches from the full catalog in the coming weeks. We’ll keep adding model families and deployable variants over time, and we want the ecosystem around it to keep improving too — better docs, better integrations, better standards, better contribution paths. Contributions and requests are both welcome: if there’s a model family you want added, a rough edge in the SDK or hub, or a workflow pattern the ecosystem still lacks, tell us.

The long-term goal isn’t just to publish more wrappers. It’s to help make biological language models easier to use as infrastructure.

If you want to explore the release: browse the repos at github.com/BioLM, start with biolm-hub for open deployments, use biolm-sdk from Python or the CLI, read the docs at biolm.ai/docs, explore the platform at biolm.ai/platform, and see hosted usage at biolm.ai/pricing.

Open BioLMs have already made the field more accessible. We think the next step is making them more usable. Serving models is getting easier — using them well for molecular design is still the harder problem. That’s the one we want to keep working on, and now more of that work is happening in the open.