pplx-decider vs Decider: Perplexity's Silent 27B Against Mapika's Open Ladder

Two decision models are sitting on Hugging Face right now that answer questions the same way and agree on almost nothing else. pplx-decider is a 27B checkpoint from Perplexity that landed on 2026-10-01 with no announcement, no blog post, no pricing page and no inference provider carrying it; a revision, pplx-decider-v1.1, followed on 2026-10-05 on the same backbone. Decider is Mapika's family of the same class of model — decider-0.8b through decider-35b-a3b, an open reproduction in the System One lineage, published with full training notes. Both take a block of named questions plus a document and return a calibrated probability per answer in one forward pass. Neither writes a sentence of prose. What follows is what is actually on the record for each, and a clear marker wherever the record stops.

First, what "decision model" is doing in that sentence

Neither of these is a chat model that has been asked to be terse. They are not language models at all in the usual sense — there is no decoding loop, no sampling, no token-by-token anything. One forward pass over your document returns a probability for every option you supplied.

The shape of the call is what makes the comparison worth writing. You hand over a state (a ticket, a JSON record, a screenshot, a contract) and a list of named questions. Each question names its answer type: choice over 2 to 255 labelled options, a yes/no/unknown readout, or a score on 2 to 10 described levels. Answers come back in the order you asked for them, as numbers between 0 and 1, and the number is meant to be read as a probability rather than a neat label — 0.62 on "is a refund being requested?" is the whole output, and a caller decides the threshold.

That design kills latency and cost, because a document with sixty questions costs one pass, not sixty. It also means the usual ways of judging a language model do not apply: there is no reasoning trace to read, no chain of thought to argue with, no way to ask it to explain itself. You get probability mass and nothing else. Both projects are explicit that this is the trade.

What shipped, and what nobody has said

The pplx-decider repository is unusually complete for a model with no launch post behind it. The weights are Apache-2.0. The base is Qwen/Qwen3.8-27B, stated on the card. There is a released readout head in bf16 at [255, 5120], which is exactly the shape you would expect for 255 selectable options over a 5,120-wide hidden state. The card documents the input budget, the option ceiling, the three question types, and the endpoint shape — POST /v1/systemone.

What is not there is the sentence a launch post would carry. There is no release date on the card, no announcement, no benchmark post from Perplexity, no price, and no third-party platform serving it. The download counts are of the size you get from a repository that was found rather than promoted. Read the two together and the honest description is: the artifact is public, the intent behind it is not. Everything below about pplx-decider comes from the repository and its cards. Nothing below has been independently reproduced, and no one outside the lab has published a run of their own.

The Ollama library entry makes that gap visible in a small way. Its page lists the tag as 27b at 17 GB with a 256K context window — a quantised build, well under the roughly 49 GiB the bf16 weights occupy — while the repository documents a much smaller text-and-images input budget and says oversized inputs are rejected rather than truncated. Those two statements are not obviously describing the same limit, and nothing published reconciles them. Treat the runtime's number as the runtime's claim.

The interesting part: two strangers, one interface

Mapika's Decider family and pplx-decider were developed independently, from different bases, for different reasons, and they converged on the same wire format. Decider models speak the System One call shape too — named questions, choice over 2 to 255 options, no text generation, states accepted up to roughly 32k. A client written against one is, near enough, a client for the other.

That convergence is the useful fact in this comparison. Which one you pick is not a rewrite; it is a swap of a base URL and a model string. The interesting question stops being "which API do I integrate" and becomes "which readout do I trust on my documents" — and the two projects answer that question in very different ways.

One checkpoint against a ladder

The structural difference is the easiest one to see. Perplexity shipped a single size. Mapika shipped a range and published the size table:

• Catalogue — pplx-decider: one 27B checkpoint, plus a v1.1 revision on the same backbone. Decider: seven-plus published sizes, from decider-0.8b at 1.4 GB up through decider-2b, decider-2b-vision, decider-4b, decider-12b, and decider-35b-a3b at 65 GB bf16 or 19.6 GB in nvfp4.

• Bases — pplx-decider: Qwen/Qwen3.8-27B, one lineage. Decider: a mix — Qwen3.5-0.8B, Qwen3.5-2B and Qwen3.5-4B for the small sizes, Qwen3.5-35B-A3B for the large one, and gemma-4-12B-it and gemma-4-31B-it under the chat variants.

• Activation — pplx-decider: dense 27B, so every parameter runs on every call. Decider: decider-35b-a3b is a mixture — 34.7B total with roughly 3B active across 256 routed experts, 8 of them live per token.

• Vision — pplx-decider: multimodal, and the repository says so; text, JSON and images including screenshots, receipts and forms, with vision tokens costing roughly width × height / 1024. Decider: a separate decider-2b-vision checkpoint rather than a flag on the main line, so image work is a different model choice, not a different argument.

• Licence — Apache-2.0 on both sides, which is the single place this comparison is boring.

• Training disclosure — pplx-decider: a data pipeline that builds on Bespoke Labs' Bespoke Nimble, with benchmark subsets pinned by record ID and checksum, and v1.1's gains credited to removing the causal mask and adding data including tasksource. Decider: per-version notes with item counts, hardware and wall-clock — decider-35b-a3b trained on 4× B300 for 394 minutes over 1,543,567 items — plus named failure modes and the share of parameters actually trained, 2.45B of 34.7B.

