pplx-decider-flash vs pplx-decider: The 4B Is Cheaper Until You Ask Three Questions

On the price list, pplx-decider-flash-v1.2 costs half what pplx-decider-v1.2 costs: $0.01 per million input tokens against $0.02. On the billing rules, that discount survives for exactly one question. Ask two questions of the same state and the two models cost the same. Ask three and the 4B model is the more expensive one, because Flash bills the state again for every question while the 27B bills it once. The cheaper model is cheaper only if you ask it one small question at a time.

That inversion is the useful part of this comparison. The rest is a familiar size trade: a 4B checkpoint that wins on latency and memory against a 26-billion-parameter model that wins on accuracy, with both sold under the same Apache-2.0 licence and the same 262,144-token default context.

Two checkpoints, one release, different jobs

Perplexity published both on 15 October 2026, the large model at 07:40 UTC and Flash at 16:57. They share a design: a Qwen backbone, a 255-way readout head instead of a language-model head, noncausal full-attention layers, and a saved calibration temperature. They do not share a backbone. pplx-decider-v1.2 is built on Qwen3.8-27B and ships at roughly 52 GiB in BF16. pplx-decider-flash-v1.2 is built on Qwen3.5-4B and ships at roughly 9 GiB.

The naming is looser than the numbers. The large model is sold as 27B, but its own card says 26B in BF16. Flash is sold as 4B in the API documentation, while its card header says 5B in BF16 and its backbone is a 4B model. Neither discrepancy changes a deployment decision; both are worth knowing before you quote a parameter count in a capacity plan.

The price list, before the asterisk

• Input price — pplx-decider-flash-v1.2 at $0.01 per million tokens vs pplx-decider-v1.2 at $0.02.

• Output price — free on both, with no per-request fee. Each question counts as one output token for accounting only.

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

• Aliases — pplx-decider-flash-latest and pplx-decider-latest both move to the newest version, so a threshold tuned against one version can silently meet another.

The asterisk is not hidden. Perplexity's documentation states plainly that Flash is built for one question per request, that sending several questions produces independent answers with no cross-talk, and that the state is billed again for each one. It even works the example: three questions on a 10,000-token state cost about 30,000 input tokens.

Where the second question erases the discount

The general form is simple. For a state of s tokens and q questions, Flash costs q × s × $0.01 per million and the 27B costs s × $0.02 per million. The Flash bill overtakes the large model at the third question.

• One question, 10,000-token state — Flash $0.0001 vs 27B $0.0002. Flash wins by half.

• Two questions, same state — Flash $0.0002 vs 27B $0.0002. A tie, not a discount.

• Three questions — Flash $0.0003 vs 27B $0.0002. The 4B is 50% more expensive.

• Five questions — Flash $0.0005 vs 27B $0.0002. The 4B is two and a half times the price.

In absolute terms these are fractions of a cent, which is why the rule is easy to overlook and why it compounds at volume. A gate that runs a million three-question requests against 10,000-token states costs about $300 on Flash and $200 on the 27B. The model that looks 50% cheaper is 50% more expensive at the workload where batching would normally be an optimisation.

Perplexity's docs say the larger model "usually costs less than Flash" at three or more questions. The exact crossover is two. If your questions are genuinely coupled — select-all-that-apply facets of one decision — the joint path is also the accurate one. If they are independent candidate scores, the docs advise splitting them into separate requests, which pushes Flash's bill up further while leaving the 27B's unchanged.

The accuracy gap, category by category

Both models are scored on Decision Index 0.3, Perplexity's own composite. The headline is 60.05 for Flash with one question per request against 68.09 for the 27B with joint requests. The category split, comparing joint runs to joint runs, shows where the 9.2-point joint-run gap comes from.

• Knowledge — 42.0 vs 56.3. A 14.3-point gap, and the one that should decide most deployments. If the question requires knowing something rather than judging something, the 4B is not a substitute.

• Language — 63.3 vs 72.8.

• Retrieval — 64.8 vs 68.4. The narrowest gap at 3.6 points. Judging whether a passage supports a claim is the task Flash was built for, and the numbers reflect it.

• Tools — 76.7 vs 84.4. Both models are strongest here in absolute terms, which fits the routing use case.

• Arts — 46.8 vs 56.2.

• Vision — 72.53 vs 77.43 on the Vision Decision Index, a 4.9-point gap that is smaller than the text gap and makes Flash more competitive on images than on prose.

