Anthropic Model Hardware Requirements for Pharma Labs

As of September 19, 2026, Anthropic's Model Hardware Standard (MHS) is a limited, application-based research preview, not a production standard or a set of server specifications. The project site says access is by application (^[1]), and an early robotics partner says it is not generally available (^[2]). The current public material supplies no minimum CPU, RAM, GPU, operating system, reference bill of materials, SDK, conformance suite, or published versioned specification. Its "hardware requirement" is functional: the instrument needs a programmable interface. Laboratories should not interpret MHS as on-premise Claude inference or as an independently certified GxP standard.

The announced architecture is nevertheless concrete enough for a bounded proof of concept. An MHS driver translates between the computer environment and a device, normalizes states and procedures, exposes read and write primitives, and declares safety limits (^[3]). Model Context Protocol (MCP), command-line, and code/API paths can invoke it. A safe pharma design should keep native controllers, physical interlocks, emergency stops, deterministic scripts, the laboratory scheduler, and the regulated system of record authoritative. The agent should initially recommend or parameterize actions, not become the safety controller.

The Genentech example is a useful proof of concept, not a benchmark. It connected a liquid handler, robotic arm, and plate reader in a bicinchoninic acid protein assay and reported convergence near 140 microliters per second for water with 0.016 root mean square error, versus about 10 microliters per second and 0.181 for viscous bovine serum albumin (^[4]). That is evidence for supervised experimentation, not validated autonomous operation.

The practical recommendation is apply and pilot only if the laboratory can isolate a non-GxP, low-energy, reversible workflow with deterministic fallback and complete records. For closed systems, Part 11 requires procedures and controls including validation for accuracy, reliability, and consistent intended performance; authorized access; and audit trails whose record changes do not obscure previously recorded information (^[5]) (^[6]). FDA gives chromatographic data as an example: such data should be saved to durable media upon completion of each step or injection (^[7]). For an MHS pilot, contemporaneous, durable capture should be a risk-based record-design control. MHS does not remove those obligations. A lab unable to pin versions, deny unsafe calls, reproduce runs, and export complete audit evidence should wait, while building a vendor-neutral abstraction around existing SiLA 2, OPC UA LADS, or vendor APIs.

The phrase "Anthropic model hardware requirements" can mean two different things. One is the compute needed to host a large language model. The other, and the subject of MHS, is the interface through which an AI agent discovers and operates physical equipment. Public MHS materials address the second question. The official site says partners are developing the standard before it becomes open source (^[8]), while official Claude documentation lists API and managed-cloud routes. Those statements do not establish an on-premise Claude product or local inference specification.

This distinction matters in pharmaceutical and biotechnology laboratories. A model may reason about an experiment, an agent harness may select tools, and an MHS driver may translate a request, but a device controller ultimately energizes motors, moves liquid, changes temperature, or records a measurement. Each layer has different owners, failure modes, update cycles, and evidence. The MHS preview began as a project between Anthropic and HHMI Janelia Research Campus (^[9]), and its project page says partners are still developing it before open sourcing (^[8]). That status is incompatible with treating the preview itself as a finished validation baseline.

The intended audience therefore has a narrower decision: whether to join the preview and gather evidence in a controlled research setting. IntuitionLabs is an adjacent life-sciences implementation and advisory firm, not an MHS vendor. Its public operating model emphasizes small portfolios of governed workflows before scaling (^[10]), and connecting AI to authoritative sources with identity, permissions, citations, and evaluation (^[11]). That perspective supports a staged evidence plan, but it does not make the consultancy a product-table alternative.

In practical terms, this report answers the related questions behind the search terms Anthropic AI infrastructure for pharmaceutical labs, Claude hardware requirements for pharma, GxP validation for Anthropic models, and on-premise Claude for life sciences. It also defines a GxP compliant AI architecture as a target system design rather than a product label, lays out a pharma AI pilot architecture, and explains what would be required before calling any stack validated AI infrastructure or an Anthropic model deployment in a regulated lab.

A device abstraction, not an inference appliance

