apfel: Apple FoundationModels als UNIX-Werkzeug und lokaler OpenAI-Server

Welches Problem apfel löst und für wen es gedacht ist

Apple liefert mit den FoundationModels ein Sprachmodell aus, das auf Apple-Silicon-Macs lokal läuft. Das Modell ist jedoch nicht ohne Weiteres aus der Shell oder aus bestehenden Programmen ansprechbar. apfel schließt genau diese Lücke: Das Projekt beschreibt sich selbst als Werkzeug, das das eingebaute Modell als UNIX-Tool und als lokalen, OpenAI-kompatiblen Server bereitstellt, ohne API-Schlüssel und ohne Cloud. Die Zielgruppe lässt sich aus den Anwendungsbeispielen im README ablesen. Da sind zum einen Shell-Nutzer, die Prompts in Pipes einbinden, Dateien anhängen oder JSON-Ausgaben mit jq weiterverarbeiten wollen. Zum anderen Entwickler, die bereits gegen die OpenAI-SDK programmieren und für Tests lediglich die base_url auf http://localhost:11434/v1 umbiegen möchten. Ein dritter Fall sind Skripte, die eine lokale Inferenz ohne Netzwerkzugriff benötigen, etwa weil Daten das Gerät nicht verlassen sollen. Kein Modell-Download, keine Registrierung, kein Kontingent. Das ist der Kern des Versprechens, und die Einschränkungen weiter unten zeigen, wo es endet.

Wie apfel das Modell an die Oberfläche bringt

Das README nennt drei Betriebsarten, die auf dieselbe FoundationModels-Schnittstelle aufsetzen. Im CLI-Modus liest apfel ein Argument oder STDIN, hängt optional per -f angegebene Dateien an und schreibt die Antwort nach STDOUT. Fehlerausgaben wie MCP-Diagnosen gehen nach STDERR, was Pipes sauber hält. Im Servermodus startet apfel --serve einen HTTP-Endpunkt auf localhost:11434, der die Chat-Completions-Route des OpenAI-Formats bedient. Der Beispielaufruf im README verwendet das Modell apple-foundationmodel und einen beliebigen api_key, weil der Server keine Authentifizierung verlangt. Der dritte Modus ist apfel --chat, eine REPL zum Testen von Prompts und MCP-Servern, in der der Kontext laut README automatisch gekürzt wird. Ein Detail, das die Architektur erklärt: Das Kontextfenster wird zur Laufzeit ausgelesen, 4096 Token unter macOS 26 und 8192 unter macOS 27. apfel kodiert diese Zahl also nicht fest, sondern fragt sie beim Start ab. Werkzeugaufrufe funktionieren laut README in allen drei Kontexten, also CLI, Server und Chat.

Installation und erste Befehle

Der einfachste Weg führt über Homebrew: brew install apfel, Updates mit brew upgrade apfel. Wer aus dem Quellcode bauen will, braucht laut README die Command Line Tools mit macOS 26.4 SDK und Swift 6.3, aber kein Xcode; der Befehl lautet git clone https://github.com/Arthur-Ficial/apfel.git && cd apfel && make install. Für den Dauerbetrieb als Hintergrunddienst nennt das README brew services start apfel und brew services stop apfel, wahlweise mit den Umgebungsvariablen APFEL_TOKEN und APFEL_MCP. Ein Aufruf gegen den Server sieht so aus: curl http://localhost:11434/v1/chat/completions mit einem JSON-Body, der model und messages enthält. Auf der CLI-Seite sind die nützlichsten Schalter schnell erklärt. apfel --stream liefert Ausgabe in Echtzeit, apfel -f README.md "Summarize this project" hängt Dateiinhalte an, apfel -o json "Translate to German: hello" | jq .content erzeugt maschinenlesbare Ausgabe. Für Skripte gibt es apfel -q für knappe Antworten, apfel --code für reine Codeausgabe ohne Markdown-Zäune und apfel --schema person.schema.json für schema-validiertes JSON. Vor großen Prompts lässt sich das Budget mit apfel --count-tokens -f README.md "Summarize this" prüfen. Wer die mitgelieferten Demos nutzen will, schreibt sie mit apfel demos ./apfel-demos heraus; nach einem Upgrade müssen sie erneut erzeugt werden.

Dateien, Bilder und PDFs als Eingabe

Ein Teil der Praxisnähe von apfel steckt in der Dateianbindung. Das README zeigt apfel -f report.pdf "Summarize the key findings" und apfel -f receipt.jpg "What is the total?", wobei die Textextraktion, OCR und eine Beschreibung des Bildinhalts laut Projekt auf dem Gerät stattfinden. Mehrere Dateien lassen sich kombinieren, etwa apfel -f old.swift -f new.swift "What changed between these two files?". Auch eine Pipe mit PDF oder Bild funktioniert: cat report.pdf | apfel "Summarize this". Besonders brauchbar wirkt das Muster, bei dem ein Diff mit einer Konventionsdatei kombiniert wird: git diff HEAD~1 | apfel -f CONVENTIONS.md "Review this diff against our conventions". Hier zeigt sich der eigentliche Nutzen gegenüber einem reinen Chatfenster, weil der Prompt aus vorhandenen Werkzeugen gespeist wird. Einschränkung bleibt das Kontextfenster: Große PDFs passen nicht hinein, und das README liefert keine Angabe darüber, wie apfel längere Dokumente behandelt. Wer solche Dateien verarbeiten will, sollte vorher mit --count-tokens messen.

