The Model That Would Not Speak: System One AI on Your Own Machine

The Model That Would Not Speak: System One AI on Your Own Machine

At 06:16 on a Tuesday morning, a support ticket landed in front of me: "I was charged twice for September and I am cancelling on Friday unless it is refunded."

Three things have to happen to that sentence. Somebody has to decide which team owns it. Somebody has to decide how urgent it is. And somebody has to notice that the customer has just threatened to leave. On a good day, a human does all three in about four seconds and never thinks about it again.

I did what I always do now, and what almost nobody I talk to has tried yet: I handed the decision to three models that fit on my own hard drive, none of which can write a sentence. Two of them took less than a second. The smallest one got the cancellation threat wrong — said the odds were about one in four, when the customer had used the word "cancelling" — and I only knew to distrust it because the same response carried a second number that told me it was guessing.

This is the story of that morning, and of the model class behind it. Not a review of a benchmark table, but the thing I actually did: downloaded four models, ran them on a machine with no graphics card, and wrote down what they said. By the end you will be able to do the same, and you will know which of the four to reach for and which one to leave alone.

"Unstructured state in, typed probabilistic decisions out. The model reads your program’s situation once and returns a number for each answer you offered it."

Why asking a chatbot was the wrong move

Every chat model you have used — Claude, GPT, Gemini, the open Llama family — answers by writing. It generates your answer one token at a time, in prose, and then your application has to read the meaning back out of the string. You asked for a category; you got a paragraph; you wrote a regex and hoped.

That last part is where the money goes. Not the inference — the plumbing around it. The retry when the model returns prose instead of JSON. The schema validator. The twelve-line system prompt begging it to reply with one word. The quarterly afternoon where a provider quietly changes its formatting and your pipeline starts dropping decisions silently.

A decision model refuses all of it. You send a block of program state and a set of typed questions, and it returns typed answers — a chosen option, a place on a scale, or the probability that a statement is true — with probabilities attached. No prose. Nothing to parse. The model class is called System One, borrowed from Daniel Kahneman’s two-mode account of thinking: System 1 is the fast, automatic judgment you make about a face or a threat; System 2 is the slow deliberation you do about a mortgage. Your chat model is System 2. This is the other one.

TypeSafe AI — a San Francisco lab founded by Diogo Almeida, one of the researchers behind RLHF — came out of stealth with the idea on 15 September 2026 and $40 million in seed funding, and shipped Jev, the first public model of the class. The name is a nod to William Stanley Jevons, the economist who noticed that making a resource cheaper tends to increase how much of it gets used, not decrease it. The bet is that decisions become so cheap that software starts making millions of them.

Jev is closed, hosted, and excellent — and it is one of four models in this story rather than the whole story. Within three weeks of its launch, the wire format it defined had been implemented in llama.cpp and Ollama, the two most-deployed ways to run a model on your own hardware, and open models answering the identical API had appeared in every size class. (I mapped that wave in System One Goes Local (/blog/system-one-goes-local); this article is the hands-on half of that map.) That is the part that changes what you can build.

The three questions a decision model can answer

The whole interface is three question types. Everything else is bookkeeping.

| Type     | You send                                                             | You get back                                                                   |
|----------|----------------------------------------------------------------------|--------------------------------------------------------------------------------|
|  choice  |  a set of named options, each with a description of when it applies  |  the winning option, plus a probability for every option                       |
|  score   |  2 to 10 ordered levels, lowest first                                |  the expected level — which can land between two levels — plus a distribution  |
|  noul    |  a statement                                                         |  the probability the statement is true                                         |

Here is the actual request I sent that morning. It is the whole program:

{
  "model": "ggml-org/Julia-1-GGUF:Q8_0",
  "state": "I was charged twice for September and I am cancelling on Friday unless it is refunded.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "billing":   "Payments, invoices, refunds",
        "technical": "Bugs and outages",
        "sales":     "Plans and upgrades"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": ["Low", "Normal", "High", "Urgent"]
    },
    "churn": {
      "type": "noul",
      "instructions": "The customer threatens to cancel."
    }
  }
}

