Claude

IntuitionLabs is now a member of the Claude Partner Network – AI training and upskilling with Claude for pharma and biotech. Book a call.

IntuitionLabs
Life sciences research team reviewing computational analysis on shared screens

Hosted Claude Science, Ready in Any Browser

Anthropic ships Claude Science for macOS and Linux only. We give every scientist a dedicated, powerful Linux server with their workbench already running — reached from any browser on any laptop, Windows included, with shared project storage and managed infrastructure behind it.

Book a Meeting

Why research teams ask us to host it

Claude Science is a desktop application with a hard platform requirement and an appetite for compute. Three things stop teams from adopting it on their own, and all three are infrastructure problems rather than science problems.

The Windows wall
Anthropic builds the app for macOS on Apple Silicon, macOS on Intel, and Linux x64. There is no Windows release. In most pharma and biotech R&D estates the standard laptop is Windows, so the scientists with the strongest case for a computational workbench are the ones who cannot install one.
Laptops run out of memory
Single-cell atlases, structural work, and large cheminformatics screens routinely need far more RAM than a corporate laptop physically has. Persistent Python and R kernels that hold dataframes and loaded models in memory across a whole analysis make that ceiling arrive sooner, not later.
Work stranded on laptops
When every analysis lives in a personal home directory, sharing it means emailing a script or copying a folder to a network drive. Datasets get duplicated, versions diverge, and a departing colleague takes the working environment with them.
Someone has to operate it
A Linux VM per scientist means provisioning, hardening, patching, identity, backup, network policy, and a support path at 9pm when a job dies. That is a platform engineering function. Most research groups do not have one, and most IT groups did not plan for one this quarter.

A workbench where every result carries its own provenance

Claude Science runs analyses, queries databases, and traces each step from raw data to publication. Every figure, table, and notebook ships with the exact code, the environment, a plain-language description, and the conversation that produced it — so a result can be reproduced, edited, or defended months later by someone else on the team. Screenshot: Anthropic.
  • Provenance is the feature that changes how a research organisation can use an AI tool at all. A chat transcript is not evidence. An artifact bound to the code that generated it, the package versions it ran against, and the reasoning that led there is something a second scientist can inspect, a supervisor can sign off, and a reviewer can challenge.
  • That matters twice over in a regulated setting. It gives you a defensible answer to "how did you get this number", and it gives you a practical answer to the staff-turnover problem that quietly destroys institutional knowledge in computational groups — the analysis leaves with the person who wrote it. Work produced on a hosted pod inherits this by default, and the pod adds an infrastructure-level audit trail underneath it.
  • Screenshots on this page are Anthropic's own published product images, reproduced to illustrate the application we host.
Claude Science showing a generated single-cell figure beside the exact code, execution log, and review tabs that produced it

A reviewer agent that checks the work before you see it

A background reviewer inspects outputs for citations that do not resolve, numbers that cannot be traced to evidence, and figures that do not match the code behind them. It flags what it finds and the agent self-corrects in its next message, which turns a class of silent AI error into something visible and auditable.
  • The failure mode everyone fears with AI in research is the confident, well-formatted, wrong answer — a mis-assigned PMID, a statistic with no traceable source, a figure caption describing a chart that says something else. Those errors are expensive precisely because they look finished.
  • The reviewer agent attacks that directly. In Anthropic's own example the reviewer catches the same PubMed identifier being assigned to two distinct methods papers, explains why the plan is internally inconsistent, and hands the finding back for correction before the result surfaces. It is not a guarantee of correctness and it does not remove the scientist from the loop, but it moves a whole category of mistake from invisible to flagged.
  • Teams doing medical review, triage, or evidence synthesis tend to weight this capability more heavily than raw analytical speed, because their bottleneck was never generating text.
Claude Science reviewer agent flagging a duplicated PubMed identifier during a cross-species literature review, next to the compiled PDF output

Cluster jobs and live kernels, driven from the same session

