decider-2b: the Jev-class causal decision model, planned as this platform's jev-causal API

decider-2b is a 2-billion-parameter open-weight decision model published by Mapika on 16 September 2026. It appeared one day after TypeSafe AI released Jev, the closed, hosted-only model that started the decision-model class. It is built for one move: you give it a state and typed questions, each question with an explicit list of options. It returns a calibrated probability distribution over those options. It does not generate text. On this platform it is the model behind a planned lane named jev-causal. That lane is the causal fallback of a three-lane Jev-class family. The lane is written, not listed. Its row sits behind the public list. Nothing answers the alias today. No date is promised. What this page carries is the model's capability record from its own card. It also carries the wire contract the lane is designed to answer, and the self-host path that works now.

Last verified: 2026-09-25

What it is

The model card states the contract in one line: the model does not generate text. It reads a state and one or more typed questions, each with an explicit option list. It returns a probability distribution over the options. It positions itself as an open reproduction of the System One class that TypeSafe AI's Jev belongs to. That means a model you call from software when a program needs a decision. It is not a model you chat with. The identity facts, each with its owner:

The three answer types are the whole interface. A choice question supplies options. It gets back the picked option with a calibrated confidence, and the full distribution over every option. A noul question is the binary door: a probability of yes. A score question returns an expected level on a scale you define, calibrated per level. Under the hood the model does something narrower than generation. It reads letter logits at the answer slots you defined, applies a softmax, and divides by a stored temperature. That temperature is 1.30 in the version 10 release behind the eval table below. The card's current release carries a per-type temperature map instead, so pin the release you test against. The card's phrasing is worth keeping: there is no decoding, no parsing, and no output outside the options you defined. A decision model cannot wander off the menu.

One disambiguation block, because the search space for this model is polluted three ways. Jev, written with a capital J and the rest lowercase, is the product name TypeSafe AI released on 15 September 2026. It is not an acronym. JEV in all caps is Japanese encephalitis virus, the biomedical abbreviation. A medical paper on it ranks on the first page of the decision-model class query. That is why definitional questions dominate the People Also Ask box. Separately, an academic paper named DECIDER ranks on decider queries. It is about rule-controllable decoding for language models. It has nothing to do with this family. On the name's origin, the publisher's own announcement documents it. Jev is named after the nineteenth-century economist William Stanley Jevons.

The posture of this page, stated once and plainly. The platform has written this lane into its catalog plan. The plan is decider-2b at 4-bit quantization, about 1.5 GB, with the build pinned by hash. It rides the platform's chat route family through an adapter that preserves the Jev wire contract. The row sits behind the public list today. Nothing answers the alias jev-causal. The rate is set, and no listing date is promised. A listing gate comes first. The gate is a standardized decision benchmark run and a calibration check against the published numbers, with the exact release pinned by hash. Until that gate and the listing, everything below is capability and contract, and the self-host path is the working path.

Use cases

The lane profile: decisions with supplied options and a calibrated confidence attached to every answer. The hardware is small enough that the decision step is never the expensive part of your stack.

• Routing and triage in agent stacks. Which tool, which queue, which department, which tier. The card's own worked example is support routing: a customer writes that their card was charged twice, and the model returns billing over technical support and sales with the distribution attached. The pattern is catching on as an architecture: a decision model picks the tool, and the chat model fills in the arguments.
• Approval and guardrail gates. A noul question is a calibrated yes-or-no at a checkpoint: does this pass review, does this claim meet the policy, should this action proceed. The confidence value gives you a threshold to tune, which a yes from a chat model does not.
• Wide option sets out of the box. This is the lane's reason to exist next to the encoder flagship. Community reads of the published head-to-head agree the encoder route wins in its trained domains and loses coverage on wide option sets; a causal model that reads the state like text holds those shapes.
• Batch backfills over longer state. Classification jobs where the context is a paragraph of policy or a ticket thread rather than a single sentence: the causal route reads the state as text, so longer state costs tokens, not a redesign.
• Escalation lanes for existing classifiers. If you already run a fast encoder classifier, this lane is the second tier: the passes the encoder cannot hold get routed here, and the rest never pay for the bigger reader.

