In June 2024, Apple introduced Private Cloud Compute alongside Apple Intelligence. The idea was to send AI tasks that need more resources than a device can provide to servers, while protecting personal data. Apple says that even its own staff cannot access the content being processed.
That promise raises a question: an AI model needs to read a request to answer it. If that happens on a server, how do you prevent the people running the server from accessing it?
For developers, there is another question: what does PCC add to an app that already uses Foundation Models on the device?
Understanding PCC means understanding both what cloud computing makes possible and what protects the data sent there. Let's look at how Foundation Models and PCC fit together, then follow a request through the system to examine those protections and their limits.
First, what exactly is PCC?
Private Cloud Compute, or PCC, is the infrastructure Apple designed to run Apple Intelligence workloads in the cloud. In 2026, Apple also opened access to apps from eligible developers.
Three things are worth distinguishing: Apple Intelligence is the collection of features; a model is the engine that generates a response; PCC is the remote environment where some of those models run.
On a device, computation is constrained by memory, processing power, and battery life. Apple's 2025 technical report describes a small on-device model with roughly three billion parameters and a different server model designed for more demanding tasks. PCC allows that second kind of model to run without requiring the iPhone to do all the work itself.
How Foundation Models and PCC fit together
When you build with Foundation Models, you use Apple's framework: the interface that lets your app request a response from a model, define an output format, and provide tools. The framework gives you access; the model does the work.
Here, context means the space available for instructions, the information supplied, and generated text. It is measured in tokens, which are fragments of text: one token does not necessarily equal one whole word.
On-device model
Runs directly on the device.
Does not require an internet connection for inference itself.
Has a limited context window that varies by device and software version.
Does not offer the configurable extended reasoning levels available through PCC.
Supports structured output and tool calling.
Does not use the PCC request quota.
Model through PCC
Runs remotely in the PCC infrastructure.
Requires an internet connection.
Offers an advertised 32K-token context window for the model provided.
Offers several extended reasoning levels, which use more time and context.
Supports structured output and tool calling.
Is subject to a daily request quota per user.
⚠️ A comparison of the documented options, not a quality ranking. Capabilities and conditions may change.
Three situations make the difference more concrete:
Too much context: a document or collection of facts that exceeds the on-device model's capacity may justify using the remote model, provided it fits within that model's own context budget.
A task with several steps: reasoning through multiple constraints or chaining tool calls may benefit from the PCC model. You still need to measure the improvement on your actual task; a remote model does not guarantee a better answer every time.
Structured output or a particular language: that requirement alone does not justify PCC. Structured generation is already available on the device; language support and quality need to be checked for the model you choose.
For developers, the change is being able to keep much of an existing integration while switching models. For the product, the implications are broader: network access, quotas, waiting times, and the data's journey become part of the experience.
Why encrypting the connection is not enough
An encrypted connection protects data in transit. The remote AI still needs to read the content to process it.
With PCC, the request is decrypted inside the authorized computing environment. Who can read it there, and what remains afterward?
Apple encrypts the request directly to validated PCC servers. The intermediaries routing it do not have the keys needed to read its content. From that point on, protection depends on the environment doing the computation.
Let’s see a request’s journey a bit more further than that.
A request’s journey
1. The app prepares what it will send
Choosing the data is still the starting point. PCC does not remove the developer's responsibility to consider what goes into a request.
In Caffio's weekly or monthly analysis, calculations happen on the device. The model receives facts about habits: parts of the day, drink categories, consistency, and intake relative to the person's daily target.
Drink names entered by the person are replaced with placeholders such as DRINK_A. The actual names are restored locally in the final text. This flow does not send sleep data read from Apple Health, exact doses in milligrams, or precise clock times.
It does, however, send categories describing residual caffeine, calculated using the configured bedtime. Excluding raw Health data does not mean excluding all information derived from a person's preferences.
These facts still describe a person. Reducing their precision limits what is exposed; it does not automatically make them anonymous.
2. The device verifies the recipient
Before sending its data to PCC, the device checks cryptographic evidence about the server's software. An address bearing Apple's name is not enough: the device also checks that the reported environment matches an authorized software release recorded in a public log.
This is what attestation is for. The term is technical, but its purpose is concrete: verifying the environment you are about to trust with a request.
3. A third-party relay hides the IP address
A third-party relay hides the device's IP address from the PCC infrastructure.
This helps make it harder to target a particular person: compromising a server should not be enough to steer that person's requests to it. It does not guarantee complete invisibility.
4. The PCC gateway routes the request
The gateway uses the metadata needed for routing to forward the request to PCC nodes. It does not have the keys needed to read the content.
5. The model works inside a restricted environment
The system is designed to process the request without giving administrators a way to inspect the data being processed. Apple's requirements also limit data use to fulfilling the user's request and call for guarantees enforced by the architecture.
The aim is to technically restrict access, including access by the people operating the service.
6. The response returns without creating a readable server-side history
The goal is for PCC not to retain personal data as a reusable history once the work is done.
Still, “nothing is retained” needs careful explanation. For inference on Apple silicon, the guide describes reusing an encrypted cache across conversation turns. The device supplies the keys, which the server does not retain between those turns. Without the device sending them again, server processes cannot decrypt the remaining cache.
Apple also states that some processes remove data within a bounded period, rather than immediately wiping every memory location after each request. Preventing usable retention is a more accurate description than claiming every trace disappears instantly.
What PCC actually brings
Its first benefit is access to more computing capacity within a documented privacy architecture.
The model offered to developers through PCC has an advertised 32K-token context window and several reasoning levels. More extensive reasoning uses more of that space and takes longer.
Another benefit is inspectability. Researchers can examine software releases and check that they match the public log. This makes the commitments more verifiable. Publication can be delayed, however: Apple allows up to 90 days in certain cases for its binaries, while some vendor components in the Google Cloud infrastructure may take longer. Model weights also remain unpublished. Transparency does not mean everything is public immediately.
What PCC does not guarantee
The data does leave the device. PCC is remote processing. Someone who wants exclusively local processing may still prefer it, even when the remote option has strong protections.
Privacy and accuracy are separate concerns. A model can protect data and still generate a wrong answer. The 2025 report acknowledges hallucination and prompt injection risks. Its performance results describe that generation of models; they are not a ranking of the models available today.
The protection has a boundary. A tool that sends information to another service creates another data flow to examine. Apple's own documentation describes external tool calls that carry request-derived data outside the PCC trust boundary. The protections do not eliminate every risk of a vulnerability.
The guide also acknowledges that personal data could accidentally appear in diagnostics despite the filters. And the published source does not support reproducing the binaries to prove that they were built from that source. These limits rule out presenting PCC as a 100% privacy guarantee.
Access comes with constraints. A compatible device, a connection, and service availability are required. Requests are subject to a daily quota per user. No cloud API cost for an eligible developer does not mean unlimited usage.
The published conditions include enrollment in the Small Business Program, fewer than two million first-time downloads under Apple's stated criterion, and a PCC entitlement assigned to the account. Developers who cease to meet the eligibility conditions are given a stated six-month migration period. This is a dependency to consider when building a product.
What about “Apple's servers”?
The original architecture used Apple silicon servers. In June 2026, Apple announced an expansion onto Google Cloud with Google and NVIDIA, while retaining its PCC requirements and control over the authorized software.
The hosting location and the processing protections are distinct questions. The current guide describes both platforms and says they enforce the same guarantees through different mechanisms. This documents the design; it is not our own audit of how those systems operate in production.
What this means for Caffio
When Apple announced PCC, my first thought was about the privacy of users' data. For months, I studied the process, tried to understand how it was working under the hood.
Understanding PCC makes it possible to ask more precise questions: what leaves the device, who can read it during computation, and under what conditions might it remain afterward?
In Caffio, daily advice stays on the device. Weekly or monthly analysis can use PCC with information prepared locally. The calculations stay in the code; the model writes the text. A setting also lets people choose entirely local processing for these AI features, with a fallback when PCC cannot respond.
PCC expands what developers can build with Foundation Models by giving apps access to a more capable remote model through a familiar interface. The trade-off is that data leaves the device, and network access, latency, and quotas become part of the experience.
Apple addresses the privacy question with technical restrictions on access, checks on the software running the request, and mechanisms for outside inspection. These protections give developers more to examine than a promise alone. They still depend on the system working as designed, with the limitations described in its documentation.
For my own apps, the approach is to keep processing local where it works well, send only the information a remote task needs, and evaluate whether PCC improves the result enough to justify using it. PCC can strengthen the privacy of cloud AI; choosing what to send and how to handle the answer remains our responsibility as developers.
