Datapoint for your outstanding question, since we run this model in production on a standard GPU stack: vLLM with the NVFP4 quant (bullerwins), RTX 5090, muse reasoning parser, official chat template.

Your exact repro does not reproduce here. MOONSHINE_CERT_ALPHA 42 comes back verbatim on 8 draws, and a denser probe (integers 40 to 49 on one line) comes back clean 8/8, no space ever inside a literal. So at least on this stack the digit-interior spacing is not a property of the weights themselves at 4-bit, which points at something in your chain, my guess would be the harmony-lite template or the sampling/decode loop of the custom server rather than the quant. Worth testing your same weights through llama.cpp with the official template before touching precision.

One adjacent thing we did measure on this lineage, in case it is related to what you're seeing: under grammar-constrained decoding (json_schema through xgrammar), the model has a real tendency to emit whitespace runs between tokens, we measured ~8% of runs on tight-schema JSON paths degenerating into long space sequences before we forced compact JSON at the grammar level. That is spaces BETWEEN elements, never inside a number literal, and it only shows under constrained decode, but it does show the sampler likes the space token more than it should in low-entropy spots. If your server does any form of constrained or biased decoding, that would be my first suspect.

Resolved: it was our stop tokens, not the weights — <|eom|> is a channel boundary

Thank you, @YoRandom . Your reply was the whole ballgame. Not because it named the answer,
but because a credible non-reproduction on a known-good stack turns an open
question into a bounded one. The moment "same weights, NVFP4, vLLM, official
template, muse reasoning parser, 8/8 clean" landed, the search space collapsed
from the model to our chain — and after that it was just walking the chain
until something confessed.

It confessed twice. Both were ours.

What we had reported

muse-glimmer-30b-3 could not reproduce exact multi-digit literals. Asked to
echo 42, it returned 4 2. Asked for 6193, 6 1 9 3. It was consistent, it
survived greedy decode, it survived a fresh box, and it reproduced under a
"control" where a different model on the same fleet returned digits perfectly. We
had it written up as a weights- or quantization-level property.

Bug one: <|eom|> in the stop list

Our stop-token list for this model was:

200008  <|eot|>           end of turn
200001  <|end_of_text|>
200007  <|eom|>           <-- this one

<|eom|> is end of message, not end of turn. It closes the analysis
channel. Immediately after it the model opens

<|start|>assistant to=user<|message|>

and emits the actual answer.

By listing it as a stop we halted generation at the exact moment the model
finished thinking and was about to speak. Everything we ever read back from
this model was its reasoning. Not a truncated answer — the wrong channel
entirely.

Same prompt, hand-templated, our front door bypassed, asked for 6193:

# with 200007 as a stop
"The user wants me to reply with only this exact value and nothing else: 6 1 9 3"
   ^ generation ends here

# without it
"...So they want the output to be exactly "6193" with no extra text.
   ...Just 6193. Proceed."
<|eom|> <|start|>assistant to=user<|message|> 6193 <|eot|>
                                              ^^^^ contiguous. correct.

The spaced digits appear only where the model spells them out while
reasoning — completely normal prose behaviour once you see it. Its answer was
always right. We were quoting its inner monologue and calling it a defect.

Your xgrammar note is what made this findable, incidentally. "The sampler likes
the space token more than it should in low-entropy spots" made us look at where
in the output the spacing lived rather than at whether it was there. It lives in
analysis text. That distinction is the whole bug.

Bug two: the trap immediately after the first one

Fixing the stop list made the answer generate, and we still didn't get it:

{"content": "The user asks for a specific value. I should comply with the
             request and output the exact value.assistant to=user6193",
 "reasoning_content": ""}

The answer is right there, contiguous — and served as one blob with the reasoning
and the channel header glued to it.

Our channel splitter was gated on "were tools offered?" as a proxy for "is
this a channel-framed reply". That proxy had been correct, but only as an
accident of bug one: while <|eom|> truncated generation, a plain chat reply
genuinely never contained a header, so the proxy never had to be right for the
right reason. Fix the stop list and the model runs on into assistant to=user on
ordinary chat too — and a mode-based proxy silently stops matching reality.

We now gate on the evidence in the text (does it actually contain a channel
header?) rather than on the shape of the request.

One subtlety worth stealing, because it is why the gate cannot simply be deleted:
our splitter treats everything before the first header as the analysis channel.
So splitting a headerless reply returns content: "" and buries the answer in
reasoning. "Always split" is not the fix; "split when a header is present" is.
We pinned that hazard in a test asserting the empty result, so nobody later reads
the gate as redundant and removes it.

Final state, end to end:

{"content": "6193",
 "reasoning_content": "The user asks for a specific value. I should comply with the request."}

Why our control fooled us

This is the part worth passing on.

We "controlled" for the model by running the same prompt through the same fleet
with a different model, which returned exact digits. That felt airtight. It
wasn't: our front door selects a different tokenizer, chat template, and
stop-token list per model. The comparison varied four things at once, isolated
none of them, and pointed confidently at the only one that was innocent.

We also had the disconfirming evidence in hand for hours. Responses were coming
back with content: "" and reasoning_content full. We logged it, noticed
it, and filed it as "the model didn't answer." It was the bug stating itself in
plain language: generation had produced reasoning and nothing else, because we
stopped it before anything else could exist.

The generalisable version

If you are running a channel/reasoning model on a custom serving stack:

1. eom is not eot. Any model that separates analysis from final output
   has a token that closes a message and one that closes a turn. If your
   harness treats the first as a stop, you will silently serve the analysis
   channel as the answer. Nothing errors. It looks like a model quality problem.

2. Analysis text has different typographic habits than final text. Models
   spell things out while thinking — digits, acronyms, step numbers. So this
   failure mode specifically mimics tokenizer, quantization and sampler
   defects. It is why our greedy-decode check "confirmed" the bug: greedy decode
   faithfully reproduced the reasoning we were wrongly reading.

3. content empty with reasoning populated is a channel-plumbing symptom,
   not a model refusal. Check it before anything else.

4. Beware proxies that are only accidentally correct. Our splitter gate
   ("were tools offered") was right for years because a different bug kept
   plain replies headerless. Fixing that bug broke the proxy. If you are
   inferring a property of the output, test the output, not the request.

5. A vendor's non-reproduction is data, not a rebuttal. It bounds the search
   even when it doesn't name the cause. Yours saved us from filing a wrong bug
   report against a model that was behaving correctly the entire time.

6. Check the stop list before the weights. It is one line, it is never
   reviewed, and it is upstream of everything you would otherwise suspect. We
   audited the tokenizer, the chat template, the FFN approximation guards, the KV
   cache, the sharded residual transfer and the decode loop — in that order —
   before looking at a three-element array. The comment above it, written by us,
   asserted that those ids "give clean turns."

A 60-second check

Drop the eom id from your stop list, give it room to run, and look at the tail:

curl -s $STATION/generate -H 'content-type: application/json' -d '{
  "tokens": [ ...your templated prompt... ],
  "max_new_tokens": 200,
  "temperature": 0,
  "eos_token_ids": [200008, 200001]
}'

If the tail contains assistant to=user followed by a different, cleaner
rendering of what you asked for, your stop list is eating your answers. Then
check that whatever parses channels downstream actually runs on that reply —
that was our second bug, and it produced a correct answer we still failed to
deliver.

Thanks again for running our repro and for reporting the negative clearly. A
well-documented "does not reproduce here, and here is my exact stack" is worth
more than most positive results and takes considerably more effort to write. We
appreciated it.