apfel: A CLI and OpenAI-Compatible Server for Apple's On-Device LLM

What apfel Solves and Who It Serves

Apple Silicon Macs ship with a built-in LLM accessible through Apple FoundationModels, but Apple does not provide a command-line interface or a local API for it. apfel fills that gap by exposing the on-device model as a UNIX tool, an OpenAI-compatible server, and an interactive chat REPL. The target user is a developer or power user on macOS 26 Tahoe or later who wants LLM inference without sending data to a cloud provider, without managing API keys, and without downloading a separate model. The README states that inference is 100% on-device and that no API keys or cloud services are involved. This makes apfel attractive for scripting, local file analysis, and privacy-sensitive tasks where the model must stay on the machine. It is not a general-purpose LLM platform; it is a thin wrapper around Apple's own model, so its usefulness depends entirely on the capabilities and constraints of that underlying model.

How It Works: From FoundationModels to a UNIX Pipe

The core mechanism is that apfel calls into Apple FoundationModels, the framework that provides the on-device LLM. The README shows three modes: a direct prompt mode, a mode that accepts piped input, and an OpenAI-compatible server mode. In the direct mode, you run `apfel "What is the capital of Austria?"` and get a text answer on stdout. The pipe mode lets you feed file contents or command output into the model, such as `git diff HEAD~1 | apfel -f CONVENTIONS.md "Review this diff against our conventions"`. This works because apfel reads stdin and attaches it to the prompt. The server mode, started with `apfel --serve`, listens on `http://localhost:11434/v1` and implements the OpenAI chat completions API. The README includes a curl example and a Python snippet using the `openai` library with `base_url="http://localhost:11434/v1"` and an unused API key. Tool calling is supported in all contexts, and the context window is read at runtime: 4096 tokens on macOS 26 and 8192 on macOS 27. The design is straightforward: it is a local proxy that translates OpenAI-style requests into FoundationModels calls.

Getting It Running: Commands and Configuration

Installation is via Homebrew: `brew install apfel`. Updating is `brew upgrade apfel`. For source builds, the README says you need Command Line Tools with the macOS 26.4 SDK and Swift 6.3, and no Xcode is required. The command is `git clone https://github.com/Arthur-Ficial/apfel.git && cd apfel && make install`. The CLI offers a variety of flags. `--permissive` reduces guardrail false positives for creative or long prompts. `--stream` outputs tokens as they are generated. `-f` attaches files, including PDFs and images, with on-device text extraction and OCR. `--code` forces code-only output and exits with code 7 if the result is empty. `-o json` gives JSON output for scripting. `--schema` takes a JSON schema file and produces guaranteed schema-valid JSON output, which the README calls guided generation. `--messages -` reads a conversation JSON from stdin for one-shot multi-turn. `--count-tokens` preflights the token budget. `-s` sets a system prompt, and `--system-file` reads it from a file. For background serving, `brew services start apfel` runs it like a service, and you can set an environment variable `APFEL_TOKEN` for authentication, plus `APFEL_MCP` to point to an MCP tool script.

Guardrails, Permissive Mode, and JSON Schema Output

The README mentions guardrails as a default behavior, and it provides a `--permissive` flag to reduce false positives for creative or long prompts. This implies that the underlying Apple model has built-in content filtering that can interfere with legitimate requests. For a developer tool, this is a significant trade-off: you cannot fully disable the guardrails, only loosen them. The `--schema` flag is more interesting: it promises guaranteed schema-valid JSON output, which is a form of constrained decoding. This is not a post-processing fix; it guides the model's generation to match a JSON schema. That is valuable for automation where you need parseable output. However, the README does not explain how the schema is enforced or what happens if the model cannot produce content matching the schema. The `--code` flag also has a specific behavior: it strips prose and markdown fences and exits with code 7 if the output is empty, which is designed for piping into files or clipboard. These features make apfel more than a simple chat wrapper, but they depend on the model's underlying reliability.

MCP Tool Calling and the Demo Scripts

