Perplexity Computer on Mac Adds Fully Local AI, With Cloud Access Optional

Perplexity Computer on Mac now offers fully local operation, according to the company, moving the model and agent onto the computer instead of requiring cloud reasoning. The announcement changes where sensitive work can happen. It also introduces a distinction users need to understand: accessing local files and processing them locally are separate capabilities.

Perplexity says the new mode keeps task planning, reasoning, and file processing on supported Apple silicon Macs. Cloud assistance remains available with user authorization. That makes the central choice more specific than “desktop versus web.” Users can decide whether a task stays on their machine or draws on remote services.

Apple provides a useful reference point, having developed separate on-device and server models for Apple Intelligence. Perplexity brings that location choice into a desktop agent, software that plans actions and uses tools. The immediate question is which everyday workflows can finish locally without sacrificing the accuracy, application access, or oversight users require.

What Perplexity Computer on Mac Actually Changes

The announcement moves the decision-making part of an agent onto the Mac, extending beyond access to files stored there.

In its fully local announcement, Perplexity says the model, agent runtime, and task execution can operate on-device. It names Qwen 3.6 and PPLX Pro as local model options. The company recommends at least 36 GB of memory on supported Apple silicon hardware.

That recommendation deserves attention because a desktop app and a local AI system have different hardware demands. Installing an interface does not establish that every Mac can comfortably run its underlying model. Buyers should distinguish the app’s general compatibility from the requirements of its fully local mode.

Perplexity also retains Hybrid Compute, which combines cloud reasoning with local handling of private material. The fully local option starts task planning on the Mac instead. According to the company, users can authorize escalation for online information, connected applications, or additional reasoning.

The practical change concerns who controls that escalation. A task that starts locally should have a clearly understandable boundary before information reaches another service. Whether the interface makes that boundary obvious will matter as much as the model selection screen.

Consider a hypothetical project review involving downloaded notes, a budget workbook, and an unfinished update. The useful outcome is an accurate draft tied to those materials. A local agent would need to inspect the inputs, reconcile inconsistencies, and save a reviewable result without remote reasoning.

That example illustrates the capability being promised, rather than an independently observed result. It also shows why a chatbot response alone would be insufficient evidence. Completing the workflow requires reliable reading, sensible planning, correct edits, and a clear record of what changed.

The announcement therefore creates a broader evaluation question. Can a local system finish useful work across the applications people already use? A model that answers a prompt successfully has cleared only part of that challenge.

For readers encountering “no Wi-Fi” descriptions, the qualification is straightforward. Offline reasoning can support tasks whose inputs and tools are already available locally. It cannot retrieve a newly published webpage or deliver an email through a disconnected network.

Initial installation and model downloads are another separate issue. A system can require connectivity during setup and still perform later tasks offline. Testing should identify the stage being measured instead of treating installation, execution, and delivery as one undifferentiated process.

Local File Access Was Already Here

The new claim concerns where reasoning happens, while earlier Mac releases already offered local application and file access.

Perplexity’s desktop agent launch documented local editing, computer use, Comet browsing, and voice orchestration in April. Its examples included organizing folders, drafting email, and working with Notes and Calendar. Those capabilities establish that Mac integration predates this announcement.

This history matters because “runs on your Mac” can describe several arrangements. An application can execute clicks locally while a remote model chooses those clicks. It can read a document from local storage while sending its contents elsewhere for analysis.

Neither arrangement becomes fully local merely because the interface sits in the menu bar. The meaningful distinction is whether the task’s reasoning depends on a remote service. That distinction determines what an offline test needs to establish.

For knowledge workers, this separates convenience from control over processing location. Convenient access reduces copying between applications. Local reasoning addresses a different concern: whether the material must leave the computer to produce an answer or action.

The pressure falls first on desktop agent vendors whose messaging leaves those arrangements unclear. Once users can select an execution location, competing products need to explain their own defaults. Broad privacy language becomes less informative than a concrete description of what travels where.

Enterprise buyers face a related documentation problem. A team evaluating an assistant needs to understand file access, processing location, external connections, and output handling separately. A single “local” label cannot answer all those questions.

This does not establish that organizations should replace their existing systems. It changes the questions they can ask during evaluation. A vendor claiming local operation should be able to describe the conditions under which that claim holds.

Developers face pressure at the application boundary. If an agent can reason locally but cannot reliably inspect or update a useful document, the workflow still stalls. Application integration and model capability must develop together.

A related distinction appears in personal knowledge management: collecting information does not automatically make it useful later. An agent needs relevant, accessible material before it can act on a request. Processing location adds another requirement to that existing information problem.