MCP-Werkzeuge und wo die Grenzen liegen

Über --mcp bindet apfel Server nach dem Model Context Protocol ein. Das README zeigt apfel --mcp ./mcp/calculator/server.py "What is 15 times 27?" und dokumentiert die Ausgabe: Auf STDERR erscheint zunächst die Liste der gefundenen Werkzeuge, dann der Aufruf multiply({"a": 15, "b": 27}) = 405, auf STDOUT die Antwort. Diese Trennung ist bewusst, denn sie erlaubt es, die eigentliche Antwort unverändert weiterzuverarbeiten. Die Grenzen des Projekts sind dagegen hart und werden im README offen benannt. Erstens die Plattformbindung: macOS 26 Tahoe oder neuer, Apple Silicon und aktivierte Apple Intelligence sind Pflicht. Auf Intel-Macs oder älteren Systemen läuft apfel nicht. Zweitens das Kontextfenster von 4096 Token unter macOS 26, das für längere Dokumente oder mehrstufige Unterhaltungen knapp ist; die 8192 Token unter macOS 27 sind zum Zeitpunkt der Dokumentation noch ein Ausblick. Drittens die Abhängigkeit vom Betriebssystemmodell selbst: apfel kann dessen Fähigkeiten nicht erweitern. Das README erwähnt außerdem einen Schalter --permissive, der Guardrail-Fehler bei kreativen oder langen Prompts reduzieren soll. Dass ein solcher Schalter nötig ist, deutet darauf hin, dass die Sicherheitsfilter des Systems gelegentlich legitime Anfragen blockieren. Wer auf reproduzierbare Ausgaben angewiesen ist, sollte das einplanen.

Was apfel von Ollama und llama.cpp unterscheidet

Der naheliegende Vergleich ist Ollama, das ebenfalls einen lokalen Server auf Port 11434 betreibt und im README als Referenz für den Hintergrunddienst auftaucht. Der Unterschied liegt im Modell selbst, nicht in der Schnittstelle. Ollama lädt eigene Gewichte herunter und führt sie über eine eigene Laufzeit aus; die Modellwahl, die Quantisierung und der Speicherbedarf liegen beim Nutzer. apfel verwendet dagegen das von Apple mitgelieferte FoundationModels-Modell, es gibt also nichts herunterzuladen und nichts zu quantisieren. Das erkauft man sich mit Kontrolle: Man kann weder ein größeres Modell wählen noch die Gewichte tauschen, und die Kontextgrenze von 4096 Token ist vorgegeben. Ein zweiter Unterschied ist die Portabilität. llama.cpp läuft auf vielen Plattformen und Betriebssystemen, apfel ausschließlich auf aktuellen Apple-Silicon-Macs mit macOS 26. Wer also ein Modell mit 128k-Kontext, feinabgestimmte Gewichte oder Betrieb auf Linux braucht, ist mit llama.cpp oder einem gehosteten Dienst besser bedient. Wer dagegen die vorhandene Hardware ohne zusätzliche Downloads nutzen will und mit kurzen Prompts auskommt, findet in apfel den kürzeren Weg.

Wartung, Lizenz und langfristige Kosten

apfel steht unter der MIT-Lizenz, was die Nutzung, Änderung und Weitergabe mit wenigen Bedingungen erlaubt. Wer das Projekt einbettet, sollte dennoch die üblichen Pflichten der Lizenz prüfen, etwa die Beibehaltung des Copyright-Hinweises; eine rechtliche Bewertung ersetzt das nicht. Wartungsseitig deutet die Versionsfolge auf ein aktives Projekt: v1.9.0 und v1.9.1 im August 2026, v1.10.0 im September 2026. Das README weist darauf hin, dass die gebündelten Demos nach jedem brew upgrade apfel mit apfel demos ./apfel-demos neu geschrieben werden müssen. Ein weiterer Kostenpunkt ist die Kopplung an das Betriebssystem. Ändert Apple die FoundationModels-Schnittstelle oder die Guardrails, muss apfel nachziehen. Umgekehrt profitiert das Projekt von Verbesserungen am Systemmodell, ohne selbst Gewichte ausliefern zu müssen. Für Teams bedeutet das: kein Modell-Hosting, keine GPU-Kosten, aber auch keine Kontrolle über Modellversion und Kontextgröße. Wer auf eine bestimmte Modellversion angewiesen ist, sollte das vorher klären.

Redaktionelles Fazit

Wer auf einem Apple-Silicon-Mac mit macOS 26 Tahoe und aktivierter Apple Intelligence kurze Prompts, Dateizusammenfassungen oder lokale SDK-Tests ohne Cloud-Anbindung braucht, kann apfel über brew install apfel ausprobieren. Für lange Dokumente, mehrsprachige Produktionspipelines oder Rechner ohne Apple Intelligence ist das Werkzeug die falsche Wahl, weil das Kontextfenster bei 4096 Token liegt und die Verfügbarkeit des Modells von der Plattform abhängt. Vor dem Einsatz im Team lohnt ein Blick auf docs/context-strategies.md und der Test von apfel --count-tokens mit dem längsten geplanten Prompt.

Offizielle Quellen

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