pplx-decider vs Kev: Two System One Models You Can Already Pull

The useful accident in this matchup is that you can settle it on your own hardware this afternoon. pplx-decider, Perplexity's 27B decision model, appeared on 2026-10-01 with no announcement attached and a v1.1 revision on 2026-10-05, and both are on the Ollama library. Kev, Jared Palmer's reproduction line, has been on Ollama since v2 landed on 2026-09-30 and covers 0.5B through 27B. They speak the same call shape — a state plus a list of named questions, one forward pass, a probability back, no generated text — which means the same harness can run both. What differs is everything underneath: how the output is produced, what the authors documented, and how much GPU it takes.

Start with the thing that makes a bake-off possible at all. Neither model writes text. You hand over a document and ask questions by name, each question declaring its answer type — a choice over 2 to 255 labelled options, a yes/no/unknown readout, or a score across 2 to 10 described levels. The answer arrives as a probability, in the order you asked. A ticket with sixty questions is one pass over the model, not sixty calls.

How much of each model is actually doing the deciding

Kev's card is explicit about its construction in a way that is rare outside internal write-ups, and the detail is worth reading before you trust a number from it. The 27B checkpoint is a full-weight supervised fine-tune on Qwen/Qwen3.8-27B, then a weight average — 0.85 of the new model blended with 0.15 of v1 in fp32. The smaller sizes, 0.8B through 9B, ship as LoRA adapters on Qwen3.5 bases rather than full checkpoints.

The part that decides how the output is shaped is separate from the language backbone. Kev carries a pointer head — about 2.6M parameters in fp32, sitting on top of a 25.6B backbone to make 26B — which is what turns a hidden state into a probability over your named options. pplx-decider does the same job with a released readout head of [255, 5120]: 255 options over a 5,120-wide hidden state, in bf16.

Two architectures, one idea: the language model reads, a small head decides. That is why neither generates prose, and it is also why a benchmark score from one does not transfer to the other even when both are quoted against the same reference model.

The only head-to-head on the record, and why you cannot subtract it

Both projects report against Jev, which makes it tempting to line them up. Do not.

Kev's own card carries a Decision Index 0.2 row that puts Kev-27B v2 at 52.3 against 50.2 for v1, Jev at 54.0, and AutoJev-27B at 50.0. That is a clean, same-suite, same-version comparison, and it says Kev v2 improved by about two points and still trails Jev.

pplx-decider's cards report a suite-weighted overall of 61.56 for v1.1, against 56.4 for v1 and 57.9 for Jev. On their own numbers that is a gain of more than five points in one revision and a lead over Jev of more than three and a half.

Those two paragraphs cannot be subtracted from each other. Different suites, different task mixes, different weighting — and neither project publishes the weighting. What you can say is narrower and still useful: both moved in the same direction in the same window, both did it by changing how the readout is trained rather than by swapping the backbone, and pplx-decider's claimed margin over Jev is larger than Kev's measured deficit. That is a reason to test pplx-decider, not a reason to believe it.

Only one of the two has an independent replication attached to any of its numbers. Kev's Ollama tags publish JevBench pass counts per tag — 205 of 231 for kev:27b-nvfp4 including 86 of 111 on the hard split, down to 146 of 231 for kev:0.8b — with an explicit note that these exclude 303 unavailable sealed or judge-graded tasks and are not an official leaderboard score. It is a self-run, but it is a self-run you can repeat. Nothing comparable exists for pplx-decider.

What Kev documents that pplx-decider does not

• Temperature — Kev ships with T = 1.32, a 90% interval of [1.20, 1.45], applied at load, so the probabilities you get out are already scaled. pplx-decider's cards publish no temperature at all, which means whatever calibration you need is yours to fit.

• Training record — Kev v2 is 129 GPU-hours on 8× H200, one epoch over 145,840 records and 337,130 questions, labels produced by GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b and MiMo-V2.6-Pro with no Jev output used, and a contamination screen that removed 6,388 records across 102 evaluation partitions. pplx-decider documents a pipeline built on Bespoke Labs' Bespoke Nimble with benchmark subsets pinned by record ID and checksum, and credits v1.1's gains to removing the causal mask plus added training data — but publishes no record count, no GPU-hours and no labeller list.

• Honest regression reporting — Kev's card prints its own misses: transfer-v4 locked down 0.8 points, CUAD down 1.6, expected calibration error on breadth-v1 at 0.015 against 0.053 on CUAD, two to four times worse than v1, and it names the selection optimism in its own evaluation. pplx-decider's v1.1 table shows tools slipping from 79.3 to 78.88 while every other category rises, and nothing in the card remarks on it.