The obvious caveat applies to every figure above: the benchmark belongs to the vendor, and no third party has reproduced it. The 27B card says the training work included the official training splits of several Decision Index tasks, decontaminated against the test sets; that is a stated practice, not an audited one. Treat the category profile as a hypothesis about where each model is strong — knowledge and arts for the 27B, retrieval and tools for both — rather than as a measured result.

The joint-request asymmetry

Grouping questions helps the large model and hurts the small one, and Perplexity's own numbers say so.

• pplx-decider-v1.2 — 68.09 joint vs 67.75 one per request. Grouping adds 0.34 points.

• pplx-decider-flash-v1.2 — 58.88 joint vs 60.05 one per request. Grouping costs 1.17 points.

The documentation explains the mechanism: the 4B loses accuracy when it answers several questions together, which is why one question per request is the recommended default. What the numbers add is that the loss is large enough to show up in the overall score, not just in edge cases. The model is marketed on single-pass speed and measures better without the single pass. If you group anyway to chase throughput, you are paying for the speed twice — once in tokens and once in accuracy.

Calibration: closer than the accuracy gap suggests

Both cards publish calibration honestly, which is rare enough to be worth noting.

• Saved temperature — 1.554 on Flash vs 1.382 on the 27B.

• Development-set accuracy — 88.8% on 1,497 questions for Flash vs 91.3% for the 27B.

• Expected calibration error after temperature — 0.021 for Flash vs 0.014 for the 27B.

• Brier score — 0.163 vs 0.134.

Flash is less accurate and less well calibrated, as expected at one-seventh the size, but the calibration gap is 0.007 ECE — small enough that a threshold tuned on the 27B will often transfer. The 27B card is also candid that held-out decision data remains somewhat overconfident, with ECE around 0.05, so neither model is a substitute for fitting thresholds on your own data. Perplexity's documentation says exactly that: benchmark both on labelled data at your intended thresholds and keep Flash only if it clears your accuracy target.

Self-hosting: 9 GiB against 52 GiB

Both are Apache-2.0, so the hosted price is a convenience rather than a lock-in. The hardware difference is the sharpest separation between them.

• Weights — roughly 9 GiB BF16 for Flash vs roughly 52 GiB for the 27B, plus working memory on both.

• Hardware — Flash fits a 16 GB consumer card; the 27B needs a serious accelerator or a multi-GPU split.

• Serving — neither drops into a stock causal server unchanged. Full-attention layers run noncausally, and prompts written for v1.1 do not carry over.

• Context — 262,144 tokens on both by default, with training only validated to about 32,000 and the cards warning that longer inputs are less tested.

Self-hosting Flash is the only version of this comparison where the 4B wins unconditionally. A single 16 GB card, a permissive licence, and no per-token bill is a genuinely different product from a 52 GiB checkpoint that needs a serving team.

A decision rule you can apply

• One question per state, high volume — Flash. The price advantage is real and the accuracy loss is concentrated in knowledge tasks you can route elsewhere.

• Two or more questions per state — the 27B. At two it is a tie on price, from three it is cheaper, and it is more accurate in joint mode; the gap widens with every added question.

• Knowledge-heavy or rubric-heavy judgments — the 27B. A 14.3-point deficit on knowledge is not something a better prompt closes.

• Retrieval gating and tool choice — Flash is defensible. The gaps there are 3.6 and 7.7 points, and the workload is exactly what the model was built for.

• On-device or single-GPU deployment — Flash, with no real alternative in this pair.

• Vision — either, with the 27B ahead by 4.9 points; if you already run the 27B for text, splitting vision to Flash buys little.

Whichever side of the split you land on, the decider is the cheap part of the pipeline. The generation it gates is where the money goes, and that is the layer worth optimising. OrcaRouter puts 200-plus models behind one key with no markup on provider list prices, so a price cut upstream lands the same day, and automatic failover covers the case where the gate sends a request to a model that is degraded. The routing DSL composes models we serve; neither pplx-decider checkpoint is among them, so a Flash-versus-27B split has to live in your own code. The hosted decider in our catalogue is TypeSafe's Jev, as jev-1.13 and jev-1.14.

The test neither vendor has published

Everything above is a decision made from vendor documentation. The test that would settle it is boring and specific: take a thousand real requests, label them, and run both models at your intended threshold with one question and with three. Record accuracy, calibration error and total billed tokens. The prediction from the published numbers is that Flash wins the single-question workload on cost and loses the three-question one on both cost and accuracy. If that holds, the choice is a property of your request shape, not of your budget — and the team that measures it will pick correctly while everyone reading the price list picks the model that is 50% cheaper on paper and 50% dearer in production.