Agentic Workflow mit Foundation Models: In-App vs. Tooling-LLM

Eine Swift-App auf iOS 26 hat zwei LLMs, die sie berühren – auf sehr unterschiedlichen Ebenen. Der eine ist das On-Device-Modell, das der Benutzer über die LanguageModelSession der App ausführt. Der andere ist der Agent, den der Entwickler über Claude Code oder Cursor oder Codex CLI ausgeführt hat, um die App überhaupt erst zu schreiben. Diese beiden LLMs zu vermischen, ist ein wiederkehrender Architekturfehler in der agentischen Apple-Entwicklung. Sie sind nicht dasselbe Problem; sie teilen sich kein Sicherheitsmodell; sie teilen sich keine Deployment-Story; und die Muster, die für das eine funktionieren, scheitern für das andere aktiv.

Die Runtime-LLM ist eine Funktion, die an den Benutzer ausgeliefert wird. Die Tooling-LLM ist ein Stift, den der Entwickler hält. Das Runtime-Modell lebt hinter den Datenschutzerwartungen des Benutzers, den Verfügbarkeitsprüfungen des Systems und der App-Store-Prüfung. Das Tooling-Modell lebt hinter dem API-Schlüssel des Entwicklers, den Dateisystemberechtigungen der IDE und einem Code Review, für den der Entwickler verantwortlich ist. Die beiden Stacks überschneiden sich selten, und wenn sie es tun (ein MCP-Server, den der Entwickler während der Entwicklung verwendet, um die Domäne der App zu bedienen, und den die Runtime-App auch für die Endbenutzer-Automatisierung freigeben könnte), verschiebt sich die Vertrauensgrenze, und die Architektur muss dies anerkennen.

Der Beitrag benennt diese Unterscheidung und die daraus folgende Routing-Frage: Welche LLM sollte welche Fähigkeit bedienen, und was schuldet jede dem Benutzer.

TL;DR

• Die Runtime-LLM ist Foundation Models (SystemLanguageModel.default plus das Tool-Protokoll). Die Inferenz ist lokal, das Modell wird mit dem Betriebssystem ausgeliefert, die App führt den Aufruf im Namen des Benutzers aus.¹
• Die Tooling-LLM ist das, was der Entwickler gewählt hat: Claude in Claude Code, GPT in Cursor, Codex CLI für Swift. Die Inferenz ist remote (Infrastruktur von Anthropic oder der konfigurierte Claude-Anbieter, OpenAI usw.), das Modell befindet sich dort, wo der Host es platziert hat, der Entwickler steuert den Agenten.
• Die beiden LLMs teilen sich weder Sicherheit, Deployment, Latenzbudgets noch Verantwortlichkeit. Eine Fähigkeit, die auf einer Ebene Sinn ergibt, hat auf der anderen oft die falsche Form.
• Derselbe MCP-Server, den der Entwickler während einer Claude Code-Sitzung verwendet, ist nicht automatisch die richtige Oberfläche für die Endbenutzer-Agent-Automatisierung. Die Vertrauensgrenze ändert sich; was ein vom Entwickler kontrolliertes Werkzeug war, wird zu einem vom Benutzer (oder vom System) kontrollierten Werkzeug.

Zwei Stacks, dasselbe Wort „LLM”

Die Kollision passiert in Gesprächen wie diesem. Jemand sagt: „Wir sollten der App eine LLM hinzufügen.” Ob das eine Funktion bedeutet, die der Benutzer aufruft (schreibe mir eine Meditationszusammenfassung, poliere diesen Entwurf, klassifiziere dieses Foto), oder ein Werkzeug, das der Entwickler in seine eigene Iterationsschleife einbindet (lasse Claude Code die Migration schreiben, lasse Cursor die View refaktorieren), geht aus dem Satz nicht klar hervor. Beides sind LLM-Erweiterungen. Keines ist dieselbe Engineering-Entscheidung.

Foundation Models ist ein Stack. Das Modell lebt unter SystemLanguageModel.default, hat ein Kontextfenster fester Größe, läuft auf Apple Silicon, verlässt das Gerät niemals und ist durch die Apple-Intelligence-Berechtigung des Benutzers eingeschränkt.¹ Der App-Entwickler beschränkt Eingaben durch @Generable-Typen, stellt App-Fähigkeiten über das Tool-Protokoll bereit und liefert ein Binary aus, das das Modell aufruft, wenn die Funktion ausgelöst wird. Der Benutzer ruft die Funktion auf; das Betriebssystem stellt das Modell bereit; die App fügt sie zusammen.