Three questions, answered independently, in one pass. And the answer that came back is the reason this category exists:

{
  "model": "ggml-org/Julia-1-GGUF:Q8_0",
  "answers": {
    "team":    { "type": "choice", "choice": "billing",
                 "probabilities": { "billing": 0.958, "technical": 0.017, "sales": 0.025 },
                 "confidence": 0.937 },
    "urgency": { "type": "score", "score": 1.42,
                 "legend": { "0": "Low", "1": "Normal", "2": "High", "3": "Urgent" },
                 "probabilities": { "0": 0.339, "1": 0.112, "2": 0.337, "3": 0.212 },
                 "confidence": 0.0 },
    "churn":   { "type": "noul", "noul": 0.269 }
  },
  "usage": { "input_tokens": 118, "output_tokens": 0 }
}

Read the last line twice. output_tokens: 0. The model produced no tokens at all — it read the state once and read a probability off its own internals. There is no generation step to be slow, and no text to be wrong in a way your parser cannot see.

Three verdicts are in there, and one of them is a warning. I will come back to the urgency answer, because its confidence of exactly 0.0 is the single most useful thing in the response.

Setting it up on my own machine

My workstation has no graphics card. Twelve CPU cores, 15 GB of RAM, a Linux kernel. If the setup needed a GPU I would have stopped here, and this would have been a shorter article.

It doesn’t. Everything below is real output from that machine, dated 14 October 2026.

Step one, get the runtime. llama.cpp merged decision-model support on 2 October 2026 in PR #29818, which is the entire trick: /v1/systemone is now a route in a program you may already have. The catch people hit in the first ten minutes is that the route did not exist in any older build — an older copy starts your model happily and then answers 404 page not found, which looks like a broken request and is actually a stale binary. The first build carrying the endpoint was b11361; I used b11609:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b11609/llama-b11609-bin-ubuntu-x64.tar.gz
tar xzf llama-b11609-bin-ubuntu-x64.tar.gz
./llama-b11609/llama-server --version
# version: 0.6.0-dev (build 11609, commit fcac19079)

Step two, start a model. The -hf flag pulls the weights from Hugging Face on first run and caches them, so the second start is instant. No configuration file, no flags to remember — the server recognises a decision model from metadata inside the file and switches its input and output handling on its own:

./llama-b11609/llama-server -hf ggml-org/Julia-1-GGUF:Q8_0 --port 8080

Inside ten seconds the log said this, and I have never seen a model describe itself more precisely:

init: decision model type: laya
model loaded
listening on http://127.0.0.1:8080

The metadata line output_modalities: ["decisions"] on /v1/models is the giveaway: not text, decisions.

Step three, ask. curl the endpoint with the JSON above and read your answer. That is the entire local setup — three commands, one of which is a download.

One trap worth knowing before you try this: pointing a runtime like this at an ordinary chat model does not make it a decision model. If the GGUF lacks the decision metadata, llama.cpp answers 501 This model is not a decision model — a clear error, and far better than the alternative of a chat model quietly returning prose for your /v1/systemone request and your parser silently accepting whatever came out.

The verdict: three models, one ticket

Then I did the thing that turns a demo into a decision, and ran the same ticket through three open models of very different sizes. Same machine, same questions, same words in the state field.

| Metric                           | Julia-1 (144M)  | Laya (421M)     | Kev-4B (4.2B)   |
|----------------------------------|-----------------|-----------------|-----------------|
|  Which team?                     |  billing 0.958  |  billing 0.978  |  billing 0.846  |
|  Urgency                         |  1.42, flat     |  2.46           |  2.18           |
|  Urgent share of mass            |  21%            |  71%            |  49%            |
|  "Customer threatens to cancel"  |  0.269          |  0.986          |  0.715          |
|  Latency, CPU-only               |  0.138 s        |  0.910 s        |  3.496 s        |
|  Tokens generated                |  0              |  0              |  0              |
|  Download size                   |  160 MB         |  429 MB         |  3.03 GB        |

All three route the ticket to billing, and all three are right. That much is unremarkable — it is not a hard question.

The interesting column is the fourth. The customer wrote "I am cancelling on Friday unless it is refunded." Laya answers 0.986. Kev-4B answers 0.715. Julia-1 — the 144-million-parameter model whose entire download is 160 MB — answers 0.269, which is to say it thinks the customer probably is not threatening to leave. It missed the plainest sentence in the ticket.

And here is what makes that a survivable mistake rather than a dangerous one: Laya took nine tenths of a second to answer instead of a tenth. The speed advantage of the tiny model is real, and so is the price.

The column that told me which model to trust

Look again at the urgency answer from Julia-1. Score 1.42 on a four-level scale, with 34% of the probability on Low, 34% on High, 21% on Urgent and 11% on Normal. That is a coin flip wearing a number’s clothing. And the response says so, in a field most people would skim past: "confidence": 0.0.

Confidence is a second axis, computed from the shape of the distribution rather than from the winning answer. TypeSafe documents it as a closed-form function of the probabilities, and I checked their formula against my own three measurements — (p_max − 1/n) / (1 − 1/n), where n is the number of options. It matched to twelve decimal places on all three models. When billing held 0.958 of the mass across three options, the reported confidence was 0.9366896510790688; the formula gives 0.9366896510790688 exactly.

That matters because it tells you what the number is not. Confidence is a statistic about certainty, not a probability that the answer is correct. It is the model saying "the options I was given are clearly separated" or "they are not" — and those are different questions. A model can be perfectly confident and completely wrong, and it can be hesitant and right. Use it as a gate, not as a guarantee.

Two other properties I verified, because they change how you test a system like this:

• It is deterministic. I sent the identical request three times to Julia-1 and twice to Kev-4B. Byte-identical distributions every time — 0.9577931007193792 on the nose, repeatedly. There is no sampling and no temperature; the model reads a distribution off one forward pass and takes the largest, so the same input gives the same answer and your regression tests are meaningful.
• confidence: 0.0 is the model being honest. On my flat four-level urgency question the raw value was negative and got floored at zero. A runtime that will print 0.0 rather than a flattering midpoint is more useful than one that always has an opinion.

Then I asked a question with no right answer

By now I trusted the setup and distrusted nothing. So I sent a second ticket, the kind that makes routing systems look clever in demos and foolish in production:

"Hi, quick question about my account."

Same three options. Three models, three different answers:

| Model            | Its answer  | Probability | Confidence |
|------------------|-------------|-------------|------------|
|  Julia-1 (144M)  |  sales      |  0.639      |  0.458     |
|  Laya (421M)     |  billing    |  0.598      |  0.397     |
|  Kev-4B (4.2B)   |  technical  |  0.594      |  0.391     |

Zero agreement. Every model picked a different team, and each one was reasonably sure of itself — a 64% favourite is not nothing. Only the third column tells you that all three were guessing: not one of them got past 0.46 confidence, and every distribution was spread across the options.

This is the failure that bites in production, and it is the reason I care about the confidence column more than the accuracy column. A routing layer that answers "sales" at 64% looks, to anything downstream, exactly like a routing layer that answers "billing" at 96%. If your code branches on the winning label and ignores the distribution, the vague ticket goes to a human anyway — the wrong human, with no flag raised.

There is one more honest thing to report here. The published example of this exact vague ticket gives 0.25 for Julia-1 and 0.80 for Kev-4B. I did not reproduce either figure. My numbers were 0.639 and 0.594 — and the reason is instructive rather than embarrassing: confidence is a property of the question you asked, not of the model alone. Change the words in criteria and the same model changes its mind about how sure it is. Copy a confidence threshold from a blog post and it will not transfer; measure your own.

A model that answers "sales" at 64% looks exactly like a model that answers "billing" at 96% — unless you read the distribution.

Every term in that code, explained

The glossary you need to read the JSON in this article. Nothing here is jargon for its own sake — each item is something the response above actually uses.

state — the situation to be judged. A string, a JSON object, or an array. It is the only thing the model reads, and everything it "knows" about your world is in it. Nothing outside the state is consulted.

