apfel : le LLM d'Apple Intelligence exposé en outil UNIX et serveur compatible OpenAI

Le problème : un modèle local sans interface exploitable

Apple Silicon embarque un LLM via Apple FoundationModels, mais le README ne décrit pas d'accès direct en ligne de commande. apfel comble cet écart en exposant le modèle sous deux formes : une commande UNIX et un serveur HTTP local. Le public visé est précis : développeurs sur macOS 26 Tahoe, Apple Silicon M1 ou plus récent, avec Apple Intelligence activé. Le README insiste sur trois absences : pas de clé d'API, pas de cloud, pas de téléchargement. L'inférence reste sur la machine. C'est la promesse centrale du projet, et elle conditionne tout le reste, y compris ses limites.

Deux modes, une même source d'inférence

Le premier mode est l'outil UNIX. `apfel "prompt"` retourne une réponse, et la commande accepte l'entrée standard : `echo "text" | apfel`. Le README mentionne les pièces jointes avec `-f`, la sortie JSON avec `-o json`, et un mode `--code` qui supprime la prose et les balises Markdown, avec un code de sortie 7 si le résultat est vide. Le second mode est le serveur compatible OpenAI, lancé avec `apfel --serve`. Il écoute sur `http://localhost:11434/v1`, ce qui permet de brancher un SDK OpenAI en changeant simplement `base_url` et en laissant `api_key` à une valeur quelconque. Le modèle à passer dans la requête s'appelle `apple-foundationmodel`. Un troisième mode, `apfel --chat`, fournit un REPL pour tester des prompts ou des serveurs MCP. Les trois partagent la même inférence on-device.

Installation et mise en route

L'installation passe par Homebrew : `brew install apfel`. La mise à jour se fait avec `brew upgrade apfel`. La compilation depuis les sources nécessite les Command Line Tools avec le SDK macOS 26.4 et Swift 6.3, sans Xcode : `git clone https://github.com/Arthur-Ficial/apfel.git && cd apfel && make install`. Le README cite aussi Nix, un tap, Mint et mise, avec un renvoi vers `docs/install.md` pour le dépannage. Pour lancer le serveur en arrière-plan, `brew services start apfel` joue le rôle équivalent à Ollama, et `brew services stop apfel` l'arrête. Deux variables d'environnement sont documentées : `APFEL_TOKEN` pour un jeton, et `APFEL_MCP` pour un chemin vers un outil au format Python. Le README précise que les prompts contenant `!` doivent être entre guillemets simples pour éviter l'expansion de l'historique en zsh et bash.

Appels d'outils MCP et sortie structurée

apfel peut attacher des serveurs Model Context Protocol avec `--mcp`. Le README donne l'exemple `apfel --mcp ./mcp/calculator/server.py "What is 15 times 27?"`, avec une trace sur stderr qui montre la découverte des outils (`add`, `subtract`, `multiply`, `divide`, `sqrt`, `power`, `round_number`), puis l'invocation `tool: multiply({"a": 15, "b": 27}) = 405`, et enfin la réponse sur stdout. Les appels d'outils fonctionnent, selon le README, dans tous les contextes. La sortie structurée s'appuie sur une génération guidée : `apfel --schema person.schema.json "Extract the person: Alice is 30."` garantit un JSON valide selon le schéma fourni. Pour les conversations multi-tours, `--messages -` accepte un JSON de conversation sur l'entrée standard et retourne le tour suivant de l'assistant. Ces deux mécanismes visent les scripts et les pipelines, pas l'usage interactif.

La contrainte de contexte et le mode permissif

