Defines the concrete browser changes required to move synchronous inference off the main thread without obscuring cancellation, result ownership, or error semantics.
Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.
Architecture topic: this page does not claim that the WordPress website implements or executes the described runtime behavior.
Target topology
A dedicated Worker owns the WASM instance, runtime state, model transfer, and generation loop. The main thread owns DOM state and sends typed commands with request IDs.
Required messages
boot, load-model, configure-sampling, generate, cancel, reset-context, free-model, diagnostics, and structured result/error events.
Ownership
Model ArrayBuffers should be transferred once to the Worker. Prompt buffers may be transferred or copied based on size. The Worker must never expose a live pointer whose lifetime crosses an asynchronous message boundary.
Cancellation
The current monolithic generate call cannot be interrupted. Cancellation requires token-step scheduling, a checked cancellation flag, or one-token ABI commands driven by the Worker loop.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?