DEV Community: Mark Marosi

decider: one forward pass, typed decisions, calibrated probabilities

Mark Marosi — Tue, 22 Sep 2026 12:11:22 +0000

decider is a language model that does not generate text. It reads a state and a set of typed questions and returns, from one forward pass, a probability distribution for every question. There is no decoding, no parsing, and no output outside the options you defined.

This post is what it does, how it is built, what the two public leaderboards say about it, and where it fails.

The interface

A typed decision is a question with a fixed answer set. Three kinds:

Choice over 2 to 255 named options.
Score over 2 to 10 described levels.
Noul, the probability that the answer is yes.

You pass a state (any JSON) and a dictionary of questions. You get back, per question, the chosen option, its confidence, and the full distribution.

pip install decider-ai

from decider.infer import Decider
d = Decider("Mapika/decider-2b")     # one CUDA GPU, bf16, about 4 GB

d.system_one(
    {"ticket": {"messages": [{"from": "customer", "text": "I was charged twice for order A-104. Please refund the duplicate."}]},
     "refund_policy": "Duplicate charges are eligible for a refund."},
    {"department": {"type": "choice", "instructions": "Which team should handle this?",
                    "criteria": {"returns": "Exchanges, refunds, wrong or damaged items",
                                 "billing": {"what": "Charges, invoices", "not_for": "delivery"},
                                 "other": None}},
     "refund_requested": {"type": "noul", "instructions": "Does `ticket.messages[0].text` request a refund?"},
     "frustration": {"type": "score", "instructions": "How frustrated is the customer?",
                     "criteria": ["calm", "frustrated", "very frustrated"]}})
# department: billing 0.56 (returns 0.44, other 0.00)
# refund_requested: 0.99
# frustration: level 1 of 3, 0.55

The plain form is d.decide(state, [{"question": ..., "options": [...]}]). There is an HTTP server with the same wire format as TypeSafe's Jev API, so their SDKs work against a local decider unchanged.

How it works

Every question is rendered into the prompt with lettered options and an answer slot. The model is run once. At each answer slot the logits of the option letters are read, divided by a fitted temperature, and passed through a softmax. That is the whole readout: the distribution is the model's own next-token belief over the letters, nothing is sampled and nothing is parsed.

Because the readout is a single position in one forward pass, the cost of a decision is the cost of a prefill. On one B300 in bf16, batch of one, no CUDA graphs and no compilation:

model	median per decision
decider-2b	18 ms
decider-35b-a3b (3B active)	41 ms

The CUDA-graph engine the package uses by default is faster than these plain numbers.

The models

All weights are on the Hub under Apache 2.0.

model	base	trained how
decider-0.8b	Qwen3.5-0.8B-Base	supervised
decider-2b (v10)	Qwen3.5-2B-Base	supervised, then calibration-aware RL on live browser tasks and exact games
decider-2b-vision	Qwen3.5-2B vision-language	supervised on image questions
decider-35b-a3b	Qwen3.5-35B-A3B-Base	supervised, routed experts frozen, Muon on the block matrices

The training mixture is public datasets plus questions labelled by a local 27B teacher. Nothing was distilled from Jev. The mixture, the trainer and the evaluation code are in the repository; the recipe runs on one GPU for the small models.

A result we did not plan for: the 35B's text weights loaded onto the vision-language version of its base answer image questions zero-shot. On 71 held-out image questions from The Cauldron it picks the gold answer 91.5% of the time, against 87.3% for the purpose-trained decider-2b-vision on the same rows.

What the leaderboards say

Two third-party leaderboards rank this model class. We did not run either; the numbers are theirs.

Decision Index (edition 0.1, 22 September 2026, by multimodalart) runs every open reproduction of Jev over the same 132,422 requests on one RTX PRO 6000, with unanswered requests counted as wrong. Its score is the mean of five capability areas. decider-35b-a3b is fourth at 54.3, behind Jev at 59.5 and two zero-training wrappers on stock models at 55.7 and 55.6. The gap is knowledge and reasoning: GPQA, GSM8K, CRUXEval and MMLU.

The index also reports calibration: expected calibration error over ten confidence bins on 33 benchmarks, where confidence is the probability placed on the chosen option.

entry	calibration error (points)	wrong at 95%+ confidence
decider-35b-a3b	3.1	0.4%
jevfire (stock Qwen3.8-27B)	6.3	1.5%
Jev 1.13.0	6.5	2.0%
decider-2b	8.8	0.9%

decider-35b-a3b is the best-calibrated entry of the 32, Jev included. Its mean confidence is 0.673 and its accuracy on the same answers 0.675. Calibration is a readout on the site, not part of the score; a model can be well calibrated and wrong.

JevBench (read 21 September 2026) scores four axes. decider-35b-a3b is tenth of 36 at 68.9, pulled down by the cost axis; decider-2b is twenty-first at 64.6, pulled down by calibration on the hard tier.

Limits, stated plainly

