Anbieter

Wozu das da ist. Anbieter sind die LLM-Backends dieser Instanz: Cloud-APIs, Host-CLIs (Claude Code, Grok, Kimi) und lokale Runtimes (Ollama, LM Studio, vLLM). Du schaltest einen Anbieter ein, hinterlegst seinen Schlüssel, wählst Modelle, und das Routing nutzt ihn. Diese Seite erklärt auch, wie EYAS die CLIs vom eigenen Setup der Maschine fernhält: Claude Code läuft immer isoliert, Grok und Kimi laufen in ihrem eigenen EYAS-Home und werden für EYAS angemeldet, und ein Zug stoppt, wenn EYAS diese Isolation nicht bestätigen kann.

Route: /providers. Untertitel: KI-Routing, Provider-Konfiguration und Budgetkontrolle. Tabs: Routing-Stufen · Provider · Budget · KI-Analyse. In der Seitenleiste: Anbieter.

Wann du es brauchst

Nach dem Setup: Anbieter Ein, API-Schlüssel einfügen, Modelle aktivieren.
claude / grok / kimi sind auf dem Host installiert, und du willst einen CLI-Anbieter ohne Schlüssel.
Grok CLI oder Kimi Code CLI zeigt Anmeldung erforderlich — für EYAS anmelden (siehe Grok und Kimi für EYAS anmelden).
EYAS soll eine bestimmte Installation einer CLI ausführen (EYAS_CLAUDE_CODE_BIN, EYAS_GROK_BIN, EYAS_KIMI_BIN) — siehe Claude-Code-Laufzeit und Grok CLI und Kimi Code CLI.
Ein Zug stoppte mit einem CLI-Isolationsfehler, und du musst wissen, was auf dem Host zu ändern ist.
Du hast Claude Code, Grok CLI oder Kimi Code CLI aktualisiert und willst wissen, ob EYAS’ Isolation auf dieser Version nachgewiesen ist (siehe Nachgewiesene CLI-Versionen).
Das Panel eines CLI-Anbieters sagt, die Kernel-Datei-Sandbox sei Auf diesem Server nicht verfügbar, oder du willst, dass CLI-Züge sie verlangen (siehe Kernel-Datei-Sandbox).
Eine Modellzeile sagt Von der letzten Aktualisierung nicht mehr angeboten, oder du willst wissen, welches konkrete Modell eine Zeile ausführt.
Du willst wissen, welche Reasoning-Effort-Stufen ein Modell anbietet, was Automatisch für es bedeutet und wie jeder Anbieter die Stufe anwendet (siehe Reasoning-Effort und Wie jeder Anbieter die Effort-Stufe anwendet).

Typischer Ablauf

Anbieter (/providers) → Tab Provider.
Karte wählen. Ein / Aus schaltet sie fürs Routing frei. Authentifizierung nimmt einen API-Schlüssel (verschlüsselt in Geheimnisse); Claude Code nutzt die Claude-Code-Anmeldung auf diesem Rechner; Grok CLI und Kimi Code CLI zeigen eine Karte Für EYAS anmelden.
Modelle aktivieren. Modelle aktualisieren lädt die Modellliste des Anbieters neu — derselbe Knopf für jeden Anbieter, API oder CLI. Modelle, die der Anbieter nicht mehr anbietet, werden ausgeschaltet und markiert, nie gelöscht.
Stufen und Budget: Routing & Budget.

Funktionen

Jede Karte zeigt Identität, Zustand und An/Aus-Schalter.

Element	Bedeutung
Ein / Aus	Anbieter fürs Routing freischalten
N/M Modelle aktiviert	Wie viele Modelle aktiv sind
CLI nicht gefunden	Host-Binary fehlt
Kein API-Schlüssel	Braucht einen Schlüssel
Authentifizierungsfehler	Zugangsdaten gescheitert — Schlüssel/Login neu eingeben
Anmeldung erforderlich	Rotes Badge bei Grok CLI / Kimi Code CLI: Die CLI ist nicht für EYAS angemeldet (Tooltip: <CLI> ist nicht für EYAS angemeldet. Öffne den Anbieter, um dich anzumelden.)

Eingebaute Anbieter (wie auf den Karten)

Anbieter	Rolle
Anthropic	Claude — die Modelle, die dein API-Schlüssel nutzen darf, gelesen aus Anthropics Modellliste (eingebauter Fallback: Fable 5.1, Fable 5, Opus 5.5, Opus 5, Opus 4.8, Sonnet 5, Sonnet 4.6, Haiku 4.5)
OpenAI	Eingebaut GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o, GPT-4o mini; Modelle aktualisieren listet den Rest
OpenRouter	Multi-Provider-Gateway (100+ Modelle)
Gemini	Google Gemini 3.x (2.5 nach einer Aktualisierung, sofern dein Schlüssel noch Zugriff hat)
Kimi	Moonshot-API (K3, K2.7 Code, K2.6)
Claude Code CLI	Die Claude-Code-CLI auf diesem Rechner (`claude`), immer isoliert — siehe Claude-Code-Isolation
Grok CLI	ACP (`grok agent --no-leader stdio`) im eigenen EYAS-Home — EYAS-Tools über die CLI-MCP-Bridge
Kimi Code CLI	ACP (`kimi acp`) im eigenen EYAS-Home — dieselbe Bridge
Ollama / LM Studio / vLLM	Lokale Runtimes — siehe Lokale Runtimes
xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo Gateway, Vercel AI Gateway, Qianfan, MiniMax, Synthetic, Xiaomi MiMo, …	Cloud-APIs wie auf den Karten

Ein Name überall. Die Namen in dieser Tabelle zeigt EYAS auf jedem Bildschirm: auf den Anbieterkarten und im Panel, in den Anbieter-Auswahlen der Routing-Stufen, in der Modellauswahl und der oberen Leiste des Gesprächs, in der Zeile Beantwortet von unter jeder Antwort, in Chat-Fehlermeldungen, in der Modellauswahl eines Kollegen, auf der Karte Modellzuweisungen in den Einstellungen, im Setup-Assistenten sowie auf der Anmeldekarte und dem Start-Banner für Grok/Kimi. Claude Code heißt immer Claude Code CLI. Kimi Code CLI, Kimi und die kompatiblen Anbieter (xAI, Mistral, Groq, MiniMax, Xiaomi MiMo, …) zeigen ihren Produktnamen, nie eine Id wie kimi-cli. Wer den Modellkatalog nicht lesen darf (Rolle Gast), sieht stattdessen Anbieter-Ids.

API (Integratoren). Jede Zeile von GET /api/v1/model/providers und das Detail GET /api/v1/model/providers/:id tragen den Produktnamen name und ein kind: cli (Claude Code, Grok CLI, Kimi Code CLI), local (Ollama, LM Studio, vLLM) oder api (jede gehostete API und jede unbekannte Id).

Gesprächskontinuität

EYAS hält das Gespräch, nicht der Anbieter. In jedem Zug schickt EYAS das ganze Gespräch aus seinem eigenen Speicher an das Modell. Kein CLI-Anbieter führt oder setzt eine eigene Session fort: Claude Code, Grok CLI und Kimi Code CLI starten jeden Zug frisch und bekommen die früheren Züge als Gesprächsverlaufs-Block. Grok und Kimi öffnen immer eine neue ACP-Session und laden nie eine frühere.

Ein Gespräch behält seinen Kontext also, wenn du Anbieter oder Modell wechselst, und der Session-Speicher einer CLI ist nie Quelle für Kontext oder Erinnerung. Dieselbe Kontinuität gilt für jeden Anbieter.

In früheren Zügen eingefügte Bilder gehören bei Grok CLI und Kimi Code CLI ebenfalls zu diesem Verlauf, jedes an der Stelle im Gespräch, an der es geschickt wurde. Siehe Was Grok und Kimi bekommen.

Die Kosten, die Claude Code für einen Zug meldet, sind die Ausgaben genau dieses Zugs und werden unverändert addiert.

Rohe Modell-API (Integratoren). POST /api/v1/model/complete und POST /api/v1/model/stream (Berechtigung use Model) validieren ihren Body. Erlaubte Felder: provider, model, messages (1–1000 Einträge; Rolle user oder assistant; Inhalt ist ein String oder eine Liste von Text-/Bild-Blöcken), system, maxTokens (positive Ganzzahl), temperature (0–2), stopSequences (höchstens 16) und optional effort (eine Stufe von none bis max oder auto). Jeder andere Key wird verworfen, auch sessionId, metadata, cwd, isolated, tools und thinking. Diese Aufrufe gelten deshalb als autonom (die Autonomie-Leiter greift), können keine Anbieter-Session fortsetzen, und thinking wirkt dort nicht. Die Antwort und das done-Ereignis des Streams tragen effortOutcome: die angeforderte Stufe, die tatsächlich an das Modell gesendete Stufe und ihre Quelle (request). Ein ungültiger Body liefert 400 mit { error: 'ValidationError', issues }.

Modelle und Modelle aktualisieren

Modelle aktualisieren fragt den Anbieter, welche Modelle er anbietet, und speichert für jede Zeile das konkrete Modell, das sie ausführt (etwa die Grok-Modell-Id oder den Alias, den Claude Code nutzt). Ein durch Aktualisieren gefundenes Modell funktioniert auch nach einem Neustart von EYAS weiter.

Jede Modellzeile zeigt eine kleine Zeile Läuft als <Modell>, wenn das konkrete Modell von der Id der Zeile abweicht.
Ein erfolgreiches Aktualisieren fügt nicht nur Modelle hinzu. Ein Modell, das der Anbieter nicht mehr anbietet, wird ausgeschaltet und als Von der letzten Aktualisierung nicht mehr angeboten markiert. Gelöscht wird es nie. Bietet ein späteres Aktualisieren es wieder an, wird es automatisch wieder eingeschaltet — außer du hattest es selbst ausgeschaltet. Ein markiertes Modell darfst du von Hand einschalten; es bleibt dann unter deiner Kontrolle.
Scheitert das Aktualisieren (Anbieter nicht erreichbar, nicht angemeldet, kein Schlüssel) oder listet der Anbieter keine Modelle, wird nichts geändert, und das Panel sagt Aktualisierung fehlgeschlagen. Die Modellliste blieb unverändert. OpenAI, Gemini, OpenRouter, Kimi (API) und OpenAI-kompatible Endpunkte melden einen solchen Fehler, statt still EYAS’ eingebaute Modellliste zu zeigen.

Agenten, die nur ein Modell nennen. Ein Agent, Spezialist oder Routing-Ziel, das eine Modell-Id ohne Anbieter nennt, erreicht den Anbieter, der dieses Modell in seiner aktivierten Modellliste hat — etwa ein durch Aktualisieren gefundenes Grok-Modell oder ein neueres OpenAI-Modell. Ein ausgeschaltetes oder unbekanntes Modell, ein Modell mit ausgeschaltetem Anbieter und eine Modell-Id, die zwei Anbieter zugleich anbieten, scheitern weiterhin mit No provider found for model. EYAS rät nie.

Welches Modell eine CLI ausführt.

Grok CLI: Die Default-Zeile Grok CLI (<Modell>) führt das Modell aus, das die installierte Grok CLI selbst als Default hat. Jede andere Grok-Zeile führt genau das Modell aus, das sie nennt, auch nach einem Neustart. Ein Gespräch oder Agent, der auf ein Grok-Modell gepinnt ist, das die CLI nicht mehr anbietet, scheitert, bevor etwas gesendet wird: Model ‘<id>’ cannot be run by this CLI: Grok CLI does not offer it (the session would run <default>). Wähle ein anderes Modell oder aktualisiere die Liste.
Claude Code: Die Modellliste kommt aus der Claude-Code-Laufzeit, die EYAS ausführt (siehe Claude-Code-Modelle und Effort). Jede Zeile nennt das konkrete Claude-Modell, das ihr Alias ausführt, etwa opus führt claude-opus-5-5 aus. Die Zeile Claude Code (Default) führt das Modell aus, das die Laufzeit als Default nutzt. Ein voller Modellname funktioniert auch.
Kimi Code CLI: Die Modellliste kommt von Kimi selbst, und EYAS stellt jede Session auf das Modell um, das du gewählt hast (siehe Kimi-Modelle und Thinking). Die Default-Zeile Kimi Code CLI führt das Modell aus, auf das Kimi gerade eingestellt ist.
Eine Modell-Id, die kein Modell nennt (etwa nur grok-cli-), lässt den Zug mit einem klaren Fehler scheitern, statt etwas anderes auszuführen.

Modelllisten der API-Anbieter.

Anthropic: Fügst du einen API-Schlüssel hinzu, liest EYAS die Modelle, die dieser Schlüssel nutzen darf, aus Anthropics Models-API. Das ist ein kostenloser Listenaufruf, kein Modellaufruf, und liefert für jedes Modell Kontextfenster, Ausgabelimit und Effort-Stufen. Ist die Models-API nicht erreichbar, gilt die eingebaute Liste. Bestehende Installationen behalten ihre gespeicherte Liste, bis du Modelle aktualisieren drückst; dann erscheinen neuere Modelle wie Opus 5.5, Opus 5, Sonnet 5 und Fable 5.1, und ältere Zeilen (Opus 4.7, Opus 4.6) funktionieren weiter, solange sie gespeichert sind.
OpenAI: Vor der ersten Aktualisierung ist die eingebaute Liste GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o und GPT-4o mini. GPT-4 Turbo ist nicht mehr eingebaut; Modelle aktualisieren listet es weiterhin, wenn OpenAI es anbietet. Ein aktualisiertes Modell, das EYAS schon kennt, behält sein Kontextfenster und sein Ausgabelimit.
OpenRouter: Modelle aktualisieren liest außerdem, welche Modelle OpenRouter als Reasoning-fähig markiert. Die eingebaute Liste ist Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.5, Gemini 3.1 Pro preview und GPT-4o.
Kimi API: Kimi K2.5 ist nicht mehr eingebaut; es erscheint nur, wenn Moonshot es bei Modelle aktualisieren noch listet.
Gemini: Die eingebaute Liste enthält die aktuellen 3.x-Modelle; die ausgemusterten gemini-2.0-flash, gemini-2.5-pro-preview-05-06 und gemini-2.5-flash-preview-05-20 sind weg. Bestehende Installationen behalten ihre alten Zeilen, bis du Modelle aktualisieren drückst, was ausschaltet und markiert, was die API nicht mehr anbietet. Die 2.5-Familie erscheint nach einer Aktualisierung nur, wenn dein Schlüssel noch Zugriff hat (Google beschränkt 2.5 auf Projekte, die es schon genutzt haben). Eine Anfrage, die kein Gemini-Modell nennt, geht an gemini-3.8-flash.
Ollama: Ist der Anbieter aktiviert und erreichbar, liest EYAS die Fähigkeiten jedes Modells von Ollama — beim Laden, im Hintergrund und bei Modelle aktualisieren. Modelle, die Ollama nicht mehr listet, werden auch nach einem Laden als Von der letzten Aktualisierung nicht mehr angeboten markiert und ausgeschaltet. Ein deaktiviertes oder unerreichbares Ollama wird nie kontaktiert.

API (Integratoren). GET /api/v1/model/providers/:id und GET /api/v1/model/models liefern pro Modell realModelId, missing (true, wenn die letzte Aktualisierung es nicht mehr anbot) und die effektive Reasoning-Fähigkeit. POST /api/v1/model/providers/:id/models/refresh liefert die Listen missing und restored oder 502 mit ModelDiscoveryFailed / ModelDiscoveryEmpty.

Reasoning-Effort

Der Reasoning-Effort wird pro Modell entschieden, in dem Moment, in dem ein Modell tatsächlich antwortet. Wechselt das Modell — Routing, Wiederholung oder Fallback —, ermittelt EYAS die Stufe für das neue Modell neu.

Eine Stufe, die das Modell nicht unterstützt, wird auf die nächstgelegene unterstützte angepasst. Maximum auf einem Modell, das bei Sehr hoch endet, läuft als Sehr hoch; Sehr hoch auf einem Modell ohne diese Stufe läuft als Hoch.
Ein Modell, das Reasoning nicht abschalten kann, bekommt seine niedrigste Stufe, wenn Keiner verlangt wird.
Ein Modell, über das EYAS keine verifizierten Fakten hat, bekommt gar keinen Reasoning-Parameter (Automatisch: der eigene Default des Modells). EYAS sendet nie einen geratenen Wert.
Thinking-Budgets für Modelle mit Token-Budget (etwa Claude Haiku 4.5 oder Gemini 2.5) werden aus dem eigenen Ausgabelimit des Modells bemessen und lassen immer Platz für die Antwort; Maximum kann das Limit des Modells also nicht überschreiten.