The app writes batch scripts, then submits and manages jobs over SSH against your own machine or HPC cluster, or through a Modal account. Persistent Python and R kernels keep variables, dataframes, and loaded models in memory across an entire analysis, so iteration stays fast instead of restarting from disk each time. Screenshot: Anthropic.
  • This is where hosting stops being a workaround for Windows and starts being the better architecture. A pod sits inside your network, close to your storage and adjacent to your cluster, so submitting an eight-arm parameter sweep to your own GPUs is a local operation rather than a VPN-mediated one.
  • It also means the expensive compute never has to be bought twice. Claude Science orchestrates the resources you already own — your Slurm queue, your object storage, your reference data — and the pod is the controlled front door to them. Groups that already run <a href="https://www.nextflow.io/" target="_blank" rel="noopener noreferrer">Nextflow</a> pipelines or a <a href="https://bioconductor.org/" target="_blank" rel="noopener noreferrer">Bioconductor</a> stack keep all of it.
  • For teams without a cluster, the same mechanism scales out to on-demand GPUs, so a group of six scientists can run structural or model-training work without a capital purchase.
Claude Science dispatching an eight-arm scVI hyperparameter sweep to a remote GPU cluster while a live Python notebook kernel stays connected

Native rendering for the objects scientists actually work with

Proteins, structures, molecules, sequence alignments, genomic tracks, and PDFs render in their native form with no extra installation. Figures can be annotated in plain language to request an edit, and the agent reads the code that produced the figure and changes it directly rather than redrawing it by hand.
  • The practical effect is that a scientist stops context-switching between a chat window, a viewer, a notebook, and a plotting script. Pulling a predicted structure from <a href="https://alphafold.ebi.ac.uk/" target="_blank" rel="noopener noreferrer">AlphaFold DB</a> or the <a href="https://www.rcsb.org/" target="_blank" rel="noopener noreferrer">RCSB Protein Data Bank</a>, layering on domains and clinical variants, and exploring it in 3D all happen in the same place as the analysis.
  • On a hosted pod this is also the reason the browser experience holds up. The heavy rendering and the data both stay on the Linux machine; the laptop is a display and a keyboard. A structural session that would stall a thin corporate laptop behaves the same on a Chromebook as it does on a workstation.
Claude Science rendering a three-dimensional protein structure with annotated domains alongside the analysis session

Four honest ways to run Claude Science

Hosting is not always the right answer. This is how the realistic options compare for a research organisation, including the two that do not involve us at all.

ApproachWorks for Windows usersCompute ceilingWho operates itTypical blocker
Install on the scientist's own MacNo — requires buying MacsLaptop RAM and CPUYour IT endpoint teamProcurement cycle and a second endpoint fleet to manage
Install on an existing lab Linux boxYes, over SSH or the browserWhatever that box hasWhoever already runs itShared state, no isolation between users, nobody formally on call
Install on your HPC login nodeYes, over SSH or the browserFull cluster via SlurmScientific computing teamLogin-node policy, change control, and queue contention
Hosted pods from IntuitionLabsYes, from any browserSized per user, plus your cluster or on-demand GPUsIntuitionLabs, as a managed serviceSecurity review and data classification, which we start on day one

How a hosted Claude Science pod is built

Every scientist gets one dedicated Linux virtual machine — not a shared login server and not a container that several people take turns using. Per-user isolation is a deliberate choice: scientific sessions are long-running and stateful, so one colleague's runaway memory allocation should never be able to kill another's eight-hour analysis, and access review is far easier to evidence when one machine maps to one named person.

Isolated compute does not mean isolated people. Alongside each private pod, project teams get shared volumes mounted into every member's machine, so a reference dataset is stored once and read by everyone, and a colleague's analysis is a path rather than an email attachment.

1. Placement and residency

We deploy into your AWS, Azure, or Google Cloud tenancy, into your on-premises virtualisation platform, or into infrastructure we operate — whichever your data residency and procurement rules require. Running inside your own tenancy keeps compute, storage, network logs, and billing under the cloud governance and contracts you already have, with us operating the environment on top.

2. Identity and access

Sign-in runs through your existing identity provider — Okta, Microsoft Entra ID, Google Workspace, or any standard SAML or OIDC service — so there is no second password and no orphaned account. On the Anthropic side, the Enterprise plan adds single sign-on, SCIM provisioning, custom roles, and usage analytics. When your directory disables an account, pod access ends with it.

