Open a terminal, ask a model to work with some text, and get a response without configuring a cloud API key. For developers, that is a useful place to begin understanding what Apple is bringing to AI on the Mac.
I’ve started experimenting with the new fm command-line tool and the Siri chat app in macOS 27. My experience is still early, and I’m working out where these tools fit into my workflow. So far, Apple’s local model feels lighter in capability than the larger models available through ChatGPT and other services. That makes me interested in identifying the smaller jobs it can handle well.
A model does not have to solve every development problem to earn a place in our toolkit. If it can reliably handle a recurring task, keep the input on our machine, and avoid a separate inference bill, that is worth exploring.
Apple’s Foundation Models deserve that kind of practical evaluation. Understanding the relationship between the local models, Siri, and Private Cloud Compute helps us make better decisions about where to start.
Understanding the Models Behind Siri
Apple’s offering spans several layers. Apple Foundation Models are the models themselves. Apple Intelligence brings model-powered capabilities into the operating system. Siri provides an assistant experience, while the Foundation Models framework and developer tools let us build our own workflows. The framework supports access to on-device and server models, including integrations with other providers.
That distinction matters because chatting with Siri and calling a model from a script are different experiences. An assistant can coordinate capabilities across the operating system. A script needs the developer to define its inputs, provide any tools, and decide what happens to the output. Calling the underlying model does not automatically give that script Siri’s personal context or application integrations.
Apple’s third-generation model family also goes beyond one local model paired with one cloud model. It includes AFM 3 Core and AFM 3 Core Advanced on the device, along with server models for more demanding workloads. Core Advanced uses a sparse architecture, activating a subset of its parameters for a request, and is optimized for Apple’s more capable silicon. We should avoid assuming that every supported Mac runs the same local model configuration.
The broad architectural idea is straightforward: use on-device processing where it can complete the task, and draw on additional server capacity when needed. Apple documents that Apple Intelligence can send more complex requests to Private Cloud Compute. That is a useful framework for understanding the system, although it does not establish a fixed model assignment for every Siri command.
Where On-Device AI Becomes Useful
For developers, the local part is particularly interesting. Keeping inference on the Mac removes the network round trip and allows supported model operations to work offline. It also keeps those model inputs out of a remote inference service. Apple explicitly supports offline experiences through the on-device model in its Foundation Models framework.
Those characteristics suggest some useful experiments: classifying a short support request, extracting fields from a note, or producing a brief description from text supplied by an application. These are candidate workloads to evaluate. Their value depends on how consistently the model handles the actual inputs we give it.
Exploring Apple Foundation Models With the fm CLI
This is where fm makes exploration easier. Apple includes the tool with macOS 27, providing interactive conversations through fm chat and individual responses through fm respond. It defaults to the on-device model, while also offering access to a Private Cloud Compute model. The command-line interface is a convenient entry point; the selected model determines where inference happens.
That last detail is easy to overlook. A command running in Terminal can still send a request to a server. If local execution is a requirement, model selection needs to be an intentional part of the workflow.
The appeal of fm is that we can begin with a small experiment before building an application around it. Apple also supports structured output in the CLI, giving scripts a way to request a defined response shape. That makes it easier to connect model output to ordinary application code, though a correctly shaped response can still contain incorrect information.
Consider a script that classifies project notes into a handful of categories. I would start with a representative sample, define the expected categories, and review the results. Ambiguous notes belong in that sample, too. Testing only the easy examples tells us very little about how much manual correction the workflow will need.
I’m still discovering which of these smaller tasks justify using Apple’s model. The absence of a separate local inference charge makes experimentation attractive, but we should count our own time as well. A workflow that saves a few seconds and then requires several minutes of correction has given us a new hobby.
What Private Cloud Compute Changes
Cloud processing remains part of Apple’s offering. Private Cloud Compute is designed to provide additional model capacity while protecting request content. Apple states that data processed there is used to fulfill the request, is not made accessible to Apple, and is not retained by PCC after processing. These are specific protections for a cloud execution environment.
The hardware story has evolved, too. Apple says AFM 3 Cloud and its cloud image model are built for Apple silicon, while AFM 3 Cloud Pro extends PCC to NVIDIA GPUs in Google Cloud. Cloud Pro supports demanding workloads such as complex reasoning and agentic tool use. Describing every Apple cloud model as running on Apple silicon would miss an important part of the current architecture.
I find Apple’s privacy direction encouraging. Local inference gives us a particularly valuable boundary because the model can process sensitive input without sending it elsewhere. Even then, we need to examine the surrounding application: logs, saved conversations, tool calls, and synchronization can move or retain data independently of inference.
Apple’s Siri app, for example, can use iCloud to synchronize conversation history across devices. That is separate from PCC retaining a request during model processing. Understanding both behaviors gives us a more accurate picture than treating “local,” “private,” and “nothing is stored” as interchangeable promises.
Third-Party Extensions Add Another Privacy Boundary
Optional third-party extensions introduce another boundary. With the ChatGPT extension, Siri can suggest sending a request to ChatGPT, and users can control whether confirmation is required. An explicit instruction to ask ChatGPT can also send the request directly. When used without an account, Apple documents protections including an obscured IP address; connecting a ChatGPT account brings that account’s settings and OpenAI’s privacy policies into play.
We should also distinguish Apple’s collaboration with Google on its foundation models from choosing a third-party extension. The company involved in developing a model does not, by itself, tell us which service receives a particular request. The execution environment and applicable data policies are the details that matter.
For application developers, cost and availability deserve the same attention. Apple’s developer materials describe eligibility conditions for access to its PCC models without cloud API charges, and its CLI documentation notes cloud usage limits. The economics of local inference should not lead us to assume that every cloud capability is available without restrictions.
A Place Alongside Ollama and Other AI Tools
This leaves plenty of room for other local AI tools. Google documents running Gemma 4 through Ollama, with multiple model sizes available. That gives developers another set of options to compare against Apple’s offering, especially when choosing a model for a particular workload.
My expectation is that I’ll continue using a combination of tools. A larger local model may be more useful for one task, a hosted service for another, and Apple’s built-in model for a small operation inside a script. I want the choice to follow the work.
Start With a Small, Measurable Workflow
Let’s make those comparisons concrete. Choose a recurring task, collect examples, and define what a useful result looks like. Measure accuracy, response time, resource use, and correction effort. If sensitive data is involved, verify the complete path it takes through the workflow.
Sharing those results would help the developer community far more than another broad claim that one model is “best.” Knowing that a particular configuration handled a specific classification task well—or repeatedly missed a certain kind of input—gives someone else a useful starting point.
Apple Foundation Models are worth learning because they expand the capabilities available on hardware many developers already use. My own exploration is just beginning, but the opportunity is clear enough to justify opening Terminal and trying a small, measurable task. The next useful addition to your AI workflow may be a modest one that runs right on your Mac.