questions — an object keyed by the names you choose. Your keys never reach the model; they exist so you can find the answers again. The same keys come back in answers, which is why a mismatched key returns null and looks like the model having no opinion.

instructions — the question in words. criteria — the descriptions of your options. These are not decoration. The descriptions are the rubric the model reasons with, which is why "technical": "Bugs and outages" outperforms "technical": "Technical things".

choice / score / noul — the three types. The odd name is worth knowing: a noul is not a boolean. It is a probability between 0 and 1, so 0.5 means "genuinely 50/50", not "medium".

probabilities — a full distribution over every option you supplied, summing to 1. This is the field to log. The winner is a decision; the distribution is the evidence for it.

confidence — a statistic computed from that distribution, not a separate estimate. See above for what it does and does not mean.

legend — for score questions, the map from level number back to your level description, so 2.46 can be read as "between High and Urgent". The expected level can land between two levels, because it is probability-weighted rather than a pick.

usage — input_tokens is what you sent; output_tokens is what it generated, which is always zero for these models.

Forward pass — one read of the input through the network. A chat model does one forward pass per output token, which is why it takes hundreds of milliseconds to start answering. A decision model does one pass in total.

Non-autoregressive — "not writing itself out word by word". The answer is read off the model’s internal state rather than produced as a sequence, which is what makes output_tokens: 0 possible.

Encoder vs decoder — the two network shapes behind these models. Laya is an encoder (ModernBERT) and answers in milliseconds; Kev is a decoder (Qwen3.5) and reads longer documents more capably. Both answer the identical API, so the difference is a runtime choice rather than a code change.

GGUF — the file format llama.cpp loads. A single file holding the weights plus metadata, which is how the server knows your file is a decision model and not a chat model.

Quantisation, and names like Q8_0, Q4_K_M, BF16 — how precisely each weight is stored. BF16 is the original precision, Q8_0 is roughly 8 bits per weight, Q4_K_M roughly 4. Smaller means a smaller download and faster answers on a slow machine, at some cost in accuracy. The same model at different quantisations is a different trade-off, not a different model.

mmap — memory-mapping the weights file, which is why a 3 GB model loaded on a machine with half a gigabyte free. The file is read as it is needed rather than copied into RAM.

Context window — the maximum input the model can see, in tokens. n_ctx_train: 262144 on Kev-4B is the training context; what you load is set by your server (I used 2,048). Tokens are roughly three-quarters of an English word — not characters.

Softmax / argmax — the softmax turns the model’s raw internal scores into a distribution summing to 1; the argmax picks the largest. That pair is the whole "decision" step, and it is why the output is deterministic.

Calibration, and ECE — calibration means that among all the times a model says 0.8, it is right about 80% of the time. ECE (expected calibration error) is how far off that promise is on average; lower is better. TypeSafe trained Jev specifically for this, with a method it calls RLCD — Reinforcement Learning for Calibrated Decisions — scored under a rule where reporting honest probabilities is the only winning strategy.

LoRA / adapter / decision head — the cheap way to build one of these. Kev is a small trained add-on (a LoRA adapter) plus a "head": a tiny pair of layers that scores each of your options and produces the distribution, bolted onto a frozen base model. The head is the part that makes it a decision model instead of a chatbot.

Wire format / base URL — the shape of the request and where it is sent. This is the quiet revolution in this category: Jev, llama.cpp, Ollama, ollajev, ollaya and the open models all speak the same /v1/systemone shape, so switching between a hosted frontier model and a file on your disk is, in most cases, changing one URL.

Doing the same thing with Ollama

If you already run Ollama, you can skip the tarball — with one version gate.

Ollama shipped its own /v1/systemone in v0.35.0 on 28 September 2026, wire-compatible with Jev, and its catalogue of decision models has been growing since. The workflow will feel familiar:

ollama pull nimble
curl http://localhost:11434/v1/systemone -H 'Content-Type: application/json' -d '{
  "model": "nimble",
  "state": "I was charged twice. Please refund the extra payment.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": { "billing": "Payments and refunds", "technical": "Bugs or integrations" }
    }
  }
}'

