AnyLanguageModel is a drop-in for Apple's Foundation Models framework

The import line is the whole promise

The description says it plainly, a Swift package that provides a drop-in replacement for Apple's Foundation Models framework with support for custom language model providers. The demonstration of that claim is a diff, and it is a short one:

- import FoundationModels
+ import AnyLanguageModel

Everything above that line, the session, the model, the tools, the prompts, all keeps the same shape. The package is careful about where it draws that line, because anything it adds beyond Apple's API is marked as an extension in the documentation, and there is a section that summarises those differences so you can tell at a glance what is Apple's and what is the package's own. That convention matters more than it sounds, because a compatibility layer that quietly extends an API you believe you know is a source of subtle bugs, and marking every addition is the difference between a shim you can reason about and one you cannot.

The provider list, from on-device to a hosted API

The supported providers list is long and it is the reason the package exists, because the point is that the API does not change when the provider does. At the top are Apple's own Foundation Models, and Apple's Private Cloud Compute, along with any type that conforms to the `FoundationModels.LanguageModel` protocol, which is stated to include the Core AI models on OS 27. Then come the local runtimes, with Core ML models, MLX models and llama.cpp with GGUF models. And then the network ones, the Ollama HTTP API, the Anthropic Messages API, the Google Gemini API, the OpenAI Chat Completions API, the OpenAI Responses API, and Open Responses, which is a multi-provider spec for Responses API compatible endpoints. The mix is the useful part, since a laptop that runs llama.cpp locally and a server that calls a hosted endpoint are the same call site, which makes it possible to write the application once and move the inference to wherever the hardware and the terms allow.

Tools are ordinary Swift types, and the session is Apple's

The example in the readme shows a tool, and it is a plain Swift struct conforming to the Tool protocol with a name, a description and an async call method. Its arguments are a nested struct marked with the generative macro, with each field carrying a guide that describes it to the model:

let model = SystemLanguageModel.default
let session = LanguageModelSession(model: model, tools: [WeatherTool()])

let response = try await session.respond {
    Prompt("How's the weather in Cupertino?")
}
print(response.content)

So the model, the session, the prompt and the response are all the same names as in Apple's framework, and the tool is a type you write yourself rather than a description in a schema. That is a meaningful difference for an application that has real logic behind a tool, since the tool can call into your code, check permissions, or ask the user, and the model only decides whether to call it.

The delegate is where an app can intervene before a tool runs

There is an extension point for observing or controlling tool execution, and it is a delegate assigned on the session. The example implements it as an actor conforming to the tool execution delegate protocol with three methods. The first is called when tool calls have been generated, so you can log them. The second is the decision point, and the comments in the example are the interesting part, you can return a decision to stop after the tool calls, or to bypass execution and provide the output yourself, or to let it execute, and the example notes that this is a good place to ask the user for confirmation in a modal dialog. The third is called after a tool call has executed. Because the delegate is an actor, the callbacks are isolated, and because the decision is a return value rather than a notification, the model waits, which is what makes a confirmation prompt possible at all.

Traits keep the heavy backends out of your binary

The package uses Swift 6.1 traits to conditionally include the heavy dependencies, and the stated reason is binary size and build time, with the claim that you opt in only to the backends you need. Three traits are listed. The `CoreML` trait enables Core ML model support and depends on the transformers package from Hugging Face. The `MLX` trait enables MLX model support and depends on the MLX Swift language model package. The `Llama` trait enables llama.cpp support and requires the llama.swift package. By default no traits are enabled, so the base package carries no model runtime at all. The declaration in your own manifest looks like this:

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

The reason the traits exist is the same reason the hosted providers need no trait at all, they are HTTP clients, so a project that only calls a remote API ships a package with no model weights library linked in.

The trait resolution bug, and the workarounds it needs

The readme flags an important problem in bold, that because of a Swift Package Manager bug, dependency resolution may fail when you enable traits, producing the error about exhausted attempts to resolve the dependencies graph. The documented workaround is to add the underlying dependencies for each trait directly to your own package, and the readme gives the full list, the transformers package for the Core ML trait, the MLX Swift language model package for the MLX trait and the llama.swift package for the Llama trait, with the instruction to include only the dependencies that correspond to the traits you enable. A second problem is flagged for Xcode, which does not yet offer a built-in way to declare package dependencies with traits, and the workaround there is to create an internal Swift package that acts as a shim, exports the AnyLanguageModel module with the traits you want, and is then added to the Xcode project as a local dependency. The example walks through creating the shim package and writing its manifest, and the issue number for the trait problem is referenced in the readme.

A 1.0 release, and the shape of the repository

The version history shows the project arriving at a stable numbering, with 1.0.0 published on 2026-10-13 after 0.16.0 on 2026-10-04 and 0.15.1 on 2026-10-02, so the API is being treated as settled rather than provisional, and the last push to the repository was on 2026-10-19. The requirements are stated tightly, Swift 6.3 or later with Xcode 26.4 or later, and iOS 17, macOS 14, visionOS 1 or Linux, so the package is not tied to Apple's own operating systems even though it mirrors their framework. The tree is small and conventional for a Swift package, with `Sources/`, `Tests/`, a `Package.swift` and a resolved file, a `.swift-format` configuration for the formatting of the sources, the licence and the GitHub configuration. The licence is Apache-2.0, which is worth noting because the package is meant to be embedded in applications rather than consumed as a service.

Editorial conclusion

AnyLanguageModel suits a Swift team that has written against Foundation Models and wants the option of a different provider, on device or hosted, without rewriting the call sites, and it suits anyone who wants to try a hosted model on a device where the on-device model is not available. It is a poor fit if you are staying entirely with Apple's own models, since then the framework itself is the simpler answer, and it is a poor fit if you want every backend compiled in, since the traits are off by default precisely so they are not. Before you adopt it, check three things: which provider you will actually call, since the trait that enables it also brings a dependency you have to version yourself, the Swift Package Manager trait bug, which the readme documents as a known issue with a workaround of adding the underlying dependencies directly, and the version, with 1.0.0 published on 2026-10-13 and the last push to the repository on 2026-10-19.

Frequently asked questions

Official sources

1. huggingface/AnyLanguageModel on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases