pplx-decider-flash: Perplexity's Quiet 4B Judge, Read From the Repo

Perplexity uploaded pplx-decider-flash-v1.2 to Hugging Face at 16:57 UTC on 15 October 2026, roughly nine hours after it uploaded pplx-decider-v1.2, the large decision model the marketing calls 27B and the model card calls 26B. We could find no launch post on the company blog. What followed was a thread from the developer account on X, a section in the Decisions API documentation, and a GGUF conversion three days later. That is the whole public record, and it is enough to describe the model precisely but not enough to tell you whether it is good on your data.

What follows separates the three things people usually blur together: what the repository proves, what the vendor's documentation states, and what nobody outside Perplexity has verified. The last category is larger than the first two.

What actually shipped, and on what day

The repository timeline is unambiguous. Perplexity created pplx-decider-v1-27b on 1 October 2026, pplx-decider-v1.1-27b on 5 October, both v1.2 checkpoints on 15 October, and pplx-decider-flash-gguf-v1.2 on 18 October. The Flash checkpoint was the second upload that day, which is the ordinary shape of a paired release: the flagship first, the distilled small sibling behind it so that both land under the same announcement.

That ordering matters for the framing. This is not a leaked model or a stray repository that escaped ahead of its paperwork. It is a coordinated release with a deliberately light public footprint — a developer thread rather than a launch essay, documentation rather than a benchmark hub. The Hugging Face API reports 4,667 downloads on the base checkpoint and 9,428 on the GGUF conversion as of 4 November, and 63 likes. Download counts on Hugging Face are a weak signal: they count requests, not distinct users, and mirror traffic inflates them. They are consistent with a real but modest open-weights audience, not with a viral drop.

What the repository tells you

The model card is unusually technical for a vendor release, and most of what is knowable comes from it.

• Backbone — Qwen3.5-4B, with a separate BF16 readout head of shape [255, 2560] instead of a full-vocabulary language-model head. This is a decision checkpoint, not a chat model with a classification wrapper.

• Size — 25 files totalling roughly 9 GiB in BF16, which is what you need to hold the weights; working memory sits on top of that.

• Parameter count — the API documentation says 4B, the model card's header says 5B in BF16, and one third-party index lists 4.5B. The backbone is a 4B model. Treat "4B class" as the honest description and do not quote a single figure as if it were measured.

• Attention — full-attention layers run noncausally over the whole request while linear-attention layers stay causal. This is the detail that will bite you: a standard causal serving stack will produce different numbers, and prompts written for v1.1 do not carry over.

• Readout position — the head fires at each <|fim_suffix|> marker rather than at the final token, which is how a single forward pass can score several questions against one state.

• Context — max_length defaults to 262,144 tokens, matching the backbone. Training used sequences up to about 32,000 tokens, and the card is explicit that longer inputs are supported but less validated.

• Images — capped at 1.6 megapixels (1,638,400 pixels), minimum 65,536 pixels, with a 1.6 MP image consuming roughly 1,600 positions.

• Calibration — a saved temperature of 1.554. On a 1,497-question development set the card reports 88.8% accuracy, expected calibration error of 0.021 and a Brier score of 0.163; without the temperature the error rises to 0.057. A vendor that publishes its own calibration numbers and the cost of skipping them is telling you something real about intended use.

One line in the card does not survive contact with the API. It says the repository is private and needs a token with access. The Hugging Face API returns gated: false and private: false, and the weights download without an access request. A stale line in a card is a small thing, but it is the kind of small thing that tells you the card was written before publication and not re-read after.

What the API documentation adds

Pricing is where the Flash argument starts. On the Decisions API, pplx-decider-flash-v1.2 costs $0.01 per million input tokens. Output tokens are free and there is no per-request fee, because there are no output tokens in the usual sense — the model returns probabilities and an expected score, and the documentation counts each question as one output token for accounting.

The same page sets the operating envelope:

• Alias — pplx-decider-flash-latest follows the newest version, so a threshold you tuned last week can silently point at a different model after an update. Pin the versioned id in anything that matters.

• Rate limits — 4,000,000 tokens per minute and 240,000,000 per hour, with a 10-requests-per-second ceiling shared across both decision models at the organisation level.

• Question types — noul returns P(yes) from 0 to 1, choice returns probabilities across up to 255 options, and score returns a distribution over rubric levels.

• Question budget — the documentation recommends one question per request. That is not a style note; it is the difference between the price you were quoted and the price you pay.

The billing rule that flips the recommendation

The 27B model answers every question in a request in one grouped pass and bills the state once. Flash answers each question independently, without seeing the others, and bills the state again for every question. The docs give the worked example: three questions against a 10,000-token state cost about 30,000 input tokens on Flash.

Run the arithmetic. One question on a 10,000-token state costs $0.0001 on Flash and $0.0002 on the 27B. Two questions cost $0.0002 on Flash and $0.0002 on the larger model — a dead heat. Three questions cost $0.0003 on Flash and $0.0002 on the 27B. The crossover is two questions per state. Perplexity's own documentation says the larger model "usually costs less than Flash" at three or more questions; the precise point is one question earlier, and it holds at any list price where Flash is exactly half the 27B rate.