The announcement’s timing is therefore best understood through product progression. Perplexity already connected Computer to the desktop. Its next claim puts the reasoning process there too, allowing users to evaluate local execution as a complete workflow.

The Choice Between Local Control and Cloud Reach

Local operation changes the default location of work, while cloud access remains useful for tasks requiring information beyond the machine.

A local task has an identifiable information boundary. It can work from documents, messages, and other material already accessible on the computer. Its answers remain limited by those inputs, regardless of how capable its reasoning becomes.

Cloud-connected work has a different advantage. It can incorporate current information and reach services unavailable offline. The tradeoff involves the handling of information across that boundary, alongside the quality and speed of the resulting work.

A hypothetical analyst reviewing a downloaded report illustrates the difference. Summarizing the report and comparing its internal sections can remain a closed task. Checking whether its assumptions still match current events introduces an external information requirement.

The same distinction applies to communication. Preparing a reply from locally available correspondence is separate from sending that reply. A useful interface should make the transition visible, particularly when the message contains material from private documents.

This is why the strongest interpretation of local AI avoids treating connectivity as an automatic failure. The relevant question is whether external access is necessary, understood, and authorized. A local starting point can coexist with deliberate online steps.

Apple offers a concrete industry comparison. Its foundation model research describes separate on-device and server models, including an approximately three-billion-parameter local model. That work establishes a precedent for designing different models around different execution environments.

Apple’s approach also supplies a caution against simplistic comparisons. A model designed for on-device features and a desktop agent coordinating applications face different evaluation demands. Their shared interest in local processing does not establish equivalent capabilities.

Perplexity’s competitive proposition centers on completing tasks across a user’s working environment. Apple’s published research provides context for the underlying location choice. Neither source, by itself, establishes which system completes a particular office workflow more accurately.

The clearest competition is therefore between execution approaches: local reasoning with bounded inputs and cloud-assisted work with broader reach. Individual products can offer both. The meaningful comparison concerns how well each approach serves a specific task.

For an organization, that suggests evaluating classes of work separately. Reviewing downloaded material, drafting internal text, and organizing a project folder have different requirements from monitoring current developments. A single overall agent score would conceal those differences.

Local AI also changes the role of hardware ownership. Processing moves onto a resource the user controls, but that resource has finite memory and competing workloads. Any assessment should account for the computer’s ordinary responsibilities alongside the agent.

Cloud assistance can remain the appropriate choice when it produces a more useful result under acceptable conditions. Fully local execution earns its place when it completes the work within the user’s intended boundary. The value lies in making that choice practical and explicit.

Permissions Still Determine What the Agent Can Do

Keeping reasoning on-device addresses processing location, but the agent still needs carefully scoped authority to act.

Perplexity’s Mac permission guide describes Accessibility access for clicking and typing, screen recording access for observing the interface, and disk access for files. It also describes connecting folders and approving sensitive actions. These are meaningful permissions, even when processing stays local.

Each permission exposes a different part of the working environment. An agent that can see an application has different capabilities from one that can edit its contents. Evaluation needs to account for both visibility and action.

The distinction becomes especially important when a task spans applications. A request to prepare a project update might involve private notes, a spreadsheet, and a communication draft. Permission to read those inputs should not become an ambiguous instruction to publish the result.

A local model can still misunderstand a request. It can select an outdated document, confuse similarly named files, or produce an incorrect calculation. Moving that model onto the computer does not remove the need to inspect consequential outputs.

The security question also extends beyond intentional instructions. Prompt injection occurs when content encountered during a task tries to redirect the agent’s behavior. Locally stored material can contain such content, so disconnected operation does not eliminate that category of risk.

That is a general risk assessment, rather than a finding that this release has a particular vulnerability. The practical implication is that location and authority need separate scrutiny. A private execution environment still benefits from clear limits on what the agent may change.

For example, a hypothetical folder cleanup task should distinguish grouping files from deleting them. A drafting task should distinguish saving a document from sending it. Those boundaries make results easier to review and mistakes easier to contain.

Buyers should also examine how the product explains its activity. A finished document alone may conceal which inputs shaped the result. An understandable account of the work helps users identify missing sources, incorrect assumptions, and unintended edits.

There is a usability tension here. Frequent approval requests can interrupt useful automation, while broad standing permissions can obscure consequential actions. The product needs to place review points where they help users make informed decisions.

This gives independent reviewers a concrete assignment. They should examine whether the permission model matches the task and whether the system stops at the expected boundary. A demonstration of successful output cannot answer those questions alone.

For knowledge workers, the lesson is practical. Private processing is valuable when combined with reliable execution and understandable control. The most useful product will make all of those properties visible during ordinary work.

Hardware Claims Need Workflow Evidence

Evidence that a model runs locally does not establish that a desktop agent completes real tasks reliably or efficiently.