Die Leiter. Die volle Leiter ist Keiner, Minimal, Niedrig, Mittel, Hoch, Sehr hoch, Maximum, plus Automatisch. Automatisch speichert an dieser Stelle nichts: Die Stufe kommt dann von weiter unten in der Reihenfolge unten, und setzt keine eine, wird nichts gesendet, und der eigene Default des Modells gilt.

Woher die Stufe kommt (der erste Treffer gewinnt):

der eigene Aufwand des Gesprächs;
Maximum, wenn das Gespräch im Modus Deep ist;
der Effort, der am Kollegen (Agenten) gesetzt ist, als der das Gespräch spricht — im Chat der Kollege des Gesprächs, sonst der Default-Kollege des Projekts;
die Stufe des nächsten Gesprächs, das die Arbeit delegiert hat (ein Untergespräch erbt von seinem Elterngespräch, bis zu fünf Ebenen nach oben);
der Default der Routing-Stufe, für eine über eine Stufe geroutete Nachricht und für EYAS’ Hintergrundaufrufe (siehe Routing & Budget — Standard-Effort der Stufen);
der eigene Default des Modells.

Dieselbe Reihenfolge gilt überall, wo ein Kollege oder Spezialist läuft: interaktiver Chat, der Home-Thread eines Kollegen, Hintergrund- und geplante Läufe, Wiederholungen und Fortsetzungen (ein fortgesetzter Lauf nutzt genau den Effort seines ersten Laufs), Team-Mitglieder, delegierte Aufgaben und Spezialisten, Pipeline-Stufen, A2A-Aufgaben, Antworten auf Messaging-Kanälen und der God-Modus. Der eigene Effort eines Kollegen gilt also in seinem Chat und auf Kanälen, und ein Team-Mitglied oder Spezialist ohne eigenen Effort erbt die Stufe des delegierenden Gesprächs — ein Deep-Gespräch schickt seine Spezialisten deshalb auf Maximum, was mehr kostet. Ein Mitglied oder Spezialist mit eigenem Effort behält ihn. Im God-Modus wird ein am Gespräch gesetzter Effort auf jeden Teilnehmer kopiert und der Modus Deep weitergegeben; die Stufe jedes Teilnehmers wird dann an sein eigenes Modell angepasst, und auch die Stimmen der gegenseitigen Bewertung nutzen den Effort des Gesprächs.

Eine Effort-Auswahl, pro Modell. Die Feldleiste des Gesprächs, der Kollegen-Editor, jede Routing-Stufe und eine geplante Agenten-Routine nutzen dieselbe Auswahl Aufwand. Sie listet nur die Stufen, die das jeweilige Modell annimmt — etwa Sehr hoch bei Modellen, die sie anbieten (Claude Opus 4.7/4.8/5.x, GPT-5.4/5.5/5.6), Keiner und Minimal, wo das Modell sie hat. Ein An/Aus-Modell zeigt Aus / An. Ein Modell ohne Effort-Steuerung oder eines, über das EYAS keine verifizierten Fakten hat, bietet nur Automatisch an, und ein Hinweis sagt warum; ein Hinweis sagt auch, wenn ein Modell seinen Reasoning-Text nicht zeigt. In einem Auto-gerouteten Gespräch oder bei einem Kollegen ohne festes Modell ist kein einzelnes Modell festgelegt: Die Auswahl bietet jede Stufe an, die mindestens ein Modell einer Auto-Routing-Stufe (Schnell, Standard, Komplex, Codeausführung) annimmt, und die Stufe jeder Nachricht wird an das Modell angepasst, auf dem sie läuft.

Automatisch sagt, was es bedeutet. Automatisch ist der erste Eintrag und nennt, worauf es dort zurückfällt: Automatisch · Maximum (Tief), Automatisch · Hoch (Kollege), Automatisch · Sehr hoch (delegierende Unterhaltung) oder Automatisch · Modellstandard (Mittel) — der eigene Default des Herstellers.

Die Liste folgt dem Modell. Ändern sich Modell, Deep-Modus oder Kollege eines Gesprächs, aktualisiert sich die Liste. Ein neues Modell schreibt den gespeicherten Effort eines Gesprächs nie um: Eine Stufe, die das neue Modell nicht hat, erscheint etwa als Sehr hoch → Hoch (Opus 4.6 bietet Sehr hoch nicht an), und jeder Zug wird angepasst und festgehalten. Im Kollegen-Editor und an einer Routing-Stufe ändert die Wahl eines Modells, das die gespeicherte Stufe nicht anbietet, diese vor dem Speichern und sagt das: Aufwand von Sehr hoch auf Hoch angepasst: Das gewählte Modell bietet Sehr hoch nicht an. Ein Modell ohne Effort-Steuerung setzt sie auf Automatisch.

Gespeicherte Stufen werden gegen das Modell geprüft. Setzt du einen Effort an einem Gespräch, einem Kollegen oder einer Routing-Stufe, prüft EYAS die Stufe gegen das Modell, auf dem er läuft. Eine Stufe, die dieses Modell nicht unterstützt, wird abgelehnt, und nichts wird gespeichert — das Gespräch listet die Stufen, die es annimmt, und eine Stufenzeile sagt Das Modell bietet diese Aufwandsstufe nicht an. Es wurde nichts gespeichert. Automatisch wird immer akzeptiert, ebenso jede Stufe, wenn das Modell vorab nicht bekannt ist (ein Auto-geroutetes Gespräch, ein Kollege ohne Modell, ein Modell, zu dem EYAS keine verifizierten Daten hat); diese werden bei jedem Aufruf angepasst. Nur das Modell zu ändern scheitert nie an einem gespeicherten Effort.

Womit jede Antwort lief. Unter jeder Antwort, neben Anbieter · Modell, zeigt ein kleiner Chip den Effort, mit dem der Zug tatsächlich lief: Aufwand: Hoch oder Aufwand: Sehr hoch → Hoch, wenn das Modell die angeforderte Stufe nicht anbot. Sein Tooltip nennt, wer sie gesetzt hat (Unterhaltung, Tief, Kollege, delegierende Unterhaltung, Routing-Stufe, Modellstandard). Es gibt keinen Chip, wenn nichts angefordert oder gesendet wurde. Jede gespeicherte Antwort behält angeforderten gegenüber tatsächlichem Effort, woher die Stufe kam und ob sie angepasst wurde — für Chat, delegierte und Spezialisten-Läufe, Pipeline-Stufen und Kanäle. Der Trace jedes KI-Aufrufs hält dasselbe fest — siehe Observability.

Was die Anbieter-Seite zeigt. Jede Modellzeile hat eine Reasoning-Zeile, etwa Denken: Niedrig, Mittel, Hoch, Sehr hoch, Maximum · Standard Mittel, mit einem Badge, woher die Fakten stammen: vom Anbieter gemeldet (die eigene Modellliste des Anbieters oder der Laufzeit) oder EYAS-Katalog, geprüft am JJJJ-MM-TT (EYAS’ versionierter Katalog geprüfter Reasoning-Fakten). Ein Modell ohne Effort-Steuerung zeigt Denken: kein Aufwand einstellbar; eines, das EYAS nicht kennt, Denken: EYAS unbekannt (Aufwand bleibt Automatisch).

API (Integratoren). GET /api/v1/model/effort-options?providerId&modelId (Lesen von Model) liefert die Stufen eines Modells; mit einer nackten Modell-Id oder einem Alias die Stufen des Modells seines einzigen Besitzer-Anbieters; ohne Modell die Vereinigung der Auto-Stufen. GET /api/v1/conversations/:id/effort-options (Lesen von Conversation, nur der Besitzer) liefert die Stufen, die gespeicherte Stufe (current) und was Automatisch erbt (inherited). Eine abgelehnte Stufe liefert 400 mit Code EFFORT_UNSUPPORTED, der Stufe und den unterstützten levels des Modells.

Wie jeder Anbieter die Effort-Stufe anwendet

EYAS ermittelt pro Aufruf eine Stufe, wie oben beschrieben, und jeder Anbieter übersetzt sie nur. In jedem Fall sendet EYAS nur, was das antwortende Modell bekanntermaßen annimmt; ein Modell ohne verifizierte Fakten bekommt keinen Reasoning-Parameter.

Anbieter	Was EYAS für eine Stufe sendet	Woher die Stufen kommen	Automatisch	Tatsächliche Stufe unter der Antwort
Anthropic-API	Die Effort-Einstellung des Modells (wo es eine hat) plus Thinking — adaptiv oder ein Token-Budget, wo das Modell eines nimmt; Keiner schaltet Thinking ab, wo das Modell es erlaubt	Anthropics Models-API, mit Fakten, die sie nicht meldet (Default, immer an, Budgetbereich), aus dem EYAS-Katalog	Nichts; ein Modell, das standardmäßig denkt, sein Reasoning aber verbirgt, wird nur um eine Zusammenfassung gebeten	Die Stufe, die EYAS gesendet hat
Anthropic-kompatible Endpunkte (MiniMax, Synthetic, Xiaomi MiMo)	Nichts	— (keine verifizierten Fakten)	Immer	—
OpenAI	`reasoning_effort`, mit dem Ausgabelimit als `max_completion_tokens` und ohne Temperatur	EYAS-Katalog	Nichts	Die Stufe, die EYAS gesendet hat
OpenRouter	`reasoning: { effort }`; OpenRouter reicht es an das Upstream-Modell weiter und kann es anpassen	OpenRouters Modellliste (Reasoning ja/nein); bekannte Familien aus dem EYAS-Katalog	Nichts	Die Stufe, die EYAS gesendet hat
Kimi API (Moonshot)	`reasoning_effort` (K3) oder Thinking an/aus (K2.6); ohne Temperatur	EYAS-Katalog	Nichts	Die Stufe, die EYAS gesendet hat
OpenAI-kompatible Gateways (xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo, Vercel AI Gateway, Qianfan, vLLM)	Nichts — außer `reasoning_effort` für xAIs Grok 3 Mini	EYAS-Katalog für Grok 3 Mini auf xAI; die Reasoning-Steuerung keines anderen Gateways ist bisher verifiziert	Immer, außer Grok 3 Mini	Die Stufe, die EYAS gesendet hat (Grok 3 Mini); sonst —
Gemini	Eine Thinking-Stufe (Gemini 3) oder ein Thinking-Budget (Gemini 2.5), mit Gedanken-Zusammenfassungen	EYAS-Katalog; Googles Modellliste kann ein Modell als nicht denkend markieren	Nichts; Modelle, die standardmäßig denken, werden nur um ihre Zusammenfassungen gebeten	Die Stufe, die EYAS gesendet hat
Ollama	`think`: an/aus oder die eigene benannte Stufe des Modells	Ollamas Modellinformation (die Fähigkeit thinking und ihre Werte); gpt-oss aus dem EYAS-Katalog	Nichts	Die Stufe, die EYAS gesendet hat
LM Studio	Nichts — das Reasoning wird in LM Studio eingestellt	—	Immer; das Panel zeigt LM Studios eigene Einstellung	—
Claude Code CLI	Den Effort, den das laufende Binary für das Modell gemeldet hat; Keiner schaltet Thinking ab, wo das Modell es erlaubt	Die Claude-Code-Laufzeit selbst, ohne Prompt gelesen	Nichts	Aus der Laufzeit zurückgelesen
Grok CLI	Die Reasoning-Effort-Option der Session, vor dem Prompt gesetzt	Die Grok CLI selbst, ohne Prompt gelesen	Nichts; der Zug hält die Stufe fest, die Grok genutzt hat	In jedem Zug von Grok zurückgelesen
Kimi Code CLI	Die Thinking- oder die normale Variante des Modells, in der Session gewählt	Kimis eigene Modellliste	Behält die Variante, die Kimi gerade ausführt	In jedem Zug von Kimi zurückgelesen

Die Stufe, die EYAS gesendet hat heißt: Der Chip unter der Antwort zeigt die Stufe, nachdem EYAS sie an das Modell angepasst hat. Zurückgelesen heißt: Die CLI meldet die Stufe, mit der sie tatsächlich lief, und genau die halten Chip und Trace fest, auch wenn sie von dem abweicht, was EYAS angefordert hat.

Einzelheiten pro Anbieter.

Anthropic-API. Die Wahl für ein Claude-Modell sind genau die Stufen, die es unterstützt: Sehr hoch gibt es auf Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8 und Sonnet 5, nicht aber auf Opus 4.6 oder Sonnet 4.6; Aus wird nur angeboten, wo das Modell Reasoning abschalten kann (nicht auf Fable oder Opus 5.5). Haiku 4.5 und Sonnet 4.5 haben keine Effort-Einstellung; dort wird die Stufe zu einem Thinking-Budget, bemessen am Ausgabelimit des Modells, und EYAS hebt das Antwortlängenlimit an, damit das Reasoning die Antwort nie abschneidet. Automatisch sendet nichts (Opus 5.5 steht standardmäßig auf Mittel; Opus 4.8 denkt nur auf Anfrage). Modelle, die ihr Reasoning ohne Aufforderung verbergen (Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8, Sonnet 5), werden um eine Reasoning-Zusammenfassung gebeten, wann immer sie denken — bei Automatisch auch jene, die standardmäßig denken —, damit es im Chat erscheint; das ändert nur, was angezeigt wird. EYAS sendet an Modelle, die sie ablehnen (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), keine Temperatur, kein top_p und kein top_k, und nie zusammen mit eingeschaltetem Thinking.
Anthropic-kompatible Endpunkte (MiniMax, Synthetic, Xiaomi MiMo): nur Automatisch. EYAS sendet keine Reasoning-Steuerung, bis das Verhalten eines Modells verifiziert ist; die Temperatur geht wie eingestellt mit.
OpenAI. Jedes Modell der GPT-5-Generation, das die Chat-Completions-API bedient, und die o-Serie bekommen die Stufe, jedes mit seinem eigenen Bereich: GPT-6 Astra Niedrig–Maximum (nicht abschaltbar); GPT-5.6 Keiner–Maximum, Standard Mittel; GPT-5.5 Keiner–Sehr hoch, Standard Mittel; GPT-5.4 Keiner–Sehr hoch, Standard Keiner; GPT-5.4 mini / nano und GPT-5.2 Keiner–Sehr hoch, Standard Keiner; GPT-5.1 Keiner–Hoch, Standard Keiner; GPT-5 / GPT-5 mini / nano Minimal–Hoch, Standard Mittel; GPT-5 pro nur Hoch; o1 / o3 / o3-mini / o4-mini Niedrig–Hoch, Standard Mittel. Eine fehlende Stufe rückt auf die nächste (Maximum auf GPT-5.5 läuft als Sehr hoch). An diese Reasoning-Modelle sendet EYAS nie eine Temperatur und nutzt das Ausgabelimit für Reasoning-Modelle (max_completion_tokens) — Hintergrundaufrufe wie die Speichererfassung eingeschlossen, die GPT-5.2 und GPT-5.4 mini / nano früher ablehnen konnten. Mit einer ausdrücklichen Stufe wird ein kleines Ausgabelimit auf das angehoben, was die Stufe braucht (Niedrig 8k, Mittel 16k, Hoch 32k, Sehr hoch/Maximum 64k Tokens, nie über das eigene Limit des Modells). Modelle ohne verifizierte Fakten (GPT-4o, GPT-4o mini und andere) bekommen keinen Reasoning-Parameter und behalten max_tokens und Temperatur. Manche OpenAI-Modelle gibt es nur auf OpenAIs Responses-API, nicht auf der Chat-Completions-API, die EYAS nutzt: GPT-5.2 pro, GPT-5.4 pro, GPT-5.5 pro, die Codex-Modelle (GPT-5 Codex, GPT-5.1 Codex / Codex Max, GPT-5.2 / 5.3 Codex, codex-mini), o1-pro, o3-pro und die Deep-Research-Modelle. Auf dem OpenAI-Anbieter bleiben sie nur bei Automatisch und können nicht antworten; nutze sie über OpenRouter. GPT-5.1 mini hat keine veröffentlichten Effort-Stufen und bleibt daher bei Automatisch.
OpenRouter. Modelle, die OpenRouter als Reasoning-fähig markiert, bieten Minimal–Maximum; Modelle, die es ohne Reasoning listet, bekommen keine Effort-Steuerung. Bekannte Familien zeigen ihre echten Stufen: Claude Opus/Sonnet 4.6 (Aus, Niedrig, Mittel, Hoch, Maximum), OpenAI GPT-5.x / GPT-6 Astra / o-Serie (wie bei OpenAI), Gemini 3.x (Geminis Thinking-Stufen, Sehr hoch läuft also als Hoch). Ebenfalls bekannt: GPT-5.2 Keiner–Sehr hoch (Standard Keiner); GPT-5.2 pro Mittel–Sehr hoch; GPT-5.4 pro Mittel–Sehr hoch (Standard Mittel); GPT-5.5 pro Mittel–Sehr hoch (Standard Hoch); GPT-5.4 mini / nano wie bei OpenAI; GPT-5.2 / 5.3 Codex Niedrig–Sehr hoch. Aus wird nur angeboten, wo die Familie Reasoning abschalten kann.
Kimi API (Moonshot). Kimi K3: Niedrig / Hoch / Maximum (Standard Maximum; Mittel läuft als Niedrig). Kimi K2.6: Reasoning an (Hoch) oder aus (Keiner). Kimi K2.7 Code und K2.7 Code Highspeed denken immer und haben keine Effort-Steuerung.
OpenAI-kompatible Gateways: nur Automatisch, auch für Ids mit Herstellerpräfix wie openai/gpt-5.4. Auf dem xAI-API-Anbieter ist Grok 3 Mini (und Grok 3 Mini Fast) das eine Modell mit Effort-Steuerung: Niedrig oder Hoch (Mittel läuft als Niedrig; Sehr hoch und Maximum laufen als Hoch). Es denkt immer, und sein Reasoning wird angezeigt. xAI listet Grok 3 Mini nicht mehr, und Oracle Cloud hat es am 15.08.2026 eingestellt; es antwortet also womöglich nicht mehr. Andere Grok-Modelle auf der xAI-API denken mit xAIs Default: EYAS spricht mit xAI über Chat Completions, wofür xAI für sie keinen Effort-Parameter dokumentiert. Der Anbieter Grok CLI behält seine Effort-Steuerung.
Gemini. Gemini-3-Modelle (3.8/3.7/3.6/3.5 Flash, 3.5/3.1 Flash-Lite, 3.1 Pro Preview, 3 Flash Preview) nehmen eine Thinking-Stufe — Minimal, Niedrig, Mittel oder Hoch. Eine fehlende Stufe rückt auf die nächste (3.8/3.7 Flash und 3.1 Pro haben kein Minimal, es wird also Niedrig; Sehr hoch und Maximum werden Hoch). Gemini-3-Modelle denken immer; Keiner lässt sie also auf ihrer niedrigsten Stufe laufen. Gemini-2.5-Modelle nehmen ein aus der Stufe abgeleitetes Thinking-Budget innerhalb ihres Bereichs (2.5 Pro 128–32.768 Tokens; 2.5 Flash bis 24.576; Flash-Lite 512–24.576); Keiner schaltet das Thinking bei 2.5 Flash und Flash-Lite ab, während 2.5 Pro auf seiner kleinsten Stufe läuft. Google berechnet Thinking-Tokens so oder so. Ein kleines Ausgabelimit wird an die Stufe angepasst, nie über das eigene Limit des Modells. Modelle, die Googles Liste als nicht denkend markiert (etwa TTS-Varianten), bekommen keinen Thinking-Parameter.
Ollama. Modelle, die die Fähigkeit thinking melden, bekommen An / Aus: Keiner schaltet das Thinking aus, jede höhere Stufe schaltet es ein. gpt-oss nimmt Niedrig, Mittel und Hoch (Standard Mittel) und lässt sich nicht abschalten (Keiner wird Niedrig). Ein aktuelles Ollama, das die genauen Thinking-Werte eines Modells meldet, bekommt genau diese, mit Ollamas Default markiert. Automatisch sendet nichts (denkende Modelle denken standardmäßig). Ein Modell ohne die Fähigkeit oder eines, dessen Fähigkeiten nicht lesbar waren, bekommt nie eine Thinking-Einstellung — Ollama würde die Anfrage ablehnen. Mit einer ausdrücklichen Stufe wird eine kleine Max-Tokens-Einstellung angehoben, damit Platz für das Thinking bleibt.
LM Studio. EYAS sendet nie einen Reasoning- oder Effort-Parameter an LM Studio, jede Stufe ist dort also faktisch Automatisch. Meldet LM Studio die Reasoning-Einstellung eines Modells, zeigt das LM-Studio-Panel sie pro Modell, etwa qwen/qwen3-8b — Das Reasoning dieses Modells wird in LM Studio selbst eingestellt (Standard dort: on). EYAS zeigt es nur an und ändert es nicht. Ältere LM-Studio-Versionen zeigen keinen Hinweis.
Claude Code CLI, Grok CLI, Kimi Code CLI. Siehe Claude-Code-Modelle und Effort, Grok-Modelle und Effort und Kimi-Modelle und Thinking.
OpenCode ist ein Tool-Sidecar, kein Chat-Anbieter: Sein Modell und seine Reasoning-Variante werden auf der OpenCode-Seite eingestellt (siehe OpenCode — Modell und Reasoning).

