Documentation

Getting started

Open the app and click the single button on the home screen. The model streams in once (149 MB for the default), is cached on your device, and every later visit starts in seconds — offline included. Nothing is ever uploaded: the weights come down to your machine and the computation happens on your GPU.

Requirements: a browser with WebGPU (Chrome, Edge, or Safari 18+). A discrete GPU helps for models above 1B parameters, but a laptop runs the small ones comfortably.

Run any Hugging Face model

Brimkern reads single-file GGUF directly — the format the Hub already hosts, with no conversion or compilation step. Paste any of these into the field on the home screen (or in the model browser):

Qwen/Qwen3-0.6B-GGUF
https://huggingface.co/Qwen/Qwen3-0.6B-GGUF
https://huggingface.co/Qwen/Qwen3-0.6B-GGUF/blob/main/Qwen3-0.6B-Q8_0.gguf
https://example.com/my-model.gguf

The best quantization is picked for you (Q4_K_M first, then Q4_K_S, Q5, Q8…), and the tokenizer follows the file — nothing to configure. Sharded GGUFs (-00001-of-0000N) and vision projectors (mmproj) are refused with an explicit message rather than half-loaded.

Instant test links

Any model can be turned into a link that loads it directly — handy to share a demo, to file a bug report, or to point a colleague at an exact quantization.

https://brimkern.com/chat?model=Qwen/Qwen3-0.6B-GGUF
https://brimkern.com/chat?model=Qwen/Qwen3-0.6B-GGUF&file=Qwen3-0.6B-Q8_0.gguf
https://brimkern.com/chat?gguf=https://example.com/model.gguf
https://brimkern.com/chat?brik=https://example.com/model.brik

?model= resolves the repository through the Hub API and picks the best loadable file (a .brik wins over a GGUF). ?file= forces one exact quantization. ?gguf= and ?brik= take a direct URL, for models you host yourself.

The .brik format & converter

A .brik is a GGUF re-packaged for the browser: weights already quantized to int4/int8, laid out so each layer is one contiguous HTTP range, with the tokenizer embedded. The practical effect: the model loads by ranges (resumable, partially, genuinely offline afterwards) instead of as one multi-gigabyte download.

You can convert a GGUF yourself, in the browser — the file never leaves your machine: open the converter.

Embeddable SDK

One script tag puts a local assistant on your own site. It runs on your visitor’s GPU: no server, no per-token cost, nothing sent anywhere.

<script src="https://brimkern.com/sdk.js"></script>
<script>
  Brimkern.embed({
    system: "You are the assistant of the Ferblanc store.",
    title: "Ask us anything",
    // Vos contenus. Découpés en passages, puis seuls les 1 à 3 passages proches de la
    // question posée sont donnés au modèle. Le tri est LOCAL (lexical) : rien ne part.
    knowledge: [
      { title: "Opening hours", text: "Open Tuesday to Saturday, 10am to 7pm." },
      { title: "Shipping", text: "Free in France from 60 euros. Switzerland: flat 8 euros." },
    ],
  });
</script>

The model only downloads when a visitor actually opens the widget, so your page speed is untouched. Knowledge documents stay on the page: they are chunked and ranked in the browser, and only the passages matching the question reach the model. Full SDK page and live demo.

It is also a package — types included, and importing it on a server does nothing (Next, Remix, Astro are safe):

npm i brimkern

import { embed, createSession } from 'brimkern';

Pin a version if you would rather the widget did not change under your feet: https://brimkern.com/sdk-0.1.0.js instead of https://brimkern.com/sdk.js.

Storage & offline

Model weights live in the browser cache, per site. The browser decides how much space it grants — often tens of gigabytes on a normal profile, but only ~1.5 GB in a private window, where a large model will not stay cached. The model browser warns you before a download that cannot fit.

Models you have not used for 30 days are cleaned up automatically (adjustable, or off, in the Storage panel). Conversations and locally converted .brik files are never touched.

Diagnostics

Every risky code path has a URL switch that falls back to the slower, simpler one. Handy to check whether an optimization is responsible for something odd — the answer should be identical, only slower.

?gemv=0        decode matmul → row kernels
?f16shared=0   f16 prefill GEMM → one row per thread
?qshared=0     q4/q8 prefill GEMM → 4 rows per invocation
?warmup=0      no weight warm-up (first message pays it)
?ggufstream=0  GGUF as one download instead of ranges
?kvq=0         KV cache in f32 instead of int8
?timing=1      per-stage timing of the forward pass, in the console

Compared to WebLLM

If you already know WebLLM — the other WebGPU engine that runs a large language model client-side — the two differ on one decisive point: what you must do to a model before it can run. We read single-file GGUF straight from Hugging Face; WebLLM needs weights compiled with MLC/TVM first. the measured comparison puts both throughputs side by side on the same GPU and the same model — including where WebLLM is ahead.

Changelog

What changed, release by release, with the measurements behind each claim: read the changelog.