The three-lane Jev-class family

This platform's Jev-class catalog is three lanes over one wire contract. The routing between them is stated plainly: flagship first, causal fallback, batch second opinion.

Route to the flagship first: the encoder is the faster, lighter pass. The published numbers behind that statement sit in the benchmarks section with their owners. Route to this lane when the pass needs the causal model. The triggers are an option set too wide for the encoder out of the box, state longer than an encoder window, or criteria that compose. Route to the batch lane for offline volume where its encoder-class economics fit. One scope note on the model family itself: Mapika's decider line has more variants than this lane loads, a 0.8b, a vision sibling, a 4b, and a 35B mixture-of-experts. This lane carries the 2b only, with the variant detail in the FAQ below. All three lanes are planned, and none is listed. The classification category page carries the family picture as the catalog grows.

Self-host: GGUF mirrors and the pinned-hash discipline

Apache 2.0 means the local road is fully open. You can download, run, fine-tune, and ship the output commercially. The full-precision weights are about 3.5 GB in bf16. For small hardware, 4-bit-class GGUF builds land around 1.5 GB and run through llama.cpp. Its OpenAI-compatible server exposes the same chat endpoint shape. This platform's lane rides that shape. The GGUF format documentation covers the container format and the quantization types, including the 4-bit class used here. Two community mirrors publish decider-2b GGUF files today. One is cosetoenor/decider-2b-GGUF, whose file list carries f16, iq4_nl, and q8_0 builds. The other is DreamBlooms/decider-2b-GGUF. The card also documents a native python entry point, a decide call that takes the state and the question list and returns the typed answers. That one serves from the full-precision weights.

The discipline that separates a self-host you can trust from mirror roulette: pin what you run. The mirrors are third-party re-uploads. Anyone can replace a file under the same name. Record the exact hash of the weights file you validated. Record the build commit of the engine you serve with too. Verify both on every re-pull, and stop the pipeline on a mismatch. This platform holds its own GGUF lanes to the same rule, engine build and weights hash pinned together. That is why the lane plan for this model names the discipline explicitly rather than trusting a tag.

API usage

The lane is designed with two doors onto one model. Both are documented here so the client work can happen before the row lands.

Door one: the platform's chat route. The stable platform contract is the OpenAI-compatible chat route: POST /v1/chat/completions on https://api.ironstratum.com/v1. It takes a Bearer key from the console in the Authorization header and the model id jev-causal. The decision rides as message content: the state and the question with its options as the user turn. That follows the same spirit the open model's own examples use. The adapter on the lane returns the typed answer: the chosen option or level, the calibrated confidence, and the distribution over your options. It does not return free text. The exact field layout of the typed answer inside the chat response publishes with the row. The route, the auth, and the model id are the stable parts. Write against them now.

Door two: the Jev-native wire contract. Jev-class clients speak a state-plus-questions shape: a state, then typed question definitions, choice with its options, noul, or score with its scale. The answer set carries one typed result per question. The model card documents a TypeSafe-compatible endpoint of exactly this shape. The lane's adapter is designed to keep that contract intact. A Jev-shaped client changes its base URL and its model name and nothing else. Wire compatibility is the product: the class standardized its contract and the open clones implement it. A hosted row that speaks it is a drop-in rather than a port.

Nothing answers under the alias today. The chat route refuses unknown model ids with a model-not-found error. That is the correct, expected answer for jev-causal until a catalog row lands. No date is attached to that event on this page.

The failure modes to know before you connect retry logic:

Metering on this lane is designed around the input token. The state and the questions you send, counted per million, draw against the platform's prepaid wallet. A request refused at the door bills nothing, and spend stops when the wallet hits zero. The next request is refused with a named error rather than billed. The starting rate is set and this page's search listing carries it; the catalog surfaces publish it the day the row joins the public list, and this page picks it up from the same source the same day.