One pass cannot do multi-step arithmetic. There is no chain of thought, so GSM8K-type items and multi-hop chains are out of reach. Split such a judgment into several questions.
Calibration on hard items is the weak axis of the 2B. Its top-label calibration error on JevBench's hard items is 0.30. The 35B's is 0.15.
Knowledge-heavy multiple choice. The 2B improves little over its base on MMLU; the 35B closes part of the gap at three to four times the cost.
Games are not solved zero-shot. The released models do not play Tetris, Breakout or Space Invaders from a text state; they sit at random level. The RL stage moved probability mass on exact games, not win rates.
Rules written into the question are not followed at this size. A convention has to be in the training data.
English only.

The full measurement tables, including the regressions between versions, are in docs/RESULTS.md and docs/CHANGELOG.md in the repository.

What is next

The base model sets the knowledge score. Under our readout, stock Qwen3.6-27B and Gemma-4-26B-A4B-it both read above our trained 35B on a sample of the index, so the next series will start from post-trained bases, keep the readout and the calibration, and train only where training beats the stock model, which on our measurements is the 2B and 4B sizes.

Code and docs: https://github.com/Mapika/decider
Weights: https://huggingface.co/Mapika
Package: pip install decider-ai

This is an independent project, not affiliated with or endorsed by TypeSafe AI.

I replaced lsof, ss, and netstat with a single Rust binary

Mark Marosi — Sat, 04 Apr 2026 10:51:53 +0000

The problem

Every developer has been here: something is hogging port 3000 and you need to find out what.

On Linux you try ss -tlnp | grep 3000. On macOS it's lsof -i :3000. On Windows... good luck. Each gives different output, different flags, and none of them tell you how long the process has been running, how much memory it's eating, or whether it's a Docker container.

I got tired of this. So I built portview.

One command, everything you need

$ portview

That's it. Every listening port, the process behind it, PID, user, uptime, memory usage, and the full command -- in a colored table. Cross-platform. ~1.3 MB single binary. Zero runtime dependencies.

PORT  PROTO  PID    USER   PROCESS   UPTIME   MEM     COMMAND
3000  TCP    48291  mark   node      3h 12m   248 MB  next dev
5432  TCP    1203   pg     postgres  14d 2h   38 MB   /usr/lib/postgresql/16/bin/postgres
6379  TCP    1198   redis  redis     14d 2h   12 MB   redis-server *:6379
8080  TCP    51002  mark   python3   22m      45 MB   uvicorn main:app --port 8080

No parsing lsof output through awk. No remembering whether it's -tlnp or -tulpn. Just portview.

But I didn't stop there

A port viewer that just lists ports isn't worth writing about. Here's what makes portview different:

Interactive TUI with tree view

portview watch opens a live-refreshing TUI. Navigate with j/k, press Enter to inspect a port in detail (full command, working directory, child processes, open connections), press d to kill it.

Press t to toggle tree view -- it groups child processes under their parents so you can see which workers belong to which master process:

PROCESS
node
├── node (worker)
├── node (worker)
└── node (worker)
postgres
└── postgres: autovacuum

Docker as a first-class citizen

portview watch --docker shows Docker containers as rows in the table. No more running docker ps in a separate terminal and cross-referencing ports. Press d on a container row to Stop, Restart, or tail Logs.

portview doctor

This is my favorite feature. portview doctor runs five diagnostic checks on your ports:

$ portview doctor
  ✓ No port conflicts
  ✗ postgres is listening on 0.0.0.0:5432 -- consider binding to 127.0.0.1
  ✓ No Docker-host conflicts
  ✓ No stale connections
  ✓ No high-resource listeners

It catches: port conflicts (two processes fighting over the same port), databases exposed on all interfaces, Docker port collisions with host processes, TIME_WAIT/CLOSE_WAIT pileups, and memory hogs. Use portview doctor --json with exit code 1 on errors for CI.

SSH remote mode

portview ssh user@server          # scan remote ports
portview ssh user@server watch    # full remote TUI
portview ssh user@server doctor   # remote diagnostics

It shells out to your system ssh binary (inherits your config, keys, ProxyJump, everything), runs portview --json on the remote host, and renders the output locally. Kill actions in the remote TUI are forwarded over SSH. No agents, no daemons, no new ports to open.

How it works

No shelling out to lsof or ss. portview reads directly from the OS:

Linux: Parses /proc/net/tcp, maps inodes to PIDs via /proc/*/fd/, reads process metadata from /proc/<pid>/status and /proc/<pid>/stat
macOS: Uses libproc FFI (proc_listpids, proc_pidfdinfo, proc_pidinfo)
Windows: Uses iphlpapi (GetExtendedTcpTable) and kernel32 (CreateToolhelp32Snapshot, GetProcessTimes)

This is why it's fast -- there's no subprocess overhead.

Install

curl -fsSL https://raw.githubusercontent.com/mapika/portview/main/install.sh | sh   # Linux/macOS
brew install mapika/tap/portview                                                      # Homebrew
cargo install portview                                                                # Cargo

Or grab a binary from the releases page.

What's next

The codebase is ~6K lines of Rust. MIT licensed. Contributions welcome.

If you've ever been frustrated by lsof, give it a try and let me know what you think: github.com/Mapika/portview