La limite la plus concrète est la fenêtre de contexte : 4096 tokens sur macOS 26, 8192 sur macOS 27. Le README indique que cette valeur est lue à l'exécution et renvoie vers la section Limitations. Une commande existe pour vérifier le budget avant d'envoyer un gros prompt : `apfel --count-tokens -f README.md "Summarize this"`. C'est un point de friction réel pour les longs documents ou les conversations prolongées, et le README mentionne que le contexte est trimmé automatiquement dans le REPL, avec un renvoi vers `docs/context-strategies.md`. Le mode `--permissive` est présenté comme réduisant les faux positifs des guardrails pour les prompts créatifs ou longs. Le README ne détaille pas le taux de faux positifs ni les cas où le mode permissif ne suffit pas. C'est une zone d'ombre : si vos prompts sont régulièrement bloqués, la documentation ne donne pas de procédure de contournement au-delà de ce drapeau.

Ce que apfel n'est pas

apfel n'est pas un runtime de modèles. Il ne télécharge pas de poids, ne permet pas de choisir une architecture, et ne fonctionne pas sans Apple Intelligence. La contrepartie est double. D'un côté, aucune clé d'API, aucun coût par token, aucune donnée qui sort de la machine. De l'autre, vous dépendez du modèle fourni par Apple, de sa version, et des guardrails associés. Un lecteur qui a besoin d'un modèle qu'il peut inspecter, quantifier ou remplacer par un fine-tuning n'est pas le public. De même, le projet cible macOS 26 Tahoe et Swift 6.3. Sur une version antérieure de macOS, ou sur un Mac Intel, il n'y a pas de chemin documenté. Le README est explicite sur les prérequis, et cette clarté évite les mauvaises surprises, mais elle ferme aussi la porte à une partie du parc.

Alternative : Ollama et l'auto-hébergement

Le README compare lui-même le mode service à Ollama via `brew services start apfel`. La différence d'approche est nette. Ollama télécharge et exécute des modèles ouverts, avec un choix de tailles et de quantifications, et une fenêtre de contexte qui dépend du modèle et de la mémoire disponible. apfel ne télécharge rien et s'appuie sur le modèle déjà présent dans macOS. Le compromis : apfel est plus léger à installer et ne consomme pas d'espace disque pour des poids, mais il hérite des limites du modèle Apple, dont la fenêtre de 4096 tokens sur macOS 26. Ollama permet de monter à des contextes plus larges et de changer de modèle, au prix d'un téléchargement et d'une gestion de ressources. Le choix dépend donc de ce que vous acceptez de ne pas contrôler.

Maintenance, licence et coût de mise à jour

Le dépôt est actif, avec des versions récentes et une licence MIT. Cette licence autorise l'usage, la modification et la redistribution, y compris commerciale, avec conservation de l'avis de copyright. Elle ne couvre pas le modèle Apple lui-même, qui relève des conditions d'Apple et de l'activation d'Apple Intelligence. Le coût de maintenance côté apfel est faible : `brew upgrade apfel` suffit pour la version Homebrew. Un point pratique : le README indique de relancer `apfel demos` après une mise à jour pour rafraîchir les scripts de démonstration écrits dans le répertoire cible. Les demos (`cmd`, `oneliner`, `mac-narrator`, `wtd`, `explain`, `naming`, `port`, `gitsum`) sont embarqués dans le binaire, ce qui évite de cloner le dépôt. Si vous compilez depuis les sources, la contrainte est le SDK macOS 26.4 et Swift 6.3. Le projet n'énonce pas de politique de support à long terme, et le README renvoie à `docs/install.md` pour le dépannage plutôt que de promettre une compatibilité étendue.

Conclusion éditoriale

apfel convient aux développeurs sur macOS 26 Tahoe avec Apple Silicon qui veulent un backend local compatible OpenAI sans clé d'API, et à ceux qui cherchent une commande shell scriptable avec sortie JSON ou schéma garanti. Il ne convient pas si vos prompts dépassent le budget de contexte annoncé, si vous visez macOS 27 avec des attentes de fenêtre double, ou si vous avez besoin d'un modèle que vous pouvez inspecter et héberger vous-même. Avant d'adopter, vérifiez trois choses : que Apple Intelligence est bien activé sur la machine, que `apfel --count-tokens` retourne un budget compatible avec vos prompts réels, et que le comportement des guardrails ne bloque pas vos cas d'usage créatifs ou longs.

Sources officielles

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