Separates visible conversation history from runtime token/KV state, explains Reset and Clear, and defines requirements for persistence or multi-session support.
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.
Two histories
The DOM transcript is JavaScript-owned presentation state. The runtime token vector and KV cache are inference state. They can diverge intentionally.
Actions
- Generate appends User and TinyRustLM entries to the transcript and extends runtime context.
- Reset clears runtime context/output but leaves transcript entries visible.
- Clear removes transcript entries but does not reset runtime context or erase the current response.
Implication
A visible transcript is not proof of what the model currently remembers. The UI must expose this distinction to avoid misleading users.
Future sessions
Use explicit session IDs and snapshot metadata. Persisting transcript text and persisting KV/token state are separate privacy and compatibility decisions. Never silently restore model memory from UI text.
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?