Neue Versionen eines bekannten Modells. Ein datierter Snapshot, ein -latest-Alias oder eine [1m]-Kontextvariante eines Modells, das EYAS kennt, bekommt die Stufen dieses Modells — zum Beispiel gpt-5.4-mini-2026-03-17 oder kimi-k3-0115. Eine andere Variante (pro, codex, chat, preview, beta, fast, …) oder eine unbekannte Modellfamilie bleibt nur bei Automatisch, bis EYAS verifizierte Fakten dazu hat. Stufen gehen nie von einem Anbieter auf einen anderen über.

Claude-Code-Laufzeit

EYAS führt die Claude-Code-CLI aus, die du installiert hast, und nutzt ein Binary für alles: Anmeldeprüfung, Verfügbarkeit des Anbieters, Auto-Setup beim ersten Start, Modellerkennung und jeden Gesprächszug. Was eyas doctor meldet, ist das, was läuft. Die Reihenfolge:

EYAS_CLAUDE_CODE_BIN — absoluter Pfad zum claude-Binary.
Das claude im PATH des Servers.
Als letzter Ausweg die ältere Claude-Code-Kopie, die in EYAS’ Agent-SDK-Abhängigkeit steckt (derzeit 2.1.89). eyas doctor warnt dann.

EYAS_CLAUDE_CODE_BIN ist bewusst eine Umgebungsvariable, keine UI-Einstellung. Nutze sie, wenn dem PATH des Dienstes claude fehlt (launchd-/systemd-Dienste, Container), oder um eine bestimmte Installation festzulegen. Ist sie gesetzt, aber ungültig (nicht absolut, fehlt oder nicht ausführbar), bleibt der Claude-Code-Anbieter aus: Es gibt keinen Rückfall auf PATH oder die gebündelte Kopie, und doctor meldet einen Fehler.

Versionsabweichung. EYAS’ SDK-Client wurde für Claude Code 2.1.89 gebaut. Eine neuere CLI wird so genutzt, wie sie ist, und doctor zeigt eine Warnung version skew. Optionen, die nur neuere CLIs verstehen, werden nur an Laufzeiten gesendet, die sie haben (etwa zusammengefasstes Thinking ab 2.1.280). Claude Code aktualisiert sich nicht selbst, solange EYAS es ausführt (siehe Claude-Code-Isolation); aktualisiere es wie gewohnt selbst und prüfe danach seine doctor-Zeile (siehe Nachgewiesene CLI-Versionen).

Angemeldet, nicht nur installiert. EYAS prüft die Anmeldung mit claude auth status --json — ein lokaler Befehl, der keine Session startet, keinen Prompt sendet und nichts kostet. Der Claude-Code-Anbieter registriert sich — und eine frische Installation schaltet ihn automatisch ein — nur, wenn dieses Binary angemeldet ist: claude.ai-Login, ANTHROPIC_API_KEY oder ein Bedrock-/Vertex-Setup. Dass claude bloß im PATH liegt, reicht nicht. Meldest du dich später an, schalte den Anbieter unter Anbieter aus und wieder an oder starte EYAS neu. E-Mail und Organisation des Kontos, die der Befehl ausgibt, werden nie geloggt oder gespeichert.

Keine versteckten Modellaufrufe. EYAS schickt nie einen Test-Prompt an die Host-CLI, um sie zu prüfen oder ihre Modelle aufzulisten. Die Modellliste wird ohne Prompt aus der Laufzeit selbst gelesen — siehe unten.

Thinking. EYAS schaltet Thinking in Claude-Code-Zügen nicht ab, außer Keiner wird verlangt. Wird kein Effort angefordert, gilt der Default des Modells. Eine angeforderte Stufe wird nur als der Effort gesendet, den diese Laufzeit für das Modell gemeldet hat; feste Thinking-Token-Budgets werden nicht gesendet. Zur Leiter und dazu, woher eine Stufe kommt, siehe Reasoning-Effort.

Claude-Code-Modelle und Effort

Die Modellliste kommt aus der Laufzeit. EYAS fragt die Claude-Code-Laufzeit, die es tatsächlich ausführt — dasselbe Binary, das eyas doctor meldet —, welche Modelle sie anbietet. Das passiert bei jedem Start des Anbieters und wenn du Modelle aktualisieren drückst. Es wird kein Prompt gesendet, es kostet nichts und läuft isoliert von deinen eigenen Claude-Code-Einstellungen; die Kontodaten in dieser Antwort werden nie gelesen oder gespeichert.

Jeder Eintrag nennt das konkrete Claude-Modell, das sein Alias ausführt, etwa opus führt claude-opus-5-5 aus. Der Eintrag Claude Code (Default) führt das Modell aus, das die Laufzeit als Default nutzt.
Einträge, die die Laufzeit nicht mehr anbietet, werden ausgeschaltet und markiert, nie gelöscht — etwa wird Fable auf einer Laufzeit, die es nicht kennt, ausgeschaltet.
Die Effort-Stufen pro Modell sind genau die, die die Laufzeit meldet, einschließlich Sehr hoch, wo sie es anbietet. Ein Modell, für das die Laufzeit keine Effort-Steuerung anbietet, etwa Haiku, bietet nur Automatisch an. Automatisch sendet nichts, und der eigene Default des Modells gilt (etwa Mittel bei Opus 5.5).
EYAS sendet nie eine Stufe, die das laufende Binary für dieses Modell nicht gemeldet hat. Stammen die gespeicherten Stufen von einer anderen Claude-Code-Version, wird bis zum nächsten Start oder zur nächsten Aktualisierung keine Stufe gesendet.
Zusammengefasstes Thinking (damit das Reasoning des Modells im Chat sichtbar ist) wird ab Claude Code 2.1.280 angefordert. Ein älteres Claude Code — auch die mit EYAS gebündelte Kopie 2.1.89 — bietet keinen Weg, es anzufordern: Für die Modelle, die ihr Denken ohne Aufforderung verbergen (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), sagt die Effort-Auswahl dann Dieses Modell zeigt seinen Denktext nicht an. Die Effort-Stufen selbst bleiben unverändert. Aktualisiere Claude Code auf 2.1.280 oder neuer und aktualisiere die Modelle (oder starte EYAS neu), um das Reasoning zu sehen.
Kontextfenster. Die Einträge Fable, Opus, Sonnet und Haiku listen ein 200k-Fenster — das Fenster, das die Laufzeit diesen Namen gibt —, auch beim ersten Start oder solange die Modellliste der Laufzeit nicht gelesen werden kann. Nur ein Eintrag, den die Laufzeit selbst als ihre 1M-Variante anbietet (zum Beispiel Opus (1M context), Alias opus[1m]), wird mit 1M gelistet und bemessen. Meldet die Laufzeit für das Modell, das geantwortet hat, ein größeres Fenster, nutzt die Kontextleiste weiterhin dieses. Ein Eintrag, den eine frühere Version mit 1M gespeichert hat und den seitdem kein Lesen der Modellliste bestätigt hat, wird beim nächsten Start auf 200k korrigiert, auch solange das Lesen der Modellliste weiter scheitert; Einträge, die du ausgeschaltet hast, bleiben aus.
Der tatsächliche Effort wird in jedem Zug aus der Laufzeit zurückgelesen: Du forderst Sehr hoch an, die Laufzeit läuft mit Hoch, und die Antwort sagt das; mit Automatisch nennt die Antwort die Stufe, die das Modell tatsächlich genutzt hat.
Jede Antwort hält das konkrete Modell fest, das geantwortet hat, in Traces und in der Speicher-Zuordnung. Ein Zug ohne gewähltes Modell wird Claude Code (Default) zugeordnet.

Hintergrundaufrufe auf einer CLI. Hintergrund-Modellaufrufe (Speichererfassung, Titel, Sicherheitsprüfungen) nutzen ein bestimmtes Modell von Claude Code, Grok CLI oder Kimi Code CLI aus einer Routing-Stufe nur, wenn die eigene Erkennung dieser CLI dieses Modell angeboten hat; sonst laufen sie auf dem Default-Modell der CLI. Wohin EYAS’ Hintergrundarbeit gerade geht, zeigt Routing & Budget — Hintergrund-Modellaufrufe.

Hintergrundaufrufe behalten auf einer CLI ihr Ausgabelimit. EYAS’ eigene kleine Einzelaufrufe — Gesprächstitel, Nachrichten-Triage, Speichererfassung, das Urteil des Security-Judges, Konsolidierung und ähnliche Hintergrunddurchläufe — verlangen eine maximale Antwortlänge. Die CLIs nehmen von EYAS kein Ausgabelimit an, deshalb zählt EYAS auf Claude Code, Grok CLI und Kimi Code CLI die Antwort mit, während sie gestreamt wird: Überschreitet sie etwa vier Zeichen pro angefordertem Token (maxTokens × 4 Zeichen), stoppt EYAS die CLI (Claude Code: die Anfrage wird geschlossen; Grok und Kimi: die Session wird abgebrochen). Der Aufruf endet dann normal mit der Antwort bis zu diesem Punkt und dem Stoppgrund max tokens (Ausgabelimit erreicht), nie mit einem Fehler — wie bei den API-Anbietern. Nur die Antwort zählt; Reasoning verbraucht das Limit nicht. Chat- und Agentenzüge mit Tools sind nicht betroffen, weil ein CLI-Zug viele Modellaufrufe ausführt. Die Release-Prüfung beweist das auf Claude Code 2.1.281 und Grok CLI 1.0.41; Kimi Code CLI nutzt denselben Code-Pfad, wurde aber nicht live getestet.

Claude-Code-Isolation

EYAS führt Claude Code immer isoliert aus. Einen Schalter gibt es nicht: Die frühere Option Host-Claude-Config laden ist weg. Das Anbieter-Panel sagt das in einer Zeile und verweist für Host-CLAUDE.md-Inhalte auf den Datenimport.

Jeder Claude-Code-Lauf — Chat, Agenten, Hintergrundarbeit und isolierte Einzelaufrufe gleichermaßen:

lädt keine Host-settings.json (also keine Hooks und keine Berechtigungsregeln), keine CLAUDE.md auf irgendeiner Ebene (User, Projekt oder lokal), keine Host-Skills und keine Projekt-.mcp.json-, Dateisystem- oder claude.ai-MCP-Server. Sein einziger Tool-Server ist EYAS’ eigener Server eyas; Hintergrund-Einzelaufrufe bekommen keinen;
läuft mit ausgeschaltetem Auto-Memory von Claude Code;
hält seine temporären Dateien, auch die Ausgabe von Shell-Befehlen, die es im Hintergrund ausführt, in einem eigenen Ordner dieses Laufs im Workspaces-Ordner von EYAS — nicht im /tmp/claude-<uid> des Hosts. Der Ordner wird am Ende des Laufs entfernt; einen, den ein Absturz zurückgelassen hat, entfernt der nächste Start;
schreibt kein Transkript unter ~/.claude/projects und legt keine Datei-Checkpoint-Kopien an, EYAS-Läufe tauchen also nicht in claude --resume auf (Transkripte früherer EYAS-Versionen werden nicht automatisch gelöscht);
behält die Host-Anmeldung: claude.ai-Abonnement, API-Schlüssel, OAuth-Token, Bedrock oder Vertex funktionieren weiter.

Unternehmensweit verwaltete Policy-Einstellungen gelten weiterhin, wo eine Organisation sie verteilt; diese Ebene kann EYAS nicht abschalten.

Projekt-Anweisungsdateien im Ordner eines Gesprächs (CLAUDE.md, AGENTS.md) werden ebenfalls nicht automatisch geladen. Das Modell kann sie weiterhin mit seinen Datei-Tools öffnen.

Arbeitsordner. Claude Code arbeitet im ersten Ordner des Gesprächs, der die Prüfung noch besteht, sonst im eigenen EYAS-Workspace des Gesprächs. Es läuft nie im eigenen Verzeichnis des EYAS-Servers (dem EYAS-Home mit Schlüsseldatei, Vault und Datenbank). Hintergrundaufrufe ohne Gespräch nutzen einen temporären Scratch-Ordner pro Lauf, der nach 7 Tagen ohne Nutzung entfernt wird. Ein gespeicherter Ordner, der die Prüfung nicht mehr besteht, wird übersprungen, mit einer Warnung im Server-Log. Siehe Gespräche — Ordner.

