AnyLanguageModel 1.0: Which Local Model Fits Your Device

AnyLanguageModel 1.0 shipped alongside swift-huggingface 1.0 and swift-xet 1.0, a year after the Swift library first stood in for Apple's Foundation Models framework.

The pitch has not changed since launch: "a drop-in replacement for Apple's Foundation Models framework that lets you choose the model and provider your app uses." What changed in a year is the surface area — enough of it that picking a model for an iOS or macOS app is now mostly a memory-budget decision rather than an API one.

One import line, three local runtimes

Migration starts and, for simple apps, ends at the import:

- import FoundationModels
+ import AnyLanguageModel

Per the release post, "the same session code then works with the system model, with open-weight models through llama.cpp, MLX, and Core ML, and with the hosted providers below." Three features that used to vary by backend now do not: tool calling works with every provider, guided generation works with every provider — "including nested @Generable types and arrays of them" — and images can be attached to prompts using Foundation Models 27's syntax, including with the system model on iOS, macOS and visionOS 27.

On OS 27 the library also accepts any model conforming to Foundation Models' LanguageModel protocol, Core AI models included. Alongside it, swift-huggingface and swift-xet exist to bring accelerated model downloads from the Hub into Swift apps.

The hosted list got long enough to matter

The 1.0 provider list covers OpenAI's Chat Completions and Responses APIs, Open Responses for any compatible endpoint, Anthropic's Messages API "with adaptive thinking and effort options", Google's Gemini API, Ollama, Private Cloud Compute on OS 27, and Hugging Face Inference Providers plus other OpenAI-compatible endpoints such as OpenRouter through a custom base URL.

Two details matter more than the list. Hosted providers get the same features as local ones — "guided generation, tool calling with streaming, and token usage on responses" — and reasoning is now part of the transcript, with reasoning blocks automatically omitted from requests if a newly selected provider cannot replay them. That is the piece that makes "start hosted, move on-device later" a code path rather than a rewrite.

The second: API keys now come from a closure instead of a string, so an app can fetch short-lived tokens from its own server. The library also runs on Linux, so the same code can run server-side.

Which model actually fits your device

The release post names four open-weight models and, usefully, their footprints:

Model	Format / quant	Size	Runs on
Gemma 4 E2B (Google)	GGUF, Q4_0 with QAT	~3.4 GB	iPhone
LFM2.5 2.6B (Liquid AI)	GGUF, Q4_K_M	~1.7 GB	iPhone
Qwen3.8 27B (Alibaba)	MLX, 4-bit	~16 GB	Mac with 32 GB+
GLM-5.3 (Z.ai)	BF16	~1.5 TB	Four maxed-out Mac Studios, or Inference Providers

The post is explicit that "the first two fit on an iPhone, and Qwen3.8 27B runs on a Mac with 32 GB of memory or more." Selecting the MLX build is one line:

let model = MLXLanguageModel(modelId: "mlx-community/Qwen3.8-27B-4bit")

GLM-5.3 is the honest edge of the range: at about 1.5 TB in BF16 it is a four-Mac-Studio proposition, and the post routes everyone else to Inference Providers for it — the same session code, a different line of setup.

Size tells you if it fits. Bandwidth tells you if it is fast

Footprint answers whether a model loads, not whether it is usable. A separate developer post published the same week argues the gap is usually memory traffic, not the model: "you can estimate it before you run anything." Its worked example is a diffusion-style audio model, not a chat LLM, so the step counts do not transfer — but the method does, and the author discloses working on Creatune AI Music Generator and using this arithmetic to decide what to run locally.

The worked example: a 1.5B model at fp16 is roughly 3 GB of weights, and at 1,500 sampler steps it streams about 4.5 TB through the memory bus for one clip. On a laptop with 150 GB/s of unified memory that is 30 seconds — real time, with no optimization and no discrete GPU. At 4-bit the same model is roughly 0.75 GB, the same 1,500 steps move about 0.75 TB, and the wait drops to about 5 seconds. Nothing architectural changed; four times fewer bytes finished four times sooner.

Two warnings from that post apply to anyone benchmarking a local model on a Mac. First-run latency is not throughput: "if your first generation takes 40 seconds and the second takes 12, you were measuring cold start." And the three numbers worth recording are RTF, peak RSS — whether the model fits or spills into swap — and bytes per step, the one you can predict before installing anything.

Installing, and what is next

The package line carries the runtime as a trait:

dependencies: [
  .package(url: "https://github.com/huggingface/AnyLanguageModel",
           from: "1.0.0", traits: ["MLX"])
]

Existing apps should read the migration notes in the AnyLanguageModel, swift-huggingface and swift-xet release notes before bumping. The post closes by pointing past text: "Coming soon: models that decide, and models that listen."

What to watch: whether guided generation stays identical across providers as that list grows, and whether short-lived-token support changes how many shipping apps route inference through their own backend instead of asking users for a key.