WebGPU was detected, the consent dialog appeared, the user granted consent, and the network tab showed a clean 200 OK on the WASM fetch. Then nothing. No console output, no progress events. The UI showed "Enhanced analysis unavailable. Try again." In npm run dev, against the same code on the same browser, everything worked.

I almost spent an afternoon on the wrong theory. The reason I didn't is the reason for this post.

When you're debugging, anomalies are easier to chase than absences. The 200 OK had a body of 0.3 KB, which is anomalous for a binary asset that should be a few megabytes. The console was silent, which is an absence. I led with the anomaly. That was the mistake.

The Wrong Hypothesis

The 0.3 KB number had a tidy explanation. A Git LFS pointer file is roughly 130 bytes plus HTTP overhead. raw.githubusercontent.com is well known for not serving LFS content from some repos: instead of redirecting to media.githubusercontent.com (which actually serves the binary), it returns the pointer text. If you fetch what you think is a 50 MB asset and get back 130 bytes of YAML-looking text, that's why.

The story almost wrote itself. WebLLM downloads the WASM. The WASM is actually an LFS pointer. The worker tries to call WebAssembly.instantiateStreaming() on the pointer text, fails immediately, and the fallback chain swallows the error. Plausible, mechanical, and it explained both the response size and the silent failure.

It was also wrong.

I pulled the .gitattributes from mlc-ai/binary-mlc-llm-libs/main. The entire file:

app-release.apk filter=lfs diff=lfs merge=lfs -text
mlc-chat.apk filter=lfs diff=lfs merge=lfs -text

Two lines. Only .apk files are LFS-tracked. WASM files are stored as regular Git blobs, which means raw.githubusercontent.com serves them directly with no pointer indirection. The theory was elegant and irrelevant.

This took thirty seconds to disprove. I'd been ready to spend hours on it.

The 0.3 KB number itself is still unexplained. Most likely a transient, a misread, or a path that 404'd with a small body served as 200 by an intermediary. Once the actual bug was fixed, the file fetched at the expected size and never showed up small again.

The lesson was sitting in plain sight the whole time. The console was silent. Silent. Not silent-after-an-error, not silent-with-a-warning, but silent across an entire failure path that was supposed to log progress events, then a model load completion, then inference timing. None of those fired. The anomaly told me where the bytes went. The absence told me the worker never got far enough to log anything.

If I'd led with the absence, I would have been looking for "what stops a worker from logging anything at all" within minutes. Instead I spent an hour on a theory about a domain I happened to find interesting.

The Actual Bug

The CSP deployed to Vercel, abridged:

default-src 'self';
script-src 'self' https://analytics.example.com;
worker-src 'self' blob:;
connect-src https://analytics.example.com
            https://huggingface.co
            https://*.huggingface.co
            https://raw.githubusercontent.com;

Notice what's missing from script-src. From MDN:

By default, if a CSP contains a default-src or a script-src directive, then a page won't be allowed to compile WebAssembly using functions like WebAssembly.compileStreaming(). The wasm-unsafe-eval keyword can be used to undo this protection.

WebLLM's worker calls WebAssembly.instantiateStreaming() on the model_lib WASM as part of engine initialization. With no 'wasm-unsafe-eval' in script-src, the browser refuses to compile and throws a CompileError inside the worker. The worker's onerror is caught by the CoachingProvider fallback chain, which is designed to fail gracefully: WebLLM fails, try Ollama, then fall back to rule-based. The architecture was handling errors correctly. The errors should not have been swallowed in the first place.

There were no diagnostic logs because every one of them was gated on import.meta.env.DEV and stripped from the production build. I'd treated error-path logging as production noise, which is the same as not having it.

The fix is one directive:

script-src 'self' 'wasm-unsafe-eval' https://analytics.example.com;

The directive is narrower than 'unsafe-eval' and is the safe choice for this case. The fix worked.

Why This Pattern is Treacherous

Three things composed to hide the failure.

The dev/prod CSP asymmetry is structural. Vite's dev server doesn't apply vercel.json headers. Any CSP-gated capability is unrestricted locally and enforced remotely. The same code path produces different runtime behavior across environments. "Works on my machine" is the literal truth.

Worker errors don't surface like main-thread errors. They propagate only through the worker's onerror event. If something catches that event for graceful degradation, the error is invisible unless the catch block logs it.

Production console hygiene fights you. Stripping logs is a defensible default, but error-path logs are not noise. They're the only signal that lets you debug failures users are actually hitting. When a try/catch lives inside a fallback handler, the catch block's logging is production-relevant even when the surrounding info logs aren't.

Each of these alone is benign. The intersection makes a failure mode that's invisible from both ends: no error in the user's UI, no error in the developer's console, no error in the deploy logs. The bug was actively being handled correctly by code that didn't know it was the bug.

What Changed After

Three changes landed in the fix PR.

The CSP directive. One line in vercel.json. Adding 'wasm-unsafe-eval' to script-src permits WebAssembly compilation and nothing else. WASM runs in its own sandbox, has no DOM access, and can only call back into JavaScript through imports the host page explicitly provides. It's the directive CSP3 added specifically so libraries like WebLLM wouldn't have to ask for 'unsafe-eval', which is genuinely riskier.

Removed import.meta.env.DEV gating from error-path logs in the WebLLM worker and the CoachingProvider fallback chain. Info and progress logs stay DEV-gated. Errors and fallback transitions surface in production. The principle, now written into the project conventions doc: gating an error log on DEV is the same as not having it. Treat it as the exception that needs justification, not the default.

Wired CSP violation reporting through Umami custom events. The securitypolicyviolation event fires regardless of whether report-to is configured in the CSP. Subscribing in the main entry point routes future violations into existing analytics:

document.addEventListener('securitypolicyviolation', (e) => {
  if (window.umami) {
    window.umami.track('csp-violation', {
      directive: e.violatedDirective,
      blockedURI: e.blockedURI,
      effectiveDirective: e.effectiveDirective,
    });
  }
});

No new infrastructure. The next CSP issue will be diagnosable in seconds.

The Takeaway

If you're debugging a WebLLM failure that works in dev and fails silently on Vercel, the answer is almost certainly 'wasm-unsafe-eval'. That's the practical takeaway.

The deeper one: when something fails, look at what's missing before you look at what's strange. Anomalies attract attention because they're concrete. You can hold a 0.3 KB response in your head and build theories about it. Absences are harder to notice because they're, by definition, not there. But the absence is usually the more honest signal. The anomaly tells you something happened. The absence tells you something didn't, which is closer to where the failure actually lives.

The thirty-second check almost always exists. Run it.

I'm building Holocron, a browser-based combat log analyzer for Star Wars: The Old Republic. The earlier WebLLM spike post covers why I chose this stack. Holocron is free and requires no install — try it at holocronparse.com.