Umgebung. Claude Code bekommt nur eine Umgebung nach Allowlist: PATH, Locale und Zeitzone, Proxys und CA-Bundles, HOME und die Anmeldevariablen für Anthropic / Claude OAuth / Bedrock / Vertex. Dazu setzt EYAS seine Isolationsschalter — CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, CLAUDE_CODE_DISABLE_CLAUDE_MDS=1 und DISABLE_AUTOUPDATER=1 —, setzt CLAUDE_CODE_TMPDIR auf den eigenen temporären Ordner des Laufs und gibt sich Claude Code gegenüber als eyas zu erkennen. Andere Servervariablen werden nicht weitergegeben: API-Schlüssel anderer Anbieter, EYAS-Geheimnisse, CLAUDE_CONFIG_DIR und die CLAUDE_CODE_*-Schalter einer Claude-Code-Session, aus der EYAS gestartet wurde. Die Anmeldeprüfung (claude auth status) nutzt dieselbe Umgebung. Wegen DISABLE_AUTOUPDATER aktualisiert sich Claude Code nicht selbst, solange EYAS es ausführt.

Startprüfung. Claude Code meldet zu Beginn jedes Laufs, was es geladen hat, und EYAS prüft diese Meldung, bevor es irgendetwas von der Antwort nutzt. Nur EYAS’ eigener Tool-Server darf verbunden sein, der Berechtigungsmodus muss default sein, der Arbeitsordner muss der erwartete sein, und kein Plugin darf geladen sein — außer den zwei Plugins, die Claude Code 2.1.281 eingebaut hat, agents-md und telemetry, und auch diese nur als agents-md@builtin und telemetry@builtin. EYAS’ Release-Prüfung hat nachgewiesen, dass sie unter EYAS’ Isolation harmlos sind: Keine AGENTS.md aus dem Arbeitsordner oder einem Unterordner erreicht das Modell. Jedes andere Plugin, auch ein neues eingebautes Plugin einer späteren Claude-Code-Version, stoppt den Lauf weiterhin. Taucht etwas anderes auf — etwa ein MCP-Server oder Plugin aus der Host-Konfiguration oder eine verwaltete Policy, die einen anderen Berechtigungsmodus erzwingt —, stoppt EYAS den Lauf sofort. Nichts aus diesem Lauf wird gezeigt, und der Zug scheitert mit einem CLI-Isolationsfehler, der die fehlgeschlagenen Prüfungen in deiner Sprache nennt — etwa Claude Code CLI wurde gestoppt: EYAS konnte nicht bestätigen, dass es isoliert läuft (der Arbeitsordner war nicht der von EYAS gewählte). Die Runde wurde nicht an ein anderes Modell übergeben. Er wird nicht wiederholt und nicht an einen anderen Anbieter übergeben. Die Abhilfe liegt auf dem Host: die störende verwaltete Einstellung oder das Plugin entfernen oder prüfen, auf welches Binary EYAS_CLAUDE_CODE_BIN zeigt.

Claude Codes eigene Tools durchlaufen zuerst EYAS’ Speicher-Policy. Bevor Read, Write, Edit, Glob, Grep, Bash, NotebookEdit, WebFetch oder ein anderes Claude-Code-Tool läuft, vergleicht eine Prüfung jeden berührten Pfad mit EYAS’ Speicher-Policy — auch Lesezugriffe, die Claude Code in seinem Arbeitsordner sonst selbst erlauben würde. Der Speicher anderer Tools (~/.claude, ~/.grok, ~/.codex, Obsidian-Vaults, der Rest der Liste und security.foreignMemoryPaths), EYAS’ eigener Datenordner und der Workspace eines anderen Gesprächs werden verweigert. Ein verweigerter Aufruf läuft nicht; Claude Code bekommt den Grund — etwa Memory outside EYAS (Obsidian) — use memory_search / memory_expand from EYAS — und kann mit EYAS’ Speicher-Tools weitermachen. Grep, Glob, LS und rekursive Bash-Suchen werden nach allem beurteilt, was sie erreichen können: Eine Suche, deren Ordner einen geschützten Ort enthält — etwa ein Grep in ~ oder ein Grep im EYAS-Checkout, der data/ enthält —, wird als Search too broad … abgelehnt, und Claude Code kann es in einem engeren Ordner erneut versuchen. Siehe Sicherheit & Datenschutz — Speicher außerhalb von EYAS. Zusätzlich zu dieser Prüfung laufen die Shell-Befehle von Claude Code in der Datei-Sandbox des Betriebssystems, wo eine verfügbar ist — siehe Kernel-Datei-Sandbox.

EYAS-Tools auf Claude Code. Claude Code erreicht EYAS-Tools über den In-Process-MCP-Server eyas, in seinem Prompt als mcp__eyas__<name> benannt. Dieser Server bietet genau die Tools an, die EYAS dem Lauf anbietet: die Tools-Liste des Agenten plus memory_search und memory_expand (eine leere Liste heißt alle Tools). In einem Solo-Gespräch bietet er keine Delegations-Tools an. Die EYAS-Tools, für die Claude Code ein gewährtes eigenes Gegenstück hat, werden nicht übergeben — read_file, grep und glob (seine Read, Glob und Grep), write_file und edit_file, solange es schreiben darf, und run_command, git_status und git_diff, solange es seine Shell nutzen darf: Claude Code nutzt dann seine eigenen Tools in den Ordnern des Zugs, unter der Sandbox und der Speicher-Policy. Auf einer Liste ohne run_command werden git_status und git_diff stattdessen als EYAS-Tools übergeben. Jedes andere EYAS-Tool wird übergeben, auch die EYAS-Browser-Tools (browser_*, mit gespeicherten Sessions und browser_totp), agent_browser_*, browser_use_* und opencode_*; sie laufen in EYAS unter demselben Security-Gate, denselben Freigaben und demselben Tool-Umfang wie bei einem API-Anbieter. Der Speicher-Drill-down zählt 3 Aufrufe pro Antwort, wie bei jedem anderen Anbieter. Siehe MCP — CLI-MCP-Tool-Parität.

Die Tools-Liste des Agenten begrenzt auch die eigenen Werkzeuge der CLI. Auf Claude Code, Grok CLI und Kimi Code CLI gleichermaßen entscheidet die Tools-Liste eines Agenten, welche der eigenen eingebauten Werkzeuge der CLI das Modell nutzen darf, nicht nur, welche EYAS-Tools es über die Bridge erreicht — so wie sie ein API-Modell begrenzt:

Dateien schreiben (Write, Edit und NotebookEdit von Claude Code; die Bearbeiten- und Verschieben-Werkzeuge von Grok und Kimi sowie Dateischreibvorgänge, die EYAS der CLI bereitstellt): nur, wenn die Liste write_file oder edit_file enthält.
Shell-Befehle (Bash von Claude Code; die Ausführen-Werkzeuge von Grok und Kimi; auch ein Löschen zählt als Shell-Befehl, so wie das Security-Gate es einstuft): nur, wenn die Liste run_command enthält. git_status und git_diff gewähren keine Shell.
Web-Abruf und Websuche (WebFetch und WebSearch von Claude Code; die Abruf-Werkzeuge von Grok und Kimi sowie Groks web_fetch und web_search): nur, wenn die Liste ein Web-Tool enthält — research, browser_navigate, agent_browser_run oder browser_use_exec.
Dateien lesen (Read, Glob und Grep von Claude Code; die Lese-, Such- und Auflistungs-Werkzeuge von Grok und Kimi) ist immer erlaubt, egal was die Liste sagt. Es bleibt in den Ordnern des Gesprächs, unter der Speicher-Policy und der Kernel-Datei-Sandbox. Auch die Speichersuche ist immer verfügbar.
Eine leere Liste bedeutet weiterhin alle Tools, die eigenen Werkzeuge der CLI eingeschlossen.

Auf Claude Code werden die zurückgehaltenen Werkzeuge dem Modell gar nicht erst angeboten. Auf Grok und Kimi lehnt EYAS ein zurückgehaltenes Werkzeug, das die CLI nutzen will, ab, bevor das Security-Gate gefragt wird: Es gibt keine Freigabeanfrage, und die Tool-Zeile zeigt Abgelehnt (Grok zeigt seinen eigenen Ablehnungstext in der Zeile). Kimis Berechtigungsanfragen sagen nicht, welche Art von Werkzeug fragt (aus dem Quellcode von Kimi 1.52.0 gelesen; noch nicht auf einem Host geprüft), deshalb lehnt EYAS eine Kimi-Anfrage, die es nicht einordnen kann, immer dann ab, wenn der Liste des Agenten entweder die Schreib-Tools oder run_command fehlen — ein solcher Agent kann keines der fragenden Werkzeuge von Kimi nutzen (Datei schreiben oder ersetzen, Shell, Hintergrundaufgaben). Kimis Websuche und Web-Abruf fragen EYAS nie und lassen sich daher nicht pro Agent erlauben; die Isolationsprüfung von EYAS stoppt einen Zug, der sie nutzt, trotzdem. Migration: Bestehende Agenten mit einer schmalen Liste — etwa ein Persönlicher Assistent ohne run_command / write_file — können auf Claude Code, Grok oder Kimi keine Dateien mehr schreiben und keine Befehle mehr ausführen. Um das zu erlauben, füge write_file / edit_file und/oder run_command zur Liste hinzu, oder leere die Liste. Siehe Agenten — Tools.

Spezialisten. Claude Code startet keine eigenen versteckten Subagenten (sein eingebautes Task/Agent-Werkzeug wird nicht angeboten). Verteilt ein Kollege auf Claude Code Arbeit, startet er Spezialisten über EYAS mit run_specialist, genau wie bei den anderen Anbietern — siehe Teams und Delegation.

Upgrade. Eine Installation, bei der Host-Claude-Config laden an war, wird automatisch auf isoliert umgestellt; die gespeicherte Einstellung wird beim ersten Start entfernt, und ein übrig gebliebener Wert wird ignoriert. Host-CLAUDE.md-Anweisungen und Host-Skills erreichen Gespräche nicht mehr. Um diesen Inhalt zu behalten, importiere ihn einmal, in eine Richtung, über Einstellungen → System → Datenportabilität → Daten importieren — siehe Datenimport.

Grok CLI und Kimi Code CLI

EYAS führt Grok CLI und Kimi Code CLI vollständig isoliert vom eigenen Grok-, Kimi- und Claude-Setup der Maschine aus.

Eigenes Home. EYAS startet jede CLI mit einem eigenen Home-Ordner im EYAS-Datenordner — <Datenverzeichnis>/cli-homes/grok-cli und <Datenverzeichnis>/cli-homes/kimi-cli. EYAS-Läufe lesen und schreiben nicht das ~/.grok, ~/.kimi, ~/.claude, ~/.cursor oder ~/.agents des Betreibers: keine Host-Konfiguration, Regeln oder AGENTS.md, kein Speicher, keine Skills, Hooks, Claude-/Cursor-Importe oder MCP-Server (etwa ein Obsidian-Vault-Server).

Umgebung. Nur eine kurze Allowlist erreicht die CLI: PATH, Locale und Zeitzone, TMPDIR, TERM, USER, LOGNAME, SHELL, Proxy-Variablen und CA-Bundle-Variablen. EYAS-Geheimnisse, Schlüssel anderer Anbieter, ein XAI_API_KEY in der Server-Umgebung und jede GROK_*-, KIMI_*- oder XDG_*-Einstellung des Servers fallen weg.

Welches Binary. EYAS_GROK_BIN / EYAS_KIMI_BIN (der absolute Pfad zum Binary) haben Vorrang, sonst grok / kimi im PATH. Ist die Variable gesetzt, aber ungültig, wird der Anbieter nicht registriert — einen Rückfall auf PATH gibt es nicht. Den Anbieter neu zu laden (aus und wieder an) sucht das Binary erneut.

Arbeitsordner. Ein Grok- oder Kimi-Zug läuft im ersten gültigen Ordner des Gesprächs, sonst im eigenen EYAS-Workspace des Gesprächs, sonst in einem privaten Scratch-Ordner des Laufs — nie im eigenen Arbeitsverzeichnis des EYAS-Servers.

Grok-Einstellungen, die EYAS schreibt. Vor jedem Lauf schreibt EYAS config.toml, requirements.toml und eine leere trusted_folders.toml in sein Grok-Home; lokale Änderungen dort werden ersetzt. Sie setzen:

Ask-Modus. Jedes native Grok-Werkzeug — Datei lesen, Ordner auflisten, suchen, Shell, schreiben/bearbeiten, Web-Abruf und -Suche, Subagenten — fragt zuerst EYAS, und EYAS’ Security-Gate entscheidet.
Always-approve ist gesperrt. --always-approve, der Yolo-Modus und /always-approve funktionieren nicht.
Speicher, Speicher v2, Session-Suche, Telemetrie und Trace-Upload, der geteilte Leader-Modus (Grok startet mit --no-leader) und Auto-Update sind aus.
Nur EYAS’ eigener Tool-Server (eyas) darf sich verbinden.
Ordner-Vertrauen wird nie gewährt. AGENTS.md, .grok-Konfiguration, Hooks und MCP-Server eines Gesprächsordners werden nicht automatisch geladen; das Modell kann Dateien weiterhin mit seinen Datei-Tools öffnen, und jeder Lesezugriff fragt EYAS.

Kimi-Einstellungen, die EYAS schreibt. EYAS setzt default_yolo = false, telemetry = false und merge_all_available_skills = false in seiner eigenen Kimi-Konfiguration und behält alles andere in dieser Datei (Anmeldung, Default-Modell). Kimi bekommt keine eigenen MCP-Server, Auto-Update ist aus, und es wird genau als kimi acp gestartet. In derselben Datei speichert Kimi auch das Modell, auf das EYAS es umstellt — siehe Kimi-Modelle und Thinking.

Session-Dateien werden gelöscht. Die Transkripte, der Prompt-Verlauf und die Tool-Logs, die eine CLI in ihrem EYAS-Home schreibt, werden am Ende jedes Zugs gelöscht. Reste, die älter als eine Stunde sind (nach einem Absturz), werden beim Start und stündlich entfernt. Das EYAS-Gespräch selbst ist nicht betroffen: EYAS spielt es in jedem Zug aus seinem eigenen Speicher ab.

Groks Shell. Groks Shell-Befehle laufen mit dem EYAS-Grok-Home als HOME, die ~/.gitconfig, SSH-Schlüssel und Shell-Konfiguration des Hosts sind also nicht verfügbar — Git-Commits aus Groks Shell haben zum Beispiel keine Host-Identität. Wo der Server eine anbietet, laufen Groks eigene Tools außerdem in der Datei-Sandbox des Betriebssystems — siehe Kernel-Datei-Sandbox.

Rundenlimit. Bei Grok und Kimi zählt das Rundenlimit Tool-Aufrufe. Ein Chat-Zug nutzt die Max. Runden des Kollegen des Gesprächs (sonst die des Default-Agenten des Projekts) oder standardmäßig 25; Agentenläufe nutzen die Max. Runden des Agenten; die Einstellung maxTurns des Anbieters (Default 25) gilt nur für Aufrufe, die kein Budget setzen. Startet die CLI einen Tool-Aufruf mehr als das Limit, bricht EYAS die CLI-Session ab: Der Zug endet als max turns und behält die Teilantwort. Das ist kein Fehler, und der zusätzliche Tool-Aufruf läuft nicht. Dasselbe Budget ist für einen Chat-Zug die interne Rundengrenze von Claude Code.

Keine feste Zeitgrenze. Ein Zug von Claude Code, Grok oder Kimi wird nicht nach einer festen Zeit gestoppt. Er stoppt nur, wenn die CLI still wird: 10 Minuten ohne Nachricht, während kein Tool läuft, oder 20 Minuten ohne Nachricht, während ein Tool läuft (etwa ein mit run_specialist gestarteter Spezialist, der bis zu 15 Minuten brauchen kann, oder ein langer Build). Jede Nachricht der CLI — gestreamter Text, ein Tool, das startet oder endet, eine Berechtigungsanfrage — startet die Uhr neu, und für den ganzen Zug gibt es keine Grenze; Stopp beendet ihn weiterhin jederzeit. Ein wegen Stille gestoppter Zug meldet ein Timeout, keinen allgemeinen aborted-Fehler; wie andere Timeouts darf er einmal wiederholt oder auf einen anderen Anbieter umgeleitet werden, solange noch nichts gestreamt wurde, und ein Hintergrundlauf kann vom Auto-Retry-Planer wiederholt werden. Die beiden Grenzen sind model.cli.idleTimeoutMs und model.cli.toolTimeoutMs — siehe Konfiguration — Zeitlimits für CLI-Runden. Der Schlüssel pro Zug, mit dem Grok und Kimi EYAS-Tools aufrufen, läuft 2 Stunden nach seiner letzten Nutzung ab; ein langer, beschäftigter Zug behält also seine EYAS-Tools. Widerrufen wird er in dem Moment, in dem der Zug endet.

