Claude Plugs Into Apple Foundation Models — As a Server-Side Model, Not an On-Device One

Anthropic shipped a Swift package called Claude for Foundation Models, and within the day the loudest question on Hacker News was the one the documentation answers in its second paragraph: does this run on the phone?

It does not. And the gap between what people assumed and what actually shipped is the most interesting thing about this release.

The package conforms Claude to the LanguageModel protocol in Apple's Foundation Models framework. That means you drive it with the same LanguageModelSession API you already use for Apple's on-device model: respond(to:), streaming, guided generation, and tool calling all behave identically. The difference is where the work happens. Requests go directly from your app to the Claude API, Apple is never in the request path and never sees your prompts or responses, and usage is billed to your Anthropic account at standard API pricing. The package is explicitly a beta targeting the server-side language model API introduced in the OS 27 betas.

So this is not a small Claude crammed onto an A-series chip. It is Claude, in the cloud, wearing Apple's interface.

What the package actually does

The entry point is ClaudeLanguageModel. You construct one with a model name and an auth mode, hand it to a session, and call it like any other Foundation Models provider:

import FoundationModels
import ClaudeForFoundationModels

let model = ClaudeLanguageModel(
    name: .sonnet4_6,
    auth: .apiKey(ProcessInfo.processInfo.environment["ANTHROPIC_API_KEY"] ?? "")
)
let session = LanguageModelSession(model: model)
let response = try await session.respond(to: "Plan a 4-day trip to Buenos Aires.")
print(response.content)

The clearest framing of the value came from an HN commenter, tonyoconnell, who laid out the substitution directly: Apple's framework is the standard Swift API for on-device AI, and this package makes Claude a drop-in swap behind that same API. ^[1] You write your app once against the Foundation Models protocol, then choose per session whether a given turn runs on Apple's small on-device model or goes out to Claude.

That "one API, two tiers" property is real and it is the point worth keeping. Model constants mirror the API IDs (.opus4_8 maps to claude-opus-4-8), each constant carries its own capabilities so the package only sends request fields a model accepts, and the initializer also takes a baseURL, a timeout, and server-side tools like web search. The GitHub repository ships a runnable command-line example that streams a chat turn to the terminal, with a --search flag to enable server-side web search, though running it requires a macOS 27 host. ^[2]

Why people think this runs on the phone

The confusion is Apple's framing, not a reading failure. Foundation Models launched as the on-device AI story, so a package that conforms to it inherits that association even when it points at a data center.

One commenter, mlpicker, named the suspicion precisely: Apple's framework caps local models somewhere around 3B parameters, Claude is far larger than that, so either there's an undocumented hybrid setup or this is "mostly a Claude SDK in FM clothing." ^[3] The honest answer is the second one, with no asterisk. It is a Claude SDK that satisfies the Foundation Models server-side provider conformance. mlpicker's closing line, "Anyone tried it on a plane?", has a definite answer: it will not work on a plane, because every request leaves the device.

This matters beyond pedantry. If you reach for this package expecting the privacy and offline guarantees that made on-device Foundation Models attractive, you get the opposite: a network dependency, per-token billing, and prompts that travel to Anthropic's servers (not Apple's). The package is upfront that Apple never sees the data, but "Apple doesn't see it" is not the same promise as "it never leaves the phone." Builders who skim will conflate the two.

What builders actually said

The thread split along a predictable line between people who saw a clean abstraction and people who saw another layer.

On the skeptical side, zkmon argued that layers are a luxury that removes control and transparency, comparing coding agents to 1990s body shops that "consume 10x more tokens" and noting that tasks which blow past context length through an agent run fine when prompted directly. ^[4] It's a sentiment more than a measurement, and it's aimed more at agent tooling than at this specific package, but it captures a real wariness about indirection between the developer and the model.

gregman1 made the same point as a joke that landed: if everything routes through a common interface now, "the most successful AI was OpenRouter Intelligence." ^[5] Funny, and also the sharpest one-line description of what Foundation Models is quietly becoming.