This is the single most useful thing in the release, and it is easy to miss because the headline is a 50% discount. A 4B model at half price is cheaper only while you ask it one thing at a time.

The number to distrust

Perplexity reports Decision Index 0.3 scores for both models. Flash scores 60.05 with one question per request and 58.88 with joint requests; the 27B scores 68.09 joint and 67.75 one-per-request. On the Vision Decision Index, Flash is 72.53 against 77.43.

The category split is more informative than the headline, because it shows where the 4B gives ground. On Flash's joint-run numbers against the 27B's joint-run numbers:

• Knowledge — 42.0 vs 56.3. This is the widest gap, 14.3 points, and the one that decides whether the model can handle open-ended world knowledge at all.

• Language — 63.3 vs 72.8.

• Retrieval — 64.8 vs 68.4. The narrowest gap at 3.6 points, which fits the intended job: judging whether a passage answers a question is a lighter task than knowing the answer.

• Tools — 76.7 vs 84.4.

• Arts — 46.8 vs 56.2.

• Overall — 58.88 vs 68.09.

Every one of those figures comes from a benchmark Perplexity maintains. The 27B card — the teacher in this distillation — is unusually candid about the training side: part of the work, it says, brought the model "in domain" for some Decision Index tasks by including the official training splits that several benchmarks ship, with the splits "decontaminated against the test sets" so the comparison stays fair. That is a more careful position than the coverage around the release implied, and it still leaves the scoreboard in the vendor's hands. No third party has audited the split discipline, and nobody has reproduced the numbers.

There is a smaller oddity inside the vendor's own numbers that cuts against the marketing. Flash scores higher when it answers one question at a time — 60.05 versus 58.88. Grouping hurts the 4B overall even though it helps on tightly coupled select-all-that-apply tasks, which is exactly what the documentation says. The model is being sold on joint-request speed and measured better without it.

What is not knowable yet

The gaps are specific, and they are the reason this is a what-we-know piece rather than a review.

• No independent benchmark. Nothing outside Perplexity has published Decision Index reproductions or a head-to-head on a neutral harness.

• No latency service level. The only speed figure the vendor publishes is a documentation test dated 19 October in which roughly 248,000 input tokens took 16 seconds on Flash against 53 seconds on the 27B. That is a vendor-side measurement with no stated hardware or percentile.

• No multilingual evaluation. The card and docs describe text and images; neither reports accuracy outside English.

• No published training-data volume. The card says Flash was distilled from the 27B on the larger model's training requests, with the student learning the teacher's full probability distributions rather than just its answers, and that several runs were combined by weight averaging. It does not say how much data that involved, where it came from, or where the cutoff sits.

• No published error analysis. For a model whose output is a probability you will threshold on, there is no breakdown of where it fails — by question type, by option count, by language, or by image content.

Where a model like this sits in a stack

It is worth being clear about what Flash is for, because the name invites the wrong expectation. It does not write anything. You hand it a state — text, JSON, images — and one or more typed questions, and it hands back a probability or a distribution that your code thresholds on. The natural architecture is a cheap gate in front of something expensive: classify the request, decide whether to retrieve, pick a tool, then generate.

That gate does not replace the generation layer, and this is where routing matters. OrcaRouter exposes 200-plus generation models behind one API key with no markup on provider list prices, so a price cut from any upstream vendor is live the same day rather than waiting on a reseller's spreadsheet. If the gate misclassifies, automatic failover keeps the request from dying at the next hop. What we do not do is host pplx-decider-flash: it is not in our catalogue, and the honest way to run it today is the vendor's own API or the Apache-2.0 weights on your own GPU.

The self-hosting maths is reasonable if you already have the hardware. Roughly 9 GiB of BF16 weights fits on a 16 GB consumer card, and coverage of the release repeated a claim from Perplexity's chief executive that Flash runs on an M4 Mac with 16 GB of memory. No published throughput numbers back that up, and the noncausal attention means you cannot simply drop it into a stock causal inference server and expect the card's scores.

What would change this assessment

Four things, in order of usefulness. A neutral reproduction of Decision Index 0.3 that either confirms the 60.05 or explains the gap. A published latency distribution from the API rather than a single documentation test. Evidence on multilingual inputs, since a 4B classifier is exactly the kind of model teams will point at non-English traffic without checking. And a first-party technical post that describes the training data behind that distillation.

Until then, the defensible position is narrow and useful: pplx-decider-flash-v1.2 is a real, downloadable, Apache-2.0, 4B-class decision model with a published price, a documented calibration temperature, and a billing rule that makes it more expensive than its big sibling the moment you batch questions. Everything beyond that is Perplexity's own scoreboard, and you should treat it as a hypothesis to test on your labelled data rather than a result.