Slash-Befehle. Eine Nachricht, die mit / beginnt (etwa /always-approve on), geht an Grok oder Kimi eingeschlossen in <message>…</message>, damit die CLI sie nie als einen ihrer eigenen Befehle ausführt. Das Modell sieht den Text trotzdem.

Grenzen von Kimi. Kimis Isolation ist aus seinem Quellcode abgeleitet und noch nicht auf einer Maschine nachgewiesen (siehe Nachgewiesene CLI-Versionen). Kimi hat keine Ordner-Vertrauensprüfung: Es liest weiterhin AGENTS.md / .kimi/AGENTS.md im Gesprächsordner, und bis zur Wurzel des umgebenden Git-Repositorys, wenn der Ordner in einem Repository liegt. Seine Such- und Web-Werkzeuge fragen EYAS nie; ein Kimi-Zug, der sie nutzt, wird also von der Isolationsprüfung unten gestoppt. Aus demselben Grund kann EYAS eine Kimi-Suche nicht als zu breit ablehnen: Kimis eigene Werkzeuge Grep und Glob fragen nie, Kimis Glob bleibt in seinem Arbeitsordner, sein Grep akzeptiert aber jeden Ordner, und Kimi hat keine Kernel-Sandbox (siehe Sicherheit & Datenschutz — Speicher außerhalb von EYAS). Die Tools-Liste des Agenten begrenzt die eigenen Schreib-, Shell- und Web-Werkzeuge von Kimi und Grok, wie unter Claude-Code-Isolation beschrieben.

Weil Grok und Kimi in EYAS’ eigenem Home laufen, wird die Anmeldung der CLI auf dem Rechner nicht genutzt. Eine Installation, die sich auf die Host-Anmeldung verließ, hat kein funktionierendes Grok- oder Kimi-Modell, bis sich jemand einmal für EYAS anmeldet. Die eigene grok- / kimi-Anmeldung des Betreibers auf dem Host wird nie gelesen, geändert oder genutzt, und die EYAS-Anmeldung erneuert sich selbst.

Die Karte Für EYAS anmelden erscheint an drei Stellen: im Anbieter-Panel von Grok CLI / Kimi Code CLI, im Schritt KI-Anbieter des Setup-Assistenten, sobald Grok oder Kimi erkannt wird, und als Banner auf Start, <CLI> braucht eine Anmeldung für EYAS, wenn eine aktivierte, installierte CLI nicht angemeldet ist (Anmelden öffnet die Karte; Ausblenden verbirgt das Banner für die Browser-Sitzung). Nur Owner und Admins können sich an- oder abmelden, und nur sie sehen Link und Code einer laufenden Anmeldung; andere Rollen sehen den Zustand.

Gerätecode (Grok und Kimi). Klicke Mit Gerätecode anmelden. EYAS führt die eigene Anmeldung der CLI in seinem eigenen Ordner aus und zeigt einen Link (Anmeldeseite öffnen) und einen Code. Öffne den Link auf einem beliebigen Gerät, melde dich an und prüfe, dass die Seite denselben Code zeigt. Auf dem Server ist kein Browser nötig, das funktioniert also auf Headless-Servern und in Docker. Die Karte zeigt Warte auf die Bestätigung des Codes…, dann Angemeldet.

Abbrechen stoppt eine laufende Anmeldung.
Nach 15 Minuten ohne Bestätigung läuft die Anmeldung ab; beginne neu. Kimi startet außerdem von selbst mit einem neuen Code neu.
Findet EYAS in der Ausgabe der CLI keinen Link, zeigt es den Text der CLI unverändert, damit du ihm folgen kannst.
Ein Fehlschlag zeigt die letzte Meldung der CLI und Erneut versuchen.

Stattdessen API-Schlüssel (nur Grok). Wähle Stattdessen API-Schlüssel verwenden und füge einen xAI-API-Schlüssel ein. EYAS speichert ihn verschlüsselt in den Geheimnissen als grok-cli-api-key (Scope System) und übergibt ihn nur an Läufe der Grok CLI, als XAI_API_KEY. Die Nutzung wird dem xAI-API-Konto berechnet, nicht einem Grok-/SuperGrok-Abonnement. Gibt es sowohl eine Gerätecode-Anmeldung als auch einen Schlüssel, nutzt Grok die Gerätecode-Anmeldung. Du kannst den Schlüssel auch auf der Seite Geheimnisse unter diesem Namen anlegen; EYAS übernimmt ihn, wenn das Anbieter-Panel oder die Assistenten-Karte geöffnet wird, wenn der Anbieter neu lädt oder nach dem ersten Zug, der mit dem Anmeldefehler scheitert. Kimi hat in EYAS keine API-Schlüssel-Option.

Abmelden entfernt EYAS’ Grok- bzw. Kimi-Zugangsdaten aus EYAS’ Ordner und löscht den gespeicherten API-Schlüssel. Für Grok führt EYAS grok logout in seinem eigenen Ordner aus. Für Kimi löscht EYAS seine eigene Zugangsdatendatei und führt kimi logout nicht aus, weil dieser Befehl auch das Kimi-Token des Betreibers aus dem Schlüsselbund des Betriebssystems löschen würde. Die Host-Anmeldung wird nie angefasst.

Ohne Anmeldung scheitert ein Gesprächs- oder Hintergrundzug auf diesem Anbieter sofort, bevor die CLI startet, mit <Anbieter> ist nicht für EYAS angemeldet … melde dich unter Anbieter an (Fehlercode cliSignIn). EYAS wiederholt ihn nicht und wechselt nicht still zu einem anderen Anbieter. Ein Authentifizierungsfehler, den die CLI während eines Zugs meldet, ergibt dieselbe Meldung.

Wo die Zugangsdaten liegen: <Datenverzeichnis>/cli-homes/grok-cli/.grok/auth.json und <Datenverzeichnis>/cli-homes/kimi-cli/.kimi/credentials/kimi-code.json, in Ordnern, die nur der EYAS-Benutzer öffnen kann. Ein Backup des Datenverzeichnisses enthält sie.

API (Integratoren, Owner/Admins; Lesezugriff für GET). GET /api/v1/model/providers/{grok-cli|kimi-cli}/sign-in liefert {signedIn, method: device|apiKey|null, apiKeySupported, apiKeyStored, session{state: pending|succeeded|failed|expired|cancelled, verificationUrl, userCode, rawPrompt, error}}. POST {"method":"device"} liefert 202 — GET abfragen, solange sie läuft. POST {"method":"apiKey","apiKey":"…"} liefert 200 (nur Grok; Kimi liefert 400). DELETE meldet ab; DELETE ?target=session bricht nur eine laufende Gerätecode-Anmeldung ab. Andere Anbieter liefern 404. Wer Modelle nicht verwalten darf, bekommt verificationUrl, userCode, rawPrompt und error als null: Wer den Code bestätigt, bindet sein eigenes Konto an das EYAS-Home.

Kimis Anmeldung folgt dem Quellcode der Kimi CLI und ist auf einem echten Host noch nicht verifiziert.

Isolationsprüfung vor jedem Zug

Grok CLI und Kimi Code CLI laufen erst, nachdem EYAS ihre Isolation geprüft hat. Ein Zug, der eine Prüfung nicht besteht, stoppt mit einem Isolationsfehler; er wird nie wiederholt und nie still an ein anderes Modell übergeben.

Grok wird vor jedem Zug geprüft, ohne Modellaufruf: EYAS führt grok inspect --json im Gesprächsordner aus, mit seinem EYAS-Grok-Home, und liest die dort geschriebenen Konfigurationsdateien zurück. Eine bestandene Prüfung gilt 10 Minuten lang für dasselbe Grok-Binary, denselben Ordner und dasselbe Home; alles, was im Home abgelegt wird (ein Skill, eine Regel oder ein Hook), erzwingt eine neue Prüfung. Grok wird abgelehnt, wenn:

es Tool-Aufrufe selbst freigeben könnte (die Always-approve-Sperre nicht greift);
Berechtigungsregeln oder eine Konfigurationsebene von woanders kommen als aus EYAS’ eigenen Dateien — etwa eine systemweite Grok-Konfigurationsdatei oder verwaltete Claude-Code-Einstellungen, die Berechtigungsregeln hinzufügen;
es einen anderen MCP-Server als EYAS’ eigene Bridge starten würde (Server, die EYAS’ Allowlist deaktiviert hat, sind in Ordnung);
Hooks, Plugins oder Language-Server konfiguriert sind;
Anweisungsdateien, Skills oder Agenten aus seinem Home oder von außerhalb der Ordner des Gesprächs kommen;
Claude-, Cursor- oder Codex-Importe an sind;
die eigene Konfiguration eines vertrauenswürdigen Projektordners greift.

Groks vom Hersteller verwaltete Einstellungsdatei. grok 1.0.41 schreibt einen Zwischenspeicher der vom Hersteller verwalteten Einstellungen, managed_config.toml, in sein EYAS-Grok-Home; bei einem normalen Konto ist er leer. Eine leere Datei wird akzeptiert. Enthält die Datei irgendeine Einstellung, wird der Zug mit den obigen Prüfungen abgelehnt (etwa Werkzeugfreigabe nicht an EYAS gebunden), und jede Änderung daran macht eine bestandene Prüfung sofort ungültig, auch innerhalb der 10 Minuten, in denen eine bestandene Prüfung sonst wiederverwendet wird.

Projekt-Anweisungsdateien (AGENTS.md, CLAUDE.md, .grok/rules) in den Ordnern des Gesprächs sind kein Ablehnungsgrund: Der Ordner wird nie als vertrauenswürdig markiert, Grok lädt sie also nicht selbst, aber das Modell darf sie mit seinen Datei-Tools lesen. Projekt-MCP-Server oder -Hooks in einem solchen Ordner listet Grok zwar auf, startet sie aber nie.

Kimi wird über sein EYAS-Home geprüft, weil es keinen Inspect-Befehl hat: In data/cli-homes/kimi-cli/.kimi/config.toml muss Auto-Approve aus sein, das Zusammenführen von Host-Skill-Ordnern aus, ohne Hooks und ohne zusätzliche Skill-Ordner; mcp.json muss leer sein; und die Skill-Ordner des Homes dürfen keine Skills enthalten. Außerdem muss Kimi seine Daten im Kimi-Home von EYAS halten: Zeigte sein Share-Ordner irgendwo anders hin, stoppt die Prüfung den Zug und die Modellaktualisierung (angezeigt als Werkzeugfreigabe nicht an EYAS gebunden), sodass ein Modellwechsel nie außerhalb dieses Homes schreiben kann.

Beim Start der Session wird eine Session gestoppt, die in einem Modus beginnt, der Tool-Aufrufe selbst freigibt.

Während der Zug läuft, stoppt EYAS den Zug, wenn Grok oder Kimi ein natives Werkzeug startet oder beendet, ohne dass EYAS darüber entschieden hat (Datei lesen oder schreiben, suchen, auflisten, Shell, Web, Subagent, Tool-Suche oder ein MCP-Tool, das nicht von EYAS ist), oder sein eigenes Speicher-Werkzeug aufruft. EYAS bricht dann die Session ab, beendet den Zug mit dem Isolationsfehler und nutzt nichts mehr, was die CLI danach sagt. EYAS’ eigene Tools (Speicher, Board usw. — von Grok über use_tool als eyas__<name> erreicht) sind nicht Teil dieser Prüfung, weil EYAS jeden dieser Aufrufe selbst entscheidet — siehe EYAS-Tools bekommen dieselben Entscheidungen unten.

Die Chat-Meldung lautet zum Beispiel: Grok CLI wurde gestoppt: EYAS konnte nicht bestätigen, dass es isoliert läuft (MCP-Server außer denen von EYAS, Hooks). Die Runde wurde nicht an ein anderes Modell übergeben. Danach folgt der Link Anbietereinstellungen öffnen. Die Prüfungen, die sie nennen kann: Werkzeugfreigabe nicht an EYAS gebunden; MCP-Server außer denen von EYAS; Hooks; Plugins oder Erweiterungen; Anweisungen oder Skills von außerhalb der Unterhaltung; das eigene Gedächtnis der CLI; Importe aus anderen KI-Werkzeugen; ein gemeinsamer Leader-Prozess; ein als vertrauenswürdig markierter Projektordner; ein Werkzeug, das ohne Freigabe durch EYAS lief; die Prüfung konnte nicht laufen.

Zum erneuten Prüfen entferne die Ursache — etwa den zusätzlichen MCP-Server, Hook, Skill oder die AGENTS.md im EYAS-Grok- oder -Kimi-Home oder eine systemweite Grok-Konfiguration — und schicke die Nachricht erneut. Jeder Zug prüft erneut. Den Anbieter neu laden oder wieder einschalten oder EYAS neu starten führt die Grok-Prüfung beim Laden aus, und Jetzt prüfen im Anbieter-Panel führt dieselben Prüfungen ohne Modellaufruf aus (siehe Laufzeit und Isolation im Anbieter-Panel unten). Die EYAS-Homes prüft eyas doctor (siehe Nachgewiesene CLI-Versionen).

Laufzeit und Isolation im Anbieter-Panel. Wähle unter Anbieter die Karte Claude Code CLI, Grok CLI oder Kimi Code CLI:

Laufzeit — wie EYAS das Binary gefunden hat, seine Version und sein Pfad. Quellen: Host-CLI im PATH, Betreiber-Überschreibung (Umgebungsvariable) (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN) oder Mitgelieferte Laufzeit (Fallback) (nur Claude Code). Die Version ist die eigene der CLI; eine CLI, die keine meldet, zeigt Version unbekannt. Zusätzliche Zeilen: Version X weicht von der erwarteten Version Y ab (das Claude-Code-Binary weicht von der Version ab, für die das festgelegte Agent SDK von EYAS gebaut wurde); Eine CLI im PATH (Version) wird nicht verwendet. (eine Überschreibung verdeckt eine andere CLI im PATH); Nicht angemeldet (nur Claude Code — Grok und Kimi zeigen ihre Anmeldung auf der Karte Für EYAS anmelden); Keine nutzbare Laufzeit gefunden — installiere die CLI oder setze die Überschreibung; und bei einer Überschreibung, die keine ausführbare Datei nennt, Die Überschreibungsvariable ist gesetzt, nennt aber keine ausführbare Datei. EYAS führt für diesen Anbieter daher kein Programm aus (und weicht nie auf den PATH aus). Korrigiere oder entferne sie.
Isolation — ein Status-Badge (Geprüft, Prüfung fehlgeschlagen, Noch nicht geprüft, Anmeldung erforderlich) und ein Satz dazu, wie EYAS die CLI isoliert hält und wann es prüft: Claude Code zu Beginn jedes Zugs anhand dessen, was es beim Start meldet (eine Prüfung ohne Zug gibt es nicht); Grok vor jedem Zug mit grok inspect, ohne Modellaufruf; Kimis EYAS-Home vor jedem Zug, und Kimi gilt erst als geprüft, wenn auf diesem Server eine Session mit bestandenen Prüfungen gestartet ist. Dann Zuletzt geprüft: <Zeit> oder Seit dem Start von EYAS nicht geprüft. — der Status wird im Speicher gehalten und setzt sich daher beim Neustart von EYAS zurück — und eine Liste Fehlgeschlagene Prüfungen mit denselben Bezeichnungen wie der Isolationsfehler im Chat, jede mit ihrem Rohdetail.
Eine Zeile, die die installierte Version mit der Version vergleicht, auf der die Live-Isolations-Release-Prüfung von EYAS bestanden wurde: auf dieser Version bestanden (mit Version und Datum); zuletzt auf einer anderen Version bestanden, nicht auf der installierten; Noch auf keinem Host geprüft — die Prüfung ist mit dieser CLI nie gelaufen, ihre Isolation beruht also nur auf dem Quellcode der CLI (derzeit Kimi); oder die CLI hat keine Version gemeldet. Jede Zeile endet mit dem Hinweis, dass jeder Zug weiterhin geprüft wird.
Restrisiko: ein Satz pro CLI. Claude Code teilt die Anmeldung des Servers, und die Release-Prüfung lief mit einem API-Schlüssel ohne echten Modellaufruf; was nur eine Anmeldung mit einem claude.ai-Konto mitbringt (mit dem Konto synchronisierte Skills, Konto-Gedächtnis, fernverwaltete Einstellungen), ist nicht abgedeckt. Die Release-Prüfung hat Grok mit einem API-Schlüssel angemeldet; ob Grok bei einer grok.com-Anmeldung Sessions mit xAI synchronisiert, wurde nicht beobachtet. Kimis eigene Such- und Web-Werkzeuge fragen EYAS nicht vorher: EYAS stoppt den Zug, sobald eines läuft, doch dann ist es bereits gelaufen, und sein Ergebnis kann Kimis Modell schon erreichen.
Jetzt prüfen (Grok CLI und Kimi Code CLI; Owner und Admins, die Modelle verwalten dürfen) — nur sichtbar, wenn der Anbieter aktiviert ist und seine CLI gefunden wurde. Es führt die Prüfungen erneut aus, die ein Laden des Anbieters ausführt, ohne Modellaufruf: Groks grok inspect-Prüfung, das Zurücklesen von Kimis Home und dann, wenn angemeldet, einen Session-Start ohne Prompt, der auch die Modellliste aktualisiert. So kann Kimi von Noch nicht geprüft auf Geprüft wechseln. Claude Code hat kein Jetzt prüfen: Es wird zu Beginn jedes Zugs geprüft. Fehler lauten „Jetzt prüfen“ setzt voraus, dass der Anbieter aktiviert ist und seine CLI gefunden wird. oder Prüfung fehlgeschlagen: <Fehler>. Der Block lädt nach einer An- oder Abmeldung und nach dem Ein- oder Ausschalten des Anbieters neu.