The most useful concrete worry came from rock_artist, who is happy about the abstraction but flagged a real device problem for the local case: if ten apps each bundle and download the same on-device model, the phone bloats, and there's no obvious mechanism for multiple apps to share one on-device model without awkward namespaces and permissions. ^[6] That's orthogonal to Claude specifically, but it's the kind of practical constraint that decides whether the on-device tier of this "two tier" world is actually usable at scale.

The abstraction question

The single best comment in the thread was a question. daniel_iversen asked whether Apple is encouraging developers to route LLM access through its abstraction layer precisely so that when Apple ships its own larger model, possibly tied to Siri, developers can transition seamlessly. ^[7]

I think that read is correct, and it reframes the whole release. Anthropic's package is the proof of concept, but the leverage belongs to Apple. Once LanguageModelSession is the place every app talks to a model, the model behind it becomes a configuration detail. Apple controls the protocol, the defaults, and eventually the routing. A future Apple cloud model slots into the exact same LanguageModelSession call with a different constructor, and the millions of apps already written against the protocol need no rewrite to adopt it.

That's the strategic shape worth watching. Anthropic gets distribution into the Apple developer surface today. Apple gets every one of those integrations pre-wired to its own switchboard for whenever its frontier model is ready. The interface is the moat, and Apple owns the interface. This is the one claim in the piece I'll plant a flag on rather than hedge.

Where does the key live?

The unglamorous problem is authentication, and a commenter named me551ah cut straight to it: where does the API key reside, given you can't ship it in the iOS client because anyone can extract and abuse it? ^[8]

The documentation half-answers this. It tells you to use a Claude API key from the Console "for development," and points to authentication options "for production," with an AuthMode type that reaches the provider. The quick-start example reads the key from an environment variable, which is fine on a Mac command line and unacceptable in a shipped app. So the package acknowledges the problem and defers it to whatever production auth pattern you wire up, presumably a token-vending backend rather than an embedded secret. If you build on this, that backend is your problem to design, and the docs don't hand you one.

That's a reasonable place to leave a beta, but it's exactly the part that turns a five-minute demo into real work. The demo is one line. The production deployment is a proxy, a token service, rate limiting, and cost controls.

If you're building on this today

The honest summary: this is a well-made Claude client that speaks Apple's protocol, not a new on-device capability, and you should treat it accordingly.

A few things to keep straight before you ship:

• Don't promise users on-device or offline behavior for any session backed by ClaudeLanguageModel. Every Claude turn is a network call billed to your Anthropic account, and it fails on a plane.
• Use the genuine strength, which is the single code path. Write against LanguageModelSession once, route cheap or private turns to Apple's on-device model, and escalate to Claude only when a turn needs the capability. That routing decision is where the value is.
• Solve key management before anything else. Plan for a token-vending backend, because the environment-variable pattern in the quick start is a development convenience, not a shipping strategy.
• Watch what Apple does with the protocol, not just what Anthropic does with the package. If daniel_iversen is right, the server-side provider conformance is the on-ramp for Apple's own cloud model, and the choice you're really making is whether to standardize your app on Apple's switchboard.

The package is worth adopting if you already wanted Claude in a Swift app and like writing against one protocol. Just buy it for what it is. The name says Foundation Models and the API says on-device, but the bytes go to the cloud, and everything you design around it has to start from that fact.

Sources

Primary source: Apple Foundation Models

1. HN comment by tonyoconnell — tonyoconnell · community
2. HN comment by _josh_meyer_ — _josh_meyer_ · community
3. HN comment by mlpicker — mlpicker · community
4. HN comment by zkmon — zkmon · community
5. HN comment by gregman1 — gregman1 · community
6. HN comment by rock_artist — rock_artist · community
7. HN comment by daniel_iversen — daniel_iversen · community
8. HN comment by me551ah — me551ah · community