MacPaw is betting that the next important AI distribution battle will not be fought only between chatbot providers, but inside the software marketplaces where users discover, pay for, and run applications. Its partnership with Liquid AI is intended to give Setapp developers access to locally hosted inference, cloud models, and eventually a more flexible way to combine both. The commercial prize is larger than a faster assistant: it is control over the layer that connects AI models, applications, billing, privacy, and user data.
The strategic question is who controls the AI workflow
MacPaw’s partnership with Liquid AI arrives at a moment when the AI market is moving beyond the simple question of which company has the strongest model. Model quality still matters, but the next phase of competition will increasingly be determined by where inference happens, how developers pay for it, how user data is stored, and which company owns the relationship with the customer.
That makes MacPaw’s move strategically significant. The Ukraine-based software company is not merely adding an AI feature to an existing product. It is working toward an infrastructure layer that could support its own applications and, eventually, applications built for its Setapp subscription marketplace.
The partnership centers on two systems. The first, called Elix, is an on-device inference system designed to run AI workloads locally. The second is a local memory system that MacPaw plans to use in Eney, its AI assistant. Together, they point to a model in which assistants and agentic workflows can operate directly on a user’s computer, including when the device is offline.
For MacPaw, this creates a potential advantage over marketplaces that treat AI as a collection of cloud services. If Setapp can help developers decide which tasks should run locally and which should be sent to a hosted model, it could become more than a subscription bundle. It could become a control plane for hybrid AI.
That distinction matters because cloud access is becoming both an economic and strategic constraint. Every AI request sent to a remote model can generate infrastructure costs, introduce latency, create privacy concerns, and expose a developer to the pricing and availability decisions of an outside provider. Local inference does not remove those challenges entirely, but it can reduce the number of requests that need to leave the device.
The opportunity for MacPaw is to make that trade-off easier for developers and more understandable for users. The risk is that building such a platform is much harder than announcing support for local models. It requires reliable performance across devices, clear billing, strong developer tools, sensible privacy controls, and an application ecosystem willing to adopt the infrastructure.
Setapp wants to become an AI distribution layer
Setapp already gives MacPaw a useful strategic asset: a paying software audience. The company says the service has more than 150,000 paying users. That installed base is modest compared with the largest consumer technology platforms, but it gives MacPaw something many AI infrastructure startups lack—a direct relationship with customers who are already accustomed to discovering and using software through a subscription.
The company says it wants to prepare Setapp for AI applications through credit-based plans that charge according to the number and complexity of AI operations. This is an important change from a conventional software subscription. Traditional applications usually have a relatively predictable marginal cost for each additional user. AI applications can create highly variable costs depending on how frequently users invoke a feature, the size of the model involved, the length of a context window, and whether an action requires a sequence of tool calls.
A subscription that bundles unlimited AI usage can therefore become difficult to manage. Heavy users may consume substantially more inference resources than light users, while developers may have limited control over the cost of the underlying models. Credit-based pricing is one way to make that variability visible.
But it also introduces friction. Users understand paying for software access more easily than they understand paying for “operations.” A simple request, a complex research task, and a multi-step agentic workflow may all feel like the same product feature even if they create very different costs. If Setapp adopts a credit model, it will need to explain those differences without making the service feel like a utility meter.
The business case depends on whether MacPaw can turn that complexity into a platform advantage. A developer using Setapp could potentially reach customers, choose among local and cloud inference options, and use a shared mechanism for billing AI activity. That could lower some of the operational burden associated with building an AI application.
The strongest version of this strategy would make Setapp a marketplace where developers do not have to choose between local and cloud AI at the architecture stage. They could use local inference for private, low-latency, or routine tasks and invoke cloud models when a workflow requires broader capability. In theory, that makes applications more resilient and allows developers to balance cost against quality.
The weakness is that marketplaces succeed only when they create clear value for both sides. Developers need distribution, monetization, and technical support. Users need a compelling selection of applications at a price that feels predictable. MacPaw must show that its AI layer improves those economics rather than adding another abstraction between developers and the models they already know how to access.
Local inference is a business model, not just a privacy feature
On-device AI is often presented primarily as a privacy technology. That is a legitimate benefit, particularly for assistants that process personal files, messages, schedules, or work documents. If a task can be completed locally, the user may avoid sending sensitive information to a third-party server.
Privacy, however, is only one part of the commercial argument. Local inference can also change the cost structure of an application. A model that runs on a laptop does not require a cloud request for every interaction. It can reduce dependence on usage-based API pricing and avoid the network delay associated with remote inference. It may also allow a product to remain useful during travel, in environments with weak connectivity, or during service disruptions.
These advantages are especially relevant for agentic workflows. An agent may perform several steps in response to one user instruction: classify a request, inspect local files, draft an answer, call a tool, revise the result, and ask for confirmation. If every step is sent to a cloud model, the cost and privacy exposure can grow quickly. A capable local model could handle routine decisions while reserving cloud access for tasks that genuinely require greater reasoning or broader knowledge.
That division of labor is likely to be more important than the simplistic choice between “local” and “cloud.” Most useful AI products will probably need both. Local models tend to face limits in scale, context, and frontier capability. Cloud models offer access to larger systems and more frequent upgrades, but they introduce recurring costs, latency, and data-handling concerns.
MacPaw’s proposed role is to help developers manage this hybrid architecture. That could become a meaningful source of differentiation if Setapp gives applications a consistent way to route work between local and hosted models. It could also allow MacPaw to negotiate or manage cloud access from multiple providers rather than tying developers to one model company.
The company plans to provide access to cloud models from companies such as Google, potentially giving developers a single environment for selecting between local and hosted AI. That approach would position MacPaw closer to an orchestrator than a model provider. Its value would come from coordinating different forms of intelligence and making the resulting system easier to package into applications.
Such a position can be commercially attractive, but it is not automatically defensible. Cloud providers already offer model-routing tools, developer platforms, and access to multiple models. Operating systems are also becoming more capable of exposing local models directly to applications. MacPaw will need to distinguish its platform through distribution, user trust, billing, workflow design, or some combination of those advantages.
Liquid AI’s hardware-specific approach raises the execution stakes
Liquid AI brings a different strategic proposition to the partnership. The company says it begins by selecting and tailoring an architecture for the target hardware before training the model. Its chief executive, Ramin Hasani, told TechCrunch that this hardware-specific design is intended to make intelligence more efficient when it runs directly on a device.
That approach aligns with the central challenge of local AI. A model cannot simply be moved from the cloud to a laptop and expected to deliver the same performance under the same conditions. Devices have limited memory, battery, thermal capacity, and processing power. A local system must be designed around those constraints.
The competitive implication is that model efficiency may become as important as raw benchmark performance. A slightly less capable model that responds quickly, consumes fewer resources, and handles common workflows reliably may be more valuable inside a consumer application than a larger model that requires a permanent network connection.
This is where Liquid AI’s hardware-aware strategy could complement MacPaw’s distribution ambitions. MacPaw brings applications, users, and a software marketplace. Liquid AI brings a technical approach focused on adapting models to the hardware on which they will run. If the collaboration works, the result could be a more integrated local AI stack than simply downloading a generic model.
But the same integration creates execution risk. Hardware environments are fragmented. Even within the Apple ecosystem, devices differ in processor generation, memory capacity, and performance characteristics. A system optimized for one configuration may not deliver the same experience on another. Supporting a broad range of hardware could require extensive testing and ongoing optimization.
The companies also say they are building a customization stack so models can use user input and become more adaptable over time. That could help local assistants become more useful as they learn a user’s preferences, work patterns, and recurring tasks. Yet a local memory system creates its own requirements. Users need to know what information is stored, how it is retrieved, how long it persists, and how it can be corrected or deleted.
Memory is therefore not just a product feature. It is a governance layer. An assistant that remembers the wrong information can become less useful or actively risky. An assistant that stores too much sensitive data can undermine the privacy argument that makes local inference attractive in the first place.
MacPaw will need to turn local memory into something users can inspect and control. Developers, meanwhile, will need clear interfaces for deciding what their applications may access. If the memory layer becomes a black box, it could create trust problems across the Setapp ecosystem.
Apple is both an enabler and a competitor
MacPaw’s strategy must also be understood against Apple’s role in local AI. Apple already provides local models to developers, giving applications a direct path to on-device intelligence within its ecosystem. That creates a favorable technical environment for MacPaw, but it also limits how unique Setapp’s proposition can be.
Apple controls the operating system, hardware, and increasingly the native AI experience. It can optimize local inference across its devices and distribute AI capabilities through system frameworks. MacPaw cannot match that vertical integration.
Instead, MacPaw is positioning Setapp as an alternative distribution and infrastructure layer. Its advantage would not be that it owns the hardware or the base operating system. Its advantage would be that it curates applications, handles subscriptions, offers a cross-application commercial model, and potentially gives developers access to both local and cloud AI through one marketplace.
That is a familiar strategic pattern in technology. A platform operating above the operating system can still create value if it solves problems that the underlying platform does not prioritize. Setapp could focus on independent developers, cross-application workflows, and flexible access to models from multiple providers.
However, it must avoid becoming dependent on features that Apple can replicate or restrict. If Apple continues improving native AI tooling, it may become easier for developers to distribute local AI applications without using Setapp. If Apple also expands its own assistant and application integration, MacPaw could face competition from the platform owner at both the infrastructure and user-experience levels.
MacPaw’s response is likely to be specialization. It can emphasize choice, including the ability to use cloud models from different vendors, as well as a marketplace experience designed around software subscriptions rather than operating-system features. The company may also benefit from serving developers who want a commercial channel without building their own subscription and usage-billing systems.
The question is whether that differentiation is strong enough to offset the scale advantage Apple enjoys. MacPaw needs to make Setapp useful even for developers who can already access local inference directly. That means distribution and monetization must be central to the value proposition, not secondary benefits attached to a technical platform.
The developer economics will decide whether the strategy works
For developers, the attraction of MacPaw’s proposal is straightforward: access to customers and a potentially simpler way to manage AI costs. But developers will evaluate the platform based on economics, not just technical ambition.
They will ask how revenue is shared, how credits are priced, whether local operations count against a user’s allowance, how cloud model costs are passed through, and whether customers can move away from the platform later. They will also need to know whether an application can use its own model providers or must rely on the services approved by Setapp.
The credit system could be a competitive advantage if it reduces uncertainty. MacPaw might use the marketplace to aggregate demand and negotiate access to cloud models, while local inference lowers the number of paid remote operations. Developers could then offer AI features without absorbing every variable cost themselves.
But credits can also make application pricing difficult. A developer may be able to estimate the cost of ordinary software support, but agentic behavior is less predictable. Users may trigger long workflows, repeat failed actions, or ask for tasks that require multiple model calls. If the application becomes expensive to operate, the developer must either limit functionality, raise prices, or pass more charges to the customer.
MacPaw’s platform will need tools for monitoring and controlling those costs. Developers should be able to set budgets, choose model tiers, define fallback behavior, and determine when a task must remain local. A marketplace that offers model access without operational controls would not solve the core business problem.
The most valuable tools may be policy tools rather than model tools. Developers need rules such as: keep personal documents on the device; use a cloud model only after user approval; use a smaller local model for classification; reserve a more expensive model for complex generation; and stop an agent when it reaches a specified credit limit.
If MacPaw can make those policies easy to implement, it may build a practical moat. If it simply exposes a menu of models, it will compete with a growing number of infrastructure providers offering similar functionality.
User trust will determine adoption
The user experience will be equally important. People may welcome local AI in principle, but they are unlikely to understand or value it automatically. The application must communicate when a task is processed on the device, when data is sent to the cloud, and what trade-off the user is making.
That communication cannot be buried in a privacy policy. A user deciding whether to summarize a confidential document or authorize an agent to act across several applications needs a clear explanation of where processing occurs and what it will cost.
Setapp’s subscription model gives MacPaw a chance to make these choices part of the product experience. The company could present local operations as included or lower-cost activities, while cloud operations consume credits based on model complexity. It could show users which actions were completed offline and provide controls for disabling cloud access.
Yet transparency can also expose weaknesses. If local inference is noticeably slower or less capable, users may quickly consume cloud credits to get better results. If the credit price is too high, they may avoid AI features altogether. If local processing drains battery or affects performance, the privacy benefit may not compensate for the inconvenience.
MacPaw therefore needs to optimize for reliable everyday usefulness rather than impressive demonstrations. The winning local assistant will not necessarily be the one that performs the most ambitious task. It may be the one that consistently handles small, frequent jobs: finding information, organizing notes, summarizing local material, drafting routine text, and coordinating simple application actions.
Those tasks create repeated engagement. Repeated engagement, in turn, is what can make a marketplace valuable. A platform that becomes part of a user’s daily workflow has more opportunity to sell additional applications and services than one that offers occasional access to a powerful model.
The market is shifting from models to orchestration
MacPaw’s partnership reflects a broader change in the AI industry. Early competition focused on model training and chatbot adoption. Increasingly, companies are competing to orchestrate AI across devices, applications, data stores, and business processes.
That shift creates room for companies that do not train the largest models. A marketplace can add value by deciding which model should handle a task, controlling access to user data, presenting a consistent interface, and managing payment. In this market, the best infrastructure may be invisible to the customer.
MacPaw’s potential advantage is that it can combine several layers: a consumer-facing subscription, an application catalog, a local inference system, a local memory architecture, and access to external cloud models. Each layer reinforces the others if adoption grows. More users attract developers. More applications make the subscription more valuable. More AI usage generates data about cost and performance. Better routing can then improve margins and user experience.
The opposite is also possible. If the local system is unreliable, developers may not adopt it. Without applications, users have little reason to pay for AI-oriented Setapp plans. Without sufficient usage, MacPaw may lack the scale to negotiate attractive cloud pricing or justify continued infrastructure investment.
This is why the partnership should be judged as a platform-building effort rather than a model launch. The central question is not whether Liquid AI can produce an efficient local model or whether MacPaw can integrate it into Eney. The question is whether the two companies can turn local inference into an advantage that developers and users can feel economically.
What investors and competitors should watch next
Several milestones will reveal whether MacPaw’s strategy is becoming commercially credible.
The first is the quality of Elix in real applications. A demonstration can show that an assistant works locally, but developers need predictable latency, manageable resource consumption, and consistent behavior across supported hardware. They also need to understand how much engineering effort is required to integrate the system.
The second is the rollout of local memory in Eney. Memory will test MacPaw’s ability to balance personalization with control. Users should be able to see and manage the information the assistant retains, while developers need safeguards around permissions and data boundaries.
The third is the structure of Setapp’s AI plans. Credit-based pricing will reveal whether MacPaw treats AI as a premium growth opportunity or primarily as a mechanism for passing infrastructure costs to customers. The terms will also indicate how much risk the company is willing to absorb while the market develops.
The fourth is developer access. MacPaw says it intends to make on-device inference available to developers once the local architecture is ready. The breadth and simplicity of that access will matter. A closed system may give MacPaw more control, but an overly restrictive platform could discourage adoption. An open system could attract more developers, but it may be harder to monetize and govern.
The fifth is the role of external cloud providers. Access to models from companies such as Google could make Setapp more useful, but it could also make MacPaw dependent on partners with far greater resources. If cloud providers improve their own hybrid AI tools, MacPaw will need to defend its position through distribution and workflow integration.
Finally, competitors will watch whether Setapp can turn local AI into a reason to subscribe. If users see the platform as merely another app bundle with experimental AI features, the partnership will have limited strategic impact. If AI becomes embedded in how users discover and operate multiple applications, Setapp could gain a distinct role in the software market.
A credible opening move, but not yet a defensible moat
MacPaw’s partnership with Liquid AI is well timed because the AI market is entering a phase where deployment economics matter more than novelty. Local inference can reduce cloud dependence, improve responsiveness, and give users more control over sensitive information. Cloud inference remains important because it offers scale and capabilities that local devices may not match. The likely future is a negotiated balance between the two.
That balance creates an opening for an application marketplace. Setapp can potentially give developers a single environment for distribution, subscriptions, usage billing, local inference, and cloud model access. If executed well, MacPaw could occupy a valuable middle layer between operating systems and model providers.
But the company will not win simply by offering more technical options. It must make those options operationally useful. Developers need control over costs and routing. Users need understandable privacy and billing choices. Local memory needs strong governance. The applications themselves need to deliver reliable benefits in ordinary workflows.
MacPaw has identified a meaningful strategic opportunity: to make AI a feature of an application ecosystem rather than a destination users visit through a standalone chatbot. Liquid AI’s hardware-specific approach could provide an important technical foundation, while Setapp supplies a path to customers and developers.
The partnership’s ultimate value will depend on whether MacPaw can convert that foundation into a repeatable business model. If it can, Setapp may become an early example of how software marketplaces compete in the hybrid AI era. If it cannot, the effort may remain a costly integration layered on top of capabilities that Apple, cloud providers, and individual developers can increasingly access on their own.
For now, the announcement is best viewed as an opening strategic move. It signals that the contest for AI leadership is expanding from model training to the places where intelligence is packaged, priced, and trusted.