Claude Code, Cursor, Codex CLI und jede andere agentische IDE bilden einen anderen Stack. Das Modell lebt dort, wo der Host der LLM-Anbieter es ausführt (Anthropics Server für Claude, OpenAIs für GPT usw.). Die IDE ist der Host. Die MCP-Server sind Werkzeuge, die das Modell des Hosts aufrufen kann. Die Maschine des Entwicklers hat Dateisystemzugriff, Shell-Zugriff und alles andere, was die IDE freigegeben hat. Der Entwickler ruft den Agenten auf; der Agent greift in das Dateisystem des Entwicklers; die Ausgabe landet im Projekt des Entwicklers.²

Dasselbe Wort „LLM”, sehr unterschiedliche Wirkungsradien.

Sechs Achsen, auf denen die beiden Stacks divergieren

Sechs Eigenschaften machen die Divergenz konkret:

Die Vertrauensgrenze ist die tragende Zeile. Die Runtime-LLM operiert innerhalb der Sandbox der App unter den Datenschutzerwartungen des Benutzers; die Tooling-LLM operiert innerhalb der Maschine des Entwicklers unter dessen Autorität. Ein Muster wie den LLM-Agenten einen Shell-Befehl ausführen lassen ist im Tooling normal (Claude Code tut dies ständig über sein Bash-Werkzeug)³ und in der Runtime ein No-Go: Foundation Models hat kein Bash-Werkzeug, und das Tool-Protokoll ist eine typisierte Swift-Funktion, die der App-Entwickler geschrieben hat und prüft.¹

Die Zeile zu den Missbrauchskosten ist die Konsequenz daraus, dass die Vertrauensgrenze falsch gezogen wird. Eine Runtime-LLM, die Benutzerdaten an einen Server exfiltriert, ist eine Datenschutzverletzung und eine Richtlinienablehnung. Eine Tooling-LLM, die den Quellcode des Entwicklers an einen LLM-Anbieter exfiltriert, ist – je nach Vertrag des Entwicklers – entweder erwartetes Verhalten oder ein Leck. Beides ist wichtig; es ist aus unterschiedlichen Gründen wichtig.

Der MCP-Server, der dazwischen sitzt

Am saubersten lässt sich die Verschiebung der Grenze beobachten, wenn ein einzelner MCP-Server von beiden Stacks verwendet wird. Get Bananas liefert einen MCP-Server aus, der Operationen für Einkaufslisten bereitstellt: Artikel lesen, Artikel hinzufügen, als erledigt markieren. Derselbe Server läuft an zwei Stellen.⁴

In der Claude Code-Sitzung des Entwicklers während der Iteration ist der MCP-Server ein Werkzeug, das der Agent des Entwicklers aufruft, um die eigene Liste des Entwicklers zu manipulieren. Der Server läuft gegen eine JSON-Datei in iCloud Drive. Der Entwickler hat den Server in seine MCP-Host-Konfiguration eingebunden; der Host weiß, dass er ihn aufrufen muss; der Agent liest und schreibt Einkaufsartikel als Teil größerer Entwicklungsaufgaben.

In einer Endbenutzer-Agent-Oberfläche (zum Beispiel ein externer Claude-Desktop-Benutzer, der auf eine geteilte Liste verweist) hat derselbe MCP-Server andere Verpflichtungen. Der Aufrufer ist nicht mehr Blake-der-Entwickler mit vollem Dateisystemvertrauen; der Aufrufer ist ein Endbenutzer, dessen Authentifizierung, Autorisierung und Absichtsprüfung nicht in der Verantwortung des Entwicklers liegen. Der MCP-Server muss diese Schutzmaßnahmen durchsetzen (oder sich weigern, sich freizugeben), bevor diese Oberfläche sicher wird.

Dieselbe JSON-RPC-Methode, add_item, einem Entwickler über einen lokalen Stdio-Transport ohne Authentifizierung bereitgestellt, hat die richtige Form. Einem internet-erreichbaren Host im Namen eines beliebigen Endbenutzers ohne Authentifizierung bereitgestellt, ist sie eine Gefahr für die Datenintegrität. Der MCP-Server ist derselbe Code; das umgebende Deployment ändert alles.