• Failure modes — Kev's card lists contamination-screening scope and the conditions under which its published numbers were produced. The Decider family, Mapika's line, goes further and names specific input shapes that break it; pplx-decider is silent on the question.

None of this says pplx-decider is worse. Documentation is not capability — a lab with a launch post in draft has different incentives from an individual publishing notes to Hugging Face. But when two models claim the same class of result and only one of them tells you its temperature, the one that tells you is the one you can put in production this month.

Context accounting, which is where the two diverge hardest

• Kev — 65,536 tokens of state, plus at least 8,192 tokens per question, with training at up to 32,768. At a 64k state the resident footprint reaches about 87.1 GB at peak, model time 9.4 seconds, 733 ms on a cache hit, and 21.1 requests per second at a single client against 36.4 at sixty-four.

• pplx-decider — 8,192 tokens for text and images combined, with oversized inputs rejected rather than truncated. The Ollama build lists a 256K context window, which nothing in the repository explains and which does not reconcile with the card's own limit.

That gap is the single most consequential difference between the two for real workloads. Kev is built for long states and many questions against them. pplx-decider is a dense 27B with a comparatively small input budget, which pushes it toward short documents, images, and asks that fit inside a few thousand tokens.

• Language — English only on both, stated as a limitation on both.

• Vision — pplx-decider takes text, JSON and images, with vision tokens costing roughly width × height / 1024 and an evaluation setup capped at 512×512. Kev has no vision in the 27B line.

• Serving floor — Kev-27B needs an 80 GB-class GPU: 51.3 GB of bf16 weights, about 65.5 GB resident, 87.1 GB at a 64k state, and its server binds openly unless KEV_API_KEY is set. pplx-decider's bf16 weights are around 49 GiB, so the floor is similar; the quantised Ollama build lands at 17 GB, which is a very different machine.

• Rungs — Kev spans 0.5B, 0.6B, 0.8B, 4B, 8B, 9B and 27B, with the small sizes as LoRA adapters. pplx-decider is one size, twice revised.

Running the bake-off without betting on it

Both models are reachable as local weights, which is exactly the situation where a routing layer earns its keep. OrcaRouter does not serve pplx-decider and does not serve Kev — neither is in the catalogue, and nothing here should be read as a claim that we host them. What we do carry in this class is typesafe/jev-1.13, exposed through the same POST /v1/systemone call shape at $0.042 per million input tokens, and it is the natural control arm: same interface, same question types, no GPU of your own.

That makes a three-way bake-off cheap to set up. Put a local pplx-decider and a local Kev behind the same harness against a routed typesafe/jev-1.13, score all three on your own documents, and let the disagreement between them tell you where your thresholds actually sit. Automatic failover matters more than usual in that arrangement, because a local 27B on a single card is the least reliable component in the chain; routing the fallback through one API for 200+ models — provider list price passed through with 0% markup — keeps the experiment from turning into an outage. And when a model like pplx-decider eventually reaches a hosted endpoint, the same key that runs the control arm runs it, with no second contract and no code change.

What would change the answer

Four things, and all of them are checkable rather than a matter of taste.

If pplx-decider reaches an inference provider, its unverified benchmark table becomes a price-versus-latency question, and the documentation gap stops mattering — you would be paying for a hosted readout, not maintaining one. If an independent party reproduces either model's JevBench numbers on a published harness, the whole comparison narrows to a single suite rather than two incompatible ones.

If Kev's documented ECE weakness on CUAD turns out to be fixable with a refit rather than a retrain, the calibration argument against it largely disappears, because Kev already ships its temperature and its failure modes are known quantities. And if you need a decision model on one card rather than two, pplx-decider's 17 GB quantised build is the only option here — not because it is better, but because it fits where a 27B at bf16 does not.

Until one of those happens, the practical read is unglamorous. Kev is the one whose numbers you can repeat today and whose calibration you can trust to be documented; pplx-decider is the one with the better claimed ceiling and the weaker paper trail. Pick the first if you are shipping this month. Pull the second into the same harness if you are the kind of team that would rather measure a quiet release than wait for a launch post.

Routing the fallback through provider list price passed through with 0% markup keeps a three-way bake-off from turning into an outage when the local checkpoint is the least reliable component in the chain.

A three-way bake-off is also a reasonable moment to ask what has already failed in this class: the documented AI incidents and agent failures involving decision models are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.