Note the port: Ollama listens on 11434, llama-server on 8080. They do not collide, so you can run both and compare on the same ticket.

On the version gate, I can show you the failure rather than describe it. My own machine had Ollama 0.33.0 installed. The chat endpoint answered normally; the decision endpoint did this:

POST http://127.0.0.1:11434/v1/systemone  ->  404 page not found

That 404 is not a malformed request. It is a version. Decision support arrived in 0.35.0, and the catalogue has since grown to a decision section with eight models in it — nimble, nimble-v3, tev1, clef, clef-flash, laya, strands-decider and kev. If you want Kev through Ollama specifically, its package asks for 0.40.4 or later.

Two more things worth knowing about the Ollama route. Its limits are tighter than llama.cpp’s: choice and score questions take 2 to 26 options (255 is the general ceiling), and a request without images must fit in 64 KiB. And Ollama does not certify third-party GGUF decision files. Its docs describe the mechanism — a CAPABILITY decision line in a Modelfile — but name only its own models, so pointing Ollama at, say, the ggml-org Laya GGUF is an unsupported experiment rather than a documented path. That is what the documentation says, which is different from what the code can do.

There is a third option if you would rather run neither: Kev ships its own server, which speaks the same API and takes a Hugging Face repo id directly:

uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8009

The server binds to 127.0.0.1 and is open unless you set KEV_API_KEY. One gotcha worth copying down: the code’s default port is 8008; 8009 is only what the project’s own examples pass explicitly. Copy a config from the docs without the flag and you will be pointing at a port nothing is listening on — and because the wire format is identical everywhere, the wrong port is the single most likely reason your first decision fails.

Kev, Nimble, Laya, Jev: four answers to the same question

Four models define the range of this category, and the honest reading is that they are not four versions of the same thing — they are four answers to "how much model do you actually need".

Jev — the hosted reference. TypeSafe’s frontier model, closed weights, no local option. If closed-versus-open is the decision that matters to you — a public body, a regulated industry — I made that argument at length in Laya vs Jev: Open Weights and the Sovereignty Question (/blog/laya-vs-jev-open-weights-sovereignty). jev-1.13.0, priced at $0.042 per million input tokens with output free, 64k context per request (32k for the state plus your longest question), and the vendor’s stated 70–500 ms. This is the model the others are measured against, and by several independent measurements it is not being flattered: Jev does not produce reasoning traces and cannot be run on your hardware, and it is also the most accurate of the four.

Nimble — a 9B that trades blows with the frontier. Bespoke Labs’ adapter on Qwen3.5-9B, Apache 2.0, ~165 MiB on top of the base model. On 324 held-back examples it matched the reference answer 90.12% of the time (292/324) against Jev 1.13.0’s 93.21% (302/324) — and the base Qwen3.5-9B alone managed 66.36%, which tells you how much of the work the fine-tune is doing. On a 13-dataset macro average over 3,880 human-labelled decisions it came in at 74.8% against Jev’s 76.0%, and it leads Jev on the rubric/score subset (54.6% against 50.1%). The catch is hardware: unquantised 9B is about 18 GB, and it wants an NVIDIA GPU with BF16 or an Apple Silicon Mac with MLX. It is not a laptop-CPU model. Check the licence before you build on it — the original Nimble is Apache 2.0, but Nimble v3 is CC BY-NC 4.0, non-commercial.

Kev — the size ladder you can actually run. A family from Jared Palmer, Apache 2.0, built on Qwen3.5 and Qwen3.8, published in 0.8B, 4B, 9B and 27B, and the one I ran above. It reports a held-out chance-corrected index of 23.3 / 38.0 / 41.0 / 52.3 across those sizes, and on its own out-of-distribution test the 27B scored 0.889 against Jev’s 0.857 on the dev set — with the caveat Kev’s own README volunteers: on MMLU-Pro the 27B scores 0.675 against Jev’s 0.840, and at a 5% error budget Jev can automate 0.70 of new-source decisions against 0.52–0.69 for the Kev family. Kev is the model that answers the portability question: the same architecture from a laptop to a data-centre card, one URL to switch.