3. The browser session

Anthropic supports connecting to a Claude Science installation from your browser; we make that connection a managed, authenticated, TLS-terminated endpoint instead of a hand-rolled SSH tunnel. The scientist opens a URL, authenticates as they would for any internal system, and lands in their own running workbench with their files and kernels exactly where they left them.

4. Data and compute attachment

We mount the storage that person is entitled to reach, configure credentials for internal systems, and wire up job submission to your Slurm cluster over SSH or to on-demand GPUs. Reference data and public resources such as NCBI, UniProt, Ensembl, and ChEMBL are reachable from the pod.

5. Shared project storage

Shared team volumes mount into every pod on the project, so reference genomes, cohort data, and intermediate results are stored once and read by everyone entitled to them — no duplicated copies per laptop and no versions quietly diverging. Group membership is driven by the same directory groups you already manage, and permissions are set per volume, so a collaborator on one study does not gain visibility into another. When someone leaves, the work stays with the project instead of leaving in a personal home directory.

6. Baseline, patching, and change control

Pods are built from a documented, version-controlled image rather than configured by hand, so every machine in your estate is the same machine and we can tell you exactly what is on it. Operating system and application updates run on a defined cadence under change control, with the configuration baseline and its history available as evidence for your quality organisation.

7. Right-sized hardware

Pods are sized against the actual workload rather than sold in fixed tiers, and resized as projects change. A literature and metadata pod is modest; a single-cell pod holding a multi-million-cell atlas in a persistent kernel needs an order of magnitude more memory than any laptop can address. That gap is the most common reason teams come to us. GPUs can be attached directly for structural and model work, or reached by dispatching jobs to your cluster.

8. Backup and continuity

Home directories, shared project volumes, and working data are backed up on an agreed schedule with a tested restore path — the single largest practical gain over the status quo of analyses living on individual laptops. A pod can be rebuilt from its image and its backup, so a lost machine is an inconvenience rather than the loss of three months of a project.

Claude Science itself remains Anthropic's application, updated by Anthropic and governed by your own Claude plan. What we take responsibility for is everything underneath and around it — the machine, the network, the identity integration, the data plumbing, the monitoring, and the person who answers when a job fails at an inconvenient hour.

Controls that make a security review survivable

The security questionnaire is usually the longest pole in adopting a new research tool. These are the controls we implement as standard, and the evidence we hand your information security and quality teams.

Per-user isolation

One scientist, one virtual machine, one set of credentials. Private home directories with no lateral visibility, while shared project volumes are mounted explicitly and permissioned per group — so least-privilege access is demonstrable rather than asserted.

Federated identity and MFA

Authentication delegated to your identity provider, inheriting your existing multi-factor and conditional access policies. Joiner, mover, and leaver processes work unchanged, and deprovisioning is immediate rather than a ticket.

Network containment

Pods sit in defined network segments with explicit egress rules, private connectivity to your data sources, and no general-purpose inbound access. Encrypted transport for the session and encryption at rest for pod storage.

Audit logging

Authentication events, session activity, and administrative changes are logged and retained to your policy, and can be forwarded to your own SIEM so this environment appears in the same monitoring as the rest of your estate.

Documented baseline

A version-controlled build with a known package inventory, change control over modifications, and installation and operational qualification evidence available for regulated environments as a documented deliverable.

Defined data boundary

Raw datasets and compute stay on infrastructure you control; prompt and response content is processed by Anthropic under your plan terms. We document that boundary explicitly so your privacy team can assess it properly.

Single-cell and transcriptomics at dataset sizes laptops cannot hold

Cluster and annotate millions of cells across tissues, surface marker genes, and trace every figure back to the code that made it. This is the workload that most often forces the hosting conversation, because a modern atlas plus persistent in-memory kernels simply exceeds what a corporate laptop can physically address. Screenshot: Anthropic.
  • A pod sized for this work removes the ceiling without asking the scientist to learn cluster job submission first. Reference atlases from <a href="https://cellxgene.cziscience.com/" target="_blank" rel="noopener noreferrer">CELLxGENE Discover</a> and tooling such as <a href="https://scanpy.readthedocs.io/" target="_blank" rel="noopener noreferrer">Scanpy</a> are available in the environment, and heavier sweeps dispatch to your cluster or to on-demand GPUs from the same session.
  • Because every figure stays welded to the code and environment that produced it, the iterate-revert-fork cycle that defines this kind of analysis stays reproducible instead of becoming a folder of undated PNGs.
