Souveränität auf geliehenem Fundament

Souveränität auf geliehenem Fundament

Artikel 12 · Serie: Ein lokaler Coding-Agent mit apfel

Elf Artikel lang haben wir einen Agenten gebaut, dessen Modell auf dem eigenen Mac läuft. Kein API-Key, kein Cloud-Endpunkt, keine Abrechnung pro Token. Das klingt nach Unabhängigkeit. Bevor wir den Agenten zum Abschluss in Xcode setzen, lohnt eine nüchterne Frage: worauf ruht diese Unabhängigkeit eigentlich? Zwei Veröffentlichungen aus einer einzigen Woche im Juni 2026 helfen, sie zu beantworten, weil sie die beiden Ränder markieren, zwischen denen apfel sitzt. Dies ist ein Einordnungs-Artikel, kein Bau-Artikel. Der Code-Stand bleibt unverändert.

Das lokale Modell bleibt Vorstufe

Am 8. Juni 2026 veröffentlichte Anthropic ein Swift-Package, das Apples Foundation-Models-Framework mit Claude verbindet (Quelle: Anthropic-Blog, 08.06.2026). Das Muster ist klar beschrieben: Das on-device-Modell übernimmt schnelle lokale Aufgaben, Zusammenfassung, Extraktion, typisierte Swift-Werte über @Generable. Sobald eine Anfrage mehrschrittiges Reasoning, Code-Generierung oder eine Websuche verlangt, reicht das Package an Claude weiter, in die Cloud, gegen einen Anthropic-API-Key. Die Antwort streamt zurück in dieselbe SwiftUI-View.

Technisch ist das elegant, und für viele Apps ist es genau richtig. Für unsere Frage ist es vor allem aufschlussreich. Hier nutzt ein von den Herstellern bereitgestelltes Werkzeug das lokale Modell für ernsthafte Arbeit, und der Weg endet beim Cloud-Anbieter. Das Foundation Model ist darin die Vorstufe, nicht der Agent, genau die Rolle, die diese Reihe ihm verweigert. Wir haben elf Artikel darauf verwendet zu zeigen, dass das kleine Modell für einen Agenten reicht, wenn man die Werkzeuge richtig baut. Das offizielle Werkzeug setzt voraus, dass es das nicht tut, und schiebt die eigentliche Arbeit zu Claude.

Geliehen und klein

apfel ruht auf demselben Fundament wie das Anthropic-Package, dem Foundation-Models-Framework. Und damit auf Entscheidungen, die wir nicht beeinflussen können. Apple bestimmt, welches Modell ausgeliefert wird, wie groß es ist, wann es sich ändert und wie stabil seine Schnittstelle bleibt. Das Modell ist closed-source. Wir können es nicht prüfen, nicht austauschen, nicht einfrieren.

Das ist keine abstrakte Sorge. Wir sind in dieser Reihe mehrfach an die Folgen gestoßen. Das Kontextfenster von 4096 Token hat unsere Loops von Anfang an begrenzt und den ContextManager nötig gemacht (Artikel 8). Die Guardrails des Modells haben harmlose Anfragen mal durchgelassen, mal blockiert, ohne erkennbares Muster (Artikel 7). Beides ist Verhalten, das Apple mit einem macOS-Update verschieben kann, ohne uns zu fragen. Ein Agent, der heute zuverlässig läuft, kann nach dem nächsten Update anders reagieren. Wer auf einer geschlossenen Plattform baut, baut auf beweglichem Grund, und sieht die Bewegung erst, wenn sie passiert ist.