apfel supports the Model Context Protocol, allowing you to attach external tools via `--mcp`. The README shows an example with a Python server that provides calculator functions. When you run `apfel --mcp ./mcp/calculator/server.py "What is 15 times 27?"`, it outputs tool invocations to stderr and the final answer to stdout. This is a clean separation: you can see what tools were called without polluting the model's output. The README also describes bundled demo scripts, such as `cmd` which translates English to shell commands, and `apfel demos` writes these scripts to a directory. This is a practical way to see real use cases. However, the MCP support is limited to the tools you provide; there is no built-in tool library. The README mentions a separate GUI project, apfel-chat, for those who want a graphical interface, but that is out of scope for this tool.

Limitations You Need to Know Before Adopting

The most obvious limitation is the platform lock-in: apfel only runs on macOS 26 Tahoe or later, on Apple Silicon (M1+), and requires Apple Intelligence to be enabled. That excludes Intel Macs and older macOS versions. The context window is also small and varies by OS version: 4096 tokens on macOS 26 and 8192 on macOS 27. For comparison, many cloud LLMs offer 128K or more. This means apfel is unsuitable for analyzing long documents or maintaining large conversations. The README warns about quoting prompts with `!` in single quotes due to shell history expansion, which is a minor usability quirk. The guardrails, even with `--permissive`, may still reject valid requests, and there is no way to disable them entirely. The token budget can be checked with `--count-tokens`, but the README does not describe what happens when you exceed the limit; presumably the context is trimmed, but the details are not given. Finally, the quality of output is tied to Apple's FoundationModels, which the README does not evaluate. You cannot choose a different model; you get what Apple provides.

Alternatives and How They Differ

The closest alternative is Ollama, which also provides a local OpenAI-compatible server on port 11434. The key difference is that Ollama runs its own set of open-weight models, such as Llama or Mistral, which you download. apfel, by contrast, uses the model already embedded in macOS via Apple FoundationModels, so there is no model download. That means apfel has zero extra storage cost and benefits from Apple's system integration, but it also means you are stuck with Apple's model and its context limits. Ollama gives you model choice and larger context windows, but it requires a separate model download and may not be as tightly integrated with the OS. Another alternative is to use Apple's own FoundationModels framework directly in a custom Swift app, but that requires Xcode and more development effort. apfel is a ready-made CLI that avoids that work. For users who want a GUI, apfel-chat exists, but it is a separate project. The choice comes down to whether you prefer Apple's built-in model with no download versus a broader model ecosystem with more setup.

Maintenance, License, and Upgrade Cost

apfel is written in Swift and is under the MIT license, which permits free use and modification. The repository is active, with recent releases including v1.10.0 in September 2026. The project depends on Apple FoundationModels, which is a system framework on macOS 26 and later. That means apfel's maintenance burden is tied to Apple's API changes: if Apple updates the framework or changes its behavior, apfel must adapt. The README notes that demos are bundled in the binary and you need to re-run `apfel demos` after `brew upgrade apfel` to refresh them. The upgrade path is straightforward via Homebrew, and the source build requires the macOS 26.4 SDK and Swift 6.3. There is no mention of a migration guide or breaking changes between versions, so you should check the release notes before upgrading. The license implications are minimal: you can use, modify, and distribute it, but you must include the MIT license text. Since it is a wrapper around Apple's proprietary model, you are not licensing the model itself, only the tool.

Editorial conclusion

Adopt apfel if you are a macOS 26 or 27 user on Apple Silicon with Apple Intelligence enabled, and you want a local, no-cloud LLM accessible from scripts or OpenAI SDKs. Do not adopt it if you need cross-platform support, a larger context window than the runtime limit (4096 or 8192 tokens), or if you cannot enable Apple Intelligence. Before relying on it, verify your macOS version, confirm Apple Intelligence is on, and check the runtime context window. Then test with a small prompt, inspect its guardrail behavior, and evaluate its JSON schema output against your expected schema. apfel is a narrow but effective tool for a specific Apple-only environment.

Official sources

1. Arthur-Ficial/apfel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases