hunch.

Hunch reads a state (text or JSON), one or more questions and the candidate answers, and returns a probability for every candidate. Two sizes, Hunch 0.6B and Hunch 1.7B, are fine-tuned from Qwen3 backbones and released under Apache-2.0, with GGUF f16 and MLX f16 builds for on-device use. It is not for decisions with legal effect on people without human review, and it is not a safety-policy classifier.

A question can be a choice among 2 to 255 candidates, a boolean (the probability a statement is true) or a score on an ordered rubric of 2 to 10 levels. Hunch builds one path per candidate from the state, the question and that candidate, runs each question's paths through the backbone together in one batch, and reads one score from each path's last token through an fp32 normalisation and a linear head. A softmax over one question's candidates turns the scores into its distribution.

A candidate's position is part of no path, so reordering the options cannot change an answer: permuting the options of 200 cases on the three suites of a public 59-suite benchmark list that test it flips 0.0 % of answers. The model has no language-model head and cannot emit text.

No trained checkpoint had been scored on the in-family test split before 25 September 2026. It was then scored once per release checkpoint, as declared in advance (a first attempt stopped at a batching limit before scoring anything, and was re-run): 3,467 questions in 12 families, the same questions an untrained backbone of each size had been scored on. Accuracy is 0.8543 (0.6B) and 0.8751 (1.7B). A constant guess of each family's most common answer scores 0.4673 on the same questions, and the untrained backbones read 0.3303 and 0.3337. 205 of those questions have a state that also occurs in the two releases' training text, most of them in the Bitext routing and urn-draw families; without them, accuracy is 0.8455 and 0.8679. On the same families' calibration questions, both sizes are ahead of TypeSafe's Jev 1.13 and of the open Decider models, all answering zero-shot: 0.8731 for Hunch 1.7B and 0.8535 for Hunch 0.6B, against 0.8010 for Jev and 0.7346 for the Decider 2B.

In one measurement on one NVIDIA RTX 5090 (bf16, one request at a time, over 380 of the 400 typed-decisions test requests after 20 of warm-up, tokenisation included), the median wall-clock time per request was 78.1 ms (0.6B) and 140.6 ms (1.7B). The shared-prefix engine, FastHunch, reads each state once per request instead of once per candidate. In fp32 it changes none of the 6,000 held-out answers, and the same measurement gave 36.7 ms (0.6B) and 66.6 ms (1.7B). On a laptop (one Apple M4 Pro, MLX f16, fp32 activations, one request at a time, the machine in normal use), the measured median per request was 950.8 ms (0.6B) and 2746.4 ms (1.7B).

Every decimal result in the README, the model cards and the benchmark and format pages is listed with the file and field it comes from, and a script checks each one against that source file. The data rebuilds from public sources with published commands. Selection is disclosed, including the rule that would have kept the earlier 1.7B checkpoint. The paper sets out the method and the results.