Bottom line up front
October 2026 brought a cluster of small models built to return a structured decision - a typed answer, in some cases with a probability attached - rather than generated prose. Cloudflare released two decision models post-trained from open bases, and Amazon's labs released a two-billion-parameter decision model with its weights, training data, and scripts. The category is new enough that published comparisons are scarce, so the useful question is not which one is best but whether the slot fits your workload at all.
A different output contract
A decision model is trained to return an answer from a defined set rather than to compose prose. A third-party tracker of October 2026 releases describes Cloudflare's pair as decision models that produce typed answers with probabilities and no generated text, post-trained from open-weight bases and able to read text, JSON, images, and video. The same tracker records Amazon's labs releasing a two-billion-parameter decision model intended to run locally on CPU or GPU, with weights, training data, and training scripts published.
The output contract is what makes the category distinct. A model that returns a class and a confidence is a different engineering object from one that returns a paragraph, even when both are built from similar bases. It changes how you evaluate it, how you integrate it, and what a failure looks like.
- Record whether the model returns a typed answer, a probability, or prose.
- Note the input modalities the vendor documents, which differ across releases.
- Record whether the weights and training data are published, as that differs by vendor.
The slot: a cheap check before an action
The natural use is a gate. A routing decision, a triage decision, a classification that determines which downstream path to take, or a validation step that decides whether output is acceptable enough to pass on. In each case the output is a small, bounded choice, and the cost of being wrong is low because a human or a larger model handles the exception.
That is also where the risk sits. A decision model's probability is a model output, not a calibrated guarantee, and calibration is exactly the kind of claim that requires evaluation on your own data before it can be relied on. Until you have measured it, treat the number as an ordering signal rather than a confidence you can threshold on.
- Identify decisions in your workflow that are bounded, frequent, and cheap to get wrong.
- Define the exception path before the gate, not after.
- Measure calibration on your own data before thresholding on the probability.
Why the size matters
The releases in this category are small by frontier standards - one tracker records 27B and 9B for one vendor's pair, and 2B for another's. At that scale, local deployment on CPU or modest GPU becomes realistic, which changes the economics: the inference cost is your hardware rather than a per-token bill, and the data path stays inside your infrastructure.
That is the same trade the self-hosting framework in this series describes, and it is worth applying here: open weights establish the permission, but the practical questions are hardware, serving stack, and whether the model's licence permits your use. For a small model those questions are much easier to answer than for a frontier one.
- Check whether the weights, training data, and scripts are all published, not just the weights.
- Confirm the licence for the checkpoint you intend to run.
- Estimate whether local deployment is realistic at your volume.
How to evaluate when there is no comparison table
In a new category there is no consensus benchmark and no established leaderboard, which removes the shortcut of picking the top entry. What remains is the same bounded protocol this series recommends throughout: pick a decision your workflow actually makes, define the correct answer, run a held-out set of real examples, and record accuracy by class rather than in aggregate.
Aggregate accuracy hides the failure mode that matters most - the class you care about being confused with the one next to it. Record the confusion pattern, not just the percentage, and decide whether the residual error is one your exception path can absorb. That is the whole evaluation, and it is one you can run yourself in an afternoon.
- Pick a real decision your workflow already makes, with known correct answers.
- Run a held-out set and record accuracy per class, not in aggregate.
- Record the confusion pattern, and decide whether the exception path absorbs it.