Das ist die Routing-Regel für MCP-Server in der agentischen Apple-Entwicklung. Der Server ist ein typisierter Vertrag über eine Domäne. Wo er im Stack sitzt (Entwicklerwerkzeug vs. Endbenutzeroberfläche), ist eine Deployment-Entscheidung, keine Protokollentscheidung. Prüfen Sie das Deployment per Code Review; gehen Sie nicht davon aus, dass die permissiven Standardwerte des Protokolls die richtigen Standardwerte des Deployments sind.

Das On-Device-Tool-Protokoll ist kein MCP-Server

Eine häufige Verwechslung: Foundation Models hat ein Tool-Protokoll, und MCP hat Tool-Aufrufe. Sind sie dasselbe? Nein, und der Unterschied ist für das Routing entscheidend.

Das Tool-Protokoll von Foundation Models ist ein Swift-API, das der App-Entwickler implementiert:¹

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."
    @Generable struct Arguments { ... }
    func call(arguments: Arguments) async throws -> String { ... }
}

Das Tool läuft innerhalb des App-Prozesses. Das Modell, das das Tool bedient, ist das SystemLanguageModel des Geräts. Die Argumente und Ausgaben sind Swift-Typen. Der Entwickler prüft die Implementierung, der App Store prüft die App. Der Benutzer ruft eine Funktion auf; die Sitzung der App ruft das Tool auf; das lokale Modell verwendet das Ergebnis.

Ein MCP-Tool ist eine JSON-RPC-Methode, die von einem MCP-Server bereitgestellt wird, der ein separater Prozess ist, mit dem die Host-LLM (Claude, GPT usw.) eine Verbindung herstellt:²

{
  "name": "add_item",
  "description": "Add an item to the shopping list.",
  "inputSchema": {"type": "object", "properties": {"name": {"type": "string"}}}
}

Das Tool läuft außerhalb des Agent-Prozesses, in der vom Entwickler gewählten Sprache, und kommuniziert per JSON über Stdio oder Streamable HTTP. Das Modell befindet sich dort, wo der Host es platziert hat. Die Argumente sind JSON, validiert gegen das Schema. Die Verantwortlichkeit liegt bei demjenigen, der den MCP-Server bereitgestellt hat.

Die beiden Protokolle lösen sich überschneidende Probleme mit unterschiedlichem Geltungsbereich:

Die Routing-Regel ist eindeutig: Wenn die Fähigkeit die eigenen LLM-Funktionen der App für Endbenutzer bedient, gehört sie in ein Foundation-Models-Tool. Wenn die Fähigkeit einen externen Agenten (Entwickler oder Endbenutzer) bedient, der prozessübergreifend operiert, gehört sie in ein MCP-Tool. Manche Apps benötigen beides; dieselbe Swift-Funktion kann beide Adapter unterstützen, aber die Adapter leben auf unterschiedlichen Stack-Ebenen und werden über unterschiedliche Release-Zyklen ausgeliefert.⁵

Hooks sind dort, wo die Tooling-LLM ihren Platz verdient

Der Wirkungsradius der Tooling-LLM macht Hooks zur tragenden Sicherheitsprimitive. Das Hook-System von Claude Code führt Skripte bei Lebenszyklusereignissen aus (PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop).⁶ Ein iOS-Entwickler, der Claude Code verwendet, richtet Hooks nicht ein, weil der Agent bösartig ist, sondern weil die Autorität des Agenten weitreichend ist: Dateisystem-Schreibzugriff, Shell-Ausführung, Git-Commits, Push.

Die Muster, die sich ihren Hook-Slot in der agentischen Apple-Arbeit verdienen:

Ein PreToolUse-Block für Bash-Befehle, die mit xcodebuild oder xcrun übereinstimmen, ohne ausdrückliche Genehmigung. Claude Code kann Builds ausführen, Simulatoren löschen, Signier- oder Exportschritte aufrufen oder den generierten Projektzustand verändern, wenn Sie es zulassen. Der Hook macht aus „der Agent hat einen Build ausgeführt” ein „der Agent hat um die Ausführung eines Builds gebeten und ein Ja erhalten”. Den Agenten bei irreversiblen Aktionen zu verlangsamen, ist der richtige Kompromiss für das Vertrauen des Entwicklers.

