StartLux-Decision: a probability for every option, in one pass

A distribution over options, not a sentence about them

The project description puts the idea in one line: open decision models from 0.8B to 27B, giving a calibrated probability for every option in one pass, and a short thought only when unsure. The README fills in the mechanics.

You give the model a state, which can be text, JSON or images, and a set of typed questions. The model returns a probability for every option of every question. The question types are specific: a choice among listed options, which the project calls choice, a yes or no judgement, which it calls noul, and a level on a scale, which it calls score. So the output is a set of distributions, one per question, not a single answer string.

That is the design decision that separates this from a general-purpose chat model asked to make a decision. The usual pattern is to ask for a choice in prose and then parse whatever came back, which means the caller has to guess at the answer and has no signal about how sure the model was. Here the confidence is the primary output and the label is a side effect of it.

The repository holds the inference engine and the HTTP server for both variants of the model, and the API is compatible with System One at the path /v1/systemone. The weights themselves are not in this repository. They are published on Hugging Face under the startlux-models organisation, with GGUF and MLX 8-bit and 4-bit conversions for the same checkpoints, and the same organisation is what the README links from its header.

The 0.6 gate decides whether the model thinks at all

There are two behaviours, and they are the reason the project ships two model sizes for every size class.

An Instant model answers in a single forward pass, with bidirectional attention over the prompt. That is the whole point of the variant: the model reads the state and the questions in one direction of attention rather than generating tokens step by step, so the cost of a decision is one pass.

An AutoThink model answers in one pass when the top probability reaches a gate, 0.6 by default, and otherwise generates a short reasoning trace and reads the answer again. So the model first produces a distribution, checks the highest probability against the gate, and only spends a second pass plus a reasoning trace on the questions where the first pass was not confident enough.

The gating behaviour is visible in the demos. The README says the rescue and launch videos send one frame a second with nine questions to the 27B AutoThink model, and that the model thinks only when its top probability is below the 0.6 gate. That is the interesting property of the design: the reasoning budget is allocated per question rather than per request, so a video analysis where most questions are obvious does not pay for reasoning on the obvious ones.

The gate is a threshold on a probability the model reports about itself, so its quality depends on that probability being calibrated rather than merely confident. The word calibrated in the project description is doing real work there, and the leaderboard breakdown the README publishes separates a public benchmark score from private tests of the same skills, which is the kind of split that tells you whether the confidence numbers transfer.

The engine and the server are here, the weights are on Hugging Face

This repository is the inference side of the project. The README says it contains the inference engine and HTTP server for both variants, and the package on PyPI is named startlux-decide, with the description of it being the inference engine and server for the StartLux-Decision models.

The packaging is plain setuptools with a small dependency list, which tells you that the heavy machinery is optional and comes from the backend you choose:

[build-system]
requires = ["setuptools>=64"]
build-backend = "setuptools.build_meta"

dependencies = [
    "aiohttp>=3.9",          # the server and the HTTP engines
    "transformers>=5.6",     # the model folder's tokenizer and chat template
]

Two dependencies for the base install, and the comments explain both. aiohttp serves the HTTP API and drives the HTTP-based engines, and transformers is used for the model folder's tokenizer and chat template rather than for inference. The model class in the classifiers is Beta, and the package targets Python 3.9 and above, so it is not tied to a recent interpreter.

The documentation lives beside the code. There is a docs/ directory with an api.md page linked from the README header, along with a blog at decision.startlux.com, a technical report on arXiv as 2610.17309, and the models on Hugging Face. The examples directory holds batch.py, client.py, image_request.py and request.sh, which is where the shape of a request and of a batch call is meant to be read.

The extras pin the backends to exact versions

Three backends are supported, and the optional dependency groups encode what each one needs, including two version pins that are there for a reason:

[project.optional-dependencies]
vllm = ["vllm==0.31.0"]                              # the vLLM plugin is validated on 0.31.0 and on 0.19.1 (the release runs)
transformers = ["torch>=2.4", "transformers>=5.8,<5.9"]  # the bidirectional read-out reproduces transformers 5.8
llamacpp = []                                        # llama-server is a separate program (llama.cpp)
mlx = ["mlx-vlm>=0.7.6"]                              

The vLLM pin is exact, and the comment says the plugin is validated on 0.31.0 and on 0.19.1, with the release running on the latter. The transformers group is a range, torch>=2.4 with transformers>=5.8,<5.9, and its comment gives the reason: the bidirectional read-out reproduces transformers 5.8. In other words, a specific transformers release is what the one-pass read-out depends on, and an older one would not reproduce the same behaviour.

The llamacpp group is empty on purpose, because llama-server is a separate program rather than a library this package imports. The README lists llama.cpp among the backends alongside vLLM and MLX, and the models table links GGUF conversions for every checkpoint, which is the format llama.cpp consumes.

MLX gets mlx-vlm>=0.7.6, and the model table offers MLX 8-bit and 4-bit conversions alongside the GGUF ones. So the practical choice of a backend is a choice of runtime and of quantisation, and the same checkpoint can be run on a workstation with a GPU, on an Apple machine through MLX, or on a CPU through llama.cpp.

The demos are one request per step, not a long agent loop