MHS introduces a standardized driver as the translation layer between a computer environment and a physical device. The announced design uses simple read and write primitives, makes devices discoverable in a common format, and normalizes native controls into a manifest of states and procedures. Because no public schema or conformance profile accompanies those concepts, the pilot must turn them into local, testable requirements rather than treating the announcement as an implementable specification.

For a pilot, "hardware requirements" should therefore be recorded as an engineering inventory, not guessed as a GPU configuration:

• Programmable endpoint: The instrument or its controller must expose an API, command interface, job-file path, or supported gateway.
• Driver host: A controlled computer must host the adapter, logs, configuration, certificates, and allowlisted network connections.
• Native control path: The existing instrument software, scheduler, or programmable logic controller remains the execution authority.
• Safety layer: Device-native limits, guards, collision avoidance, and emergency stop remain independent of the model.
• Agent boundary: The harness gets only the tools, parameters, and scopes required for the intended use.
• Record boundary: A designated laboratory information or electronic laboratory notebook system retains authoritative inputs, outputs, approvals, and deviations.
• Fallback: A qualified deterministic method can complete, pause, or safely terminate the workflow without model reasoning.

The public preview does not publish minimum CPU, RAM, GPU, storage, latency, bandwidth, or supported operating-system values. It also does not publish a reference SDK, schema repository, conformance suite, version, or license. A proposal that supplies those values is a local design assumption, not an Anthropic requirement.

Separate the model service from the laboratory control plane

Official documentation describes Claude access through the direct API and managed cloud platforms (^[12]). Anthropic identifies AWS, Google Cloud, and Microsoft Azure as the cloud routes (^[13]), while Google describes its Claude offering as a managed API that does not require customers to provision model infrastructure (^[14]). No official customer-managed local or on-premise Claude inference offering, model weights, or corresponding hardware specification was located. This is a public-documentation finding, not proof that a private arrangement could never exist.

Accordingly, a pharma AI pilot architecture has two distinct compute zones:

• Model-service zone: The documented API or managed-cloud endpoint performs inference under its service, identity, region, and retention configuration.
• Laboratory edge zone: A locally controlled host runs drivers, MCP servers or clients, policy enforcement, allowlists, deterministic scripts, queues, logs, and adapters to instrument networks.
• Instrument zone: Native controllers execute commands and enforce machine-level safety.
• Record zone: Approved repositories retain authoritative methods, results, metadata, approvals, and audit evidence.

The separation makes deployment choices explicit. Anthropic states that standard API inputs and outputs are automatically deleted from its backend within 30 days (^[15]), while Amazon Bedrock documents a zero-data-retention mode in which AWS writes no request or response data to durable storage (^[16]). Microsoft documents two Claude hosting options in Foundry (^[17]) and says data at rest for the Azure-hosted option stays in the selected Azure geography (^[18]). These are configuration inputs to privacy and quality assessments, not substitutes for laboratory records.

Model lifecycle is another control-plane dependency. Anthropic notes that lifecycle dates may differ between its own and partner platforms (^[19]) and commits to at least 60 days of notice before retiring publicly released models (^[20]). A regulated-lab design should capture the provider, endpoint, model identifier, lifecycle notice, and regression decision, rather than recording only the brand name "Claude."

Three invocation paths, one controlled execution boundary

The preview names MCP, command line, and code/API files as control mechanisms. MCP uses JSON-RPC 2.0 for communication (^[21]), and its tools carry names and schema metadata (^[22]). MCP is thus an invocation and context contract. It is not, by itself, an instrument qualification, a process recipe, or a physical safety controller.

MCP's own guidance recommends a human ability to deny tool calls (^[23]), confirmation for sensitive operations (^[24]), and logging for audit purposes (^[25]). Authorization is optional in the protocol (^[26]), so a laboratory cannot assume that adopting MCP automatically provides access control. The client should request least-privilege scopes (^[27]), while the lab independently enforces identity, segmentation, and approval policy.

Deterministic code remains the execution workhorse

The preview repeatedly points toward a hybrid pattern: exploratory interaction becomes deterministic control code, acquisition and analysis remain in deterministic loops, and existing scheduling software stays in the native control path. This is consistent with a current commercial scheduler pattern in which a high-level instrument action is compiled into a deterministic sequence of driver actions (^[28]). A published LINQ workflow is immutable and must be saved and republished to change it (^[29]).