Ein PostToolUse-Validator für jeden Edit- oder Write-Tool-Aufruf gegen .pbxproj-Dateien. Die Xcode-Projektdatei ist menschlich bearbeitet, aber agentenfeindlich; eine falsche Zeile bricht den Build für jeden Entwickler im Team stillschweigend. Ein Hook, der plutil -lint (oder eine ähnliche Strukturprüfung) bei jedem .pbxproj-Schreibvorgang vor dem Commit ausführt, ist der Unterschied zwischen „der Agent hat die Migration in fünf Minuten geschrieben” und „der Agent hat die Migration und fünfundvierzig Minuten Git-Bisect geschrieben”.

Ein Stop-Hook, der swift build (oder den entsprechenden Build-Befehl) ausführt, bevor der Agent eine Aufgabe als erledigt erklären darf. Agenten sind darauf trainiert, was „erledigt” im Gespräch aussieht. Der Hook macht aus „erledigt” „der Build kompiliert noch”, was die einzige Definition ist, die für das Ausliefern zählt.

Die Runtime-LLM braucht nichts davon. Foundation Models hat keine Shell, kein Git, keine Projektdatei, keine MCP-Server-Konfiguration. Das On-Device-Tool ist die Swift-Funktion, die der App-Entwickler geschrieben hat; der Benutzer ruft eine Funktion auf; nichts entkommt der Sandbox oder den Berechtigungen der App, es sei denn, die Tool-Implementierung der App selbst tut es.

Die Asymmetrie ist der Punkt. Die Tooling-LLM hat mehr Autorität und benötigt mehr Schutzgeländer. Die Runtime-LLM hat konstruktionsbedingt weniger Autorität. Apple hat die Arbeit geleistet, die Runtime-LLM sicher zu machen; der Entwickler leistet die Arbeit, die Tooling-LLM sicher zu machen.

Architekturregeln

Aus der Unterscheidung zwischen Runtime und Tooling folgen drei Architekturregeln.

Wählen Sie die Ebene pro Fähigkeit, nicht pro App. Eine Meditations-App könnte Foundation Models für die In-App-Zusammenfassung verwenden (Runtime-LLM, On-Device, mit der App ausgeliefert) und einen MCP-Server bereitstellen, den der Entwickler mit Claude Code verwendet, um den Sitzungsverlauf während der Iteration in größeren Mengen zu importieren. Die beiden LLMs erfüllen unterschiedliche Aufgaben auf unterschiedlichen Ebenen. Sie als eine Entscheidung zu behandeln, führt auf beiden Ebenen zu einem schlechteren Ergebnis als sie als zwei Entscheidungen zu behandeln.

Prüfen Sie die Reichweite der Tooling-LLM per Code Review. Eine Claude Code-Sitzung mit vollem Dateisystemzugriff und Remote-MCP-Servern ist eine mächtige Entwicklungsumgebung und eine großzügige Angriffsfläche. Die Abhilfe lautet nicht „dem Agenten vertrauen”; die Abhilfe sind Hooks, eingegrenzte Berechtigungen und ein Entwickler, der das Diff liest. Der Agent arbeitet für Sie; der Agent ist nicht Sie.

Liefern Sie das Tool-Set der Runtime-LLM als stabiles API aus. Foundation-Models-Tools sind Teil des binären Vertrags Ihrer App. Das Entfernen oder Umbenennen eines Tools zwischen Releases ist eine Verhaltensänderung für Benutzer, die sich auf die Funktion verlassen haben. Behandeln Sie Tool-Definitionen wie UI-Affordances, nicht wie interne Hilfsfunktionen.

Was ich in meinem Stack anders bauen würde

Zwei Muster, die die Apps des Clusters entweder ausliefern oder sich wünschen, ausgeliefert zu haben.

