apfel: Apple Intelligence as a UNIX Tool and a Local OpenAI Endpoint

The model is already on the machine; apfel is the missing interface

Apple Silicon Macs running macOS 26 Tahoe ship a language model through Apple FoundationModels. There is no download, no account and no key. What is missing is a way to reach it from a shell script or an application that speaks the OpenAI wire format. apfel fills that gap: the README describes it as exposing the built-in model as "a UNIX tool and a local OpenAI-compatible server", with inference staying on-device.

The audience is narrow and specific. You need an Apple Silicon Mac (M1 or later), macOS 26 Tahoe or newer, and Apple Intelligence turned on. If any of those three is missing, apfel has nothing to talk to. Within that group, the tool is aimed at people who already live in a terminal: shell script authors, developers who want a local backend for an OpenAI SDK, and anyone wiring up Model Context Protocol tools. The pitch is the absence of moving parts, not model quality.

Three modes over one FoundationModels session

apfel presents the same model through three entry points. A one-shot CLI handles a prompt argument or piped stdin. `apfel --chat` starts an interactive REPL, described in the README as a small tool for testing prompts or MCP servers. `apfel --serve` runs an HTTP server that answers at `http://localhost:11434/v1`, which is the port Ollama uses, so existing OpenAI clients can be pointed at it by changing the base URL only.

The interesting part is the plumbing around the model. Files passed with `-f` are read on-device, and the README states that PDFs and images go through on-device text extraction and OCR. `--schema` uses guided generation, which the README says produces guaranteed schema-valid JSON. `--count-tokens` reports the token budget before you send a prompt, which matters because the context window is read at runtime from the FoundationModels APIs rather than being a fixed constant in the binary. MCP servers attached with `--mcp` are discovered, invoked and returned, with the tool call and its arguments printed to stderr while the answer goes to stdout, so piping stays clean.

Installing apfel and running a first real command

Homebrew is the short path. The README gives a single command, and updating is a single command as well.

brew install apfel
brew upgrade apfel

If you prefer to build, the README documents a source path that needs Command Line Tools with the macOS 26.4 SDK and Swift 6.3, and explicitly does not need Xcode.

git clone https://github.com/Arthur-Ficial/apfel.git && cd apfel && make install

The Makefile's `check-toolchain` target explains why the SDK floor exists: the FoundationModels token-counting APIs (`tokenCount` and `contextSize`) are absent from older SDKs, so the build fails with an explicit error rather than a confusing linker message.

For a first real use, pipe a file in and ask for a summary. The README shows `-f` for attaching file content, and `--count-tokens` for checking the budget first.

apfel --count-tokens -f README.md "Summarize this"
apfel -f README.md "Summarize this project"

If you want the OpenAI-compatible server instead, start it in the foreground or as a background service.

apfel --serve
brew services start apfel
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"apple-foundationmodel","messages":[{"role":"user","content":"Hello"}]}'

The model identifier to use in requests is `apple-foundationmodel`, and the README's Python example passes `api_key="unused"` because there is no key to supply. The README notes that quoting prompts containing `!` in single quotes avoids shell history expansion, which is a small thing that will otherwise bite you on the first exclamation mark.

The context window is the real ceiling

The README's limitations section, referenced from the feature table, states the on-device context window is 4096 tokens on macOS 26 and 8192 on macOS 27. That number is read at runtime rather than assumed, which is honest engineering, but it also means the ceiling is set by the operating system and the model Apple shipped, not by anything apfel can tune.

4096 tokens is roughly a few pages of prose. A large source file, a long PDF or a multi-turn conversation will exceed it, and `apfel --chat` handles that by trimming context automatically, with the README pointing at `docs/context-strategies.md` for the details. Trimming is a reasonable default for a REPL, but it means the model can silently lose earlier turns. For a review of a large diff, `--count-tokens` is the honest way to find out before you burn a request on a truncated prompt.

Two other limits follow from the design. There is no model choice: you get the FoundationModels model or nothing, so you cannot trade quality for speed or pick a larger variant. And there is no cloud fallback, which is the point of the tool but also means a prompt the on-device guardrails reject stays rejected. The README offers `--permissive` to reduce guardrail false positives on creative or long prompts, which is a mitigation rather than a fix.

How it compares with Ollama and llama.cpp

The obvious comparison is Ollama, and the README invites it by using port 11434 and by noting that `brew services start apfel` runs it in the background "like Ollama". The difference in approach is where the weights live. Ollama downloads and manages model files, so you choose among many models and pay in disk space and setup time. apfel downloads nothing and offers exactly one model, the one Apple already installed with the operating system. If your requirement is a specific open-weights model, or a context window larger than a few thousand tokens, Ollama is the right tool and apfel is not.

Against llama.cpp the split is similar but sharper. llama.cpp gives you quantization choices, GPU offload tuning and a broad model zoo, at the cost of a build and a configuration surface. apfel gives you none of that control and in exchange asks for `brew install apfel` and an Apple Intelligence toggle. The trade is capability for zero configuration, and it is a real trade, not a free win.

Licence, maintenance and the cost of upgrading

apfel is MIT licensed, which permits commercial use and modification with the usual attribution requirement. The practical licence question is not apfel's own terms but the terms attached to the FoundationModels framework it calls, which come from Apple and are outside the repository's control. That is a question for your own review, not something the MIT file answers.

On maintenance: the last push to the repository was on 2026-09-08, and the most recent release, v1.10.0, was tagged on 2026-09-07, with v1.9.1 and v1.9.0 before it in August. The repository is not archived. Upgrade cost is low by design. `brew upgrade apfel` replaces the binary, and the README notes one follow-up step: the bundled demo scripts are written out by `apfel demos ./apfel-demos`, so re-running that command after an upgrade refreshes them. The README also points to a same-day Homebrew tap and to Nix, Mint and mise in `docs/install.md` for people who do not use homebrew-core.

The version floor is the cost that does not go away. macOS 26.4 SDK or newer for source builds, macOS 26 Tahoe or newer to run, and Apple Silicon only. On an Intel Mac there is no path at all.

What a first-week user should check

Start with the token budget. Run `apfel --count-tokens -f` against the largest file you actually intend to summarise. If the count is near 4096 on macOS 26, the workflow you have in mind will not fit, and no flag changes that.

Then confirm the model is reachable at all. Apple Intelligence must be enabled in system settings, and that is a prerequisite apfel cannot satisfy for you. A failure here looks like a broken install rather than a disabled feature, so check it before filing anything.

Finally, decide which interface you need. The CLI is the lower-commitment option; the server is worth it only if you already have OpenAI SDK code or an MCP tool you want to attach. The README's demo scripts, written out with `apfel demos ./apfel-demos`, are the fastest way to see what the CLI is good at, and `cmd -x` and `cmd -c` show the execute-after-confirm and copy-to-clipboard patterns that make the tool useful in a shell rather than in a chat window.

Editorial conclusion

apfel fits macOS 26 users on Apple Silicon who want a zero-config local model for summarising files, shell one-liners, JSON extraction and MCP tool calls, and who can live inside a 4096-token context window. It is the wrong tool for long-document reasoning, for Intel Macs, for anything below macOS 26, and for anyone who needs a model they can swap out. Before adopting it, run apfel --count-tokens -f on your largest realistic input and confirm the model is actually present in System Settings, because a missing Apple Intelligence model is the failure that looks like a broken install.

Frequently asked questions

Official sources

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