Die Panels von Grok und Kimi sagen nicht mehr, dass Session-Fortsetzung und Tool-Nutzung die Host-Anmeldung nutzen oder dass die CLI ihre eigene Host-Konfiguration und ihr eigenes Gedächtnis lädt: Das stimmt nicht mehr, seit Grok und Kimi im eigenen Home von EYAS laufen. Kimi Code CLI bleibt standardmäßig aktiviert; das Panel sagt offen, dass seine Isolation noch auf keinem Host geprüft ist.

API (Integratoren). GET /api/v1/model/providers/{claude-code|grok-cli|kimi-cli}/isolation (Lesezugriff auf Modelle; jeder andere Anbieter ist 404, ohne Session 401) liefert {providerId, status: verified|violation|unverified|auth-required, checks[{check, detail}], checkedAt, runtime, hostCli{path, version}|null, signedIn: true|false|null, proof{version, verifiedAt, paidCanary, drift: match|drift|never-verified|unknown-version|null}, canVerify}, wobei runtime entweder {available: true, path, version, source: override|host|sdk-bundled, expectedVersion, skew} oder {available: false, error: override-invalid|not-found|no-policy} ist. POST …/isolation/verify braucht das Recht, Modelle zu verwalten (sonst 403), führt die Prüfungen aus und liefert dieselbe Ansicht; Claude Code oder ein Anbieter, der nicht aktiviert ist oder nicht gefunden wird, liefert 409 {code: 'verifyUnavailable'}.

Freigaben. EYAS beantwortet eine Berechtigungsanfrage einer CLI nur mit einmal erlauben. Bietet die CLI nur immer erlauben oder eine Option für die ganze Session an, antwortet EYAS mit abgebrochen. Eine Ablehnung ist einmal ablehnen.

EYAS-Tools bekommen dieselben Entscheidungen. EYAS’ eigene Tools, die Grok und Kimi über die Tool-Bridge erreichen (Speicher, Board, Dokumente, E-Mail, Browser, Odoo usw.), werden genauso entschieden wie bei den API-Anbietern und Claude Code:

In einem Chat, den du begleitest, oder in einer Kanal-Unterhaltung läuft ein Aufruf, den das Security-Gate erlaubt. Ein als freigabepflichtig markiertes Tool wartet nicht mehr nur deshalb in der Freigabe-Warteschlange, weil das Modell Grok oder Kimi ist, und die Autonomiestufen gelten nicht für begleitete Chats. Ein Aufruf, den das Gate eskaliert, zeigt eine Freigabekarte im Gespräch und einen Eintrag unter Freigaben; der Chat wird nicht angehalten.
In Hintergrundläufen (geplant, Team, Pipeline oder jeder Lauf, der nicht als begleitet gekennzeichnet ist) gilt die Autonomie-Leiter: Ein Aufruf in einer Kategorie auf Hinweis oder Freigeben wartet auf Freigabe, und ein Aufruf, den das Gate eskaliert, wartet immer auf einen Menschen, auch wenn seine Kategorie auf Auto steht (früher lief ein solcher Aufruf auf Grok und Kimi ungefragt). Ein überwachter Lauf pausiert als Wartet auf Freigabe, sobald der Zug der CLI endet, und die Freigabe lässt genau diesen Aufruf einmal laufen.
Ein fortgesetzter oder erneut versuchter Lauf, der einen EYAS-Tool-Aufruf wiederholt, den der ursprüngliche Lauf bereits abgeschlossen hat (zum Beispiel dieselbe E-Mail oder Rechnung), wird abgelehnt, bevor er läuft; die Tool-Zeile zeigt Übersprungen mit already executed on the original run — duplicate side effect prevented. Dasselbe Tool mit anderen Argumenten läuft weiterhin.
Ein Tool außerhalb der Tools-Liste des Agenten wird als Abgelehnt zurückgewiesen, bevor das Security-Gate gefragt wird, und legt daher nie einen Freigabe-Eintrag an. Ohne laufendes Security-Gate wird jeder gebridgte EYAS-Tool-Aufruf abgelehnt.

Bewiesen mit der installierten Grok CLI durch die Release-Prüfung. Für Kimi gelten dieselben Entscheidungen, weil sie in EYAS fallen; wie ein echtes Kimi-Binary diese Aufrufe in seinem eigenen Stream meldet (woraus die Duplikatprüfung eines Fortsetzens gebaut wird), ist noch auf keinem Host geprüft. Siehe MCP — Wie die Bridge gesichert ist.

Ein abgelehnter Aufruf beendet eine Grok-Antwort. Lehnt EYAS einen von Groks Tool-Aufrufen ab — etwa einen Lesezugriff auf Speicher außerhalb von EYAS —, beendet Grok diese Antwort (geprüft mit grok 1.0.41). Der Chat zeigt die abgelehnte Tool-Zeile und danach nichts mehr, und Groks Modell sieht EYAS’ Begründung nicht; frage also ohne diesen Schritt erneut. Claude Code macht dagegen weiter und bekommt die Begründung.

Dateizugriff. Dateien, die Grok oder Kimi über EYAS lesen oder schreiben, sind auf die Ordner des Gesprächs beschränkt (die Ordner, die die Prüfung noch bestehen, plus den Arbeitsordner), mit aufgelösten symbolischen Links — auch für eine neue Datei unter einem verlinkten Ordner. ..-Ausbrüche, sensible Dateien und, wenn es keinen Ordner gibt, jede Datei werden abgelehnt. Danach greift die Speicher-Policy (Speicher anderer Tools, Obsidian-Vaults, EYAS’ eigener Datenordner und Workspaces anderer Gespräche werden verweigert). Jede Dateioperation wird einmal beurteilt: Ein Lese- oder Schreibzugriff, der schon über die Berechtigungsanfrage des Tool-Aufrufs freigegeben wurde, wird ohne erneute Nachfrage bedient. Teilweises Lesen (Startzeile und Zeilenzahl) wird unterstützt.

Hintergrundarbeit. Grok und Kimi werden für EYAS-Hintergrundaufrufe (Titel, der Security-Judge usw.) nur genutzt, solange ihre Isolation verifiziert ist: Grok, nachdem seine Prüfung beim Laden, Jetzt prüfen oder der Session-Start eines beliebigen Zugs bestanden hat; Kimi erst, nachdem auf diesem Host eine Session gestartet wurde (ein Jetzt prüfen im angemeldeten Zustand startet eine). Ein solcher Aufruf bekommt keine EYAS-Tools, jede Berechtigungs- und Dateianfrage wird abgelehnt, und sein erster Tool-Aufruf beendet ihn. Seine Antwort wird auf das Ausgabelimit begrenzt, das EYAS verlangt (siehe Claude-Code-Modelle und Effort).

Was Grok und Kimi bekommen

EYAS’ System-Prompt, geprüft. Kimi bekommt den EYAS-System-Prompt oben in jeder Nachricht, markiert als EYAS-Systemanweisungen. Grok kann seinen eigenen Default-System-Prompt durch den von EYAS ersetzen, hält aber erst, nachdem das Modell gefragt wurde, fest, welchen Prompt es genutzt hat; EYAS prüft also nach jedem Zug — in seinem eigenen Grok-Home, bevor die Session-Dateien dieses Zugs gelöscht werden. In den ersten Zügen nach dem Start von EYAS oder nachdem das grok-Programm ersetzt wurde, geht der Prompt auf beiden Wegen raus (als Groks System-Prompt und oben in der Nachricht), sodass keine Antwort von einem ungeprüften Weg abhängt. Sobald die Prüfung besteht, schicken spätere Züge ihn nur noch als Groks System-Prompt, und jeder Zug wird erneut geprüft. Hat das Modell ohne EYAS’ Prompt geantwortet, loggt EYAS eine Warnung und schickt den Prompt ab dann oben in der Nachricht (bis zum Neustart oder zu einem neuen grok-Programm). Zu konfigurieren gibt es nichts.
Der ganze Verlauf, Bilder eingeschlossen. Jeder Zug spielt EYAS’ Gesprächsverlauf ab, einschließlich der Bilder früherer Züge an ihrer Stelle. Bilder werden nur übergeben, wenn die installierte CLI zu Beginn jedes Laufs meldet, dass sie Bildeingaben annimmt. Tut sie das nicht, wird jedes Bild durch einen kurzen Hinweis an das Modell ersetzt, etwa [image omitted (image/png): this model cannot see images], damit das Modell weiß, dass eines da war; der Composer warnt vor dem Senden, und der Zug zeigt einen Hinweis (siehe Bilder und Modelle, die sie nicht sehen können). Den ganzen Verlauf samt Bildern abzuspielen kostet in jedem Zug Prompt-Tokens, wie schon bei den API-Anbietern.
Das Vision-Badge folgt der CLI. Das Badge Vision der Modelle von Grok CLI und Kimi Code CLI folgt dem, was die CLI in jedem Zug meldet. Grok CLI 1.0.40 meldet keine Bildeingabe, Grok-CLI-Modelle zeigen Vision also aus. Kimi-Modelle behalten ihren Default, bis der erste Zug meldet. Nach einem Neustart kann ein Modelle aktualisieren vor dem ersten Zug wieder den Default zeigen; der nächste Zug korrigiert das.

Grok-Modelle und Effort

EYAS liest Groks Modelle und die Reasoning-Effort-Stufen, die jedes annimmt, aus der Grok CLI selbst: Es öffnet eine Session in seinem EYAS-Grok-Home, ohne einen Prompt zu senden — also ohne Modellaufruf und ohne Kosten. grok-4.6 und grok-4.7 bieten zum Beispiel low, medium, high und xhigh; grok-4.5 bietet low, medium und high; ein Modell ohne Reasoning-Steuerung bietet keine. Das passiert bei jedem Laden des Anbieters (Start von EYAS, Neuladen des Anbieters) und wenn du Modelle aktualisieren drückst, und entfällt, solange Grok nicht für EYAS angemeldet ist. Ein Modell, das die CLI nicht mehr anbietet, wird markiert und ausgeschaltet, nie gelöscht, und die Effort-Auswahl eines Grok-Modells entspricht dem, was es wirklich annimmt.

In jedem Zug setzt EYAS den gewählten Effort in der Grok-Session, bevor die Nachricht gesendet wird, und liest zurück, welche Stufe Grok angewendet hat. Eine nicht unterstützte Stufe wird zuerst auf die nächstgelegene angenommene verschoben (max läuft auf grok-4.5 als high). Lehnt Grok eine Stufe trotzdem ab, läuft der Zug mit Groks eigener Stufe, und diese hält der Zug fest. Automatisch sendet nichts: Das Modell läuft mit seinem eigenen Default (high bei aktuellen Grok-Modellen), und der Zug hält fest, welche Stufe das war. Die eigene ~/.grok-Konfiguration des Betreibers, einschließlich ihres Default-Efforts, entscheidet nichts. Jeder Grok-Zug hält außerdem das Modell fest, das Grok tatsächlich ausgeführt hat, so wie Grok es meldet.

Kimi-Modelle und Thinking

kimi acp ignoriert die Optionen --model und --thinking; deshalb öffnet EYAS in jedem Zug die Kimi-Session, prüft, dass sie isoliert ist, und stellt sie dann auf das gewählte Modell und die gewählte Thinking-Variante um, bevor der Prompt gesendet wird.

Woher die Modelle kommen. Kimis eigene Modellliste — die Modelle seiner eigenen Konfiguration, etwa kimi-code/kimi-for-coding nach der Kimi-Code-Anmeldung. EYAS liest sie ohne Prompt und ohne Modellaufruf, indem es eine Session in seinem eigenen Kimi-Home öffnet: im Hintergrund bei jedem Laden des Anbieters (nur solange Kimi für EYAS angemeldet ist) und wenn du Modelle aktualisieren klickst. Die Zeilen heißen Kimi Code CLI (<Modellname>). Die Default-Zeile Kimi Code CLI führt das Modell aus, auf das Kimi gerade eingestellt ist.
Thinking pro Modell, nach dem, was Kimi listet. Ein Modell mit einer normalen und einer Thinking-Variante bekommt eine Effort-Wahl An / Aus (Keiner = Thinking aus, Hoch = Thinking an). Ein Modell, das immer denkt, bietet nur Hoch an (Keiner wird Hoch). Ein Modell ohne Thinking bietet keine Effort-Steuerung. Automatisch behält das Thinking, mit dem Kimi gerade läuft, auch wenn das Modell wechselt. Nach jedem Zug liest EYAS zurück, welches Modell und welche Variante tatsächlich liefen, und hält das als tatsächliches Modell und tatsächlichen Effort fest.
Kimi merkt sich die letzte Wahl. Stellt EYAS das Modell um, speichert Kimi es in seiner eigenen Konfigurationsdatei (im Kimi-Home von EYAS, nie in ~/.kimi) und nutzt es ab dann als Default. Die Default-Zeile Kimi Code CLI führt also das Modell aus, das EYAS zuletzt in irgendeinem Gespräch gewählt hat. Für eine stabile Wahl nimm ein bestimmtes Kimi-Modell.
Bevor die Liste gelesen ist (noch nicht angemeldet oder das Lesen scheiterte), sagt das Anbieter-Panel: EYAS hat die Modellliste von Kimi noch nicht gelesen und kann daher weder ein Modell festlegen noch das Denken ein- oder ausschalten: Kimi führt das Modell aus, auf das es selbst eingestellt ist. Melde Kimi für EYAS an und klicke dann auf „Modelle aktualisieren“. In diesem Zustand sendet EYAS keine Modell- oder Thinking-Wahl.
Ein Modell, das Kimi nicht anbietet, stoppt den Zug vor dem Prompt mit einem Fehler, der sagt, dass Kimi dieses Modell nicht anbietet. Es wird nie still durch ein anderes Modell ersetzt.
Ausgemusterte Zeilen. Die festen Zeilen Kimi Code CLI (K3), (K2.7 Code) und (K2.6) nannten Modelle der Moonshot-API, keine Kimi-CLI-Modelle, und führten immer Kimis Default aus. Nach der ersten Aktualisierung oder Erkennung werden sie als Von der letzten Aktualisierung nicht mehr angeboten markiert und ausgeschaltet (nie gelöscht). Routing-Stufen, Stufen-Fallbacks und der Kimi-Anbieter-Default, die EYAS selbst darauf gesetzt hatte, werden beim Start automatisch auf Kimi Code CLI (die Default-Zeile) umgestellt — das, was sie immer ausgeführt haben. Ein Gespräch oder Agent, den du auf eine davon gepinnt hast, stoppt mit dem Fehler bietet es nicht an; wähle stattdessen eines der erkannten Kimi-Modelle. Auf einer neuen reinen Kimi-Installation startet jede Routing-Stufe auf Kimi Code CLI, ohne Fallback; auch die Opus-/Sonnet-/Haiku-Stufen des Agenten-Assistenten zeigen bei Kimi darauf, und Budget-Downgrades haben keinen Kimi-Code-CLI-Schritt.
Kostenschätzungen. Erkannte Kimi-Code-CLI-Modelle werden zum Default-Satz von Kimi Code CLI bepreist ($0,95 Input / $4 Output pro Million Tokens).

Das ist aus dem Quellcode von kimi-cli 1.52.0 gebaut und noch nicht an einer echten Kimi-Installation verifiziert.

Kernel-Datei-Sandbox

Wenn Claude Code oder Grok CLI ihre eigenen Tools ausführen — die Shell-Befehle von Claude Code; Groks Shell, grep, Dateiauflistung und Lesezugriffe von Subagenten —, sperrt das Betriebssystem selbst diesen Tools das Lesen und Schreiben in:

dem Speicher anderer KI-Werkzeuge (~/.claude, ~/.grok, ~/.codex, ~/.gemini, ~/.kimi, ~/.cursor, ~/.codeium, die Daten von OpenCode), den Obsidian-Vaults, die EYAS kennt, und den Pfaden aus security.foreignMemoryPaths;
EYAS’ eigenen privaten Daten: dem Vault, der Datenbank, den Schlüsseln und den EYAS-Homes anderer CLIs;
den Workspaces anderer Gespräche.