Bauen Sie zuerst die Domänenschicht; lassen Sie Runtime-Tools und Tooling-MCP-Server dieselben Swift-Funktionen umhüllen. Das Dual-Adapter-Muster aus App Intents vs. MCP erweitert sich natürlich auf Runtime-LLM-Tools. Eine logWater(amount:caller:)-Domänenmethode wird durch ein AppIntent (Apple-Intelligence-Oberfläche), ein MCP-Tool (Oberfläche externer Agenten) und ein Foundation-Models-Tool (In-App-Runtime-LLM-Oberfläche) umhüllt. Drei Protokolladapter, eine Domänenfunktion, drei Aufruferklassen (System-Agent, externer Agent, On-Device-Modell) mit drei unterschiedlichen Verpflichtungen. Die Funktion weiß nicht, welcher Aufrufer sie aufgerufen hat; die Adapter tragen die Vertrauenssignale.

Behandeln Sie die MCP-Server des Agenten als Code, nicht als Konfiguration. Eine .mcp.json, auf die in einem iOS-Projekt verwiesen wird, ist eine Vertrauensoberfläche für Geltungsbereich und Vorrang (behandelt in The Repo Shouldn’t Get to Vote on Its Own Trust). Claude Code löst den MCP-Server-Geltungsbereich als lokal > Projekt > Benutzer auf, und projektbezogene Server fragen den Entwickler vor der Verwendung um Genehmigung. Der Agent liest die Konfiguration und verbindet sich mit den Servern, die der Entwickler genehmigt; der Entwickler prüft die Konfiguration und die Server. Das Hinzufügen eines MCP-Servers zu einem Projekt ist ein Code Review, keine Konfigurationsanpassung.

Wann Foundation Models richtig ist und wann die Tooling-LLM richtig ist

Der Entscheidungsbaum, auf den die Beiträge des Clusters konvergieren:

Is the capability a feature an end user invokes inside your app?
├── Yes → Runtime LLM (Foundation Models or cloud LLM behind an Apple Intelligence-aware surface)
│         Use the Tool protocol for app-internal tool calls.
│         Use App Intents for capabilities the system agent should reach.
└── No → It is part of the developer's iteration loop.
          ├── Is the capability local to one developer's machine? → Tooling LLM
          │     Use Claude Code, Cursor, or Codex CLI directly.
          │     Wrap shared utilities as MCP servers behind hooks.
          └── Is the capability shared across the team? → Tooling LLM with shared MCP servers
                Deploy the MCP server somewhere the team can reach.
                Code review the server like production code; gate dangerous tools behind explicit approval.

Die Entscheidung führt selten zu einem Unentschieden. Wenn doch (dieselbe Fähigkeit könnte legitim sowohl Endbenutzer als auch Entwickler bedienen), ist die Antwort zwei Adapter, nicht eine geteilte Oberfläche, denn die Vertrauenshaltungen und Update-Kadenzen unterscheiden sich so sehr, dass eine Oberfläche, die versucht, beides zu bedienen, an beidem Kompromisse eingeht.

Was das Muster für Apps bedeutet, die auf iOS 26+ ausgeliefert werden

Drei Erkenntnisse.

1. Zwei LLMs, zwei Stacks. Die Runtime-LLM (Foundation Models, On-Device) ist der Agent des Benutzers, der mit dessen Daten innerhalb Ihrer App operiert. Die Tooling-LLM (Claude Code, Cursor, Codex CLI) ist der Agent des Entwicklers, der auf der Maschine des Entwicklers operiert, um die App zu bauen. Sie teilen sich das Wort „LLM” und fast nichts anderes.

2. Die Vertrauensgrenze ist die Architektur. Wo das Modell läuft, wer es ausführt und was es berührt, definieren die Verpflichtungen. Muster, die zu der einen Grenze passen, scheitern an der anderen aktiv.

3. MCP-Server tragen die Grenze. Derselbe Server ist in einem Deployment ein Entwicklerwerkzeug und in einem anderen eine Endbenutzeroberfläche. Das Protokoll ändert sich nicht; das Deployment ändert sich, und das Deployment ist der Teil, der die technische Aufmerksamkeit braucht.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents für Apple Intelligence; MCP-Server für LLM-übergreifende Agenten; die Routing-Frage zwischen den beiden; Foundation Models für die On-Device-LLM und das Tool-Protokoll, mit Anwendungsfällen und eigenen Adaptern als Geschwister für Workload-Eignung und Spezialisierung; Live Activities für die Zustandsmaschine des iOS-Sperrbildschirms; der watchOS-Runtime-Vertrag auf der Apple Watch; SwiftUI-Internas für das Framework-Substrat; RealityKits räumliches Denkmodell für visionOS-Szenen; SwiftData-Schema-Disziplin für die Persistenz; Liquid-Glass-Muster für die visuelle Ebene; plattformübergreifendes Ausliefern für die geräteübergreifende Reichweite. Der Hub befindet sich in der Apple Ecosystem Series. Für einen breiteren Kontext zu iOS mit AI-Agenten siehe den iOS Agent Development guide.