curl

curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-causal",
    "messages": [
      {
        "role": "user",
        "content": "State: a customer writes that their card was charged twice for the same purchase. Question: which department should handle this? Options: billing, technical support, sales."
      }
    ]
  }'

The user turn carries the state, the question, and the options, following the model's own worked example. The typed answer comes back through the adapter.

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    json={
        "model": "jev-causal",
        "messages": [
            {
                "role": "user",
                "content": (
                    "State: a customer writes that their card was charged "
                    "twice for the same purchase. Question: which department "
                    "should handle this? Options: billing, technical support, "
                    "sales."
                ),
            }
        ],
    },
    timeout=60,
)
resp.raise_for_status()

body = resp.json()
print(body["choices"][0]["message"]["content"])
print("usage:", body["usage"])

The usage object reports the input tokens that meter the call. Several questions can ride one request; each gets its own typed answer.

openai-sdk

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

response = client.chat.completions.create(
    model="jev-causal",
    messages=[
        {
            "role": "user",
            "content": (
                "State: a customer writes that their card was charged "
                "twice for the same purchase. Question: which department "
                "should handle this? Options: billing, technical support, "
                "sales."
            ),
        }
    ],
)

print(response.choices[0].message.content)

Code already written against the OpenAI SDK points here with two changes: the base URL and the model id. A Jev-native client changes the same two things on the wire-contract door. The API reference documents the chat route's accepted parameters in full.

Benchmarks

Three layers of evidence, each dated and each with its owner named.

The publisher's numbers. From the model card, read 2026-09-24, evaluation set version 10:

Read the table the way it was run. Everything in it is publisher-measured, on the publisher's own evaluation sets and hardware. The two rows that matter most for sizing a real deployment are the first two rows of the table. Accuracy holds from in-task to held-out with a visible drop. The calibration error roughly doubles off-distribution. That is exactly the behavior to test against your own questions before trusting a threshold. The speed rows are the publisher's own hardware numbers and say nothing about this platform's hardware. This platform publishes speed for its lanes only from its own measurements. The number must also hold.

The class context. Two other measured reference points exist in the Jev-class clone wave. Both carry their owners. Laya's published head-to-head against the hosted original reads 0.766 against 0.727 routing accuracy on 2,000 typed decisions. The latency split is 38.4 ms against roughly 400 ms. Calibration metrics are published alongside. Community coverage of that result reads it as the encoder winning in-domain and the hosted model holding wide option sets. That split is what the three-lane family above is built on. Bespoke's in-house comparison of its 9B clone against the hosted original reads 90.1 against 93.2 on 324 held-out items, with the untrained base at 66.4. Those are vendor numbers. They are published as claims to check, not as a neutral audit.

This platform's layer: nothing measured yet, and a gate before anything is claimed. The lane's listing gate is a run on the standardized decision benchmarks (JevBench and the Jev Decision Index). The exact model release is pinned by hash. The gate adds a calibration spot-check against the card's published numbers. Nothing publishes before it passes. Quality and speed claims for the hosted lane publish on this page only after that gate. They come from this platform's own measurements, with their dates. That is the same discipline every lane on the platform holds: measured, dated, owned, or not said.

Getting started

1. Join through the console's invite flow. The signup page is the door; the console holds the wallet, the keys, and the spend history. The platform runs as an invite-only beta in this phase.
2. Create one key per project. Keys revoke independently, so a leaked key costs a rotation, not the account. The wallet balance, not a per-key cap, is the spend boundary.
3. Write the client against the contract now. The tabs above are the shape the lane answers. The day a catalog row lands, the same call works with no changes; until then the alias answers model-not-found, which is the honest state, not an outage.
4. Self-host meanwhile, or watch the catalog. The GGUF path above is real today and the pinning discipline travels with it. The models index carries the catalog's current state, and the classification category page holds the family picture: the jev-fast flagship this lane falls back from, and the jev-batch encoder for offline volume.