Lists diagnostic fields, JSON escaping behavior, host-versus-runtime timing ownership, error recovery, and requirements for stable observability schemas.
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.
Fields
The runtime reports model-loaded state, last error, model-load time, prompt/generated token counts, token speed, peak scratch, KV length, quantization mode, tokenizer output, logits summary, selected token, top-k summary, and sampling configuration.
Serialization
JSON is handwritten without serde. Strings escape quotes, backslashes, control characters, and Unicode line/paragraph separators before browser parsing.
Timing split
Runtime-side model-load time and token speed are initialized to zero in the inspected Rust path. The browser measures wall-clock load and generation time and renders host-side token speed. Consumers must not confuse host values with runtime counters.
Schema stability
Diagnostics is currently an informal JSON object. A version field, units, nullable semantics, monotonic counters, and backward-compatible additions are needed before external tooling can depend on it.
Privacy
Tokenizer IDs and logits summaries may reveal prompt characteristics. A production export mode should separate operator diagnostics from user-safe telemetry and default to no transmission.
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?