Apple's LanguageModel Protocol: One API for Local and Cloud AI

Direct answer: Apple's new LanguageModel protocol lets a Foundation Models session work with more than the built-in Apple Intelligence model. A provider can wrap Core AI, MLX, Private Cloud Compute, a server model, or another runtime behind a common interface. Developers keep the session concepts they already use, including transcripts, generation options, guided output, tools, and streaming, while the provider handles model packaging, prewarming, execution, and native input translation. The protocol reduces integration duplication. It does not make every model equally private, capable, cheap, or compatible, so apps still need explicit provider policy and user-visible fallbacks.

Quick decision table

The architectural change is a boundary, not a new chatbot

Foundation Models originally gave developers a high-level API around Apple's on-device language model. The 2026 design keeps that session layer and introduces a provider boundary. Apple identifies two central protocol types: LanguageModel, which declares capabilities and configuration, and LanguageModelExecutor, which prewarms the runtime, translates transcript segments, applies generation options, manages context, and streams output. A well-built provider makes a model feel native to the framework without hiding what it is.

This matters because application code should describe the job, not the tensor library. A script editor may ask for structured scene metadata, a game may request character dialogue, and a voice studio may ask for pronunciation notes. The same feature can use an on-device model by default, then choose another provider only when the user approves or the task exceeds local capability. Apple's WWDC26 provider session is the primary implementation overview.

What the common API gives an app

A shared session model can reduce separate prompt, tool, and streaming layers for each backend. Guided generation can still target Swift data structures. Tool calls can still connect the model to app-owned code. The transcript can preserve the same user and tool history while the executor converts it to the provider's tokens and segment types. Metadata-first streaming gives the app a chance to learn about the response before rendering partial content.

The common API is especially valuable for evaluation. You can run the same typed request through two providers and compare validity, latency, token use, and task success. That is cleaner than comparing two unrelated chat interfaces. It also makes fallback behavior testable. If a model lacks image input or a required tool capability, the app can detect that before sending the request.

What the protocol deliberately does not normalize

Privacy remains provider-specific. A local MLX model can keep a transcript on the Mac, while a third-party provider may process it on remote infrastructure. Cost remains provider-specific. The system model has device and OS requirements, Private Cloud Compute has request limits, and commercial APIs have their own usage billing. Model licenses, safety rules, output rights, context size, and retention policy also remain separate decisions.

Expose those differences in the product. A provider picker should show local or remote execution, download size, expected memory, network requirement, and any account or price. Do not label the whole feature on-device merely because the default provider is local. Murmur's private voice-cloning guide uses the same principle: describe what data leaves the device and why.

How to design a provider-ready Mac feature

Start with a narrow typed task. Define the expected output, maximum acceptable latency, offline requirement, and what failure looks like. Add a provider capability matrix and choose one default. Treat model availability as runtime state because Apple Intelligence can be disabled, model assets may be absent, and an open checkpoint can fail validation after an update. Store provider identity with generated artifacts so later audits can reproduce the result.

For a local voice workflow, an LLM provider might clean a script or assign speaker labels, while TTS remains a separate deterministic job. Keep that boundary visible. A language model can prepare text, but speech recognition and synthesis have their own latency and accuracy budgets. One protocol should not tempt the app to represent every model as the same kind of intelligence.

Evidence to collect before publication

Create one sample feature that returns a Swift structure from the system model and a second provider, then deliberately remove a capability. Record how the app reports unavailable image input, tool calling, context, and network state. A short architecture diagram should show the Foundation Models session above provider-specific execution and privacy policy. Link the provider matrix to the existing private voice guide so a shared API never becomes a shared privacy claim.

• One typed request used across two providers
• A capability-mismatch failure screenshot
• Local versus remote data-flow diagram
• Provider identity stored with the result
• OS and model-version evaluation notes

Reader worksheet

Create a one-page worksheet before acting on this Foundation Models LanguageModel protocol guide. Write the job, current baseline, minimum supported Mac, privacy requirement, model and runtime revision, acceptable failure rate, and the one result that would change your decision. Add measured values only after the test, and keep upstream claims in a separate column. Save links to raw output and licenses beside the row they support. Review the worksheet after seven days of real use, not only after a successful demo. Browse the Murmur research library for the related memory, privacy, model, and production checks that belong in the same decision.

Practical checklist

1. Define one typed task and its success metric before adding providers.
2. Record each provider's location, context, tools, media inputs, cost, and availability.
3. Make local versus remote execution visible before the request runs.
4. Test model-disabled, asset-missing, network-offline, and safety-rejection states.
5. Save provider and model version beside important generated artifacts.
6. Evaluate the same fixed dataset after every OS or provider update.

Frequently asked questions