Documents all numeric ABI error codes, their boundary meaning, recovery expectations, and the distinction between transport failures and model/runtime failures.
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.
| Code | Name | Boundary |
|---|---|---|
| 0 | Ok | Operation completed. |
| 1 | NullPointer | A required raw pointer was zero. |
| 2 | InvalidLength | Zero, excessive, overflowed, or invalid configuration length. |
| 3 | InvalidUtf8 | Prompt bytes were not valid UTF-8. |
| 4 | InvalidModelMagic | Artifact did not begin with SLM1. |
| 5 | UnsupportedModelVersion | Header version is not supported. |
| 6 | InvalidHeader | Header, checksum, offsets, or dimensions are invalid. |
| 7 | InvalidTensorDirectory | Tensor entry or range is malformed. |
| 8 | MissingTensor | A required stable tensor name is absent. |
| 9 | ShapeMismatch | Header or tensor dimensions violate the model contract. |
| 10 | UnsupportedDType | Tensor dtype is not f32, q8_0, or q4_0. |
| 11 | ContextExceeded | Prompt or continuation exceeds model context. |
| 12 | ModelNotLoaded | Generation was requested without a resident model. |
| 13 | GenerationFailed | A forward/sampling operation failed. |
| 14 | OutputBufferExceeded | A bounded result buffer could not contain output. |
Recovery semantics
The supplied q8 ABI smoke demonstrates that invalid prompt and sampling calls do not discard a valid loaded model. After restoring greedy sampling, generation succeeds. free_model clears model state and subsequent stepping returns ModelNotLoaded.
Host rendering
The browser displays both numeric state and a human-readable last error. Host fetch and JavaScript failures remain separate because they occur before an ABI call can return an ErrorCode.
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?