Die eigenen Ordner des Gesprächs bleiben beschreibbar. Die Sandbox ist macOS Seatbelt (eingebaut) oder Linux bubblewrap. EYAS prüft weiterhin jeden Tool-Aufruf, den es sieht; die Sandbox fängt zusätzlich ab, was ein Shell-Befehl auf Wegen erreicht, die EYAS aus dem Befehlstext nicht lesen kann.

CLI	Was in der Sandbox läuft
Claude Code	Jeder Zug mit Tools führt seine Shell-Befehle in der Sandbox aus. Unter Linux braucht es bubblewrap (`bwrap`) und `socat`. Claude Codes eigener Shell-Zustand (`~/.claude/shell-snapshots`, `~/.claude/session-env`) und sein Programmordner bleiben lesbar; der Rest von `~/.claude` ist gesperrt.
Grok CLI	Jeder Zug mit Tools startet Grok unter einem EYAS-Sandbox-Profil, das in `sandbox.toml` in seinem EYAS-eigenen Home geschrieben wird (Name `eyas-<hash>`). Grok kann es nicht lockern. Unter Linux braucht es bubblewrap.
Kimi Code CLI	Hat keine Kernel-Sandbox (Nicht unterstützt).

Hintergrundaufrufe ohne Tools (Titel, Speicherdurchläufe, der Security-Judge) brauchen keine Sandbox und werden nie mangels Sandbox abgelehnt.

security.cliSandbox (config/local.yaml):

auto (Default) nutzt die Sandbox, wo sie verfügbar ist. Wo nicht, führt die CLI ihre Tools trotzdem aus, und der Chat zeigt pro Gespräch einmal einen Hinweis: <CLI> führt seine eigenen Werkzeuge auf diesem Server ohne Kernel-Datei-Sandbox aus. EYAS prüft weiterhin jeden Werkzeugaufruf, den es sieht; die Anbietereinstellungen zeigen den Grund. In auto kann Claude Code darum bitten, einen einzelnen Befehl außerhalb der Sandbox auszuführen (etwa einen, der ~/.npm braucht). Ein solcher Befehl wartet immer auf die Freigabe eines Menschen in der Warteschlange Ausstehende Freigaben — nie auf den KI-Judge, nie auf die Autonomie-Leiter —, dort erklärt als Ein Shell-Befehl will außerhalb der Kernel-Datei-Sandbox laufen …. Die Freigabe lässt genau diesen Befehl einmal laufen; autonome Läufe parken darauf.
required lehnt einen CLI-Zug mit Tools ab, bevor die CLI startet, wenn keine Sandbox verfügbar ist: <CLI> wurde nicht gestartet: Deine Einstellungen verlangen eine Kernel-Datei-Sandbox für die eigenen Werkzeuge der CLI (security.cliSandbox: required), und auf diesem Server ist dafür keine verfügbar. Der Zug wird nicht wiederholt und an kein anderes Modell übergeben, und Kimi-Züge mit Tools werden immer abgelehnt. Mit required kann Claude Code nie einen Befehl außerhalb der Sandbox ausführen (seine Bitte wird ignoriert), und es startet nicht, wenn die Sandbox nicht starten kann.
Ein off gibt es nicht. Jeder andere Wert ist ein Konfigurationsfehler: EYAS startet nicht, und die Fehlermeldung nennt security.cliSandbox.

Wo du es siehst. Das Panel eines CLI-Anbieters hat eine Zeile Kernel-Datei-Sandbox: Aktiv, Auf diesem Server nicht verfügbar mit dem Grund (bubblewrap nicht installiert; socat nicht installiert; bubblewrap kann hier keine Sandbox erstellen, meist weil User-Namespaces deaktiviert sind; nicht unterstütztes Betriebssystem) oder Nicht unterstützt (Kimi). Sie zeigt außerdem den Hinweis zu required und, für Claude Code in auto, Ein Befehl, der außerhalb der Sandbox laufen will, wartet immer auf deine Freigabe. eyas doctor hat eine Zeile CLI sandbox (siehe CLI), und Sicherheitsereignisse zeigt den Status jeder eingeschalteten CLI (siehe Sicherheit & Datenschutz). GET /api/v1/model/providers und GET /api/v1/model/providers/:id tragen fileSandbox {status: active|unavailable|unsupported, reason, mode} für claude-code, grok-cli und kimi-cli.

Docker und Kubernetes. Das EYAS-Image enthält bubblewrap nicht (es steht unter LGPL, die Installation ist also Sache des Betreibers). Ein Linux-Host oder -Container braucht für die Kernel-Schicht bubblewrap (und socat für Claude Code) plus unprivilegierte User-Namespaces. Ohne sie lehnt EYAS trotzdem jede Anfrage ab, die es sieht, und zeigt Nicht verfügbar; mit required werden CLI-Züge mit Tools abgelehnt. Siehe Docker und Kubernetes.

Grenzen. Unter Linux deckt Groks Sperrliste die Dateien ab, die es beim Start der Session gibt. Ein Vault, der nur an seinem .obsidian-Ordner erkannt wird, kommt hinzu, sobald EYAS einem Pfad darin begegnet ist (ein registrierter Vault oder ein Eintrag in security.foreignMemoryPaths zählt immer). Kimi hat keine Kernel-Schicht.

Nachgewiesene CLI-Versionen

Jede CLI-Version, die EYAS unterstützt, wird vor dem Release geprüft: EYAS führt die echte Claude Code und Grok CLI (und Kimi Code CLI, wo sie installiert ist) über seine eigenen Anbieter in einem Wegwerf-Home voller Fallen aus (Host-Einstellungen, die alles erlauben, Hooks und MCP-Server, die eine Spur hinterlassen würden, CLAUDE.md, AGENTS.md, Skills, ein Vault im Obsidian-Stil) und weist nach, dass nichts davon geladen wird, dass EYAS’ Speicher-Policy und die Kernel-Sandbox den Vault und EYAS’ Datenordner fernhalten und dass ein abgelehnter Lesezugriff auf Speicher außerhalb von EYAS abgelehnt bleibt. Die Einzelheiten stehen unter Sicherheit & Datenschutz — Wie die Isolation nachgewiesen wird.

CLI	Zuletzt nachgewiesene Version
Claude Code	2.1.281
Grok CLI	1.0.41
Kimi Code CLI	Noch nicht nachgewiesen

Prüfe deine Installation mit eyas doctor. Es hat pro CLI eine Zeile CLI isolation — CLI isolation (Claude Code), CLI isolation (Grok CLI), CLI isolation (Kimi Code CLI). Jede zeigt das Binary, das EYAS ausführt: wie es gefunden wurde (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN, claude/grok/kimi on PATH oder SDK-bundled), seinen Pfad und seine Version, und dann:

isolation proven on this version (<Datum>) — in Ordnung;
eine Warnung, wenn die Version von der zuletzt nachgewiesenen abweicht, wenn das Binary keine Version meldet oder wenn die CLI nie nachgewiesen wurde (heute Kimi). Die Warnung ergänzt, dass EYAS weiterhin jede Session beim Start prüft: Die Prüfungen auf dieser Seite laufen mit jeder installierten Version;
not installed — in Ordnung. Ein ungültiges EYAS_*_BIN ist ein Fehler, mit Abhilfe.

Für Grok und Kimi prüft die Zeile außerdem ihr EYAS-Home, <Datenverzeichnis>/cli-homes/<Anbieter>:

noch nicht angelegt — in Ordnung, der erste Lauf legt es an;
ein symbolischer Link oder kein Ordner — ein Fehler: EYAS weigert sich, die CLI auszuführen; entferne es, der nächste Lauf legt es neu an;
für andere Benutzer lesbar — eine Warnung, weil es die Anmeldung der CLI enthält; Abhilfe: chmod 700 <Ordner>;
eine Datei, die EYAS dort verwaltet (Groks config.toml, requirements.toml, trusted_folders.toml; Kimis mcp.json und EYAS’ Schlüssel in config.toml), hat sich geändert, seit EYAS sie geschrieben hat — eine Warnung. EYAS schreibt diese Dateien vor dem nächsten Lauf neu; eine Änderung zwischen zwei Läufen bedeutet also, dass etwas anderes diesen Ordner bearbeitet.

Doctor liest nur: Er führt lediglich --version aus. Siehe CLI — Was doctor prüft.

Derselbe Chat bei jedem Anbieter

Ein Gespräch sieht gleich aus, egal welcher Anbieter antwortet.

Live-Text. Claude Code tippt seine Antwort und sein Thinking live aus, während das Modell sie schreibt, wie die API-Anbieter.
Eine Zeile pro Tool-Aufruf, mit dem gemeinsamen Namen. Tool-Zeilen nutzen die Namen, die EYAS bei jedem Anbieter nutzt — read_file, run_command, edit_file, write_file, grep, glob, web_fetch, web_search —, Datei-Edits und -Schreibvorgänge erscheinen also überall als Diff. EYAS’ eigene Tools erscheinen unter ihren schlichten Namen (memory_search, nicht mcp__eyas__memory_search). Bei Grok und Kimi zeigt die Zeile nicht den freien Titel der CLI.
Eingabe, Ausgabe und Dauer. Eine Zeile zeigt, worum das Tool gebeten wurde (die Datei, der Befehl, die Suche, bei einem Edit Pfad sowie alter und neuer Text), was es zurückgab — sehr lange Ausgabe wird bei 64 KiB abgeschnitten und als gekürzt markiert — und wie lange es dauerte.
Eine Zeile schließt erst, wenn das Tool fertig ist. Sie wird nie vorab als erledigt markiert: Ein Aufruf, der scheitert oder vom Tool-Budget übersprungen wird, erscheint als fehlgeschlagen, mit dem Fehler.
Abgelehnte Aufrufe erscheinen nicht als erfolgreich. Ein Aufruf, den EYAS abgelehnt hat — durch das Security-Gate, durch die Speicher-Policy, während er auf eine Freigabe wartet oder als Wiederholung einer Aktion, die ein fortgesetzter Lauf schon ausgeführt hat —, zeigt seinen eigenen Status (Abgelehnt, Freigabe nötig, Übersprungen) mit EYAS’ Begründung, nie einen grünen Haken. Aufrufe, nach denen eine CLI fragt, nachdem das Tool-Aufruf-Limit erreicht ist, werden als übersprungen festgehalten. Ein Aufruf, der eine Freigabe braucht, löst eine Freigabekarte im Gespräch und einen Eintrag in Ausstehende Freigaben aus. Siehe Gespräche — Tool-Zeilen.
Das Rundenlimit behält die Antwort. Erreicht ein Zug sein Rundenlimit, wird die bis dahin geschriebene Antwort behalten und als Antwort gespeichert; der Zug endet als Rundenlimit erreicht, nicht als Fehler. Ein echter Fehlschlag erscheint weiterhin als Fehler, und auch dann bleibt die Teilantwort erhalten.
Ein Ende pro Zug. Eine Antwort wird bei jedem Anbieter genau einmal gespeichert und angezeigt.
Derselbe Laufbaum. Die Ansicht Run tree / Workflow eines Gesprächs erscheint bei jedem Anbieter, API und CLI, mit dem aktuell laufenden Tool, dem Rundenzähler (bei einer CLI ihre eigenen internen Schritte), Tokens und den Kosten des Laufs. Siehe Gespräche — Run tree.
Kompaktierung schreibt keinen Speicher. Kompaktiert eine CLI während eines langen Zugs ihren eigenen Kontext, zeigt der Zug einen Hinweis Kontext verdichtet, und nichts wird in den EYAS-Speicher geschrieben. Den EYAS-Speicher füttert nur EYAS.
Fehlermeldungen nennen die richtige CLI. Ein Kimi-Fehler sagt Kimi Code CLI, nie Grok CLI.

Warum ein Zug endete. Jeder API-Anbieter hält dieselben Gründe fest: fertig, Tool-Nutzung, Ausgabelimit erreicht, Stop-Sequenz oder abgelehnt. Abgelehnt umfasst Anthropics Refusal, OpenAIs Content-Filter und die Ablehnungsnachricht des Modells, Geminis sicherheitsbedingte Stopps (Safety, verbotene Inhalte, Blocklist, Recitation, personenbezogene Daten, Bildsicherheit) und einen Prompt, den Gemini direkt blockiert hat. Eine OpenAI-Ablehnungsnachricht wird als Antwort des Assistenten gezeigt statt einer leeren Antwort. Eine am Ausgabe-Token-Limit abgeschnittene Antwort gilt als max tokens, und ein so abgeschnittener Tool-Aufruf wird nie ausgeführt. Der Chat zeigt diese Ergebnisse als Badge unter der Antwort — siehe Gespräche — Zugergebnis.

Token-Zahlen bedeuten bei jedem Anbieter dasselbe, CLIs eingeschlossen: Input-Tokens sind die Prompt-Tokens, die nicht aus dem Cache des Anbieters kamen; Cache-Reads (und bei Anthropic Cache-Writes) werden getrennt gezählt; Reasoning- bzw. Thinking-Tokens gehören zu den Output-Tokens. Ein Zug, für den der Anbieter keine Nutzung gemeldet hat, wird als Nutzung nicht gemeldet markiert und zeigt keinen Preis; sein Trace wird nie aus Platzhalter-Tokenzahlen bepreist. Observability zählt auch die Tools, die eine CLI in ihrer eigenen Schleife ausgeführt hat — Züge von Claude Code, Grok CLI und Kimi Code CLI zeigen nicht mehr 0 Tool-Aufrufe. Siehe Observability — Usage.

Tool-Aufrufe

Bei API- und lokalen Anbietern führt EYAS die Tool-Schleife selbst: Das Modell fordert ein Tool an, EYAS führt es aus, schickt das Ergebnis zurück, und das Modell setzt seine Antwort fort. Jeder Aufruf erscheint als eine Live-Zeile im Gespräch.

Anbieter	Was du erwarten kannst
Anthropic, Anthropic-kompatible Endpunkte (MiniMax, Synthetic, Xiaomi MiMo, …)	EYAS-Tools laufen, auch die Speicher-Tools. Mit eingeschaltetem Reasoning — jede Effort-Stufe oder ein Modell, bei dem es immer an ist — geht das signierte Reasoning des Modells (auch geschwärztes Reasoning) unverändert in der nächsten Anfrage derselben Antwort zurück, Züge mit Tools und Reasoning funktionieren also zuverlässig. Anthropic-kompatible Anbieter melden auch gecachte Input-Tokens für gestreamte Antworten.
OpenAI	EYAS-Tools laufen, auch die Speicher-Tools
Gemini	EYAS-Tools laufen, auch die Speichersuche. Geminis Reasoning-Signatur geht mit jedem Tool-Aufruf zurück, sodass neuere Gemini-Modelle ihr Reasoning über eine Tool-Schleife hinweg behalten. Ein Tool, das einen Fehler meldet, geht als Fehler an Gemini. Geminis Gedanken-Zusammenfassungen erscheinen im Gespräch als Reasoning, nie im Antworttext oder in der gespeicherten Antwort.
OpenAI-kompatible Endpunkte, Kimi API, OpenRouter	EYAS-Tools laufen. Ein Backend, das ein normales stop meldet und zugleich Tools anfordert, beendet die Schleife nicht vorzeitig — die angeforderten Tools laufen. Reasoning-Text, den diese Backends zurückgeben (etwa der von DeepSeek reasoner), erscheint als Thinking und wird nie mit der Antwort vermischt. Kimi API und OpenRouter bekommen ihr eigenes Reasoning in den Tool-Aufruf-Runden derselben Antwort zurück, wie sie es verlangen.
LM Studio	Nutzt dieselbe OpenAI-kompatible Verbindung wie die Anbieter darüber; Tool-Aufrufe und ihre Ergebnisse (auch die Speichersuche) erreichen das Modell über Standard-Function-Calling.
Ollama	EYAS-Tools laufen. Jedes Tool-Ergebnis trägt den Namen des Tools, damit das Modell bei mehreren Aufrufen weiß, welches Ergebnis zu welchem Aufruf gehört. Das Reasoning eines denkenden Modells streamt als Thinking, getrennt von der Antwort.
Claude Code CLI, Grok CLI, Kimi Code CLI	Die CLI führt die Schleife; EYAS-Tools erreichen sie über MCP — siehe MCP