Claude Science rendering a Tabula Sapiens single-cell UMAP across 28 organs beside a cell-type marker dot plot

Cheminformatics and molecular design in a live session

Search bioactivity data, compute molecular properties and similarities, and draw or refine structures in a live two-dimensional sketcher. Chemistry teams get an interactive surface over the public bioactivity corpus without standing up and maintaining a separate desktop toolchain for every chemist.
  • The databases that matter here — <a href="https://www.ebi.ac.uk/chembl/" target="_blank" rel="noopener noreferrer">ChEMBL</a> for bioactivity, <a href="https://pubchem.ncbi.nlm.nih.gov/" target="_blank" rel="noopener noreferrer">PubChem</a> for compound data — are among the 60-plus scientific sources the workbench can query directly, so a medicinal chemist is not writing API clients before doing chemistry.
  • On a hosted pod the whole toolchain is installed once, in a build we control and can reproduce, rather than negotiated separately with endpoint security on each chemist's machine.
Claude Science cheminformatics session showing molecular structures, computed properties, and bioactivity search results

Phylogenetics, evolution, and comparative genomics

Align orthologs, infer maximum-likelihood trees, and map functional residues onto the phylogeny inside a single reproducible session. Comparative work is unusually sensitive to environment drift, so a controlled, versioned build is worth more here than in almost any other domain. Screenshot: Anthropic.
  • Alignment and tree inference results depend on tool versions and parameters in ways that are easy to lose track of and painful to reconstruct at review time. A pod built from a version-controlled image, combined with artifacts that carry their own environment metadata, means a tree produced in March can still be explained in November.
  • Sequence and annotation resources including <a href="https://www.ensembl.org/" target="_blank" rel="noopener noreferrer">Ensembl</a> and <a href="https://www.ncbi.nlm.nih.gov/" target="_blank" rel="noopener noreferrer">NCBI</a> are reachable directly, and literature retrieval across <a href="https://pubmed.ncbi.nlm.nih.gov/" target="_blank" rel="noopener noreferrer">PubMed</a> and <a href="https://www.biorxiv.org/" target="_blank" rel="noopener noreferrer">bioRxiv</a> runs in the same session as the analysis.
Claude Science phylogenetic analysis showing a maximum-likelihood tree with functional residues mapped onto the phylogeny

What you bring, and what we bring

Hosting and licensing are separate purchases, and we keep them separate on purpose. You hold your Anthropic relationship directly; we are responsible for the infrastructure underneath it. We do not resell or mark up Claude subscriptions.
Book a Meeting

Your Claude plan

Claude Science is in beta on Pro, Max, Team, and Enterprise plans. Team and Enterprise need an admin to enable it.

Your data and compute

Your storage, your cluster, your internal systems. We connect the pod to them; the assets stay yours throughout.

Our managed pods

Provisioning, hardening, identity, patching, backup, monitoring, and a support path with a named engineer.

What the managed service covers

A fixed scope so you can tell what you are buying, and so your procurement and security teams can review it without a discovery call for every question.

Provisioning and sizing

Pod build, per-user sizing against real workloads, and resizing as projects change. Machines are created from a version-controlled image, so the estate stays uniform and reproducible rather than drifting into snowflakes.

Scope your pilot

Identity integration

SAML or OIDC integration with Okta, Microsoft Entra ID, Google Workspace, or your provider of choice, plus support for configuring single sign-on, SCIM provisioning, and roles on the Anthropic side for Enterprise plans.

AI governance

Data and cluster connectivity

Mounting entitled storage, configuring credentials for internal systems, and wiring job submission to your Slurm cluster over SSH or to on-demand GPUs, so the workbench reaches the compute you have already paid for.

