Browser boot state and stale-load suppression

Follows WebAssembly instantiation, runtime initialization, model fetch, model acceptance, manifest fetch, control gating, and race prevention during model changes.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
2 minutes

Follows WebAssembly instantiation, runtime initialization, model fetch, model acceptance, manifest fetch, control gating, and race prevention during model changes.

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.

Boot sequence

  1. Fetch runtime/tinyrustlm.wasm.
  2. Instantiate it with an empty imports object.
  3. Call init_runtime.
  4. Load the selected local model, defaulting to TinyLM-16M q8_0.
  5. After Rust acceptance, fetch and render the adjacent manifest.

Control gating

Generate and Reset remain disabled until a model is accepted. The model selector is enabled after the WASM exports are available, including after a model fetch or admission failure.

Race prevention

modelLoadSequence assigns a monotonically increasing load ID. A stale response exits without changing current UI state when a newer model selection has started.

Current gap

Fetch is not aborted; stale bytes may still download and allocate. A future implementation should pair the sequence guard with AbortController.

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?