Strands Decider 2B makes local decisions in a median of about 115 ms on an RTX 3090

Teams that plan to ship it should check the GitHub repo and Hugging Face model card before treating the weights as cleared for commercial use. The model arrived one day after OpenAI's Decisions API page listed the API as in public beta. It belongs to the same class as TypeSafe AI's Jev, which the post credits with drawing attention to these models earlier in the month. The engineering question is whether a 2B model on hardware you already own can take over the cheap, frequent decisions in an agent loop that would otherwise go to a hosted endpoint.

Decision models do not generate free text. They pick from a fixed set of options or assign simple numerical scores, such as a value between 0 and 1. The post says they are faster and more capable at a given size, always return one of the supplied options, give each decision a reliability score, and make it efficient to ask several questions about the same prompt. The cost of that single parallel pass is that they are significantly worse than reasoning models at complex problems. They are also unsuited to coding, chatbots and document summarization.

The architecture starts from a pre-trained Qwen3.5-2B torso. The LM head is removed and replaced with a pointer head that scores the hidden state at each option position against the hidden state at the <answer> position. The torso is fine-tuned with a rank-16 LoRA adapter. The released model is v19, published as strands-decider-2B-hobson-v19, and it is the second major architecture iteration. The team found that an earlier slot head performed significantly worse.

The team measures accuracy on JevBench's public set and calibration with the Brier score on the same set. It reports the model as 3rd of 33 in the 2B class, and 1st of 30 when models just over 2B are excluded. It answers 100% of the easy tasks on JevBench correctly. The post does not give absolute accuracy or Brier numbers, does not identify the 32 other models, and does not report hard-task results. A chart shows both metrics improving across versions, but the text does not state the values.

Without a hard-task number, there is no direct way to compare this model with Jev on difficult decisions. The supported reading is that it ranks near the top among small models. The team positions it for the easier, rote decisions in an agent and says these problems map well to some of the easier ones people tackle with agents.

The team reports a median local decision time of around 115 ms. The graphed results come from a local Nvidia RTX 3090, and small tasks on an M3 MacBook take around 153 ms at the median. Latency rises approximately linearly with task size in tokens. The published latency chart was measured on v18, not the released v19, and the post reports medians only, with no p90 or p99. The team says it has ideas for improving latency, especially for reducing the floor.

Hardware choice changes these numbers a lot. One Hacker News commenter ran the model on an M3 Mac inside a Docker container on CPU only. That setup reported 1732.17 ms for a noul question with 86 input tokens, an order of magnitude slower than the RTX 3090 median. The commenter said optimizing for MLX instead of the Docker wrapper would leave much more room to improve, and the 115 ms figure should be read as a GPU number.

The quickest path is the strands-decider CLI. The example below is from the release post. For a payouts complaint it returned billing with a confidence of 0.768. The option scores were billing 0.845, retail 0.091 and sales 0.064.

The repo's examples/strands/ directory shows the model acting as a pre-tool-call check. An InterventionHandler with a before_tool_call method asks two Decider.noul questions about a proposed get_weather call: are the argument values grounded in what the user said, and is the call premature. A few lines of Python turn the predictions into a typed action: Proceed, Deny, Confirm, which stops to ask a person, or Guide, which hands the model back its turn with feedback. The agent and the decision model run locally, and the main LLM is the default from Amazon Bedrock. The team says the questions, threshold and policy were picked by hand and are an illustration, not a recommendation.

The post lists early uses: model routing, tool selection, evaluations, guardrails, memory, context management and policy classification. It also describes hybrid agents that send the hardest decisions to an LLM and the rote ones to a decision model to reduce cost and latency. The team says you can use, and even train, the model on hardware you already have.

The OpenAI material covered here shows only that the Decisions API is in public beta and is listed beside the Responses API under core concepts in the docs; its pricing, latency, model size, accuracy and request schema are not covered. A direct comparison on cost, speed or quality is therefore not possible here.

One naming difference may matter in code. According to one Hacker News commenter, OpenAI's API calls binary questions predicates, while the Strands model uses the noul type, and another commenter asked whether that name was copied from Jev's API. If the schemas differ, swapping one for the other would need an adapter layer, not just a change of endpoint. The release post says frontier LLM inference APIs do not offer high-quality reliability scores. Whether OpenAI's Decisions API returns calibrated confidences is not covered here.

Four gaps decide whether this replaces a hosted call in production. First, the post does not name the licence. Second, it gives no absolute JevBench accuracy, Brier or hard-task figures. Third, it does not report tail latency, and the latency chart covers v18 rather than v19. Fourth, nothing covered here about the OpenAI Decisions API gives a benchmark to compare against, and the Strands team says only that it is working on libraries for decision model integration.