Apple foundation models: on-device and server-based usage
Apple's marketing for Apple Intelligence has spent two years telling users that the smarts run "on your iPhone, for your iPhone." Open any keynote, any back-of-the-box tagline, and you'll find the same drumbeat: privacy by design, processing on device.
The Two-Track Reality Behind "Apple Intelligence"
The architectural reality is more nuanced — and considerably more interesting.
Apple's Foundation Models stack is not a single model. It's a two-track system: a compact ~3-billion-parameter language model living on the silicon itself, plus a server-side model that activates the moment a request outgrows what the phone can do. Apple's developer documentation makes the split explicit. The on-device SystemLanguageModel is the default. PrivateCloudComputeLanguageModel is the escalation. Get that routing wrong, and your feature ends up sluggish on bad networks, mysteriously offline in a tunnel, or quietly burning through a quota you didn't know existed.
This is the duality every developer integrating Apple's foundation models has to internalize before writing the first line of code. It is also the duality that shapes how the entire product feels to the person using it.
Routing Logic and the Four Practical Axes
Apple's recommended workflow is short and worth restating. Developers start with the on-device model. They evaluate whether the feature performs. If the answer is no — the request needs stronger reasoning, or it doesn't fit inside 4,096 tokens of context — they escalate to PCC. If the PCC call fails because the network is unavailable, Apple explicitly recommends falling back to the on-device model. That is not a footnote buried in a setup guide. It is the architecture.
Two paths, one API surface, differentiated along four practical axes that show up in Apple's developer comparison chart:
| Property | On-device model | Private Cloud Compute |
|---|---|---|
| Context window | 4,096 tokens | 32K tokens |
| Connectivity required | None | Yes |
| Per-day request cap | Unlimited | Yes (exact quota not published) |
| Reasoning capability | Tuned for short, structured tasks | Tuned for complex reasoning; AFM 3 Cloud Pro targets agentic tool use |
That table is, in effect, the entire developer contract. Every other piece of the stack — the model architecture underneath, the quantization tricks, the privacy posture, the eligibility rules — flows from those four constraints.
Apple's hybrid setup isn't a marketing footnote. It's the product. If you design for one track and ignore the other, you ship a feature that breaks exactly when a user needs it most.
What's Actually In the On-Device Box
The on-device model is the part of the stack you never have to apologize for. It runs offline. It is unlimited. It costs nothing extra to serve. For a developer, that is the good surface — no rate-limit math, no retry storms, no analytics dashboards whispering that 2% of sessions are timing out because the server is congested.
What sits underneath that utility is the technical bit worth knowing. Apple's July 2025 Foundation Language Models technical report describes the on-device model as roughly 3 billion parameters, optimized for Apple silicon, trained with KV-cache sharing and 2-bit quantization-aware training baked into the process rather than bolted on after the fact. That last detail matters. Post-training quantization to 2 bits is a common memory trick; quantization-aware training tends to land closer to quality retention at the same bit-width because the model has learned to compensate during training, not at deployment time. KV-cache sharing, the other named optimization, reduces the memory footprint of token-by-token generation — the higher cost component of running a transformer locally rather than serving it from a cluster.
The 4,096-token context window is the other constraint to design around. In practice, 4K tokens is enough for short conversational turns, structured extraction, summarization of modest passages, classification, and the kind of "rewrite this email" jobs that show up in Apple Intelligence features like Writing Tools. It is not enough for long-document Q&A, multi-turn agent loops, or any feature that needs to chew through a stack of PDFs without chunking. Any developer treating 4K as a comfortable default is one product pivot away from discovering it isn't.
The on-device model is fast, free, and offline. The server model is smarter, rationed, and required to log in.
Why the Server Side Exists: PCC and the 32K Window
Private Cloud Compute is what happens when the on-device budget runs out. Apple's documentation pegs the context at 32,000 tokens — eight times the on-device budget — and notes that the server path is where stronger reasoning lives. For the third-generation Foundation Models family Apple outlined in June 2026, Apple identifies AFM 3 Cloud as the server-side workhorse and AFM 3 Cloud Pro as the most capable server model, positioned for agentic tool use and complex reasoning.
The underlying architecture is a Parallel-Track Mixture-of-Experts transformer, documented in Apple's 2025 technical report. The relevant property for a developer integrating the API is not the architecture diagram — it's the inference profile. How the model behaves under load, what it returns at the token edge of its 32K window, how it degrades when the network wobbles, and whether agentic tool calls complete in time or stall waiting for a tool result the user has already moved past. Those are the things that determine whether the feature feels sharp or fragile.
A few practical realities to plan for:
- A daily request limit applies. Apple does not publish the exact quota in the public documentation, which means developers building features that might burst — summarization queues, background tasks, batch document ingestion — need to assume the ceiling exists even if they cannot name it.
- Network is mandatory. There is no offline PCC path. If the user is in an elevator, a tunnel, or on a flaky corporate Wi-Fi, PCC simply isn't available, which is precisely why Apple's fallback recommendation matters.
- Cost shifts at scale. Calling PCC from a third-party app is currently tied to a specific eligibility tier — third-party cloud API cost is on Apple's tab only for developers inside that envelope (more on that below).
- Latency profile differs. Even on a strong connection, PCC has a round-trip and a server-side inference budget the on-device path does not. Features that need to feel instant — text generation alongside the cursor, real-time rewriting — generally belong on-device even when the on-device model is the less capable one.
Privacy Posture: Stateless Design, Not Independent Verification
Apple's privacy story is the spine of the entire pitch, and it deserves precise treatment because it is also the easiest to overstate.
Apple documents that PCC processes personal user data statelessly: data received for a request is used exclusively to fulfill that request and is not accessible after the response is returned. Apple also specifies that PCC should have no privileged runtime interfaces — no admin backdoor, no SRE override, no debug shell — that would bypass those guarantees. These are documented design requirements.
They are also Apple's claims about its own system. Apple has put real engineering weight behind making PCC externally inspectable in principle — publishing parts of its virtual research environment, publishing build and runtime images, allowing security researchers to inspect the binaries that run on the server. What it does not do is hand a third-party benchmark number to a public model and call the privacy posture "verified." That distinction matters when writing about Apple's foundation models for a developer audience deciding what their data exposure will look like in production.
Apple's stated training-data composition is also worth tracking for the opt-in conversation. Apple says it trains its foundation models using publicly available information, licensed or purchased third-party data, open-source data, dedicated studies, and synthetic data, and that users' private personal data and user interactions are not used for training. That tells developers what Apple's training pipeline excludes; it does not tell them what any given model invocation will reveal about an end user in transit. The two are commonly conflated in product write-ups. They are not the same thing.
PCC isn't advertised as a privacy miracle. It's advertised as a stateless server with the admin tools removed. Read those claims as Apple's design commitments, not as third-party benchmarks.
Developer Access: The Small Business Window and the Migration Clock
The economics of calling PCC from a third-party app is the section most integration write-ups skip, and it is the one a shipping team will trip over first.
Access to PCC for third-party apps is currently limited to developers enrolled in the App Store Small Business Program, with fewer than 2 million first-time downloads across their apps, and with the PCC entitlement assigned. Eligible developers can use PCC without a cloud API cost. Two things follow from that:
1. If a developer exceeds the 2-million-first-time-downloads threshold or leaves the Small Business Program, Apple says they must migrate within six months.
2. The developer most likely to start bumping into the daily quota is the developer who has already crossed the download threshold.
For a team choosing between leaning on PCC for everything or routing aggressively to the on-device model first, the calculus is no longer just about latency and context. It now includes a unit-economics shift at scale, a quota to plan around without a published number, and a clock that starts the moment the app crosses the eligibility line.
The third-generation AFM family adds another wrinkle worth tracking for the next planning cycle. Apple announced five models in June 2026, ranging from on-device variants up to AFM 3 Cloud Pro on the server side. What the developer-facing API surface now treats as one "PCC model" is becoming a small tier list, with the Cloud Pro variant effectively gated behind use cases — agentic tool flows, complex reasoning, long-context synthesis — that the on-device budget and the standard Cloud variant cannot service. Teams designing for the next twelve months should be mapping which of their features are candidates for the Cloud Pro tier rather than for "PCC in general."
What This Actually Means at the User Surface
Strip the architecture out and what does the dual-track system feel like from the consumer side? Three things, in practice.
Summarization of short content, classification, rewriting, structured extraction — fast, offline, no throttling. This is the smooth surface, and it is the one users will judge the product by first. Long-context Q&A, multi-step agent flows, anything that needs the 32K window — works, requires connectivity, has a daily ceiling, and may eventually cost the developer a cloud bill if the app crosses the small-business threshold. The fallback seam, the part most polished features will hide: when PCC fails for network reasons and the call lands back on the on-device model, the experience shifts. Sometimes gracefully. Sometimes visibly. Apple's design recommends the graceful path; shipping features that hide the seam cleanly is on the developer, not the platform.
That is the user-facing shape of Apple's foundation models today. It is not the single-model story the marketing copy keeps selling. It is also not a half-built product in need of a roadmap rescue. It is a deliberate split with a clear routing contract, a documented privacy posture that is best treated as a design commitment rather than an external verification, and an access tier that flips economics at scale. Treat it as that, and integration work stops fighting the platform and starts using it.