Strands Decider adds a typed, confidence-scored call to an agent loop

A classifier that sits between the LLM and the trained model

The Strands Decider project describes itself as a small, fast decision model for agentic AI, and the packaging metadata calls it an experimental typed classifier that produces calibrated yes or no, choice and score answers from an LLM torso with a pointer readout.

The category it belongs to is described as a system one model. The contrast drawn in the README is with an LLM, which can generate arbitrary text. A decision model instead picks between sets of options and rates things on a scale. The stated position of this class is between LLMs and traditional classification models: it responds faster than an LLM, and it does not demand the time and expertise to train that a traditional classifier does. The natural home for it is inside agentic workflows built with the Strands Agents SDK.

The mechanics behind that are worth unpacking, because the name says more than it seems. The answer comes from a pointer readout over the vocabulary of the options, which is why the tool can report a score per option rather than a free-text answer, and why a question like whether a phrase is English, Zulu or Dutch has a defined output space. The example checkpoints are named after the base model they use, strands-decider-2B-qwen3.5-v1-2610, so the size of the model is roughly two billion parameters and the family is Qwen3.5.

The claim that makes this interesting is calibration. Every decision carries a confidence. On short classification tasks it has not seen before, the README states that answers at a confidence of 0.9 or more are right about 95% of the time, and it points to evaluation/results.md for the details. Below that threshold the guidance is to confirm or ask a person. Frontier LLM inference APIs are said to expose nothing equivalent, which is the whole argument for keeping a separate small model in the loop.

Three question shapes: choice, noul and score

The CLI exposes three question types, and the differences are practical rather than theoretical.

A choice question gives a state and a set of options, and the model picks one and reports the distribution:

strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
  --state "Help! My payouts have been failing for 3 days! " \
  --choice "Which team should handle this?=billing,sales,retail"

The output names the winning option and prints a confidence, with a per-option breakdown underneath:

choice_0 -> billing (confidence 0.659)
  billing                  0.773
  sales                    0.121
  retail                   0.106

A noul question is the yes or no case, where the answer is a single number whose distance from 1 indicates the lean towards Yes:

strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
  --state "Help! My payouts have been failing for 3 days! " \
  --noul "Does this convey urgency?"

noul_0 noul = 0.858

A score question rates the state on a scale defined by its options, and here the model returns both the value and a confidence:

strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
  --state "Help! My payouts have been failing for 3 days! " \
  --score "How frustrated is the writer?=calm,frustrated,depressed"

score_0 score = 1.03 (confidence 0.509)
  0: calm                                     0.196
  1: frustrated                               0.574
  2: depressed                                0.230

One detail catches people out. The three example outputs come from the same state, and the first one shows a low confidence of 0.659 on a question the model got right, while the score question returns 0.509. A confidence that low means the answer should be confirmed rather than acted on, which is the behaviour the calibration section asks for. The README also notes that the recorded outputs were produced with --device cpu and that other devices differ in the last digits of the numbers, so these values should be read as shape examples, not as expected results.

Batching questions so the state is loaded once

The CLI accepts several questions in one invocation, and the README is explicit about why: it is more efficient, because the state only needs to be loaded for the model once.

strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
  --state "Help! My payouts have been failing for 3 days! " \
  --choice "Which team should handle this?=billing,sales,retail" \
  --noul "Does this convey urgency?" \
  --score "How frustrated is the writer?=calm,frustrated,depressed"

The combined output keeps the same per-question keys, and it is worth reading it as a single model pass with three heads rather than three independent calls:

noul_0 noul = 0.858
choice_0 -> billing (confidence 0.659)
  billing                  0.773
  sales                    0.121
  retail                   0.106
score_0 score = 1.03 (confidence 0.509)
  0: calm                                     0.196
  1: frustrated                               0.574
  2: depressed                                0.230

For an agent, that distinction is the interesting one. A workflow that needs routing and a sentiment signal from the same incoming message can ask both in a single pass instead of paying for two model loads, and the answers stay attached to the same state. The key naming convention, with a type prefix and an index, is also what the HTTP response uses, so a client can read the results of a multi-question request without parsing prose.

The server exposes one endpoint with a fixed JSON shape

The same model can run as a server, which is the mode an agent integration needs:

strands-decider serve StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --port 8000

Requests go to a single path, and the payload separates the state from the questions, with each question carrying a type and its instructions:

curl -s localhost:8000/v1/systemone \
  -H 'content-type: application/json' \
  -d '{
    "state": "Help! My payouts have been failing for 3 days!",
    "questions": {
      "is_urgent": {"type": "noul", "instructions": "Does this convey urgency?"}
    }
  }'

The response echoes the model name, returns the answers keyed by the question names the client chose, and includes a usage block with input and output token counts and a latency figure in milliseconds:

{
  "model": "strands-decider-2B-qwen3.5-v1-2610",
  "answers": {
    "is_urgent": {
      "type": "noul",
      "noul": 0.8581
    }
  },
  "usage": {
    "input_tokens": 86,
    "output_tokens": 1
  },
  "latency_ms": 489.01
}