That division is appropriate for a regulated pilot:

• Agent: Interpret goals, propose parameters, select among preapproved methods, explain anomalies, and request approval.
• Deterministic workflow: Enforce sequence, units, ranges, preconditions, timeout behavior, and repeatable execution.
• Scheduler: Reserve resources, serialize jobs, manage dependencies, and coordinate instrument readiness.
• Device controller: Execute commands and expose actual state.
• Safety system: Stop or inhibit motion and energy independently of agent availability.
• System of record: Capture the approved intent, exact command, response, timestamp, identity, model/version, and resulting data.

MHS enters an environment that already includes SiLA 2, vendor APIs, schedulers, MCP, and OPC Unified Architecture Laboratory and Analytical Device Standard (OPC UA LADS). SiLA 2 defines interoperability schemes for devices and services (^[30]), uses a service-oriented architecture (^[31]), and describes services through a Feature Definition Language (^[32]). OPC UA LADS supplies an information model for laboratory and analytical devices (^[33]).

Table 1 assigns responsibilities based on the published role of each layer. It is an architectural comparison, not a claim that MHS formally maps to SiLA 2 or LADS. No public MHS mapping or conformance profile was located as of the publication date.

Layer	Published or practical responsibility	What it should not be assumed to provide	Pilot evidence
MHS driver	Normalize device discovery, states, procedures, read/write primitives, and declared limits.	A public conformance certificate, GxP validation, or local Claude inference.	Driver version, manifest hash, command/state tests, limit tests.
SiLA 2 server/client	Expose self-describing laboratory services. SiLA 2 runs over HTTP/2 with Protocol Buffers ([34]).	An AI policy layer or complete workflow scheduler.	Feature definitions, certificates, interface qualification, server logs.
OPC UA LADS	Represent device functions, states, and results; a functional unit can expose state through a state machine ([35]).	A model agent or experimental planner.	Information-model version, state-transition tests, identity/security configuration.
Vendor API/controller	Execute device-specific commands and enforce native constraints.	Cross-vendor semantic equivalence.	Vendor version, qualified method, alarms, raw results, maintenance status.
Scheduler	Coordinate jobs, resources, timing, dependencies, and recovery.	Physical interlock authority unless explicitly engineered and qualified.	Job history, resource locks, retry policy, recovery tests.
MCP/CLI/API	Carry tool discovery and invocation between harness and driver. MCP can provide transport authorization ([36]).	Device semantics, qualification, or mandatory authorization.	Tool schemas, scope tests, approval logs, rejected-call tests.
Agent/model	Interpret context, select allowed tools, propose adjustments, and explain choices.	Deterministic behavior, calibrated physical intuition, or an emergency stop.	Model ID, prompt/configuration, evaluation set, approvals, response archive.

The matrix shows why MHS versus SiLA 2 is the wrong procurement question. SiLA 2 focuses on systems offering services (^[37]) and makes those services machine-readable. MHS is presented as an agent-oriented driver and manifest abstraction. A future adapter might expose a SiLA 2 service as an MHS device, but without a published mapping, that is a design hypothesis to test, not compatibility to claim. Likewise, LADS anticipates gateways for devices using other protocols (^[38]), but no official MHS-to-LADS mapping is public.

Security responsibilities also remain layered. SiLA says client-server communication must be encrypted (^[39]). OPC UA states goals including encryption, authentication, authorization, and auditing (^[40]). Those properties do not validate the agent's choice, the scientific method, or the receiving record system. End-to-end assurance must test every trust boundary.

Select a deliberately narrow pilot

A strong pilot begins with a workflow whose failure is observable, reversible, and physically contained. It should use nonclinical samples, no batch-release decision, no direct impact on product disposition, and no uncontrolled energy or hazardous manipulation. The first path should be read-only telemetry or supervised parameter entry, not closed-loop optimization.

Use this selection checklist:

• Programmability: Every included device already exposes a supported programmable path.
• Containment: Maximum volumes, travel, temperatures, forces, and speeds are bounded by native controls.
• Observability: Actual state, alarms, command acknowledgments, and raw results can be exported.
• Reversibility: A failed action can be stopped and reset without losing irreplaceable material.
• Fallback: A qualified manual or deterministic method is available.
• Record ownership: One named system owns each input, approval, command, result, and exception.
• Version control: Driver, manifest, tool schema, model, prompt, method, and device firmware are pinned.
• Separation: Development credentials, networks, samples, and records are isolated from regulated production.

This conservative boundary reflects the preview's present limitation to hardware with programmable interfaces. Product-level details must be verified independently. For example, Tecan documents USB for all data traffic to and from Fluent (^[41]). That interface does not establish MHS support or qualification, but it illustrates the local facts an inventory must capture.

Set autonomy by consequence, not novelty

Table 2 defines four autonomy levels. Moving right requires new evidence and approval. A laboratory can stop at any level indefinitely.

Level	Allowed behavior	Required controls	Release criterion
0. Observe	Read state and results; summarize without issuing device commands.	Read-only identity, data reconciliation, source citations, no write tool.	Export matches native records for approved scenarios.
1. Recommend	Propose a method or parameter set for a human to enter.	Named reviewer, approved ranges, rationale capture, independent execution.	Reviewer can detect out-of-range and scientifically implausible proposals.
2. Supervised write	Send an allowlisted command only after human confirmation.	Least privilege, two-step approval for sensitive actions, parameter bounds, deterministic preflight, complete log.	Positive, negative, timeout, duplicate, and denial tests pass.
3. Bounded closed loop	Adjust parameters within a preapproved envelope using measured results.	Independent interlocks, stop conditions, run budget, drift monitoring, automatic safe state, expert oversight.	Predefined performance and recovery criteria pass under representative conditions.

The transition from Level 2 to Level 3 is substantial. NIST says human-oversight processes should be defined, assessed, and documented (^[42]), recommends testing before deployment and regularly in operation (^[43]), and calls for mechanisms to disengage systems inconsistent with intended use (^[44]).

Universal Robots' preview account gives the correct safety hierarchy: devices declare bounds, interlocks, and emergency stops (^[45]), while the robot's underlying safety architecture remains in charge (^[46]). A natural-language declaration may inform the agent, but it cannot replace a safety-rated function.

Make records contemporaneous and reconstructable

GxP applicability depends on intended use and the records involved. FDA's Part 11 guidance says the rule applies to electronic records created or maintained under FDA record requirements (^[47]). When applicable, closed systems must limit access to authorized people (^[48]). Signed records must retain signing information (^[49]).

At minimum, each transaction record should preserve:

• Intent: Protocol, sample context, approved objective, and initiating identity.
• Decision: Model ID, harness version, prompt/configuration, retrieved context, proposed action, and rationale.
• Approval: Approver identity, timestamp, meaning, and any modified parameter.
• Execution: Exact normalized command and native command, units, device and driver versions, timestamps, acknowledgment, and actual state.
• Result: Raw device output, derived result, calculation version, and link to the authoritative repository.
• Exception: Alarm, rejection, timeout, retry, intervention, deviation, and final disposition.
• Integrity: Hashes or equivalent linkage among intent, command, result, and metadata.
• Lifecycle: Configuration change, access change, backup, restore, periodic review, and retirement evidence.

FDA defines data integrity as completeness, consistency, and accuracy (^[50]), treats audit trails as tracking creation, modification, or deletion (^[51]), and expects exact, complete backups protected against alteration, erasure, or loss (^[52]). A conversational transcript alone does not satisfy this record model.

MHS has little independent quantitative evidence. The defensible numbers are status dates, the three-instrument Genentech chain, 96-well format, the two reported flow rates and errors, and partner-specific demonstrations. They should not be generalized into integration-time, throughput, or validation-effort forecasts.

What the Genentech measurements show

Anthropic reports that Genentech ran the proof of concept in standard 96-well microplates, compared AI-controlled transfers with an expert-performed transfer in the same plate, (^[53]). These observations show closed-loop adaptation in one configured workflow. They do not provide sample size, confidence intervals, cross-site reproducibility, long-run failure frequency, or comparison against a qualified production method.