Reasoning bleibt bei seinem Anbieter. Das in einer Tool-Schleife zurückgespielte Reasoning (Anthropic-Familie, Kimi API, OpenRouter) gilt nur innerhalb einer Antwort: Es wird nicht mit dem Gespräch gespeichert und nicht in späteren Zügen gesendet. Fällt ein Zug auf einen anderen Anbieter zurück, wird das Reasoning für diesen Anbieter verworfen, und die Antwort geht ohne es weiter. Wird ein gestoppter oder gescheiterter Hintergrundlauf ab seinem letzten Checkpoint fortgesetzt, beginnt das Modell sein Reasoning einmal neu. Reasoning wird nie an einen anderen Anbieter oder ein anderes Modell gesendet, nicht einmal als Text; die native OpenAI-Verbindung schickt Reasoning überhaupt nie zurück.

Eine Zeile pro Tool-Aufruf. Manche OpenAI-kompatiblen Backends — oft lokale Server — streamen einen Tool-Aufruf ohne Call-Id. So ein Aufruf erscheint als genau eine Tool-Zeile. Das gilt für OpenAI, OpenAI-kompatible Anbieter, Kimi API, OpenRouter und LM Studio.

Modelle ohne Tools. Ein Modell, das in der Modellliste als ohne Tool-Unterstützung markiert ist — zum Beispiel ein Ollama-Modell, dessen Server keine Tool-Fähigkeit meldet, oder ein Modell, bei dem du die Tool-Unterstützung abgeschaltet hast —, bekommt keine Tools und keine Tool-Liste im Prompt. Fordert es trotzdem ein Tool an, führt EYAS es nicht aus, und der Zug endet mit dem Text des Modells. Sein Prompt fordert es auch nicht mehr auf, Tools aufzurufen: Die Speicher- und Grounding-Regeln sagen, dass das, was EYAS abgerufen hat, im <eyas-memory>-Block ankommt und dass es nicht weitersuchen kann, und es bekommt keine Skill-Liste und keine Agentenliste, die nur über Tool-Aufrufe funktionieren. Siehe Prompts — Der Speicher-Vertrag.

Bilder und Modelle, die sie nicht sehen können

Welche Modelle Bilder sehen können, kommt aus dem Modellkatalog: dem Badge Vision in der Modellliste. Bei Grok CLI und Kimi Code CLI folgt das Badge dem, was die installierte CLI meldet.

Kann das Modell des Gesprächs keine Bilder sehen, erreicht jedes angehängte Bild das Modell als kurzer Hinweis an seiner Stelle ([image omitted (image/png): this model cannot see images]). Das Modell weiß, dass ein Bild da war, aber nicht, was es zeigt. Der Zug wird nicht abgelehnt.
Unter diesem Zug erscheint ein Hinweis: Bilder nicht an das Modell übergeben (N): <Modell> kann keine Bilder sehen … Er wird mit der Antwort gespeichert und ist also auch nach einem Neuladen noch da. Die Zählung umfasst Bilder aus früheren Zügen; auf einem solchen Modell erscheint der Hinweis daher bei jedem Zug, solange das Gespräch Bilder enthält.
Der Composer warnt vor dem Senden: Mit einem angehängten Bild und einem Modell, das keine Bilder sehen kann, sagt ein Chip über der Eingabe <Modell> kann keine Bilder sehen: Es erfährt nur, dass ein Bild angehängt ist. Im God-Modus erscheint der Chip nicht; bei einem Gespräch mit automatischem Routing richtet er sich nach dem für das Gespräch angezeigten Modell (der Stufe Standard).
Hat EYAS keine Katalogangaben zu einem Modell, werden Bilder unverändert gesendet, und der Anbieter entscheidet. Wechsle zu einem Modell mit dem Badge Vision, damit Bilder gelesen werden.
Claude Code sieht die Bilder früherer Züge eines Gesprächs, nicht nur die der letzten Nachricht: Jeder Zug sendet alle früheren Bilder erneut, genau wie die API-Anbieter; bildlastige Gespräche senden also größere Prompts.

Prompt-Caching (Anthropic-API)

Beim Anbieter Anthropic-API (direkter API-Schlüssel) ist Prompt-Caching automatisch — eine Einstellung gibt es nicht.

System-Prompt. Der System-Prompt von EYAS ändert sich nicht von Zug zu Zug, weil die aktuelle Uhrzeit und der abgerufene Speicher mit deiner aktuellen Nachricht reisen. EYAS markiert den System-Prompt (zusammen mit den Tool-Definitionen davor) daher zum Caching, und jeder spätere Zug und jeder Tool-Schritt liest ihn aus Anthropics Cache zurück.
Früheres Gespräch. Auch das Gespräch bis zu deiner aktuellen Nachricht wird markiert, sodass der nächste Zug es zurückliest, statt erneut den vollen Preis zu zahlen.
Tool-Schritte. In einem Zug mit Tools liest jeder Tool-Schritt die vorherige Anfrage zurück.
Lebensdauer und Kosten. Der Cache hält 5 Minuten und wird von jeder Anfrage, die ihn nutzt, aufgefrischt; nach einer längeren Pause schreibt die erste Anfrage ihn neu. Ein Cache-Write kostet das 1,25-Fache des normalen Input-Preises; ein Read etwa das 0,1-Fache (oder den eigenen veröffentlichten Cache-Read-Satz des Modells, bei manchen neueren Modellen niedriger). Prompts, die kürzer sind als die minimale cachebare Länge des Modells (je nach Modell 512 bis 4096 Tokens), werden einfach nicht gecacht.
Wo du es siehst. Token-Nutzung und Kosten zeigen für Aufrufe der Anthropic-API Cache-Read- und Cache-Write-Tokens.
Anthropic-kompatible Endpunkte von Drittanbietern bekommen keinen Caching-Parameter, weil ein solcher Endpunkt ihn ablehnen kann. Claude Code verwaltet sein Caching selbst.

Lokale Runtimes

LM Studio

Temperatur, maximale Ausgabe-Tokens und Stop-Sequenzen aus Gespräch oder Agent werden wie eingestellt gesendet. Ist nichts gesetzt, gilt der Default des Modells in LM Studio.
Eine Anfrage ohne Modellnamen fragt nach dem Modell, das LM Studio gerade geladen hat. Das an einer Antwort angezeigte Modell ist die Id, die LM Studio meldet.
Aufrufe nutzen den Standard-Timeout des Clients (10 Minuten), und eine abgebrochene Verbindung wird wiederholt.
LM_STUDIO_URL (Default http://localhost:1234) darf mit einem Schrägstrich enden.
Das Reasoning bleibt LM Studios eigene Einstellung: EYAS sendet nie einen Reasoning- oder Effort-Parameter, und das Panel zeigt pro Modell die Einstellung, die LM Studio meldet (siehe Wie jeder Anbieter die Effort-Stufe anwendet).

Ollama

Modelle aktualisieren liest die Fähigkeiten jedes Modells vom Ollama-Server — beim Laden, im Hintergrund und bei der Aktualisierung —, sodass Modelle ohne Tool-Unterstützung entsprechend markiert werden und denkende Modelle ihre Thinking-Steuerung bekommen (siehe Wie jeder Anbieter die Effort-Stufe anwendet). Ein älteres Ollama, das keine Fähigkeiten meldet, behält Tools an.
Ollamas Default-Kontext sind 4096 Tokens. Braucht eine Anfrage samt Antwort mehr, setzt EYAS num_ctx auf die nächste Zweierpotenz (8192, 16384, …), gedeckelt beim Kontextfenster des Modells aus der Modellliste. Kleine Anfragen lassen Ollamas Default unberührt. OLLAMA_CONTEXT_LENGTH gilt weiterhin, wann immer EYAS num_ctx nicht setzt. Ein größeres num_ctx erhöht Ollamas Speicherbedarf nur für die Anfragen, die es brauchen.

Stopp bricht die lokale Generierung ab. Bei LM Studio und Ollama beendet Stopp die laufende Generierung sofort — die GPU ist frei, sobald du stoppst.

Kontextfenster

EYAS baut den Prompt jedes Zugs für das Modell, das ihn beantwortet. Das Fenster kommt aus der Modellliste (dem Kontextgrößen-Badge an jedem Modell), auch bei CLI-Modellen: Ein Claude-Code-Modell, das mit 1M-Fenster gelistet ist, nutzt 1M. Claude Code listet 1M nur für die eigenen 1M-Varianten der Laufzeit (zum Beispiel Opus (1M context)); seine Einträge Fable, Opus, Sonnet und Haiku listen 200k, auch bevor die Laufzeit ihre Modelle gemeldet hat, sodass Kontextgrößen-Badge, Kontextleiste und Prompt-Bemessung vom ersten Start an übereinstimmen. Die bekannten Fenster der CLIs — Claude Code 200k, Grok 500k, Kimi 256k — sind nur der Fallback für ein Modell, für das die Liste kein Fenster hat, und ein Modell, über das nichts bekannt ist, nutzt 200k. Größere Fenster geben den anpassbaren Prompt-Abschnitten mehr Platz; kleine lokale Modelle bekommen einen Prompt, der Raum für das Gespräch lässt. Siehe Prompts — auf das Modell zugeschnitten.

Die Kontextleiste des Gesprächs nutzt dasselbe Fenster und, wo der Anbieter sie meldet, die echte Prompt-Größe des letzten Modellaufrufs (Anthropic und Anthropic-kompatibel, die OpenAI-Familie einschließlich OpenRouter, Kimi API und LM Studio, Gemini, Claude Code). Meldet die Laufzeit das Fenster des Modells, das geantwortet hat (Claude Code tut das), gewinnt dieses gegenüber der Modellliste. Ollama, Grok CLI und Kimi Code CLI melden keine brauchbare Prompt-Größe pro Aufruf; ihre Leiste ist daher eine Schätzung. Siehe Gespräche — Kontext-Zusammenstellung.

Datenschutz: was jeder Anbieter bekommt

Die Datenschutzrichtlinie maskiert personenbezogene Daten auf dem Weg zu einem Modell, pro Versuch und pro Ziel. Ob ein Anbieter als lokal gilt (Text geht unmaskiert hinaus), hängt vom Endpunkt-Host ab, an den er sendet — nie vom Namen des Anbieters:

Lokal: ein Loopback-Endpunkt (localhost, 127.x.x.x, ::1) oder ein Host, der in der Datenschutzrichtlinie als lokaler Host eingetragen ist. Ein lokales Ollama oder LM Studio ist lokal.
Entfernt (maskiert): alles andere — ein entferntes OLLAMA_HOST, nicht eingetragene LAN-Hosts, Cloud-APIs und jeder CLI-Anbieter (Claude Code, Grok CLI, Kimi Code CLI), weil EYAS nicht sehen kann, wohin eine CLI ihren Verkehr schickt.

Fällt ein Aufruf auf einen anderen Anbieter zurück, wird jeder Versuch für sein eigenes Ziel maskiert. Hast du dich darauf verlassen, dass ein entfernter Ollama-Host ausgenommen ist, trag diesen Host bei den lokalen Hosts der Richtlinie ein. Speicher-Tool-Ergebnisse, die eine CLI über die EYAS-Tool-Bridge holt, werden genauso maskiert. Eine neue Nachricht, die du sendest und die einen Wert der Klasse block trägt (etwa eine IBAN), wird vor dem Speichern abgelehnt, wenn sie an ein entferntes Modell ginge — CLI-Anbieter eingeschlossen —, mit dem Angebot, sie maskiert zu senden. Der eingebaute OpenAI-Anbieter widerspricht außerdem bei jeder Anfrage OpenAIs Stored Completions. Siehe Sicherheit & Datenschutz.

Felder und Steuerelemente

Anbieter-Panel

Abschnitt	Bedeutung
● Aktiv	Badge neben dem Panel-Titel: Der Anbieter ist eingeschaltet und läuft; sonst steht dort Inaktiv
Authentifizierung	API-Schlüssel, die Claude-Code-Anmeldung auf diesem Rechner oder die Karte Für EYAS anmelden (Grok CLI, Kimi Code CLI)
CLI-Auth (Claude Code)	Kein API-Schlüssel nötig. Claude Code teilt nur seine Anmeldung mit diesem Server: Melde dich mit der `claude` CLI als der Benutzer an, unter dem EYAS läuft. Claude Code ist erst verfügbar, wenn diese CLI angemeldet ist.
Zeile zur Claude-Code-Isolation	EYAS führt Claude Code isoliert aus: Es werden keine CLAUDE.md, Einstellungen, Hooks, Skills, MCP-Server oder Auto-Memory des Hosts geladen, und unter ~/.claude/projects bleibt kein Transkript zurück. Nur die Anmeldung wird mit dem Host geteilt. Sie verweist für Host-`CLAUDE.md`-Inhalte auf Einstellungen → System → Datenportabilität → Daten importieren.
Für EYAS anmelden	Nur Grok CLI / Kimi Code CLI — Mit Gerätecode anmelden, Stattdessen API-Schlüssel verwenden (Grok), Abbrechen, Abmelden — siehe Grok und Kimi für EYAS anmelden
Kernel-Datei-Sandbox	Claude Code / Grok CLI / Kimi Code CLI — Aktiv, Auf diesem Server nicht verfügbar (mit Grund) oder Nicht unterstützt, dazu der Hinweis zu `required` und, für Claude Code in `auto`, Ein Befehl, der außerhalb der Sandbox laufen will, wartet immer auf deine Freigabe. — siehe Kernel-Datei-Sandbox
Kimi-Modellhinweis	Kimi Code CLI, bis EYAS Kimis Modellliste gelesen hat: EYAS hat die Modellliste von Kimi noch nicht gelesen und kann daher weder ein Modell festlegen noch das Denken ein- oder ausschalten …
API-Schlüssel-Felder	Verschlüsselt in den Geheimnissen gespeichert; Schlüssel gespeichert / Kein Schlüssel / Schlüssel entfernen
Modellliste	Einzelne Modelle an/aus; Badges Tools / Vision / Kontextgröße; Läuft als <Modell>, wenn das konkrete Modell von der Zeilen-Id abweicht; Von der letzten Aktualisierung nicht mehr angeboten an Zeilen, die die letzte Aktualisierung nicht zurückgab; eine Zeile Denken mit den Effort-Stufen und dem Default des Modells und woher die Fakten stammen (vom Anbieter gemeldet / EYAS-Katalog, geprüft am …); bei LM Studio die Reasoning-Einstellung, die LM Studio meldet
Modelle aktualisieren	Lädt die Modellliste des Anbieters neu (jeder Anbieter). Bei einem Fehler: Aktualisierung fehlgeschlagen. Die Modellliste blieb unverändert.

Die Panels von Claude Code CLI, Grok CLI und Kimi Code CLI zeigen außerdem die Zeile Laufzeit und den Block Isolation, mit Jetzt prüfen für Grok und Kimi — siehe Laufzeit und Isolation im Anbieter-Panel unter Isolationsprüfung vor jedem Zug. Ihre Kartenuntertitel lauten Claude Code CLI, von EYAS isoliert ausgeführt, Grok CLI im eigenen EYAS-Home (ACP) und Kimi Code CLI im eigenen EYAS-Home (ACP).

Anbieter

Wann du es brauchst

Typischer Ablauf

Funktionen

Eingebaute Anbieter (wie auf den Karten)

Gesprächskontinuität

Modelle und Modelle aktualisieren

Reasoning-Effort

Wie jeder Anbieter die Effort-Stufe anwendet

Claude-Code-Laufzeit

Claude-Code-Modelle und Effort

Claude-Code-Isolation

Grok CLI und Kimi Code CLI

Isolationsprüfung vor jedem Zug

Was Grok und Kimi bekommen

Grok-Modelle und Effort

Kimi-Modelle und Thinking

Kernel-Datei-Sandbox

Nachgewiesene CLI-Versionen

Derselbe Chat bei jedem Anbieter

Tool-Aufrufe

Bilder und Modelle, die sie nicht sehen können

Prompt-Caching (Anthropic-API)

Lokale Runtimes

Kontextfenster

Datenschutz: was jeder Anbieter bekommt

Felder und Steuerelemente

Anbieter-Panel

Verwandte Tabs

Verwandt

Anbieter

Wann du es brauchst

Typischer Ablauf

Funktionen

Eingebaute Anbieter (wie auf den Karten)

Gesprächskontinuität

Modelle und Modelle aktualisieren

Reasoning-Effort

Wie jeder Anbieter die Effort-Stufe anwendet

Claude-Code-Laufzeit

Claude-Code-Modelle und Effort

Claude-Code-Isolation

Grok CLI und Kimi Code CLI

Grok und Kimi für EYAS anmelden

Isolationsprüfung vor jedem Zug

Was Grok und Kimi bekommen

Grok-Modelle und Effort

Kimi-Modelle und Thinking

Kernel-Datei-Sandbox

Nachgewiesene CLI-Versionen

Derselbe Chat bei jedem Anbieter

Tool-Aufrufe

Bilder und Modelle, die sie nicht sehen können

Prompt-Caching (Anthropic-API)

Lokale Runtimes

Kontextfenster

Datenschutz: was jeder Anbieter bekommt

Felder und Steuerelemente

Anbieter-Panel

Verwandte Tabs

Verwandt