Zur Geschlossenheit kommt die schlichte Größe. Das Modell hat berichtete drei Milliarden Parameter (Artikel 6), und das merkt man im Agent-Betrieb. Es fasst zusammen, erklärt und übersetzt zuverlässig, aber bei mehrschrittiger Planung bricht es ab, und die Argumente eines Werkzeugaufrufs trifft es nur etwa zwei von drei Malen, weshalb wir das Editieren über Artikel 4 bis 7 erst mit Constrained Output gangbar gemacht haben. Für einen Agenten reicht dieses Modell nur, weil wir die Werkzeuge eng führen und die Aufgaben klein halten. Artikel 6 hat die Grenze vermessen: kleine, lokale Edits ja, ernsthafte mehrschrittige Arbeit nein. Wir borgen also nicht bloß ein Modell, das sich ändern kann, sondern ein kleines. Dem steht ein realer Vorteil gegenüber, und der ist mehr als Bequemlichkeit: dieses Modell ist überall. Apple zählt über zwei Milliarden aktive Geräte, und auf der wachsenden, Apple-Intelligence-fähigen Teilmenge steckt es in der Plattform selbst, nicht in einer App, die man erst installiert. Wer darauf baut, erreicht jedes dieser Geräte ohne Download, ohne Key, ohne Einrichtung. Den Preis zahlt man in Leistung, nicht in Reichweite.

Die offene Alternative kostet Mühe

