Choice probabilities
direct readout · no decodingRead the model’s choice logits and normalize only across the options you supplied.
waiting for a run
- total
- —
- input
- —
- output
- 1 readout
Decision model in your browser
A local model can either read probabilities for your allowed options without decoding them, or write the same kind of distribution token by token.
1 · direct readout
Read the answer off the logits
One forward pass over your state, question and options. The model never writes a word: we take its next-token logits for the option letters and softmax across them.
2 · generation
Let the model write it out
Same decision, but the model is asked to type a JSON distribution token by token. You watch every token arrive and compare the wall time of both paths on your own GPU.
Qwen3 0.6B loads automatically
Measured model qualitynative checkpoints · owned + public benchmarks
| Model | Download | Authored | Perturbed | TypeSafe |
|---|---|---|---|---|
| Qwen3 0.6B | 639 MB | 44.0% | 52.8% | 40.7% |
| Published Jev | hosted | — | — | 88.3% |
Owned columns are balanced accuracy. TypeSafe is equal-case agreement on the same 102-row public subset; Jev is the published value. Browser quantization may change model accuracy.
{{ text }}
download / cache—
639 MB on first visit, cached afterwards
model load—download and prepare
warmup—compile passes for both methods
Weights come from Hugging Face and remain in your browser cache. Inputs never leave this page. First load can take a few minutes depending on network and GPU.
Give it a real choice
Try an example
Both paths receive the same decision. One reads option probabilities directly; the other asks the model to write its option probabilities as JSON text.
your decisionstate + question + options
same local modelQwen3 · 0.6B
read logitsA…T probabilities
write tokens{options + probabilities}
JSON probabilities
generation · token by tokenAsk the model to estimate the same displayed-option distribution and write it as JSON. Watch every token arrive.
waiting for a run
- first token
- —
- total
- —
- input
- —
- output
- —
The methods run sequentially on the same loaded model so they do not contend for one GPU. Direct runs first, then generation.
Why direct readout and generation disagree
Because they measure two different things, and only one of them is a probability in the strict sense.
Direct readout takes the model's logits at the first answer position, keeps only the option letter tokens, and applies a softmax across them. That is the model's actual next-token preference between the options. It reflects what the network computes, including small residual mass on unlikely options. These are conditional probabilities over the displayed options only; they are not calibrated confidence. A typical run gives something like A 0.865, B 0.000, C 0.135.
Generation asks the model to write numbers as text. The values in the JSON are just tokens the model decided to emit, not a readout of anything internal. A 0.6B model has strong habits here: it writes round, stereotyped numbers like 0.5 / 0.4 / 0.1, or collapses to 1.0 on one key, because "1.0" is a common pattern in its training data. Verbalized probabilities are known to be poorly calibrated even for large models, and for a tiny one they are closer to a formatting reflex than an estimate.
There are also two smaller contributors:
- Different prompts. The direct path says "reply with one letter". The generation path adds instructions about JSON keys, values summing to 1 and an example distribution. The model conditions on that example, which nudges its numbers toward the example's shape.
- Greedy decoding. Generation runs at temperature 0, so you always get the single most habitual number sequence, not a sample from a distribution.
The timing gap has a simpler cause. Direct needs one forward pass over the prompt and reads the logits. Generation needs that same pass plus one full forward pass per emitted token, run sequentially, so 30 to 40 tokens costs 2 to 3× the wall time. That ratio is what the page is designed to show. Setup, warmup and both paths are timed with performance.now(); no canned results appear.
So the honest reading of the two panels: the left one is the model's decision, the right one is the model's story about its decision.