TL;DR — the answer firstd3 is not a chat model: ollama's own door refuses
/api/generateand/api/chatoutright. It answers--askquestions with a yes/no, a label, or a score — each stamped with a confidence percent. On this box the 2b rung stamps in 0.8 s warm (3.7 GB loaded), 4b in ~2 s (7.1 GB), and clear tickets earn 97–99%. But the label's 262,144-token context never ships: the card pinsnum_ctx 4096, a 3,600-token ticket overflows it, and the ask door hard-fuses input at 64 KiB. Worst of all: the same ticket scored “no 53%” then “yes 99%” — the verdict wobble, and the CLI ships no dial for it.
Ask it to summarize and it hands you the manual — d3's longest utterance is its refusal.
$ curl -s localhost:11434/api/generate -d '{"model":"d3:2b",…}'
{"error":"\"d3:2b\" does not support generate"}
$ curl -s localhost:11434/api/chat -d '{"model":"d3:2b",…}'
{"error":"\"d3:2b\" does not support chat"}
$ ollama run d3:2b "Say only: ok"
Error: d3:2b answers questions about text, e.g.
ollama run d3:2b --ask "Is a refund being requested?" < ticket.txt
--askyes or no — always with a confidence percent--choicenamed labels — routing, not rumination--levela graded scale — it prints a number, e.g. 1.8 / 2Same four tickets, same 8 cores — press a rung and read the stamps.
every stamp above is a verbatim run: ollama 0.40.10, default sampling, no seed, no temperature dial. latencies shown where individually timed.
| ticket | d3:2b | d3:4b | 9b / 27b |
|---|---|---|---|
| “card was charged twice” → billing? | yes 98% | yes 97% · 23.7 s cold | won't load — see below |
| “arrived a day early, perfect condition” → billing? | no 99% | no 99% · 2.6 s | — |
| “invoice total changed after checkout” → billing? | no 53% then yes 99% · 0.8 s | not run | — |
| “45 minutes on hold, gave up” → escalate? | yes 77% | yes 86% · 1.8 s | — |
The size ladder buys gray-zone confidence — 77% to 86% — and doubles the RAM. On the clear tickets, 2b was already at the ceiling.
The label promises 262,144 tokens. Three measured doors sit far below it.
replay of measured runs — zero interpolation: the 3,600-token ticket died at 7.9 s on the context wall; the 14,400-token one tripped the fuse in 0.03 s, before the model even loaded.
Error: the prompt is longer than the context length currently
available to the model; shorten the prompt, adjust the context
length in settings, or use a model with a longer context length
Error: text and schema must not exceed 64 KiB
What the receipts actually buy — and what they refuse to promise.
ollama run --help exposes --format only — no --seed, no --temperature, and the API lanes refuse d3 entirely$ ollama run d3:2b "A customer says their card was charged twice." \
--ask "Is this a billing issue? answer yes or no"
yes 98%
■ honest stamp — benched 2026-10-24 on a throwaway 8-vCPU / 8.7 GiB QEMU-KVM VM, Ubuntu 24.04, ollama 0.40.10, CPU-only, default sampling throughout. the ladder tops out at 4b on a CPU box: 9b ships as a 9.5 GB Q8_0 that cannot fit 8.7 GiB, and the nvfp4 / mxfp8 quants refuse with “this model requires MLX support” — Apple silicon only. 27b was not attempted: a 16 GB pull against the box's disk wall. family: 2b / 4b / 9b / 27b, Apache-2.0, from vLLM Semantic Router's decision models, shipped in ollama v0.40.9 (2026-10-22).
— the bench is the ledger · Mr Say Nothing