FAQ

Was ist der Unterschied zwischen Foundation Models und Claude Code aus Architektursicht?

Foundation Models ist eine Runtime-Funktion: Die LLM wird mit iOS 26 ausgeliefert, läuft auf dem Gerät des Benutzers über SystemLanguageModel.default und wird aufgerufen, wenn die LanguageModelSession der App auslöst. Die App führt den Aufruf im Namen des Benutzers aus. Claude Code ist ein Entwicklungswerkzeug: Die LLM läuft auf der Infrastruktur von Anthropic (oder dem konfigurierten Claude-Anbieter), die Maschine des Entwicklers hostet die IDE, und der Agent hat Zugriff auf Dateisystem, Shell und MCP-Server des Entwicklers. Der Entwickler steuert den Agenten; der Agent hilft beim Bau der App.

Sollte derselbe MCP-Server sowohl meinen Agenten als auch meine Endbenutzer bedienen?

Wahrscheinlich nicht. Derselbe JSON-RPC-Vertrag kann für beide die richtige Form haben, aber die Deployments sind unterschiedlich: entwicklerseitiges Stdio ohne Authentifizierung ist für ein Entwicklerwerkzeug normal und für eine Endbenutzeroberfläche eine Gefahr. Das Protokoll ist wiederverwendbar; das Deployment nicht. Wenn Sie denselben Server tatsächlich beiden bereitstellen, behandeln Sie ihn als zwei Deployments hinter einer Codebasis, nicht als eine Oberfläche für beide Zielgruppen.

Warum braucht die Tooling-LLM Hooks, die Runtime-LLM aber nicht?

Die Tooling-LLM hat Dateisystemzugriff, Shell-Zugriff, MCP-Server und beliebige Code-Ausführungsautorität auf der Maschine des Entwicklers. Die Runtime-LLM (Foundation Models) hat das, was die Tool-Implementierungen der App freigeben, innerhalb der Sandbox der App, ohne Shell. Der Wirkungsradius ist asymmetrisch. Hooks bieten dem Entwickler eine Vor-Ausführungs-Prüfung und eine Nach-Ausführungs-Validierung gegen die weitreichende Autorität. Die Runtime-LLM braucht sie nicht, weil ihre Autorität konstruktionsbedingt eingeschränkt ist.

Kann eine einzelne Swift-Domänenfunktion sowohl Runtime- als auch Tooling-LLM-Anwendungsfälle bedienen?

Ja, und das ist das richtige Muster. Der Dual-Adapter-Ansatz (eine Swift-Funktion, mehrere Protokoll-Wrapper) erweitert sich von App Intents vs. MCP um Foundation-Models-Tools. Die Funktion weiß nicht, welcher Aufrufer sie aufgerufen hat; die Adapter tragen das Schema, die Vertrauenssignale und die protokollspezifischen Verpflichtungen. Drei Adapter, eine Domänenmethode.

Wo passen gehostete Cloud-LLMs (OpenAI, Anthropic-API direkt) in dieses Bild?

Cloud-LLMs, die von innerhalb einer App zur Laufzeit aufgerufen werden, sind eine dritte Kategorie: Runtime-LLM mit Off-Device-Inferenz. Sie teilen die Foundation-Models-Vertrauenshaltung „die App führt den Aufruf im Namen des Benutzers aus”, verlieren aber die On-Device-Datenschutzgeschichte und die vom Betriebssystem bereitgestellte Verfügbarkeitsgeschichte. Der Entscheidungsbaum erweitert sich: Cloud-Runtime-LLMs sind angemessen für Fähigkeiten, die das Leistungsspektrum des On-Device-Modells echt überschreiten (großer Kontext, Frontier-Reasoning, multimodal in Skalierung), und akzeptabel für die Datenschutzerwartungen des Benutzers (mit transparenter Offenlegung). Foundation Models ist die Standardwahl, wenn der Workload passt; Cloud ist die Eskalation, wenn er es nicht tut.

Quellen