Perplexity Portable Computer is now available on Windows systems with supported NVIDIA graphics hardware, extending a local-first approach previously associated with Linux and DGX Spark. NVIDIA announced the Windows availability on 14 September. The headline brings agent-style task execution to a broader operating-system audience, but it comes with a hardware qualification that should not be lost in the excitement.
According to NVIDIA's announcement, the supported GeForce RTX and RTX PRO configuration requires at least 24GB of graphics memory. That is video memory on the graphics hardware, not simply 24GB of ordinary system RAM. The announcement therefore does not mean that any Windows laptop, or even any computer carrying an RTX badge, can run this configuration.
Local execution changes the buying question
The immediate decision is partly a software question and partly a hardware one. A person who already owns a suitable machine can evaluate a different proposition from someone considering an upgrade specifically for this service. Before spending money, the latter should confirm compatibility with the actual product requirements and consider whether the intended workload justifies dedicating local computing resources to it.
NVIDIA describes local tasks as not consuming credits and says permission is sought before work moves to the cloud. It also identifies a built-in browser and connections to familiar workplace services. These are useful distinctions, but “local” should be treated as a property of a particular processing step rather than an assumption about every possible action in an extended workflow.
That is especially relevant when a task mixes private files with information that changes on the public internet. Reading a document, drafting a response and retrieving fresh information can involve different components. A user evaluating the system should ask which step is running where, rather than rely on a single label applied to the overall application.
Perplexity positions it as a connected workspace
Perplexity's official Windows announcement describes availability for Pro and Max users, including individual and enterprise offerings, through its Windows app. It also points to scheduled local tasks and desktop MCP connections. Subscription eligibility and hardware compatibility are separate checks: satisfying one does not establish the other.
The company's earlier local-first introduction frames Portable Computer around working with files, analysing information and carrying out multi-step tasks, with search or deeper research available when needed. That background helps explain the Windows release. It is not evidence that every earlier demonstration has been repeated with identical performance on every supported Windows machine.
For everyday work, the relevant comparison is not just a local model against a hosted chat window. A connected assistant needs access to the right files, a way to use the relevant tools and a clear point at which the user can inspect its plan. Those surrounding functions can determine whether a technically capable model is useful on a real task.
A demo illustrates the boundary, not a benchmark
An official Portable Computer workshop provides a helpful architectural example. In that demonstration on DGX Spark, a local model plans work and routes tools, while a financial-document task processes statements locally and uses cloud search when fresh market information is needed. The example illustrates a hybrid workflow; it is not a Windows benchmark or independent verification of performance.
The workshop also shows why planning and tool selection matter alongside text generation. An assistant carrying out a task needs to decide what information is missing, which available action addresses that gap and when an external service is required. Users should evaluate the resulting sequence as well as the final answer. A polished result alone does not reveal whether the chosen route was appropriate.
For a first trial, a low-risk collection of documents is a better starting point than a broad set of sensitive workplace files. The reviewer can define a clear expected output, inspect the proposed steps and check the answer against the originals. This is a suggested evaluation method, not a claim that the product automatically applies that procedure.
Keep recurring work observable
Scheduled tasks add another consideration: a process that succeeds once may face missing files, changed permissions or different inputs later. A useful trial should therefore include how a failure is surfaced and what the user will inspect afterwards. Recurrence is valuable only when the owner can tell whether the expected work actually happened and whether the result still makes sense.
Local operation also shifts some practical responsibility towards the machine running the work. Users assessing the arrangement should consider where the computer will be, whether it is available when needed and whether the chosen tasks compete with other work. Those are deployment questions rather than announced product limitations, and the answers will differ between a personal desktop and a managed workstation.
The Windows release is a meaningful expansion for people with eligible hardware who want more control over where parts of an AI workflow execute. It should not be read as universal Windows compatibility or an assurance that every task remains entirely offline. The strongest starting point is a specific job, a verified configuration and a clear understanding of when the workflow uses local resources or asks to reach beyond them.