Laya — the one that should not work. Convai Innovations’ 421-million-parameter encoder, trained with the same RLCD method, Apache 2.0, with a 512-token context in the base checkpoint and about 33 ms per decision in the vendor’s own measurement. It was the surprise of my morning: a file smaller than a phone photo, running on a CPU, catching the cancellation threat at 0.986 where a 4.2B decoder settled for 0.715. Its own fine-tuned checkpoint reports 0.766 accuracy over 2,000 decisions on a 400-case typed-decision benchmark against Jev’s published 0.727. Treat a 421M model as a specialist, not a generalist — but do not treat "small" as "toy".

And a note on the one that is not in your hands: the 27B OpenJev is the largest open option and the only one that reads images, but its weights are CC BY-NC 4.0 — non-commercial — and the 19 GB Q4 file wants a 24 GB card. It is the model most likely to end a business conversation with a lawyer.

What these models get wrong

I have been enthusiastic for several thousand words, and this is the section that decides whether any of it is usable. Three sources of bad news, in descending order of authority.

The vendor’s own list. TypeSafe publishes a "model jaggedness" page for jev-1.13 — nine documented failure modes, last reviewed 2 October 2026 — and it is unusually candid. A decision model answers the literal question rather than the intended one. It is not a calculator; arithmetic belongs in code. It reads dates as text, not as ordered quantities, so date comparisons are unreliable. It loses accuracy as indirection and double negatives accumulate. It suffers context rot — irrelevant detail in the state actively drags accuracy down. It does not treat the state as hostile, so injected instructions can move the answer. And it leans toward whichever option you listed first, which the vendor tells you to test for. A vendor that publishes its own model’s defect list is worth reading twice.

The audit that should change your architecture. A controlled audit of self-knowledge in black-box decision models found the failure that matters most: confidence is calibrated on familiar questions but fails as an indicator of missing knowledge. Past its knowledge boundary the model does not become hesitant — it becomes more confident, a failure that recalibrating confidence does not repair. Their demonstration is the one to remember: on a hidden fair die roll, Jev reported 83% probability on one face and was right 19% of the time, exactly chance. And under misleading but related context, accuracy fell from 0.84 to 0.75 while confidence stayed at 0.83 — confident, wrong, and unbothered.

The independent benchmarks, which are less flattering than the marketing. TypeSafe’s homepage says 193.6x faster and 444.6x cheaper. Two independent reproductions on real tasks found the direction right and the magnitude far smaller: 3.25x–3.62x faster and about 40.6x cheaper than Claude Sonnet 5 on one task, roughly 50x and 11x short of the headline. On another, Jev and Claude Sonnet 5 tied exactly on accuracy for a structured risk classification — which is the fair criticism of this whole category: if a frontier model with constrained decoding gets the same answer, the decision model’s advantage is latency and cost, not capability. And on that second benchmark the p50 was 421.6 ms for Jev against 1371.0 ms for Claude; the first found Jev at p50/p95/p99 of 176/336/532 ms against Qwen3.8-27B on purpose-built silicon at 215/452/912 ms. Real gains. Not a different universe.

The academic picture is the most useful of all, because it is neither a vendor nor a rival. A 37-dataset, 346,009-request evaluation of jev-1.13.0 — which cost $9.15 in total, at a mean 0.36 s per request — found it strong where you would want: 96.5% on IMDB, 96.4% on SST-2, 95.5% on HellaSwag, 99.6% on language identification, beating Qwen3.8-27B on 27 of 37 datasets. It also found the edges: 57.9% on five-way sentiment, 32.2% on detecting real versus fake text, an F-score of 0.204 on legal clause analysis, and multilingual performance that collapses from 97.2% in English to 37.4% for Nigerian Fulfulde. Rubric scoring of generated text was the one area where the generative baseline was ahead. And the calibration result is the nuance worth carrying: pooled ECE 0.028 over 279,925 answers is genuinely well calibrated — but the miscalibration that exists is almost always overconfidence, concentrated exactly where accuracy is lowest.

Which is the whole lesson. Read the confidence, gate on it, and keep your thresholds somewhere a human reviews them.