The error difference is instructive but narrow. The reported viscous BSA root mean square error of 0.181 is about 11.3 times the water error of 0.016, calculated as 0.181 divided by 0.016. This is not a universal performance ratio. It illustrates sensitivity to fluid physics, consistent with the team's statement that models still struggle with physical, chemical, and biological constraints (^[54]).

A transparent way to count verification cases

The report does not assign invented weeks or labor hours. Instead, the pilot owner can compute a minimum traceable case inventory:

Total planned cases = sum of applicable command classes across devices + interface cases + negative cases + recovery cases + audit-record cases + model-change cases.

Here, a command class is a distinct risk-bearing behavior such as read, write, move, start, stop, reset, or export, not every parameter permutation. The inventory should expand through risk analysis. ICH Q9(R1) defines quality risk management across assessment, control, communication, and review (^[55]), and says review frequency should follow risk level (^[56]).

Table 3 turns that formula into auditable categories. The laboratory enters its own counts in the final column.

Category	Evidence question	Representative cases	Reader input
Device commands	Does each allowed command produce the defined result only in valid states?	Read, bounded write, start, stop, reset, export.	Devices multiplied by applicable command classes, adjusted for actual scope.
Interfaces	Is meaning preserved across agent, MCP, driver, scheduler, and native API?	Unit conversion, schema version, timestamp, sample ID, duplicate message.	Number of distinct trust-boundary cases.
Negative behavior	Are forbidden or malformed requests rejected without unsafe side effects?	Out-of-range, wrong state, expired credential, missing approval, replay.	Number of risk-derived denial cases.
Recovery	Does the system reach a known safe state and reconcile records?	Timeout, lost network, partial job, device alarm, restart, manual takeover.	Number of credible failure and recovery paths.
Audit evidence	Can an independent reviewer reconstruct intent through result?	Creation, modification, rejection, approval, signature, export, restore.	Number of record-control cases.
Model or configuration change	Does the approved behavior persist after a controlled change?	New model snapshot, prompt, tool schema, driver, firmware, scheduler.	Number of change classes requiring regression.

The table prevents a misleading single test count. A three-device chain with different capabilities should not be modeled as three identical units. EU GMP Annex 11 expects evidence for appropriate methods and scenarios (^[57]), and expects configuration changes to follow a defined controlled procedure (^[58]). The counted inventory is only complete when each risk and requirement maps to evidence and an owner.

Genentech BCA assay proof of concept

The best-documented pharmaceutical example is Genentech's bicinchoninic acid (BCA) protein-assay proof of concept. It coordinated a liquid handler, robotic arm, and plate reader, with MHS operating instruments and streaming state back to Claude (^[59]). The model reportedly optimized flow rates, handled some device errors, and supported an end-to-end assay sequence.

The case is most valuable for the limitations it makes visible:

• The chain was incomplete for broader work: Genentech identified centrifuges, automated incubators, analytical instruments, and sensors as additional needs.
• Evidence was partner-reported: No separate protocol, raw dataset, independent replication, or GxP validation package was found.

The right inference is that MHS can connect heterogeneous instruments and expose a useful reasoning loop. The wrong inference is that the same configuration is ready for a validated assay, any liquid class, any instrument firmware, or unattended production.

Other preview signals

The surrounding ecosystem confirms breadth, not maturity. AWS says Strands Robots and AWS are participating in the limited preview (^[60]) and describes mesh-based discovery and coordination (^[61]). Universal Robots describes the specification as provisional, application-only, and not generally available (^[62]). These accounts justify technical exploration, while reinforcing that procurement and validation claims should wait for stable, versioned artifacts.

The apply, wait, or build now decision depends on the laboratory's objective.

• Apply now: The lab has a non-GxP research workflow, programmable devices, strong engineering ownership, an independent safety layer, and a willingness to contribute evaluation evidence.
• Wait: The proposed use directly creates release, stability, clinical, or other regulated records; needs unsupported devices; requires a published conformance target; or cannot tolerate preview change.
• Build an abstraction now: The lab can normalize existing vendor APIs, SiLA 2 services, or LADS models behind its own versioned interface without representing that layer as MHS-compatible.