The README's demo table is the most concrete evidence of what the models are for, and the pattern across all six is the same: a step of a longer task is expressed as typed questions in a single request.

In the chess run, the model with White checkmates Jev 1.13 on move 19 of a Scotch Game, and the caption notes that neither side searches. In the Super Mario Bros. run it clears World 1-1. In the StarCraft II run it makes the strategic calls for a Terran bot and beats the built-in Hard AI, which is the one demo where the model is making decisions for something else. JevBall has it making the decisions for a football team in real time.

The README states the protocol: in the chess and game runs, every step is one request with typed questions, answered by StartLux-Decision-v1-27B, the first release, in one pass. So the model is not running a tool loop with a chain of thought for its own reasons. It is being asked a batch of typed questions per step and answering all of them at once.

The two video runs are the same idea with perception attached. The Coast Guard helicopter rescue clip calls each stage of a hoist rescue in Hurricane Harvey, one frame a second, and the Artemis I clip follows the night launch, calls liftoff and tells the camera when to tilt up. Those runs use the 27B AutoThink model on bamboonode.dev, which the README links as free unlimited use, and the model thinks only when its top probability is below the gate.

The footage is credited to the U.S. Coast Guard and NASA as public domain, with no endorsement implied, and the faces of the people being rescued are blurred. The harnesses for computer use and chess are in the v1/demos directory, and v1/README.md describes each one, so the request formats are inspectable rather than described.

Reading the leaderboard numbers without over-reading them

The release notes are specific about what was measured. On 2026-10-16, StartLux-Decision v1.1 27B Instant ranked first of 174 entries on the Decision Index 0.3.2 leaderboard on Hugging Face, with a Full score of 69.12, and it was also first on each of three parts: the public benchmarks at 72.88, the private tests of the same skills at 64.82, and the private tasks from new domains at 61.41.

That third part is the one that matters for a reader deciding whether to use the model, because private tasks from new domains are the closest thing in the leaderboard to a generalisation test, and they are the lowest of the three numbers for the model that leads the board. A gap of about eleven points between the public benchmarks and the new-domain tasks is exactly the kind of gap that suggests the leaderboard average is not a safe proxy for a specific workload.

The model table in the README carries a different set of figures, which are the Decision Index 0.3 public scores and a DecisionPivot column: 27B AutoThink at 73.37 and 86.9, 27B Instant at 72.83 and 75.4, 9B AutoThink at 70.45 and 59.9, 9B Instant at 69.96 and 47.5, 4B AutoThink at 68.21 and 59.9, and 4B Instant at 67.88 and 41.5. The table's public score for the 27B Instant and the release note's Full score of 69.12 are different measurements, so they should not be quoted as the same number.

The gap that the table does show is between the two behaviours, and it is not a gap in the public score. The AutoThink models are consistently ahead on DecisionPivot, and the 9B AutoThink scores 70.45 against the 27B Instant's 72.83 on the public column, which is the practical argument for the gated design: a smaller model that thinks when it is unsure can land near a larger model that never thinks.

The technical report on arXiv as 2610.17309 is where the method and the evaluation are described, and it is the right document to read before treating any of these numbers as a prediction of performance on your own task.

What is in the repository, and what a project inherits with it

The top-level listing is small and tells you the shape of the project: docs/, examples/, patches/, startlux_decide/ for the package itself, tests/, a v1/ directory for the first release with its media and demos, and the usual set of project files including CHANGELOG.md, CONTRIBUTING.md, CITATION.cff, SECURITY.md and the Apache-2.0 LICENSE.

The release recorded for the package is v1.1.0, published on 2026-10-14, with the last push to the repository on 2026-10-17. The repository is not archived, and the classifier in the manifest says Development Status :: 4 - Beta, so the engine is early even though the leaderboard position is not.

Two things a project inherits are worth naming. The first is the version pinning described above, where the vLLM plugin is validated against two specific releases and the transformers range exists to reproduce one specific bidirectional read-out, so a dependency bump is a compatibility event rather than a routine upgrade. The second is the split between code and weights: this repository is the engine and the server, the checkpoints live on Hugging Face, and the demo videos need a hosted endpoint, since the rescue and launch runs are described as running on bamboonode.dev.

There is also an operational assumption baked into the API shape. The endpoint is /v1/systemone, described as compatible with System One, so an existing client for that API can talk to a local server, and that is the migration path for anyone already using a decision API of that kind. What a project should not do is assume the leaderboard position transfers to a domain the private new-domain tasks did not cover.

Editorial conclusion

Adopt StartLux-Decision when the thing your application needs is a distribution over options rather than a paragraph of text, because the models are trained to emit a probability for every option of every typed question, which is something a general chat model asked to pick one does not give you. Do not adopt it for open-ended generation, and do not assume the Instant variant is enough: the AutoThink gate at 0.6 is the mechanism that makes the model spend compute only where it is unsure. Before you build on it, read docs/api.md for the request format, check the backend extras in pyproject.toml because the vLLM and transformers versions are pinned for a reason, and read the arXiv technical report 2610.17309 before treating the leaderboard ranking as a claim about your own task.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. StartLuxLabs/StartLux-Decision on GitHub