Am selben 8. Juni zeigte Apple auf der WWDC26, wie ein vollständig lokaler agentischer Stack ohne Foundation Model aussieht (Quelle: Apple, WWDC26-Session „Run local agentic AI on the Mac using MLX", 08.06.2026). Der Stack hat vier Schichten: MLX als Rechenfundament, MLX-LM zum Laden und Quantisieren von Modellen, einen MLX-LM-Server und darüber einen beliebigen Agenten. Der Server ist OpenAI-kompatibel und versteht structured tool calling, „a drop-in replacement for any cloud LLM API". Das ist exakt das Muster, das apfel-Serve uns gegeben hat, und auf das diese ganze Reihe baut.

Der Unterschied liegt im Modell. Bei MLX wählt man es selbst, aus Tausenden offenen Modellen, und kann es prüfen, tauschen, einfrieren. Zwei Beobachtungen aus der Session sind für uns bemerkenswert. Erstens bewirbt Apple für agentische Arbeit ausdrücklich MLX mit offenen Modellen, nicht das Foundation Model. Die Reihe nutzt also genau das Modell, das Apple selbst nicht als Agent-Backend positioniert. Zweitens spricht die Session von „hundreds of thousands of tokens" pro agentischer Sitzung, während wir mit 4096 Token gerechnet haben. Die enge Kontextgrenze ist kein Merkmal lokaler KI an sich, sondern eine Eigenschaft dieses einen, von Apple gewählten Modells.

Diese Offenheit hat einen Preis, und er ist real, in zwei Währungen. Die erste ist Aufwand: Installation, Modellwahl, Quantisierung, ein Download von mehreren Gigabyte. Die zweite ist Hardware, und sie skaliert mit dem Modell. Ein gutes, quantisiertes Modell, deutlich fähiger als apfels Foundation Model, läuft heute ordentlich auf einem einzelnen aktuellen Mac mit genug Unified Memory; das ist der realistische Weg für die meisten. Erst die größten Frontier-Modelle sprengen eine einzelne Maschine, und dafür zeigt die Session die Oberklasse: Macs mit 512 GB RAM und die größten Modelle über mehrere Macs per Thunderbolt verteilt (Apple, WWDC26, 08.06.2026). Die Hürde ist also kein Monster auf dem Schreibtisch, sondern ein abgestufter Aufwand, mehr RAM und etwas Einrichtung für ein klar besseres Modell. apfels Foundation Model verlangt nichts davon und läuft auf jedem aktuellen Mac, weil es klein ist. Genau das, was es schwach macht, macht es auch genügsam.

Das Dreieck

Zwischen diesen Polen wird die Lage der apfel-Reihe genau lesbar. Drei Wege, ein lokales oder lokal beginnendes Modell für einen Agenten zu nutzen, mit je einem Preis:

WegModellOrtHardwareAufwandBindung
MLX + offenes Modellfrei wählbar, offen, prüfbar, beliebig großvollständig lokalskaliert mit dem Modell: ein aktueller Mac für gute quantisierte, mehrere für Frontier-GrößeSetup, Download, Quantisierungkeine
Anthropic-PackageFoundation Model als Vorstufe, dann Claudelokal + Cloud-Handoffniedrig lokal, die Cloud trägt die LastgeringAPI-Key, Anbieter
apfel / Foundation Modelvon Apple vorgegeben, closed, kleinvollständig lokalniedrig, jeder aktuelle Macpraktisch nullPlattform (Apple)

MLX ist der souveränste Weg und der aufwändigste, in Mühe und etwas Hardware; dafür laufen dort frei wählbare, deutlich fähigere Modelle. Das Anthropic-Package ist das bequemste und leiht sich die Leistung aus der Cloud. apfel ist der niedrigschwelligste, läuft auf jeder Maschine und bleibt ganz auf dem Gerät, und zahlt dafür mit einem kleinen Modell auf geliehenem, jederzeit schließbarem Grund. Keiner der drei Wege bekommt alles: Leistung, Offenheit, niedrige Hürde, das sind drei Ecken, und man wählt zwei.

Der mittlere Pfad und seine Grenze

apfel sitzt in der Mitte dieses Dreiecks, und das ist eine bewusste Wahl, keine Verlegenheit. Der Wert des mittleren Pfads ist die Niedrigschwelligkeit: ein Agent, der auf jedem Apple-Silicon-Mac sofort läuft, ohne Key, ohne Download, ohne Anbieter im Rücken und ohne besondere Hardware. Für einen Einstieg in agentisches Coding, für kleine, lokale Aufgaben mit einem Werkzeug, das nichts kostet und nichts nach außen gibt, ist das ein ernsthaft guter Ausgangspunkt. Für mehr stößt das kleine Modell an genau die Grenzen, die Artikel 6 vermessen hat, und dann führt der Weg zu einem größeren Modell, also zu MLX mit etwas mehr RAM und Einrichtung oder zurück in die Cloud.

Zur Wahrheit gehört aber auch die Einordnung dieses Pfads. Souveränität auf dem eigenen Gerät ist real, solange man sie nicht mit Unabhängigkeit verwechselt. Unsere Daten verlassen den Mac nicht, das ist wahr und wertvoll. Aber das Modell, das sie verarbeitet, gehört uns nicht, und die Plattform, die es ausliefert, kann es morgen ändern. Wer echte Unabhängigkeit will, also ein Modell, das man besitzt und kontrolliert, landet bei offenen Gewichten und MLX, und zahlt mit Aufwand. Diese Reihe hat sich bewusst für den anderen Weg entschieden, und es ist fair, beide zu benennen.

Das Gelernte ist nicht geliehen, und der Agent selbst auch nicht. Er kennt das Foundation Model gar nicht. Er spricht das OpenAI-Protokoll gegen apfel-Serve, eine bewusste Entscheidung aus Artikel 2, und genau dieses Protokoll spricht auch der MLX-LM-Server mit seinen offenen Modellen. Ein Modellwechsel ist daher kein Neubau, sondern ein Backend-Tausch: das offene Modell über MLX einrichten, die base-url umstellen, fertig. Der Loop, die Werkzeuge, das Constrained-Editing, die drei Oberflächen, all das wandert unverändert mit. Wir haben in zwölf Artikeln nicht ein Modell verstanden, sondern wie man einen Agenten baut, und dieses Wissen läuft auf jedem Modell, das dasselbe Protokoll spricht. Verschiebt Apple morgen das Fundament, tragen wir den Agenten mit etwas Aufwand auf ein anderes.

Fazit

Der lokale Agent ist kein Souveränitäts-Endsieg, und er gibt vor, keiner zu sein. Er ist ein gangbarer mittlerer Weg: lokal, kostenlos, sofort verfügbar, und sein Modell zugleich gebunden an eine Entscheidung, die in Cupertino fällt, nicht bei uns. Das Anthropic-Package zeigt, wohin der bequeme Weg führt, zurück in die Cloud. MLX zeigt, dass der ganz freie Weg auf demselben Gerät offensteht, gegen Mühe. apfel macht das Dazwischen brauchbar, und weil wir gegen das Protokoll gebaut haben, bleibt der Weg zu einem anderen Modell jederzeit offen. Im letzten Schritt der Reihe setzen wir diesen Agenten dorthin, wo sonst die Cloud-Assistenten sitzen: in Xcode.


Vorheriger Artikel: Der Agent im Browser. Nächster Artikel: der lokale Agent in Xcode (Platzhalter, Link wird mit Publish von Artikel 13 final). Dieser Artikel ist ein Konzept-Interludium ohne eigenen Repo-Tag; der Code-Stand bleibt bei v1.0.