Neither of those is a decisive advantage. A single checkpoint is simpler to reason about, easier to serve and impossible to size down. A ladder lets you put decider-0.8b behind a cheap pre-filter and spend the 35B only on the items that need it — but only if you are willing to maintain the routing logic that decides which is which.

The numbers, and who produced them

Both sets of headline figures are vendor-reported, and neither has an independent replication attached. That matters more here than it usually does, because there is no third-party decision-model leaderboard with the standing of the image or language arenas.

Perplexity's own figures for pplx-decider put it at 85.7% across 11 public benchmarks, against 84.5% for Jev and 74.8% for the Qwen3.8-27B base it was trained from. Individual rows reported include RAGTruth 88.8, FinancialPhraseBank 84.2, TabFact 90.6, JudgeBench 78.3 and WinoGrande 83.3, with the fuller set spanning Circa, Belebele, TruthfulQA binary, BBH, ContractNLI and a public hard split of JevBench. The v1.1 revision reports a suite-weighted overall of 61.56 against 56.4 for v1 and 57.9 for Jev, with the largest single-category gain in language tasks. The comparison to Jev is the vendor's, computed on the vendor's own suite, and the weighting is not published.

Mapika's reporting has a different texture: figures arrive attached to caveats that undercut them. decider-35b-a3b reports 0.855 in-task and 0.810 held-out against a 0.732 zero-shot base, and 0.676 on the public hard split of JevBench — below Jev 1.13.0's 0.730. The card also states there is no reinforcement stage, so sampled play sits at 86.4% against decider-2b v10's 93.2%, and that the model is overconfident on the hardest items, with expected calibration error of 0.15 on the hard tier. decider-2b v11 is reported at 0.802 in-task and 0.752 held-out with an ECE of 0.156 against a stated release guideline of 0.08 — a miss, printed by the authors.

Two documented failure modes are worth carrying into any evaluation you run. Selecting a record by its position in a long JSON array is described as the least accurate input shape the family handles, and packing several independent questions into one call can flip up to 12% of answers when the independent flag is off. Both are the kind of thing a spec sheet hides and a card mentions once.

What it costs to run either one

• Smallest workable Decider — decider-0.8b is 1.4 GB. pplx-decider has no small variant, so its floor is the full 27B.

• Largest Decider — decider-35b-a3b at 65 GB bf16 or 19.6 GB nvfp4, with only about 3B parameters active per token.

• Latency, Decider side — decider-2b runs 4 ms per request with CUDA graphs on a B300, down from 18.9 ms eager, and roughly 2,700 decisions per second at batch 32. The 35B is a different world: about 47 ms for a 92-token ticket with three questions, 368 ms for 64 tickets.

• Latency, pplx-decider side — none published. The cards give no throughput or latency figure at all, which is normal for a repository that was not launched.

• Cost per decision — this is where the design pays off on both sides. Sixty questions on one document is one forward pass either way, so the per-decision cost collapses as you ask more of the same document.

Here is the honest routing picture. OrcaRouter does not serve pplx-decider, and it does not serve Mapika's Decider family — neither appears in the catalogue, and nothing in this article should be read as a claim otherwise. What the catalogue does carry in this class today is typesafe/jev-1.13, a decision model of the same System One shape with a 65,536-token window exposed through the same POST /v1/systemone endpoint at $0.042 per million input tokens, which is a useful anchor for what a routed decision model costs. If you are evaluating an unannounced checkpoint like pplx-decider, the way to do it without betting a production path on it is to run it yourself alongside a routed model behind one API for 200+ models — provider list price passed through with 0% markup, so when these projects do reach an inference provider, the list price is the price here the same day. Until then, a self-hosted pplx-decider next to a routed typesafe/jev-1.13 is the comparison that will actually tell you something.

Which one to reach for

If you need a decision model today, on your own hardware, at a size you choose, with training notes you can audit and a licence that asks nothing of you, the answer is a Decider checkpoint, and the only real question is which rung. Start at decider-2b; the v11 numbers show the family improving against its own v10 on precisely the hard split you would care about, and the documented ECE gap tells you to refit a temperature before you trust the probabilities in production.

Reach for pplx-decider if you want the same interface with a larger dense model behind it, if image inputs matter and you would rather not run a second checkpoint, or if you are the sort of team that would rather evaluate a frontier lab's readout head yourself than wait for a launch post that may never come. Its advantages are real but unverified: a bigger backbone, a benchmark table that flatters it, and a training pipeline documented down to record-level checksums.

What to watch is not a benchmark. It is whether pplx-decider reaches an inference provider at all. A repository with weights and no announcement is a signal, not a product; the moment it appears on a hosted endpoint, the price-versus-latency question that Decider's cards already answer becomes a real comparison instead of an aspiration.

Run a self-hosted pplx-decider next to a routed decision model behind provider list price passed through with 0% markup , so when either project reaches an inference provider the listed price is the price here the same day.

A new checkpoint measured against a published ladder is also a good place to check the record: the documented AI incidents and agent failures around models in this class are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.