The on-device model for ThoxMini (Pi Zero 2 W, arm64/NEON, 512 MB).

Thox-ai/thox-micro-125m role-tuned so it can actually be used as an assistant.

The base is a base LM with no instruct tuning. Measured on the exact file that had been dropped to the image lane:

That is raw training-scrape leaking. It could not ship as an assistant. After tuning, the same prompt returns a coherent deferral.

Prompts held out of the training corpus:

Zero fabrications, and no scrape leakage. In-corpus commands work: status → "Key online. Storage sealed. No pending transfers."

1. It says "the key", not "the mini." The role corpus was authored for ThoxKey-S3 and reused verbatim, so device-specific strings are wrong for this board: do you send my data anywhere → "No. I run on the key. Nothing leaves it." Correct in substance, wrong in noun. Fix is a ThoxMini variant of datasets/device/thoxkey-role.jsonl, not a retrain of the recipe.

2. It over-defers on identity. Hello, who are you? returns "I cannot answer that locally. The host has it." It should name itself. The corpus trains deferral hard and contains no identity turn for this device; adding one fixes it.

Neither is a fabrication, which is the failure mode that actually blocks shipping. Both are corpus gaps.

v5 and not v4 deliberately. v4 carries tag: correction rows that quote a falsehood so the assistant can deny it; those rows taught fabrication rather than preventing it — a 7B trained on them invented "a Partner at Insight Partners" for a real named person. v5 quarantines them.

EOS is appended explicitly during training. Omitting it is a defect this factory already paid for: adapters trained without it emitted EOS zero times across 12 gate answers and ran to the token cap every time.