Discuss integration

Internal system connectors

Connecting electronic lab notebooks, internal APIs, and bespoke pipelines through connectors and the Model Context Protocol, prioritising the two or three systems that will actually be used rather than everything at once.

AI enablement

Operations and support

Patching under change control, monitoring, backup with a tested restore path, and a named engineer who understands both the infrastructure and the science, so an escalation does not start with explaining what a kernel is.

Talk to us

Validation support

Qualification evidence for the pod build, documented configuration baselines, and access logs to support your own validation activities. Full computer system validation is available as a separate, scoped engagement.

CSV services

How we start, and where the boundaries are

A pilot that tests adoption, not just installation

We start with three to eight scientists working on real projects, because the only reliable way to learn whether a computational workbench earns its place is to point it at work someone genuinely needs finished. Demo datasets prove the software installs; they tell you nothing about whether people will still be using it in week six.

A pilot runs on three parallel tracks from day one: the technical build, the security and data classification review, and the administrator enablement on your Claude plan. Running those in sequence instead of in parallel is the single most common reason a pilot that should take two weeks takes two months. At the end we review honestly, including the case for stopping — if the pilot group did not adopt it, a wider rollout will not fix that, and we would rather say so than sell you forty pods that go idle.

Where this fits alongside your validated systems

A research workbench is not a validated system of record, and it should not quietly become one. We help teams draw that line explicitly: exploratory and hypothesis-generating work on the pod, regulated records in the systems built to hold them, and a documented handoff between the two rather than an accidental one.

For work that touches regulated records, validation is an activity performed against your intended use, your procedures, and your risk assessment — not a property a vendor can ship. We supply the qualified infrastructure layer and its evidence; your quality organisation defines intended use and runs acceptance testing, guided by GAMP 5 and, where electronic records and signatures are in scope, 21 CFR Part 11. Our computer system validation team can run that engagement, and it is deliberately scoped and priced separately from hosting so neither one hides inside the other.

Working with a life sciences specialist

IntuitionLabs works exclusively in pharmaceutical, biotechnology, and life sciences, and is a member of the Claude Partner Network. That matters mainly in what we do not need explained: what a GxP boundary is, why a bioinformatician cares about environment drift, and why "just give them local admin" is not an available answer in your organisation.

We are not an Anthropic reseller, and nothing here should be read as an Anthropic endorsement of this hosting service. Claude and Claude Science are Anthropic products; for authoritative product information, supported platforms, and terms, go to Anthropic's own documentation. The product screenshots on this page are Anthropic's published material, reproduced to show what the application looks like. If your situation genuinely does not need us — you have a Linux fleet, a platform engineer, and a completed security review — we will say so on the first call. Related work we do: AI enablement, AI readiness assessment, and computer system validation.

Hosted Claude Science: common questions

