Das Modell ist schon da — Prolog zum lokalen Coding-Agenten
Prolog · Serie: Ein lokaler Coding-Agent mit apfel
Auf jedem Apple-Silicon-Mac mit macOS 26 läuft ein Sprachmodell, das wir bisher kaum als solches benutzen. Es sitzt im System, formuliert Mails vor, fasst Notizen zusammen, schreibt Texte um — als programmierbares Werkzeug bleibt es aber unerreichbar. apfel öffnet dieses Modell als Kommandozeile und als OpenAI-kompatiblen Server. Daran setzt diese Reihe an: Wir bauen einen Coding-Agenten in Swift, der dieses lokale Modell als Backend nutzt — ohne API-Key, ohne Cloud-Endpunkt, ohne Token-Abrechnung. Über zwölf Artikel arbeiten wir uns von der CLI bis zur Anbindung an Xcode 26.3 über das Model Context Protocol vor. Zwei kritische Interludien zwischendurch ordnen ein, was das kleine on-device-Modell trägt und welche Plattform-Abhängigkeit wir uns mit dem lokalen Weg einhandeln.
Das Modell, das schon im Mac wohnt
Apple hat mit macOS 26 das Foundation-Models-Framework geöffnet — der gleiche Modellstamm, der bisher die Schreibwerkzeuge, Mail-Zusammenfassungen und andere Apple-Intelligence-Funktionen mit Sprache versorgt¹. Voraussetzung: ein Apple-Silicon-Mac (M1 oder neuer), macOS 26 und ein in den Systemeinstellungen aktiviertes Apple Intelligence. Das Modell liegt auf dem Gerät, kein Download nötig, keine Netzverbindung erforderlich. Was uns bisher fehlte, war ein bequemer Pfad vom Terminal oder vom eigenen Code aus zu diesem Modell.
¹ Apple Developer: FoundationModels Framework, https://developer.apple.com/documentation/foundationmodels (Abruf 2026-06-02).
Was apfel öffnet
apfel ist eine kleine CLI in Swift, installierbar über Homebrew. Sie kennt drei Modi.
Prompt-Modus für einmalige Anfragen:
apfel "fasse den Inhalt dieser Datei zusammen" -f notes.md
Serve-Modus als lokaler HTTP-Server, der die OpenAI-kompatible Chat-Completions-API spricht:
apfel --serve
# Server lauscht lokal, exakter Port siehe Artikel 2
Damit lässt sich jedes Tool, das einen OpenAI-Endpoint erwartet, auf das lokale Modell umlenken — von Skripten bis zu komplexeren Agenten.
Chat-Modus für eine interaktive Sitzung im Terminal:
apfel --chat
Der Chat-Modus hält Kontext über mehrere Runden, begrenzt durch das Kontextfenster des Modells. Die genauen Befehlsoptionen und Versions-Eigenheiten arbeiten wir in Artikel 1 aus.
Was lokal heißt
Lokal heißt: kein API-Key in einer .env-Datei, kein Endpoint, der morgen seine Preise ändert, keine Telemetrie an einen Anbieter. Daten bleiben auf dem Gerät. Für eine Reihe, die einen Coding-Agenten baut, ist das mehr als ein technisches Detail — Code, der durch den Agenten läuft, verlässt den Rechner nicht.
Lokal heißt aber auch: kein Cloud-Tempo. Ein on-device-Modell mit ein paar Milliarden Parametern hat eine andere Geschwindigkeit und eine andere Kapazität als die hochskalierten Modelle, gegen die wir es im Kopf vielleicht messen. Wer eine Frage in Claude oder ChatGPT stellt, vergleicht implizit gegen Cluster, die zwei Größenordnungen mehr Rechenleistung pro Antwort aufwenden. Dieser Vergleich ist hier nicht der Maßstab — der Maßstab ist, was lokal sinnvoll geht.
Wo das lokale Modell schmal wird
Das Foundation Model in macOS 26 ist klein. Drittquellen berichten von einer Größenordnung um drei Milliarden Parameter² — etwa auf dem Niveau, das Qwen-3-4B oder Llama-3-3B vor einem Jahr markiert haben. Das Kontextfenster ist ebenfalls klein, deutlich unter den 128k oder 200k, die wir aus den Cloud-Modellen kennen. Was das praktisch bedeutet, messen wir in Artikel 6: kleine, lokale Edits — ja. Mehrschrittige Pläne mit fünf Dateien Kontext — wackelig bis nein.
² Apple Machine Learning Research (10. Juni 2024, aktualisiert 29. Juli 2024): „Introducing Apple’s On-Device and Server Foundation Models", https://machinelearning.apple.com/research/introducing-apple-foundation-models — wörtlich: „a ~3 billion parameter on-device language model". Eine offizielle Spec für die macOS-26-Iteration ist Stand 2026-06 nicht öffentlich; konkrete Messung im Eval von Artikel 6.
Der zweite Punkt ist die Grundlage, auf der apfel steht. apfel nutzt das offizielle FoundationModels-Framework von Apple — eine dokumentierte Swift-API, keine undokumentierten Pfade. Was bleibt, ist die Plattform-Abhängigkeit selbst: Apple entscheidet, wann das Foundation Model aktualisiert wird, in welche Richtung es sich entwickelt, wie stabil die Schnittstelle bleibt. Das Modell ist closed-source — kein Audit der Trainingsdaten, kein Fine-Tuning, kein Cross-Platform-Fallback. Ein macOS-Update kann das Verhalten verschieben. Das ist bei anderen Anbietern nicht anders — auch Cloud-Modelle laufen closed-source, ohne Audit, mit Plattform-Bindung an einen einzigen Anbieter. Artikel 11 nimmt sich diese Spannung im Detail vor.
Wir nennen das hier nicht, um die Reihe zu relativieren, bevor sie begonnen hat — sondern damit klar ist, worauf wir bauen. Souveränität auf einem Fundament, das einer einzelnen Plattform-Entscheidung folgt, ist eine andere Souveränität als eine vollständig offene Modell-Laufzeit.
Was die Reihe ist und nicht ist
Die Reihe ist ein Lehrstück über den Agent-Loop. Wir bauen ein Werkzeug, das ein Modell auf dem eigenen Rechner ansprechen kann, das Werkzeuge benutzt, Dateien liest, Diffs zeigt, Bestätigungen einholt, Pläne abarbeitet. Über die zwölf Hauptartikel führt der Weg von der ersten CLI-Antwort bis zur Integration in Xcode 26.3 — drei verschiedene Oberflächen auf demselben AgentCore.
Die Reihe ist kein Claude-Code-Klon. Wir bauen kein Produkt, das mit Cloud-Agenten konkurrieren will. Wir bauen ein Werkzeug, das zeigt, was die Mechanik unterhalb solcher Agenten ist — und das im Rahmen dessen, was lokal trägt, anständig läuft. Die Reihe ist auch kein Sieg-Vergleich. Wenn wir in Artikel 6 das lokale Modell gegen einen Cloud-Agenten vermessen, geht es um Einsatz-Profile, nicht um Punktstände.
Ausserhalb des Bogens bleiben: MLX direkt und alternative Modell-Laufzeiten (Querverweis zur Hummingbird-Reihe), VS-Code-Anbindungen, Multi-Agent-Orchestrierung. Und alles, was eine andere Plattform als Apple Silicon mit macOS 26 voraussetzt.
Mitmachen
Der Demo-Code wächst öffentlich auf Codeberg: rotecodefraktion/apfel-coding-agent. Pro Artikel ein Git-Tag (v0.1 bis v1.1), der den Stand am Ende des Artikels einfriert. Wer nachbauen möchte:
- Apple-Silicon-Mac, macOS 26 (Tahoe), Apple Intelligence in den Systemeinstellungen aktiv
brew install apfel(genauer Befehl in Artikel 1)- Repo klonen, Tag pro Artikel auschecken, mitziehen
Die genauen Versionsstände (apfel, macOS, Xcode) stehen im Frontmatter jedes Artikels und in docs/setup.md des Demo-Repos. Wenn ein späterer Artikel ein apfel-Update nötig macht, benennen wir den Sprung explizit.
Wie es weitergeht
Artikel 1 nimmt apfel selbst auseinander: Installation, die drei Modi im Detail, JSON-Output für Skripte, System-Prompts, Datei-Input. Bevor wir den Agenten bauen, lernen wir das Werkzeug kennen, auf dem er sitzt.
Nächster Artikel: apfel von der Kommandozeile (Platzhalter — Link wird mit Publish von Artikel 1 final). Repo-Tag: keiner (Konzept-Artikel).