Two properties of that response are the reason to care. The output token count is one, because the answer is a pointer readout rather than generated text, and the latency is reported in the payload, so a caller can decide whether to accept the answer or escalate without extra instrumentation. The path name, /v1/systemone, also signals that the interface is versioned and that the system one model family is expected to be addressed by name.

Devices, extras and the vision path

The model runs on several backends, and the choice is a flag rather than a separate deployment.

On an Apple-silicon Mac, the README says that --device mlx runs the model through MLX and is 1.4 to 1.6 times faster than MPS. The mlx extra that provides it ships with the next release, so until then the documented route is to install from a clone with pip install -e ".[mlx]". The cuda, mps and cpu extras name the other devices, and the inference documentation is pointed at for the environments for serving.

There is also a vision path, and the reasoning behind it is unusual. Qwen3.5-2B-Base is described as natively multimodal, and with --vision the server keeps its vision tower. A request may then carry images encoded as base64 as part of the state, and the published checkpoints, which are v1 and hobson-v21 and v19 before it, answer over them with no image training. That last point is the one to hold on to: the checkpoints were not trained for images, so the vision behaviour is inherited from the base model rather than acquired.

The install requirement for that path is specific, needing the vision extra and transformers 5.18 or later:

strands-decider serve StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --vision --port 8000
strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --state "" --image page.png \
  --noul "Is the signature block filled in?"

The second command shows the CLI form of the same capability, with a local image file and a yes or no question about it. The README also flags a limitation of the older checkpoint, noting that v19 matches an image-trained 2B decoder, and the text is cut off there, so the exact comparison is not spelled out.

What the repository shows about how the model is built

The source tree is broader than a thin inference wrapper, and that tells you how the project is organised.

At the top level there are src, training, evaluation, deploy, configs, data, docs, research, skills, tests and examples directories, along with the usual governance files, including CHANGELOG.md, SECURITY.md, CODE_OF_CONDUCT.md and THIRD_PARTY_NOTICES.md. The training directory is the important one, because the packaging comment says the corpus build and multistep converter are run as python -m training.data build and python -m training.data.multistep, and that those modules live under training rather than src, so they ship in the repository and not in the wheel. The train extra exists so that a checkout can install them, and the comment is explicit that the extra is not for consumers installing from the Hub.

The evaluation directory holds the results the calibration claim depends on, with evaluation/results.md as the anchor point. The skills and examples directories, including examples/strands, point at the intended integration, the Strands Agents SDK. The deploy directory is where the serving path is configured, and configs holds the experiment configurations.

That structure also explains the dependency set. The base install pulls in torch, transformers with an upper bound below 6, peft and accelerate for the parameter-efficient fine-tuning that produced the checkpoints, huggingface_hub for the Hub distribution, pydantic and typer and rich for the CLI and validation, pyyaml for configs, fastapi and uvicorn for the server, and numpy and safetensors for the weights.

The mlx extra is worth reading closely, because it documents a real constraint. The mlx-lm dependency is capped below 0.33, and the comment explains that the backend uses the Qwen3.5 module layout and the prompt cache classes, which are internals of that library and can change without notice.

Apache-2.0, two releases on one day, and a young package

The licence is Apache-2.0, with the licence text in a LICENSE file and the project metadata declaring license = "Apache-2.0". It also ships THIRD_PARTY_NOTICES.md, which matters for a project that distributes model weights alongside code. For an organisation that has to clear a licence, this is the straightforward case: a permissive licence with the standard notice obligations and no copyleft requirement to pass on to your own code.

The release history is short. Two tags exist, v0.1.0 and v0.2.0, and both were published on 2026-10-19, the same day, with v0.2.0 named as the v1 Strands Decider Models release. The last push to the repository was also on 2026-10-19. In other words, this is a young project with a single meaningful release day so far.

The version numbers are also a warning label. Both tags are 0.x, and the package description in the metadata begins with the word experimental. The Python requirement is 3.10 or later, and the dependency floors are modern rather than conservative, with torch at 2.7 or later and transformers at 5.15 or later and below 6. That combination means a working environment needs a recent Python and a recent PyTorch stack, and it means an upgrade of transformers within the allowed range could still change behaviour in a project this young.

The practical reading is that strands-decider is a component to evaluate on your own data, with the evaluation results and the confidence thresholds as the deciding artefacts, rather than a dependency to commit to without a check.

Editorial conclusion

strands-decider fits a team building an agentic workflow on the Strands Agents SDK that needs one narrow judgement, such as routing a support message to a team, made quickly and with a number attached that says how far to trust it. It is the wrong tool for open-ended generation, for questions with many valid answers, or for anything that needs the accuracy of a frontier model, since the checkpoints are 2B scale and the packaging calls the project experimental. Before adopting it, read evaluation/results.md to see how the confidence numbers behave on tasks resembling your own, check the transformers and torch floors in pyproject.toml against your environment, and confirm that the extra you need, mlx, vision or train, is installable on your platform, since the mlx dependency is capped at a tested minor version.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. strands-labs/strands-decider on GitHub