No. Anthropic publishes the Claude Science desktop app for macOS on Apple Silicon, macOS on Intel, and Linux x64 only. There is no Windows build and Anthropic does not list Windows as a supported platform. That is a genuine blocker for a large share of pharmaceutical and biotechnology R&D organisations, where a managed Windows fleet is the corporate standard and the scientists who most want a computational workbench are the ones least able to install one. The practical answer is not to fight your endpoint policy but to put the application on a Linux machine that the scientist reaches remotely. Our hosted service provisions and operates that Linux machine for each user, so a Windows laptop, a locked-down virtual desktop, or a Chromebook becomes a perfectly good way to work.
Some individual users do run Linux desktop applications through Windows Subsystem for Linux, but it is not a configuration Anthropic lists as supported for Claude Science, and it is rarely a realistic answer at organisational scale. WSL usually requires local administrator rights or an explicit enterprise policy exception, it gives every scientist a slightly different environment to support, and it leaves regulated research data sitting on a laptop rather than inside a controlled environment. It also does nothing for the compute problem: a corporate laptop still has the RAM and CPU of a corporate laptop. A managed Linux pod sidesteps all four issues at once and gives your IT team one supported configuration instead of hundreds.
No, and we are careful not to imply otherwise. Anthropic states plainly that you can install Claude Science on a laptop, a lab Linux box, an HPC login node, or a cloud VM, and connect to it from your browser. That capability belongs to the product. What we sell is the part Anthropic does not do for you: procuring, sizing, hardening, and operating the cloud VM, wiring it to your identity provider, connecting it to your data and your cluster, keeping it patched, and giving your scientists a support path when something breaks. If your team already has a Linux server, a platform engineer to run it, and a security review completed, you may not need us at all — and we will tell you that on the first call.
Yes. Claude Science is an application, not a separate model, and it uses the Claude models included in your existing plan. Anthropic offers it in beta on the Pro, Max, Team, and Enterprise plans, and Team and Enterprise users need an administrator to enable it before it appears. Our hosting fee covers the infrastructure and the operations around the app; it does not include or resell Anthropic model access, and we do not mark up your subscription. Most of our clients bring an existing Claude Team or Enterprise plan and we help their administrator complete the enablement step and configure single sign-on.
A pod is a dedicated Linux virtual machine belonging to one named scientist. It is not a shared login server and not a container that several people time-slice. Each pod has its own filesystem, its own home directory, its own persistent Python and R kernels, its own installed packages, and its own credentials into whatever data sources that person is entitled to reach. One user cannot see another user's data, working files, or session history. We chose per-user isolation deliberately because scientific work is long-running and stateful: a shared box means one person's runaway memory allocation kills a colleague's eight-hour analysis, and it makes access review far harder to evidence during an audit.
Through shared project volumes that mount into every pod belonging to that project, so isolation applies to compute and personal working space rather than to data. A reference genome, a cohort dataset, or an intermediate result is stored once on the shared volume and read by everyone entitled to it, instead of being copied to six laptops where the versions immediately begin to diverge. Membership follows the directory groups you already manage and permissions are set per volume, so someone working on one study does not gain visibility into another. The practical benefit shows up most clearly at handover: when a postdoc leaves or a project changes hands, the data, the environment, and the analyses stay with the project rather than departing inside a personal home directory. Because Claude Science binds every artifact to the code and environment that produced it, a colleague opening shared work gets the reasoning behind it too, not just the output file.
Pods are sized to the work rather than to a fixed tier, and we resize them as your workload changes. A literature and metadata pod is small; a single-cell pod handling millions of cells needs substantially more memory than a laptop can physically hold, which is one of the most common reasons teams come to us in the first place. For heavier work, Claude Science does not have to compute locally at all: it writes batch scripts and submits and manages jobs over SSH against your own Slurm cluster, or scales out through a Modal account. We configure whichever of those routes you already own, so the pod acts as a controlled front door to compute you have already paid for.
Anthropic describes the model plainly: the app runs on your infrastructure, raw datasets and compute stay local to that infrastructure, and the content included in prompts and model responses is processed by Anthropic under its standard retention terms. Hosting the app on a pod does not change that boundary — it moves "local" from a laptop to a machine you and we control together. In practice that is usually an improvement in data governance rather than a compromise, because the pod sits inside a defined network with logging, backup, and access control, whereas a laptop does not. For the specific commitments that apply to your plan, review Anthropic's Trust Center and your own agreement, and involve your privacy team before loading regulated data.
Yes, and for many regulated clients that is the preferred arrangement. We can deploy pods into your AWS, Azure, or Google Cloud tenancy, into your on-premises virtualisation platform, or into infrastructure we operate, depending on your data residency and procurement constraints. Running in your tenancy means the compute, storage, network logs, and billing all remain under your existing cloud governance and your existing agreements, and we operate the environment as a managed service on top. Teams with European data residency requirements under the GDPR, or with contractual commitments to keep specific datasets in a named region, generally choose this route.
Through your existing identity provider, using the same credentials and the same multi-factor prompt they already use for everything else. We integrate with Okta, Microsoft Entra ID, Google Workspace, and other standard SAML or OIDC providers, so there is no separate password for anyone to write down and no orphaned account left behind when someone changes teams. On the Anthropic side, the Enterprise plan supports single sign-on, SCIM provisioning, custom roles, and usage analytics, which we configure alongside the infrastructure access. Deprovisioning is the part auditors care about most: when your identity provider disables an account, both the pod session and the application access go with it.
Not out of the box, and any vendor who tells you their product arrives "GxP validated" is describing something that does not exist. Validation is an activity you perform against your own intended use, your own procedures, and your own risk assessment. What we provide is the qualified infrastructure layer and the documentation that makes your validation tractable: installation and operational qualification evidence for the pod build, change control over the environment, access logs, and a documented configuration baseline. Teams then run their own user acceptance testing against their intended use, guided by GAMP 5 and, where electronic records are in scope, 21 CFR Part 11. Our computer system validation practice does this work as a separate engagement.
Buying MacBooks is a legitimate answer and we say so when it is the right one. It stops being the right one at a certain scale and in certain environments. A Mac refresh is a capital purchase and a multi-month procurement cycle for a tool your scientists want to try this quarter; it creates a second endpoint fleet for IT to manage, patch, and secure alongside the Windows estate; and it still leaves every scientist with a laptop-sized amount of RAM, which is the actual constraint for single-cell and structural work. Hosted pods change one variable instead of the whole estate, can be running for a pilot group within days, and can be resized or switched off when a project ends.
Anthropic ships it pre-configured for genomics, single-cell analysis, proteomics, structural biology, and cheminformatics, with access to more than 60 scientific databases and the ability to read literature directly. In practice that covers clustering and annotating single-cell datasets, aligning orthologs and inferring phylogenies, pulling predicted structures and layering on domains and clinical variants, searching bioactivity data and computing molecular properties, and assembling cited literature reviews. It also connects to the models and libraries in NVIDIA BioNeMo, including Evo 2, Boltz-2, and OpenFold3. It is a workbench that orchestrates specialist tools, not a replacement for them — your existing pipelines and scripts keep working.
They keep running and Claude Science works alongside them. The app reads, runs, and builds on existing Python, R, and shell workflows, and any pipeline you already trust can be saved as a reusable skill so future sessions inherit it automatically. Internal APIs, electronic lab notebooks, and bespoke systems connect through connectors and the Model Context Protocol, which is where most of the value shows up for an established R&D organisation — the workbench becomes useful in proportion to how much of your own institutional data it can reach. Part of our onboarding is identifying which two or three internal systems are worth connecting first, because connecting everything at once is how these projects stall.
A pilot for a small group is typically live within a week or two, and the gating item is almost never the technology. It is the security review, the data classification decision, and the administrator enablement on your Claude plan. We start those three in parallel on day one for exactly that reason. A pilot usually covers three to eight scientists on real projects, because the only reliable way to find out whether a computational workbench earns its place is to point it at work someone actually needs finished. Broader rollout follows the pilot review, and we size that against the appetite the pilot exposed rather than a number chosen up front.
Pricing depends on the number of pods, how they are sized, whether they run in your cloud tenancy or ours, and how much integration and validation support you need, so we quote against a defined scope rather than publishing a list price that would be wrong for most readers. The two components are always separable: the infrastructure and managed operations that we provide, and the Anthropic subscription that you hold directly. Academic and nonprofit labs should look at Anthropic's Claude Team plan for research labs before talking to us about commercial terms, since eligibility is verified through the lab's principal investigator and it may cover the licensing side entirely. Book a meeting and we will scope it properly.
IntuitionLabs is a member of the Claude Partner Network. We are not reselling Anthropic software, we do not speak for Anthropic, and nothing on this page should be read as an Anthropic endorsement of our hosting service. Claude and Claude Science are products of Anthropic, and the product screenshots on this page are Anthropic's own published material, reproduced here to show what the application looks like. For authoritative product information, platform support, and terms, always go to Anthropic's own documentation rather than relying on a partner's summary.
Give your scientists the workbench their laptops cannot run
Give your scientists the workbench their laptops cannot run image

Give your scientists the workbench their laptops cannot run

Tell us how many scientists, what they analyse, and which constraints you are working under. We will tell you honestly whether hosted pods are the right answer — and what a pilot would take.

Book a Meeting

© 2026 IntuitionLabs. All rights reserved.

Privacy PolicyTerms of ServiceBook Meeting