The bottom line

Five things I would tell someone starting this today.

Separate deciding from explaining. Do not ask one model to choose the branch and justify it in the same breath. Let the decision model pick — in 138 ms, with a distribution — and let your chat model write the explanation if a human asks for one.

Write your options like a rubric, not a menu. Every description you write in criteria is reasoning material for the model. "billing": "Payments, invoices, refunds" is worth ten times "billing": "Billing".

Log the distribution, and gate on it. The winner is a decision; the probabilities are the audit trail. Act on confident answers, send the rest to a human, and treat the size of the runner-up as seriously as the size of the winner. My flat urgency answer — 34% Low against 34% High — is the case you must not act on.

Measure your own confidence floor. Mine did not match the published figures, because confidence depends on the rubric you wrote, not on the model. A threshold copied from a blog post is a coin flip.

Do not put a 144M model behind a business rule you care about. It was twenty times faster and it missed the word "cancelling". Start with the smallest model that passes your own accuracy bar — and if the answer matters, that is Kev-4B, Nimble 9B, Laya, or the hosted Jev, in the order your hardware and licence can afford.

The models that will not speak are, for a surprising share of software work, the ones you have been waiting for.

Go deeper

Every source below was fetched and checked while writing this, and every one answered. Start with the vendor’s own documentation if you only read one thing — the confidence page and the jaggedness page are the two that change how you design around these models.

The class, the original, and how it works

