---
type: "post"
id: "perplexity-s-pplx-decider-v1-2-is-a-c3587d"
slug: "perplexity-s-pplx-decider-v1-2-is-a-c3587d"
title: "Perplexity’s pplx-decider-v1.2 is a new version of its decision model"
description: "Perplexity’s pplx-decider-v1.2 is a new version of its decision model, built on the same Qwen3.8-27B backbone as its predecessor."
retrieval_nugget: "Perplexity’s pplx-decider-v1.2 is a new version of its decision model, built on the same Qwen3.8-27B backbone as its predecessor."
published_at: "2026-11-02"
updated_at: "2026-11-07"
record_date: "2026-11-02"
date_kind: "published_at"
topics: ["agent-economics"]
entities: ["Perplexity","pplx-decider-v1.2","pplx-decider-v1.1-27b","Qwen3.8-27B"]
related_patterns: ["agent-economics-moves-to-completed-work"]
novelty_label: "same_event"
prior_refs: []
source_url: "https://huggingface.co/perplexity-ai/pplx-decider-v1.2"
source_urls: ["https://huggingface.co/perplexity-ai/pplx-decider-v1.2"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:perplexity-s-pplx-decider-v1-2-is-a-c3587d"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/perplexity-s-pplx-decider-v1-2-is-a-c3587d/","markdown":"https://newruntime.com/posts/perplexity-s-pplx-decider-v1-2-is-a-c3587d.md","json":"https://newruntime.com/posts/perplexity-s-pplx-decider-v1-2-is-a-c3587d.json"}
markdown_url: "https://newruntime.com/posts/perplexity-s-pplx-decider-v1-2-is-a-c3587d.md"
---

# Perplexity’s pplx-decider-v1.2 is a new version of its decision model

## Retrieval answer

Perplexity’s pplx-decider-v1.2 is a new version of its decision model, built on the same Qwen3.8-27B backbone as its predecessor.

## Summary
Perplexity’s `pplx-decider-v1.2` is a new version of its decision model, built on the same Qwen3.8-27B backbone as its predecessor. Its model card reports higher Decision Index scores and a joint-request mode that answers multiple questions about one state in a sequence, at about the cost of one question. For builders, the notable claim is a cheaper way to compare choices sharing context, though the supplied evidence is Perplexity’s own model-card material.

## What happened
Perplexity published the `pplx-decider-v1.2` model on Hugging Face. The card identifies it as the successor to `pplx-decider-v1.1-27b`; both use the same Qwen3.8-27B backbone. The release therefore presents itself as an iteration on the decision-model product rather than a change to a different underlying model family. The supplied material does not give a release date.

The card’s central feature is support for joint requests. Rather than sending one request for each question about a state, a user can provide the state and all the questions in one sequence. The model produces a readout after each question. Perplexity says that several questions about the same state cost about as much as asking one question. That claim makes the release relevant to workloads where a system must evaluate multiple choices against shared context; the card does not specify a monetary price or provide a cost breakdown.

Perplexity reports a Decision Index of 68.09 when using joint requests, compared with 67.75 when using one question per request. The v1.1 score shown for comparison is 62.30. For vision, the card reports a Vision Decision Index of 77.43, versus 73.22 for the predecessor. These are figures supplied in the model card; the evidence provided here does not include benchmark methodology, test-set details, or independent replication, so the numbers describe the publisher’s claims rather than an independently established ranking.

The model accepts images up to 1.6 megapixels. Its weights require about 52 GiB in BF16, a substantial memory requirement for teams considering local deployment. The card lists an Apache-2.0 license. The supplied material does not state a hosted API, commercial service price, hardware configuration for the scores, or supported inference providers. Those details should not be inferred from the repository listing or license.

## What the archive adds
This is a new version in an existing Perplexity decision-model thread, not an unrelated first appearance. The archive covered [pplx-decider-v1.1-27b](https://newruntime.com/posts/pplx-decider-v1-1-27b-hugging-face-repo-44e8c0/), whose visible claim was a benchmark-score change with evaluation context still unresolved. A later [Decider for Mac release](https://newruntime.com/posts/perplexity-releases-decider-for-mac-to-run-pplx-25c390/) described a local Mac application serving pplx-decider-flash-v1.2. This model-card release adds a new version, joint requests, and new reported scores; it does not resolve the evaluation-context question.

## Trend signal
The joint-request claim supports [agent economics moves to completed work](https://newruntime.com/patterns/agent-economics-moves-to-completed-work): the relevant efficiency unit can be a set of decisions over shared context, rather than the count of separate model calls. The evidence is narrow, however. The card says several questions cost about as much as one; it does not report cost per verified completed task or establish that this pattern generalizes beyond this model.

## Why now
The archive places this release after Perplexity’s earlier v1.1 model and the Decider for Mac application using a flash v1.2 model. The new card gives builders another point in that product sequence: a full-size v1.2 model with joint requests and vision scores. The supplied source does not explain why Perplexity released it now or describe a launch strategy, so the timing should not be read as evidence of a broader market shift by itself.

## Connections to other events
The closest connection is the earlier Perplexity Decider for Mac release, which made a related flash model available through a local application. The present card concerns `pplx-decider-v1.2`, not that flash model, and the supplied material does not establish that the two share deployment behavior. The archive also includes other decision-model releases, including FrontiersMind’s Lumma-Fev-v2, but shared terminology alone is not evidence that their methods or results are comparable.

## Why it matters
Joint requests offer a concrete design option for systems that repeatedly ask questions about the same state: batch those questions rather than resending the context separately. If the card’s cost claim holds for a team’s workload, this could reduce repeated-request overhead while preserving a readout for each question. The slightly higher reported score for joint requests than for separate requests also suggests batching need not automatically reduce the model-card metric, though the difference is small and the evidence supplied does not establish its significance.

The practical trade-off is deployment weight. About 52 GiB for BF16 weights is a meaningful resource requirement, and an Apache-2.0 license does not remove hardware or operational costs. Teams should distinguish the reusable interface idea—shared state plus multiple questions—from the specific model’s reported performance. Before relying on it, they need to test their own decision tasks and determine whether joint outputs remain reliable when questions interact or vary in importance.

## Limits and uncertainty
The source material gives publisher-reported index values, but no benchmark protocol, sample sizes, uncertainty intervals, or independent results. It does not explain what the indices measure or whether scores are comparable across versions and request modes under identical conditions. The cost statement is qualitative: there is no token accounting, latency, throughput, or hosted price. The card excerpt also does not establish API access, inference-provider availability, or a release date. Image resolution and weight size are stated, but do not establish real-world vision performance or deployment requirements beyond the BF16 estimate.

## Reader takeaway
The useful change is not simply a higher score: v1.2 says it can answer several questions about one shared state in a joint request, at roughly the cost of one question. That could matter in decision workflows with repeated comparisons. Treat the benchmark gains as model-card claims, and validate both the score and the batching economics on your own tasks before building around them.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Agent Economics](https://newruntime.com/topics/agent-economics.md): Explore the agent-economics topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)