Wiki audit: correct 12 pages against the code, and retire a command that cannot run
Every page was read against the 5.7 tree. Three systemic causes account for most of
what the audit found.
**Docs described tuning that is no longer shipped.** FAQ and Runtime-Controls quoted
the family fallback and pre-repair arms, while the defaults are the per-install
`ModelProfile.table`: the 35B rows are 10 GiB/160 slots at 4-bit and 12 GiB/96 at
8-bit with prefetch on, and Qwen3.8 is 12 GiB/96 at 4-bit and 9.5 GiB/40 at 8-bit
with prefetch off. Also corrected: Home's Swift floor (6.3 -> 6.4) and its 35B disk
range; Getting-Started's dense sizes, and its claim that a pipe sets up the browser
window (that prompt needs a terminal); Features' missing 8-bit Qwen3.8, its three
clients where there are five, and "binary thinking" where Qwen3.8 has four levels.
**Version labels had drifted.** Benchmarks' "v4.7" section is 5.0's work — there is
no v4.7 tag — and it claimed a v4.6 baseline for Qwen3.8, which did not exist then.
Its three percentages were withdrawn rather than re-guessed: their baselines cannot
be re-derived from anything in the repository.
**The LAN Manager's remote-access recipe was impossible.** The harness refuses
`--host 0.0.0.0`, and a specific address fails the webserver plugin's schema
(`expected "127.0.0.1" | "0.0.0.0"`), so the profile does not load. Verified by
trying both on a throwaway DSH_HOME. The page, the plugin README and the plugin's
own boot log all told operators to do it; all three now say what is true, and the
boot log no longer advertises addresses nothing is listening on.
Also: Cookbook's launcher keys, OpenAI-Compatible-Server's `-fast` listing and its
per-surface reasoning field, System-Design's ANE default, MTP numbers and interface
list, TinyTitan-Plugin's `--web` owner and its session-title overclaim, the LAN
fence's IPv6 ranges and its missing config keys, an unquoted receipt error, and a
duplicated sentence.
Verified after: links, anchors and the sidebar clean; every cited path still
resolves; both plugin suites pass; all six lint gates green.
Getting Started: the one command downloads the engine, and the safe way to run it
The tip still said the installer "gets the source, builds the server",
which stopped being true when it began downloading the published arm64
executables — and it needs no Xcode, Homebrew, git or Node now.
It also recommended `curl … | bash`, the form the README warns against:
a pipe makes the script's stdin the pipe, so it cannot ask anything and
takes the default at every step, including the model download and the
browser window. It shows `bash -c "$(curl …)"` now, and says why.
The by-hand path keeps its build step, renamed to say so, with a note that
only that path needs a Swift toolchain.
Getting Started: the optional browser chat window
`tools/server_launcher.sh --web` starts the server and opens TinyTitan's own
DeepSeek Harness on a local page already pointed at the model, and the installer
offers the same thing as `--web`. Step 5 now names it and says what it installs:
a pinned harness under ~/.tinytitan with its own home, npm prefix, pnpm store and
port (7788, or the next free one), kept separate from any DeepSeek Harness the
reader already runs. The one-command tip points at it.
The engine and its loopback server are still the product; this is a client that
is installed and configured for the reader, not a bundled app.
Remove the Mac app: the product is the engine and its server
The app, the out-of-process decode service it drove, and their library and test
targets are gone from the repository. The wiki followed them: the Interfaces
rows, the app preference block, the app-only control rows and the iOS roadmap
item all described a front end TinyTitan no longer has and will not carry. A
second front end is a second surface to build, keep in step with every engine
feature, and support, so the Roadmap now says a GUI or mobile front end is out
of scope rather than deferred, and the tracker's issue-#5 items are closed
instead of left open for a future session to pick up.
Where a page told the reader to do something in the app it now gives the real
equivalent: the launcher's --model keys and --bits, the served id from
/v1/models, and the OpenAI (http://127.0.0.1:8080/v1) and Anthropic Messages
(http://127.0.0.1:8080) endpoints. Every process guard is now exactly
'TinyTitanServer|TinyTitanCLI|TinyTitanPackageTests|swiftpm-testing-helper|mlx_lm|mlx-lm'.
Getting Started also gained the one-command install it never mentioned
(tools/install_tinytitan.sh, which leaves ~/.local/bin/tinytitan), since the
installer and the server launcher are now the whole product surface.
Changelog.md is untouched: it is the chronological record of what shipped, and
entries describing the app were true when they were written.
Getting Started: what the 2B cannot do, measured
The model table lists the dense Qwen 3.5 2B as a supported install and says
nothing about what it is for. Note it: measured, it got a two-part instruction
(copy a code, add two three-digit numbers) wrong in three to five of eight
attempts with thinking off, and six of eight at the model's own sampling.
Thinking is not the fix -- in 8-bit with thinking on it answered five of eight
but took 42 to 253 seconds per reply and produced nothing on the other three,
spending the whole budget inside the reasoning block, and decoded greedily it
never answers at all. Point readers at chat/summaries/recall beside a bigger
model, and at a 4B/9B or a 35B when the output has to be right.
The wiki is TinyTitan
Every page except the Changelog is renamed by the same rule the checkout used
(`NVMAI_` -> `TINYTITAN_`, `NVMAI` -> `TinyTitan`, `nvmai` -> `tinytitan`), and
the wiki's own `assets/wordmark.svg` is fixed the way the repository's was: the
name was split across two coloured spans, so it read `NVM` + `AI` and had to
become `Tiny` + `Titan`, with the canvas widened from 132 to 176 so the longer
name is not clipped.
The Changelog keeps its entries as they shipped -- they are the record of
releases made under the old name -- and gains one line at the top saying the
project was renamed on 2026-09-14, so the page is not a mystery. Its release
links still resolve: GitHub redirects a renamed repository.
Home now leads with the project's brand image
(`assets/tinytitan-hero.png`), the same artwork the README leads with, and the
tracker gains the closed row.
agent
committed
Sep 14, 2026
Getting-Started: document the catalog installer and the both-widths install
One download yields both widths for the Qwen3.5-MoE checkpoints, so
`tools/install_models.sh <model> both` is the cheap way to get KAT (or Ornith
1.5, Qwen 3.6, AgentWorld) at 4-bit and 8-bit, and a single width still keeps
the other snapshot for later.
agent
committed
Sep 13, 2026
KAT is supported: flip Getting-Started, Features and Roadmap, and close the tracker
Both widths verified on the real install with stored golden baselines. The
Roadmap entry is DONE, the wiki status wording no longer says a first
verification is pending, and the tracker's task table is closed out. Records
that it took five bugs, including the expert-fusion ordering that no byte-level
check could see.
agent
committed
Sep 13, 2026
State KAT-Coder's verification status where a user reads it
KAT-Coder-V2.5-Dev: prep landed, conversion pending
The new family member is a Qwen3.6-35B-A3B fine-tune, so it is the same code
path this runtime already serves. The tracker records what was checked against
the checkpoint before any download (31,333 tensors, none outside the converter's
namespaces, no vision tower despite the declared vision_config, the plan's
tensor split and the ~20 GB 4-bit output), what has landed (converter, installer
and launcher rows, profile rows, display name), and what remains (conversion,
installs, the app's two fingerprints which need the converted snapshot to
exist, and verification).
Two deviations from the checkpoint's own recommendations are stated rather than
hidden: presence_penalty 1.5 is not implemented by this runtime (it supports
0.0 only), and preserve_thinking has no equivalent here. The roadmap entry
gains a status line and its own open questions are answered -- the mrope block
is present and identical to AgentWorld's, and the checkpoint carries no vision
tensors.
Record the dense Qwen 3.5 GPU port: both engines, engine per request
The tracker's "planned work" entry for the dense GPU engine is closed and
moved under "Recently closed", with the account of what the port cost: the
role-versus-width finding (C89), the four MoE-shaped load assumptions (C88),
the two config-derived traps (C86/C87), the keep-mask placeholder (C85), and
the prefill command buffer that was never committed. The CPU-only entry that
the port supersedes now says so and points at the new section instead of
reading as current.
The server guide no longer calls the engine a property of the model: the
dense installs show GPU+CPU, --engine picks for them, and <id>@cpu / <id>@gpu
select an engine per request. Getting-Started and Runtime-Controls drop the
"(CPU)" and "CPU engine" labels the port made wrong.
Dense .gturbo: the writer was the blocker, and all six are migrated
The previous entry recorded the CPU reader as the problem. It was right and
the repacker was dropping the source checkpoint's per-tensor widths, so a
4-bit build's 8-bit embedding and K/V were being dequantized as 4-bit --
word count changes, strides still divide evenly, shapes all check, fluent
nonsense. Recording the widths turned that into identical logits.
All six installs (2B/4B/9B at 4-bit and 8-bit) are .gturbo now, with
receipts, and serve through the catalog path. Two further bugs the
migration surfaced are recorded: verify-install demanding layer files a
dense model has none of, and routedExpert starting at a literal 4 so every
8-bit install advertised itself as 4-bit and was skipped as a duplicate.
Also drops the "snapshots, not .gturbo" note from Getting-Started, which
stops being true.
Runtime requests: best-effort, and Qwen 3.5 9B
Two changes from 195eb3c.
Reasoning levels are now accepted and mapped rather than refused. A coding
agent's `reasoning_effort` was a 400 whenever the served template did not
name that exact level, which ended the turn and often the session; OpenCode,
Zed and Qoder all send it. Runtime Controls gains the per-family level table
(the old text claimed no family defines effort levels, which stopped being
true when Qwen3.8 landed) and the mapping rule, with the log line shown.
The page also states plainly what is still load-time: thinking and effort are
baked into the session's tokenizer, so a mid-session switch — including
turning thinking off — does not yet change what the model renders, and the
log says so instead of claiming a level that is not in force.
Qwen 3.5 2B / 4B / 9B join the model table in Getting Started. They install
as affine snapshots rather than .gturbo installs, so they carry no
verification receipt — recorded in both pages rather than glossed.
The tracker gets the reasoning policy (what was wrong, what now happens, what
is left), the 9B's two tied-output assumptions — the converter refused to
plan it, and the CPU engine would have run it and produced fluent nonsense —
and the snapshot-versus-receipt trade with the honest fix named for later.
One launcher, and three stale claims corrected
Documents the consolidation in bb261d8: one tools/server_launcher.sh that
starts the server alone or with Codex, Claude Code, Qwen Code, OpenCode or
Zed, and asks about the model, the thinking level and the RAM limit
(1/2/4/8/16/32 GB, defaulting to the install's measured profile).
The launcher section was documenting a flow that had been replaced: the
old per-model argument positions and a per-quantization port scheme (8081
for 4-bit, 8083 for 8-bit) that the one-port catalog launcher removed. It
now describes what the script actually asks and what it writes per client,
including the two JSONC merges.
Two other corrections, both found while writing the forum series and both
of the kind a reader would have believed:
- Runtime Controls said --expert-cache-slots accepts 8/16/24/32/64/96/128
because that is what --help prints. RuntimeConfiguration accepts
40/48/112/160/192/256 as well. The wiki now lists the accepted set and
flags the help text as narrower.
- The tracker said item 9 would remove a shipped refusal. The QSA
indexer shipped the same day as the gate (f5b1720 decode, 23eb4c4
prefill) and the gate is now unreachable, so nothing is refused today.
Exact block-wise merging is still worth having, but it is no longer
unblocking anything.
Also: the ANE prefill default. The wiki's `on` is right --
ANEPrefillAttention returns .on when the variable is unset -- but
docs/v4.5-ane-prefill.md and the enum's own doc comment both still say off
by default. Recorded in the tracker as stale design notes; no wiki change
needed.
The tracker also gains the CPU side-engine as planned work, with the
measurements that decide its design (1 thread = 3% cost, ~7 tok/s; 92%
one-clause accuracy against 38-of-47 on decomposition), and a duplicate
`## 6.` heading is renumbered to 7.
Head every page with the NVMAI wordmark
The wiki carried no visual identity at all, so the README and the wiki did
not look like the same project. Every content page and the sidebar now open
with the same two-colour wordmark the README slogan uses -- NVM in cyan, AI
in orange.
One file serves both themes here. The slogan needs a light and a dark
variant because its body text is neutral, but the wordmark is entirely
brand colours and both carry enough contrast on #ffffff and #0d1117, which
was checked against each before committing.
Deliberately not applied to the hundreds of inline "NVMAI" mentions in
prose: GitHub cannot colour inline text, so each one would have to become
an image, which would break text selection, search and screen readers for
no gain.
Audit the wiki: current v4.6 state, remove engineering history records
- Move the v4.2/v4.3 experiment qualification record out of the wiki
(now docs/v4.2-experiments.md in the source repository) and drop its
navigation entries; the wiki keeps user-facing documentation only.
- Trim Benchmarks to current, decision-relevant results: v4.6, its v4.1
baseline, the MTP and coding/tooling qualifications behind the shipped
defaults, and fast-alias latency. Remove superseded 6-bit-era tables,
the stale prompt-length record, and the historical M5 reference.
- Bring Features and System Design to v4.6 (tiled Top-K sampling, opt-in
ANE prefill) and remove release-tag phrasing from runtime descriptions.
- Remove the empty Unreleased changelog section, the legacy 6-bit row in
Getting Started, and a duplicated server snippet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Document NVMAI 4.0 defaults and qualification
Document Ornith as the default baseline
Document Ornith native MTP support and benchmarks
Document compressed KV cache and YaRN contexts
docs: add Ornith 1.5 user guide
docs: refocus wiki on core user workflows
docs: update launchers and release history through 3.9
docs: use nvmai/ as the model directory convention
rename model dirs to qwen3.6_35B_A3B_{4,6,8}Bit and update all references
Refresh for Qwen-only NVMAI: fix binary names, defaults, and broken links
- Getting Started and the server guide: rename the old fork's binary names
(TurboFieldfareRepack/CLI/Server/Mac) to NVMAIRepack/NVMAICLI/NVMAIServer/
NVMAIMac and the defaults suite to NVMAI; pgrep patterns updated
- Runtime Controls: expert-cache default 32 (64 accepted), prefill chunk
default 4096, new 4-bit chunk-sizing measurement added alongside the older
8-bit data point
- Qwen performance notes: profile updated to 32 slots; slot cap note updated
- System Design: Qwen-only banner, broken Sources/TurboFieldfare links fixed
to sources/NVMAI, trusted-install load default documented
- Optimization Journey: 2026-08 Qwen acceleration measurements (chunk sizing,
trusted-install startup, slot neutrality, rejected prefetch/mmap)
Document streaming-aware native MTP
Migrate project documentation into structured Wiki