Building an internal abstraction can be productive if it preserves replaceability. Define typed commands, states, units, limits, identities, and records in a model-neutral contract. Keep an adapter boundary for MHS if a public specification arrives. SiLA 2's claim that Feature Definitions are machine-readable functional specifications is relevant here (^[63]), as is LADS result metadata for timestamps, action identifiers, and sample identifiers (^[64]).

For GxP evolution, every moving component needs change control. Annex 11 expects validation documentation to include change-control records (^[65]), regular backup (^[66]), and documented, tested continuity arrangements (^[67]). WHO guidance says automatic or live software updates should be reviewed before taking effect (^[68]). Model snapshots and server-side behavior therefore belong in the same change-impact process as drivers and firmware.

The regulatory direction is also still developing. As of July 2026, EMA said it was considering consultation results for the draft AI-specific GMP Annex 22 (^[69]), with human oversight among the key principles under consideration (^[70]). A pilot should track this work but validate against requirements actually applicable to its intended use and jurisdiction.

Does MHS specify GPUs or servers for a pharma lab?

No public minimum CPU, RAM, GPU, server, or operating-system specification was found as of September 19, 2026. MHS addresses device integration. Its stated device prerequisite is a programmable interface, and its preview is not a local Claude inference package.

Can a pharmaceutical company run Claude on premises through MHS?

MHS is model-agnostic and can be accessed by an agent harness, but that does not establish on-premise Claude model deployment. Labs should separate the local driver/control-plane design from the documented model-service deployment and security review.

Is MHS GxP compliant or validated?

No. The public material describes a research preview. Compliance depends on intended use, system configuration, procedures, records, controls, and validation evidence. FDA permits combined technical and procedural controls for electronic CGMP documentation (^[71]), but adopting an interface does not create that evidence.

Does MHS replace SiLA 2, vendor APIs, or a scheduler?

No published source establishes replacement or formal compatibility. The announced MHS driver can sit above a native API or scheduler, while SiLA 2 or LADS can provide device/service semantics. The exact adapter relationship must be designed and tested.

What should the first pilot control?

Begin with read-only state and result retrieval. Progress to recommendations, then human-approved allowlisted writes. Closed-loop optimization should come only after independent interlocks, safe-state behavior, full records, representative negative tests, and an approved risk assessment.

Who should own emergency stop behavior?

The device-native safety architecture or a separately engineered safety system. The agent may request a normal stop, but loss of model service, network, or driver must not disable the emergency stop or safe state.

What evidence is still missing?

The main gaps are a public versioned specification, SDK, schema, license, conformance tests, supported-device matrix, MHS-to-SiLA or MHS-to-LADS mapping, long-run reliability data, independent benchmarks, and a validation reference architecture. Until those exist, laboratories should document local assumptions and avoid general availability claims.

Anthropic's Model Hardware Standard is a promising device and discovery abstraction in research preview, not a published hardware sizing guide, on-premise Claude package, or production-ready GxP standard. Its announced primitives, manifests, invocation paths, and deterministic-code pattern are relevant to pharmaceutical lab automation. The Genentech proof of concept demonstrates heterogeneous device coordination and bounded optimization.

For most regulated laboratories, the best near-term architecture is layered: the agent reasons within an allowlist, deterministic software executes approved procedures, native controllers and independent interlocks retain physical authority, and a designated system of record captures the complete transaction. Existing SiLA 2, OPC UA LADS, vendor API, and scheduler investments remain useful. No formal MHS compatibility should be claimed without a published mapping.

An application to the preview is justified when the laboratory has a narrow non-GxP use case, programmable instruments, named engineering and quality owners, deterministic fallback, and resources to generate evidence. Otherwise, waiting is rational. Teams can still prepare by inventorying device APIs, defining typed state and command contracts, assigning record ownership, and building risk-based tests. The decision standard is not whether an agent can move hardware once. It is whether the whole system can remain bounded, reconstructable, recoverable, and controlled through every expected state and credible failure.