• System One — TypeSafe AI docs: the definition of the class, and the vendor’s own framing of what it is for. — https://docs.typesafe.ai/concepts/system-one
• Primitives (Questions) — TypeSafe AI docs: `choice`, [`score`](https://docs.typesafe.ai/primitives/score) and [`noul`](https://docs.typesafe.ai/primitives/noul) in full, including the option and level limits. — https://docs.typesafe.ai/primitives
• Confidence — TypeSafe AI docs: the closed-form confidence formula I verified against my own measurements, and the vendor’s plain statement that it is a shape statistic. — https://docs.typesafe.ai/confidence
• Jev 1.13 jaggedness — TypeSafe AI docs: nine documented failure modes. The most honest page in this ecosystem. — https://docs.typesafe.ai/model-jaggedness/jev-1.13
• API reference — TypeSafe AI docs: and [Models](https://docs.typesafe.ai/models) — exact request and response bodies, pricing, context and rate limits. — https://docs.typesafe.ai/api
• Introducing System One Models & Jev — TypeSafe AI: the launch framing and the "machine-native" argument. — https://typesafe.ai/blog/introducing-system-one-models-and-jev
• Lies, Damned Lies, and Benchmarks — TypeSafe AI: the vendor arguing that benchmarks are easily gamed and declining to publish a standard table. — https://typesafe.ai/blog/antibenchmaxxing
• What Is Jev? — OpenRouter: and [Jev documentation — OpenRouter](https://openrouter.ai/docs/guides/community/jev) — the easiest way to call Jev without a separate account, and the audit-trail advice. — https://openrouter.ai/blog/insights/what-is-jev/
• Jev (AI model): ) and [Jevons paradox](https://en.wikipedia.org/wiki/Jevons_paradox) — where the names come from. — https://en.wikipedia.org/wiki/Jev_(AI_model
• Maps of Bounded Rationality — Daniel Kahneman, Nobel lecture (PDF): the original System 1 / System 2 distinction the class is named after. — https://www.nobelprize.org/uploads/2018/06/kahnemann-lecture.pdf

Running one on your own machine

• New in llama.cpp: Decision Models — ggml-org / Hugging Face: the endpoint, the model table, the confidence-cutoff advice, and the start of the local story. — https://huggingface.co/blog/ggml-org/decision-models-in-llamacpp
• llama.cpp PR #29818: the actual implementation, and the build history that tells you which versions have the route. — https://github.com/ggml-org/llama.cpp/pull/29818
• Decision — Ollama docs: and [System One API — Ollama docs](https://docs.ollama.com/api/systemone) — the Ollama route, its limits, and the version gate. — https://docs.ollama.com/capabilities/decision
• Ollama now supports Jev-style decision models — Ollama blog: the 0.35 release that made it native. — https://ollama.com/blog/ollama-now-supports-jev-style-decision-models
• Modelfile reference — Ollama docs: the `CAPABILITY decision` line, for pointing Ollama at a GGUF decision model of your own. — https://docs.ollama.com/modelfile
• ollajev: and [ollaya](https://github.com/ollaya-dev/ollaya) ([quickstart](https://ollaya.dev/docs/quickstart), [TypeSafe compatibility](https://ollaya.dev/docs/typesafe-compatibility)) — the two third-party runtimes that behave like package managers for decision models, with their own model shelves and hardware notes. — https://github.com/nvkudva/ollajev

The four models

• jaredpalmer/kev: README, the [1.0 release notes](https://raw.githubusercontent.com/jaredpalmer/kev/main/docs/releases/kev-1.0.md), the [serving entry point](https://raw.githubusercontent.com/jaredpalmer/kev/main/kev/serve.py), and the [long-context issue #48](https://github.com/jaredpalmer/kev/issues/48). — https://github.com/jaredpalmer/kev
• kev — Ollama library: the packaged version, if you would rather not run a server yourself. — https://ollama.com/library/kev
• Bespoke-Nimble-9B — Hugging Face: and [nimble — Ollama library](https://ollama.com/library/nimble) — the model card, the contrastive training method, and the published comparison against Jev. — https://huggingface.co/bespokelabs/Bespoke-Nimble-9B
• convaiinnovations/laya: , [laya-typed-decisions](https://huggingface.co/convaiinnovations/laya-typed-decisions) and [laya-multilingual](https://huggingface.co/convaiinnovations/laya-multilingual) — the 421M encoder, its benchmark table and its multilingual sibling. — https://huggingface.co/convaiinnovations/laya
• ggml-org/Laya-GGUF: , [Julia-1-GGUF](https://huggingface.co/api/models/ggml-org/Julia-1-GGUF/tree/main) and [Kev-4B-GGUF](https://huggingface.co/api/models/ggml-org/Kev-4B-GGUF/tree/main) — the exact files, sizes and quantisations I ran. — https://huggingface.co/ggml-org/Laya-GGUF
• Decision models — Ollama model search: the current catalogue, so you can see what has been added since this was written. — https://ollama.com/search?c=decision

The evidence, including the unflattering parts

• Evaluating and Benchmarking the System One Model Jev — arXiv:2609.37647: ([full HTML](https://arxiv.org/html/2609.37647v1)) — 37 datasets, 346,009 requests, $9.15, and the per-dataset numbers including where Jev loses. — https://arxiv.org/abs/2609.37647
• Beyond Answer Confidence: A Controlled Audit of Self-Knowledge in a Black-Box Decision Model — arXiv:2610.01006: the finding that confidence is not self-knowledge, and that the model grows more confident past its knowledge boundary. — https://arxiv.org/html/2610.01006v1
• Jev Does Not Play Dice — Kanta Hayashi: the die-roll demonstration of confident guessing. — https://kantahayashiai.github.io/posts/jev-does-not-play-dice/
• themsquared/jev-benchmark: and [iammrduncan/typesafe-ai-benchmark](https://github.com/iammrduncan/typesafe-ai-benchmark) — two independent, reproducible benchmarks, together the reason the 193.6x headline should be read as a ceiling rather than an expectation. — https://github.com/themsquared/jev-benchmark
• Jev’s Architecture Unmasked — Archer Hume: a black-box reconstruction from roughly 10,000 instrumented calls, including an independently measured ECE of 0.0313. — https://archerhume.com/posts/jevs-architecture-unmasked/
• Decision models in llama.cpp: what /v1/systemone actually evaluates: a practitioner’s read on what the endpoint does, and the `501` you get when you point it at a chat model. — https://ai.thesatyajit.com/articles/llamacpp-decision-models

All measurements attributed to "my machine" in this article were taken on 14 October 2026, CPU-only, using llama.cpp build b11609 with ggml-org GGUF files, and are reproducible with the commands in the setup section.