Perplexity has published technical work that makes its local inference effort more inspectable. Inference means running a trained model to generate outputs. Its public local inference server, Lily, targets a specific Qwen checkpoint on supported Apple hardware.

The repository documents a narrow implementation with explicit requirements and limitations. That is useful engineering evidence because it identifies what the software accepts and how it operates. It should not be treated as a complete specification for the consumer Mac application.

A desktop agent contains more than an inference server. It needs to interpret requests, select tools, handle application state, and recover when actions fail. Performance in one component does not automatically predict the experience across that chain.

This makes task completion a better primary measure than the speed of generated text. A fast response followed by incorrect edits wastes time. A slower run that produces an accurate, reviewable artifact can be more useful.

Reviewers should define success before starting a test. A document task might require preserving named facts and saving to the correct location. A spreadsheet task might require correct formulas and no unintended changes outside the requested range.

Those criteria should remain the same when comparing local and cloud-assisted execution. Otherwise, a comparison risks rewarding whichever mode received the easier assignment. Identical inputs and expected outputs make the result interpretable.

Hardware reporting needs similar discipline. A useful review identifies the machine, available memory, model choice, and other applications running during the task. Without that context, readers cannot tell whether the experience applies to their own setup.

Laptop behavior deserves attention alongside desktop demonstrations. Readers need to know whether ordinary work remains responsive while the agent operates. Sustained tasks should be assessed as working sessions, rather than isolated moments of successful generation.

Offline testing also needs a defined scope. Disconnecting after setup can test whether a local task requires remote reasoning. It does not establish that every product feature works offline or that all background activity has been characterized.

Network observation can provide additional evidence about connections attempted during a task. Interpreting that evidence requires care because account checks, updates, and task processing serve different purposes. Reviewers should describe what they observed without assigning unsupported explanations.

Privacy claims require the same restraint. The announcement supports reporting what Perplexity says its local mode does. Independent verification would require examining behavior across representative tasks, settings, and transitions into cloud assistance.

The strongest evidence would combine accurate outputs, understandable permissions, and repeatable behavior under stated conditions. Until such testing is available, the release is a documented product claim with a clear evaluation path. It is not a universal assurance about every Mac workflow.

Three Signals Will Show How Useful Local Computer Becomes

The next evidence should establish offline completion, visible cloud transitions, and repeatable performance on supported Macs.

The first signal is independent testing of complete offline workflows. Over the coming months, reviewers should publish the inputs, expected results, and resulting files for representative tasks. That would strengthen confidence more than another short demonstration.

The most informative tasks will involve ordinary work with enough complexity to expose errors. Conflicting notes, revised documents, and incomplete instructions are useful challenges. They reveal whether the system recognizes uncertainty or silently fills gaps.

A successful result would show that local execution extends beyond a self-contained chat response. Repeated failures at application boundaries would narrow the practical value of the launch. Both outcomes would help users identify suitable work.

The second signal is how the product handles movement into cloud assistance. Readers should watch for clear explanations of why an external step is needed and what information it uses. The interface should make the execution choice understandable during the task.

That visibility would strengthen the claim that users control the processing boundary. Confusing transitions or unclear defaults would weaken it. The issue is whether a person can make an informed decision without reconstructing the system’s behavior afterward.

This matters most for mixed tasks. A private document review followed by current research crosses a meaningful boundary. Good product design should preserve that distinction even when the overall request sounds like one continuous assignment.

The third signal is repeatable performance across the supported hardware range. Independent tests should compare completion quality and working-session behavior under disclosed conditions. A result on a well-equipped desktop should not stand in for every supported computer.

Consistent results would make the feature easier for teams to evaluate and deploy. Large differences between configurations would make hardware guidance more important. Either finding would be more useful than an undifferentiated claim that local AI has arrived.

Adoption will depend on the intersection of these signals. Users need work that finishes, boundaries they understand, and performance that fits their machine. Strength in only one area will leave important parts of the experience unresolved.

For now, Perplexity Computer on Mac offers a concrete change in execution choice. The company says a task’s reasoning can stay beside its local inputs, with remote assistance available when authorized. That is a meaningful capability to evaluate, particularly for document-heavy work.

Choose a representative task before drawing a broader conclusion. Use copies of ordinary working files, specify the expected output, and decide which actions require review. Compare the result with the source material, then repeat the assignment under the same conditions. If the task needs current information, examine how the product explains that transition. Keep processing location, accuracy, and application control as separate questions throughout the evaluation. The useful question is whether Perplexity’s local mode completes your work within the boundary you intended. Start with a bounded document workflow and judge the finished artifact, the changes made, and the decisions you were asked to approve.