Drug interaction checker runs an LLM entirely in the browser with WebGPU and WebLLM

A medication checker with no server

A tutorial on dev.to, written by beck_moulton, details how to build a drug-interaction checker that runs a large language model entirely in the browser. The stack is React 18+, TypeScript and Vite, with the @mlc-ai/web-llm library driving model execution. Instead of calling a hosted inference API, the app loads a quantised Llama-3 8B Instruct model and runs it on the user's own GPU through WebGPU. According to the post, medication queries never leave the device — there is no backend to receive them and no request log that could be breached.

How the local pipeline works

The tutorial's data flow keeps everything inside one privacy boundary: React state feeds a WebLLM engine instance, the engine dispatches work to the WebGPU API, and the device's GPU generates tokens that stream back into the UI. WebGPU, the post explains, gives the browser direct, low-level access to the local graphics card, which is what makes in-browser LLM execution viable where a Python backend with server-class GPUs used to be the default.

Model loading is the main friction point. The weights run roughly 2GB to 5GB, so the tutorial wraps engine initialisation in a React hook that surfaces download progress as a percentage. After the first run, the weights are cached in IndexedDB, so returning users skip the download.

The interaction logic is a prompt

There is no interaction database in the build as written. The tool sends the model a system prompt instructing it to behave as a clinical pharmacy expert and to answer in a fixed structure: an interaction severity rating (mild, moderate or severe), the mechanism behind the interaction, and a recommendation. If the model finds no interaction, it is told to say so. Responses stream token by token into the interface.

The trade-offs the author claims

The post lays out three arguments for the approach. On latency, it claims that once the model is cached, time to first token can beat a round trip to OpenAI's servers. On cost, the operator pays nothing for inference because the user's hardware supplies the compute. On security, the author contends the design is inherently suited to health-data rules such as HIPAA, because there is no server-side record of the query at all.

These are the author's claims rather than independently benchmarked results — the post includes no published measurements, and formal HIPAA compliance is a regulatory determination that involves more than software architecture.

Caveats the tutorial itself flags

The post is explicit that the build is a proof of concept. For production, it points to unresolved work: managing VRAM carefully, handling model caching properly, and layering retrieval-augmented generation on top so the model draws on current medical references rather than its parametric memory alone. Its suggested next steps include wiring in a local vector store, Voy, to search FDA documentation on-device, and adding logic to route simpler queries to smaller models. Hardware is also a constraint: the tool needs a WebGPU-capable GPU and a recent Chrome, Edge or Arc browser, plus the bandwidth for a multi-gigabyte first download.

The more fundamental limitation is accuracy. An 8B-parameter model answering from a prompt, with no lookup layer, can produce confident errors — a serious risk in a pharmacology context. The tutorial's own emphasis on adding retrieval before anything production-ready is effectively an acknowledgment of that gap.

Why it matters

The project is a useful marker for how far in-browser AI has come. A few years ago, running an LLM implied a server; today a quantised 8B model can execute in a browser tab on consumer hardware, with WebGPU supplying the compute and IndexedDB acting as the model cache. For sensitive domains such as health, legal and finance, the interesting property is architectural: privacy stops being a policy about what a provider does with your data and becomes a fact about where the data physically resides. Even if this particular tool is a demo rather than medical software, the pattern it demonstrates — local model, structured prompt, optional on-device retrieval — is one that production applications can borrow while swapping in verified data sources.