On August 25, 2026, Perplexity began offering "Portable Computer," a version of its AI agent "Perplexity Computer" that runs on NVIDIA DGX Spark. The original Computer, which launched in February, bundled multiple models and sub-agents in the cloud. The new version moves the models, conversation history, and task execution engine onto the device itself. It doesn't abandon search or cloud models—it simply calls on them only with user permission when needed. This boundary design, where "local is the default and cloud is the exception," sits at the center of this shift.
Moving the Default Execution Location from Cloud Computer to On-Device
In Portable Computer, the local model runs alongside a planner that breaks down tasks and a router that decides which tools to call, both operating on the device. A scheduler that manages long-running processes, a persistent task queue, and an index for local search are also housed on the same machine. If file analysis or code processing can be completed on-device, there's no need to send that data to Perplexity's servers. Work done locally also doesn't consume service credits.
However, local-first doesn't mean fully offline. When up-to-date information is needed, Perplexity Search is used, and for more difficult reasoning, the system can request advice from more than 15 cloud models. Connected services include Google Drive, Gmail, Slack, and GitHub. When on-device content needs to be sent to an external service, Portable Computer reportedly indicates the target and asks the user for permission.
Cloud-side models never directly manipulate files or tools on the device. The local execution engine selects the relevant context, screens it for personal information, and sends only what's been approved. What the cloud model returns is advisory text—the authority to actually execute tools remains on the device. Privacy isn't protected by "never communicating" but by controlling, on a per-task basis, exactly what leaves the device.
The same philosophy applies to voice input. NVIDIA's Nemotron 3.5 ASR Model converts speech to text on-device, so recordings and local file operations never need to be sent to the cloud. For work that involves giving verbal instructions while viewing confidential documents, knowing exactly which path the data travels matters just as much as model accuracy.
A Design Built to Offset Performance Degradation Beyond 100K Tokens
The initial version uses Qwen 3.8 27B, or PPLX 27B, Perplexity's post-trained version of the same model. NVIDIA's 30-billion-parameter MoE model, "Nemotron 3.5 Lightning," is planned as an additional option. Beyond model selection, Perplexity also rebuilt its execution engine so that smaller local models could sustain long-running work.
Qwen 3.8 27B has a stated context length of roughly 260K tokens, but Perplexity's experiments found that performance began to degrade with inputs beyond 100K tokens. This isn't a hard input ceiling but rather a trend the company observed empirically. To address this, the core system prompt and always-on tools are kept small, while skills for research, data analysis, and document creation are loaded only when needed. As conversations grow longer, older context is summarized and folded back into the effective range.
The handling of connected apps was also made lighter. Because typical MCP server tool definitions themselves consume context, Perplexity converted frequently used functions into short command-line tools. The goal is to reduce the descriptive overhead the model carries and redirect tokens toward actual documents and work history.
Self-verification is another mechanism used to shore up accuracy. Hooks that monitor the model's own decisions and execution prompt it to double-check its work, hunting for errors before submitting results. Tools run inside OS-level sandboxes that restrict processes, accessible files, and network connections. When a sandbox isn't available, the system doesn't loosen permissions to continue—it halts the tool call instead.
What's notable here is a shift away from the race to scale up model size and toward how to allocate limited capability. Portable Computer doesn't hide the weaknesses of a smaller model. It separates effective context, the overhead of tool definitions, and reasoning power on hard problems, and compensates for each through compression, lightweight design, and cloud advice.
How to Read an 85.4% Self-Reported Score
Perplexity states that on its internal benchmark, the "Local Knowledge Work Bench" — comprising 53 everyday knowledge-work tasks — the PPLX 27B version of Computer scored 85.4%. When the underlying Qwen 3.8 27B model was run on the same Computer harness, it scored 82.6%, compared to 77.6% for the general-purpose agent framework Pi and 74.0% for Hermes. Each task was attempted three times.
| Benchmark | Computer | Pi | Hermes | Notes on Interpretation |
|---|---|---|---|---|
| Local Knowledge Work Bench (53 tasks, Qwen 3.8 27B) | 82.6% | 77.6% | 74.0% | Perplexity's internal benchmark |
| BrowseComp (1,266 questions) | 66.7% | 50.2% | 43.9% | Search backends are not identical |
| ParseBench-100 (100 tasks) | 65.1% | 13.9% | 34.6% | Average score for document comprehension |
When the same underlying model is used across comparisons, differences due to the harness itself become easier to see. However, on BrowseComp, Computer used Perplexity Search, while Pi and Hermes used Brave. Because the 66.7% gap includes differences from the search engines themselves, it can't be attributed solely to the execution engine. The Local Knowledge Work Bench also hasn't been made public yet; Perplexity says it plans to release it alongside a technical report on PPLX 27B.
On harder coding challenges, the division of labor between local and cloud execution shows up clearly in the numbers. Across 89 tasks in Terminal Bench 2.1, local execution with Qwen 3.8 27B scored 59.6%. A configuration that consulted Claude Opus 5 for advice rose to 73.0%, with an estimated API cost of $0.415 per run. Using Claude Opus 5 alone scored 82.4%, at a cost of $0.65.
In other words, this isn't an announcement that on-device execution matches frontier-model performance. In Perplexity's evaluation, consulting the cloud based on task difficulty narrowed part of the performance gap. In real-world use, organizations will need to measure how many tasks can be completed locally, what information gets passed to advisory models, and how much external API costs contribute to total cost.
The First Entry Point Is Limited to DGX Spark and Linux
As of launch, Portable Computer is available only to Perplexity Pro or Max subscribers who own an NVIDIA DGX Spark running Linux. It can reportedly be installed with one click from the Perplexity app. Support for Windows, GeForce RTX, RTX PRO, and DGX Station is planned but not yet available.
DGX Spark is a compact machine built around the GB10 Grace Blackwell chip, featuring a 20-core Arm CPU, 128GB of unified LPDDR5x memory, and 4TB of NVMe storage. Its FP4 compute performance reaches a theoretical maximum of 1 PFLOP using sparsity. While it's built with enough headroom to run a 27B-class model continuously, it isn't a configuration that can simply be extended to a typical Windows PC.
Even the benefit that "local processing doesn't consume credits" comes with caveats. The cost of purchasing a DGX Spark, its power consumption, and device management overhead still remain. Using cloud search or advisory models can also incur networking and API costs. For enterprises evaluating the return on adoption, it won't be enough to track credit usage alone—they'll need to record the local completion rate, the number of external data transmissions, and the total cost of completing each task.
Whether Portable Computer evolves into a widely used product will first be determined by whether the Windows/RTX version arrives as planned. After that, the key questions are whether the undisclosed benchmark set gets published and independently reproduced, and whether the permission screens can show, in sufficient detail, exactly what information is leaving the device. If these pieces come together, AI agents that handle sensitive data will shift from being tools premised on cloud use to tools grounded in local compute resources at hand.