Providerek

Mire való. A provider az LLM backend, amit ez a példány hívhat: felhő API, host CLI (Claude Code, Grok, Kimi) és lokális runtime (Ollama, LM Studio, vLLM). Bekapcsolod, kulcsot tárolsz, modelleket választasz, a routing ezt használja. Ez az oldal azt is leírja, hogyan tartja távol az EYAS a CLI-ket a gép saját beállításaitól: a Claude Code mindig izoláltan fut, a Grok és a Kimi a saját EYAS home-jában fut, és az EYAS számára kell bejelentkeztetni őket, egy kör pedig leáll, ha az EYAS nem tudja megerősíteni ezt az izolációt.

Útvonal: /providers. Alcím: AI-útválasztás, provider-beállítások és költségkeret. Fülek: Útválasztási szintek · Providerek · Költségkeret · AI-elemzés.

Mikor használd

Setup után: provider Be, API-kulcs, modellek.
Hoston van claude / grok / kimi, kulcs nélküli CLI provider kell.
A Grok CLI vagy a Kimi Code CLI Bejelentkezés szükséges jelzést mutat — jelentkeztesd be az EYAS számára (lásd Bejelentkezés a Grokba és a Kimibe az EYAS számára).
Az EYAS egy CLI adott telepítését futtassa (EYAS_CLAUDE_CODE_BIN, EYAS_GROK_BIN, EYAS_KIMI_BIN) — lásd Claude Code runtime és Grok CLI és Kimi Code CLI.
Egy kör CLI-izolációs hibával állt le, és tudni akarod, mit kell a hoston megváltoztatni.
Frissítetted a Claude Code-ot, a Grok CLI-t vagy a Kimi Code CLI-t, és tudni akarod, hogy az EYAS izolációja bizonyított-e azon a verzión (lásd Bizonyított CLI-verziók).
Egy CLI provider panelje szerint a Kernel fájl-sandbox ezen a szerveren nem érhető el, vagy azt akarod, hogy a CLI-körök megköveteljék (lásd Kernel fájl-sandbox).
Egy modellsor A legutóbbi frissítés már nem kínálta jelzést mutat, vagy tudni akarod, melyik konkrét modellt futtatja egy sor.
Tudni akarod, milyen reasoning-effort szinteket kínál egy modell, mit jelent nála az Automatikus, és hogyan alkalmazza a szintet az egyes provider (lásd Reasoning effort és Hogyan alkalmazza az effort-szintet az egyes provider).

Tipikus folyamat

Providerek (/providers) → Providerek fül.
Kártya. Be / Ki a routinghoz. Hitelesítés: API-kulcs (titkosítva a Titkok között); a Claude Code a gépen lévő Claude Code bejelentkezést használja; a Grok CLI és a Kimi Code CLI Bejelentkezés az EYAS számára kártyát mutat.
Modellek engedélyezése. A Modellek frissítése újratölti a provider modellistáját — minden providernél ugyanaz a gomb, API-nál és CLI-nél is. Azokat a modelleket, amelyeket a provider már nem kínál, kikapcsolja és megjelöli, de soha nem törli.
Szintek és költés: Routing és költségkeret.

Funkciók

Minden kártya az azonosítót, az állapotot és a be/ki kapcsolót mutatja.

Elem	Jelentés
Be / Ki	Routinghoz engedélyezés
N/M modell engedélyezve	Hány modell aktív
CLI nem található	Hiányzó host bináris
Nincs API-kulcs	Kulcs kell
Hitelesítési hiba	A hitelesítés elbukott — add meg újra a kulcsot vagy a bejelentkezést
Bejelentkezés szükséges	Piros badge a Grok CLI / Kimi Code CLI kártyán: a CLI nincs bejelentkezve az EYAS számára (tooltip: <CLI>: nincs bejelentkezve az EYAS számára. Nyisd meg a providert a bejelentkezéshez.)

Beépített providerek (a kártyákon)

Provider	Szerep
Anthropic	Claude — azok a modellek, amelyeket az API-kulcsod használhat, az Anthropic modellistájából olvasva (beépített tartalék: Fable 5.1, Fable 5, Opus 5.5, Opus 5, Opus 4.8, Sonnet 5, Sonnet 4.6, Haiku 4.5)
OpenAI	Beépítve GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o, GPT-4o mini; a többit a Modellek frissítése listázza
OpenRouter	Több providert összefogó átjáró (100+ modell)
Gemini	Google Gemini 3.x (a 2.5-ösök egy frissítés után, ahol a kulcsod még hozzáfér)
Kimi	Moonshot API (K3, K2.7 Code, K2.6)
Claude Code CLI	A gépen lévő Claude Code CLI (`claude`), mindig izoláltan — lásd Claude Code izoláció
Grok CLI	ACP (`grok agent --no-leader stdio`) a saját EYAS home-jában — EYAS toolok a CLI MCP hídon
Kimi Code CLI	ACP (`kimi acp`) a saját EYAS home-jában — ugyanazon a hídon
Ollama / LM Studio / vLLM	Lokális runtime-ok — lásd Lokális runtime-ok
xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo Gateway, Vercel AI Gateway, Qianfan, MiniMax, Synthetic, Xiaomi MiMo, …	Felhő API-k a kártyák szerint

Egy név mindenhol. A táblázat nevei azok, amelyeket az EYAS minden képernyőn mutat: a provider kártyákon és paneleken, a routing-szintek provider-választóiban, a beszélgetés modellválasztójában és felső sávjában, a válaszok alatti Válaszolt: sorban, a chat hibaüzeneteiben, egy kolléga modellválasztójában, a Beállítások Modell-hozzárendelések kártyáján, a setup varázslóban, valamint a Grok/Kimi bejelentkezési kártyán és a Kezdőlap-bannerben. A Claude Code mindig Claude Code CLI. A Kimi Code CLI, a Kimi és a kompatibilis providerek (xAI, Mistral, Groq, MiniMax, Xiaomi MiMo, …) a termékük nevét mutatják, soha nem egy azonosítót, mint a kimi-cli. Aki nem olvashatja a modellkatalógust (vendég szerepkör), provider-azonosítókat lát nevek helyett.

API (integrátoroknak). A GET /api/v1/model/providers minden sora és a GET /api/v1/model/providers/:id részletei a termék name nevét és egy kind mezőt hordoznak: cli (Claude Code, Grok CLI, Kimi Code CLI), local (Ollama, LM Studio, vLLM) vagy api (minden hosztolt API és minden ismeretlen azonosító).

Beszélgetés-folytonosság

A beszélgetést az EYAS őrzi, nem a provider. Minden körben a teljes beszélgetést küldi a modellnek a saját tárából. Egyik CLI provider sem tart meg és nem folytat saját sessiont: a Claude Code, a Grok CLI és a Kimi Code CLI minden körben tisztán indul, a korábbi köröket pedig beszélgetés-előzmény blokkban kapja. A Grok és a Kimi mindig új ACP sessiont nyit, korábbit soha nem tölt be.

Így provider- vagy modellváltáskor a beszélgetés megtartja a kontextusát, és egy CLI saját session-tára soha nem forrása sem kontextusnak, sem memóriának. Ugyanez a folytonosság érvényes minden providerre.

A korábbi körökben beillesztett képek a Grok CLI-n és a Kimi Code CLI-n is részei ennek az előzménynek, mindegyik azon a ponton, ahol a beszélgetésben elküldték. Lásd Mit kap a Grok és a Kimi.

A Claude Code által egy körre jelentett költség az adott kör saját költése, és változatlanul adódik hozzá.

Nyers modell API (integrátoroknak). A POST /api/v1/model/complete és a POST /api/v1/model/stream (jogosultság: use Model) validálja a törzset. Elfogadott mezők: provider, model, messages (1–1000 elem; szerep user vagy assistant; a tartalom szöveg vagy szöveg-/képblokkok listája), system, maxTokens (pozitív egész), temperature (0–2), stopSequences (legfeljebb 16) és egy opcionális effort (egy szint none-tól max-ig, vagy auto). Minden más kulcs kimarad, köztük a sessionId, metadata, cwd, isolated, tools és thinking. Ezért ezek a hívások autonómként számítanak (az autonómia-létra érvényes rájuk), nem folytathatnak provider sessiont, és a thinking-nek ott nincs hatása. A válasz és a stream done eseménye effortOutcome-ot hordoz: a kért szintet, a modellnek ténylegesen küldött szintet és a forrását (request). Érvénytelen törzsre 400 a válasz: { error: 'ValidationError', issues }.

Modellek és a Modellek frissítése

A Modellek frissítése megkérdezi a providert, milyen modelleket kínál, és minden sorhoz elmenti a konkrét modellt, amelyet a sor futtat (például a Grok modellazonosítót, vagy az aliast, amelyet a Claude Code használ). A frissítéssel talált modell az EYAS újraindítása után is működik.

Minden modellsor egy kis Futtatott modell: <modell> sort mutat, ha a konkrét modell eltér a sor saját azonosítójától.
A sikeres frissítés nem csak hozzáad. Azt a modellt, amelyet a provider már nem kínál, kikapcsolja, és A legutóbbi frissítés már nem kínálta jelöléssel látja el. Soha nem törli. Ha egy későbbi frissítés újra kínálja, automatikusan visszakapcsolja — kivéve, ha te magad kapcsoltad ki. A megjelölt modellt kézzel is bekapcsolhatod; onnantól a te irányításod alatt marad.
Ha a frissítés elbukik (a provider nem érhető el, nincs bejelentkezve, nincs kulcs), vagy a provider egyetlen modellt sem listáz, semmi nem változik, és a panel ezt írja: A frissítés nem sikerült. A modelllista változatlan maradt. Az OpenAI, a Gemini, az OpenRouter, a Kimi (API) és az OpenAI-kompatibilis endpointok jelzik az ilyen hibát, ahelyett hogy csendben az EYAS beépített modellistáját mutatnák.

Csak modellt megnevező agentek. Az az agent, specialista vagy routing-cél, amely provider nélkül nevez meg egy modellazonosítót, ahhoz a providerhez jut el, amelynek engedélyezett modellistájában az a modell szerepel — például egy frissítéssel talált Grok modellhez vagy egy újabb OpenAI modellhez. A kikapcsolt vagy ismeretlen modell, a kikapcsolt provider modellje, és az a modellazonosító, amelyet két provider is kínál, továbbra is No provider found for model hibával bukik el. Az EYAS soha nem találgat.

Melyik modellt futtatja egy CLI.

Grok CLI: a Grok CLI (<modell>) alapértelmezett sor azt a modellt futtatja, amely a telepített Grok CLI saját alapértelmezése. Minden más Grok sor pontosan azt a modellt futtatja, amelyet megnevez, újraindítás után is. Az a beszélgetés vagy agent, amely olyan Grok modellhez van rögzítve, amelyet a CLI már nem kínál, még azelőtt elbukik, hogy bármit elküldene: Model ‘<id>’ cannot be run by this CLI: Grok CLI does not offer it (the session would run <default>). Válassz másik modellt, vagy frissítsd a listát.
Claude Code: a modellista abból a Claude Code runtime-ból jön, amelyet az EYAS futtat (lásd Claude Code modellek és effort). Minden sor megnevezi a konkrét Claude modellt, amelyet az aliasa futtat, például az opus a claude-opus-5-5-öt. A Claude Code (Default) sor azt a modellt futtatja, amelyet a runtime alapértelmezésként használ. A teljes modellnév is működik.
Kimi Code CLI: a modellista magától a Kimitől jön, és az EYAS minden sessiont átállít az általad választott modellre (lásd Kimi modellek és thinking). A Kimi Code CLI alapértelmezett sor azt a modellt futtatja, amelyre a Kimi épp be van állítva.
Az a modellazonosító, amely nem nevez meg modellt (például csak grok-cli-), egyértelmű hibával buktatja el a kört, ahelyett hogy valami mást futtatna.

API-modellisták.

Anthropic: amikor API-kulcsot adsz meg, az EYAS az Anthropic Models API-jából kiolvassa, milyen modelleket használhat a kulcs. Ez ingyenes listahívás, nem modellhívás, és minden modellhez hozza a kontextusablakot, a kimeneti limitet és az effort-szinteket. Ha a Models API nem érhető el, a beépített lista érvényes. A meglévő telepítések a Modellek frissítése megnyomásáig megtartják a tárolt listájukat; ekkor megjelennek az újabb modellek, például az Opus 5.5, az Opus 5, a Sonnet 5 és a Fable 5.1, a régebbi sorok (Opus 4.7, Opus 4.6) pedig tovább működnek, amíg tárolva vannak.
OpenAI: az első frissítés előtt a beépített lista: GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o és GPT-4o mini. A GPT-4 Turbo már nincs beépítve; a Modellek frissítése továbbra is listázza, ha az OpenAI kínálja. Az EYAS által már ismert, frissítéssel talált modell megtartja a kontextusablakát és a kimeneti limitjét.
OpenRouter: a Modellek frissítése azt is kiolvassa, mely modelleket jelöli az OpenRouter reasoninget támogatónak. A beépített lista: Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.5, Gemini 3.1 Pro preview és GPT-4o.
Kimi API: a Kimi K2.5 már nincs beépítve; csak akkor jelenik meg, ha a Moonshot a Modellek frissítése során még listázza.
Gemini: a beépített lista a jelenlegi 3.x modelleket tartalmazza; a kivezetett gemini-2.0-flash, gemini-2.5-pro-preview-05-06 és gemini-2.5-flash-preview-05-20 megszűnt. A meglévő telepítések a Modellek frissítése megnyomásáig megtartják a régi soraikat; a frissítés kikapcsolja és megjelöli, amit az API már nem kínál. A 2.5-ös család csak akkor jelenik meg egy frissítés után, ha a kulcsod még hozzáfér (a Google a 2.5-öt azokra a projektekre korlátozza, amelyek korábban használták). A modellt meg nem nevező kérés a gemini-3.8-flash-hez megy.
Ollama: ha a provider engedélyezve van és elérhető, az EYAS minden modell képességeit kiolvassa az Ollamából betöltéskor, a háttérben és a Modellek frissítése megnyomásakor. Az Ollama által már nem listázott modellek A legutóbbi frissítés már nem kínálta jelölést kapnak, és egy betöltés után is kikapcsolnak. A kikapcsolt vagy nem elérhető Ollamához az EYAS soha nem fordul.

API (integrátoroknak). A GET /api/v1/model/providers/:id és a GET /api/v1/model/models modellenként visszaadja a realModelId-t, a missing mezőt (true, ha a legutóbbi frissítés már nem kínálta) és az érvényes reasoning-képességet. A POST /api/v1/model/providers/:id/models/refresh visszaadja a missing és a restored listát, vagy 502-t ModelDiscoveryFailed / ModelDiscoveryEmpty hibával.

Reasoning effort

A reasoning effortot az EYAS modellenként dönti el, abban a pillanatban, amikor egy modell ténylegesen válaszol. Ha a modell megváltozik — routing, újrapróbálás vagy tartalék miatt —, az EYAS az új modellhez újra kiszámítja a szintet.

A modell által nem támogatott szintet a legközelebbi támogatottra igazítja. A Maximális olyan modellen, amelynek a teteje a Nagyon magas, Nagyon magas szinten fut; a Nagyon magas olyan modellen, amelyen nincs ilyen, Magas szinten.
Az a modell, amely nem tudja kikapcsolni a gondolkodást, a legalacsonyabb szintjét kapja, ha Nincs szintet kérnek.
Az a modell, amelyről az EYAS-nak nincsenek ellenőrzött adatai, egyáltalán nem kap reasoning-paramétert (Automatikus: a modell saját alapértelmezése). Az EYAS soha nem küld találgatott értéket.
A tokenkeretet fogadó modellek (például a Claude Haiku 4.5 vagy a Gemini 2.5) thinking-kerete a modell saját kimeneti limitjéből méreteződik, és mindig hagy helyet a válasznak, így a Maximális nem lépheti túl a modell limitjét.

A létra. A teljes létra: Nincs, Minimális, Alacsony, Közepes, Magas, Nagyon magas, Maximális, plusz az Automatikus. Az Automatikus az adott helyen semmit nem tárol: a szint ilyenkor a lenti sorrendben lejjebbről jön, és ha semmi nem állít be egyet, semmi nem megy ki, és a modell saját alapértelmezése érvényes.

Honnan jön a szint (az első egyezés nyer):

a beszélgetés saját Erőfeszítés beállítása;
Maximális, ha a beszélgetés Deep módban van;
annak a kollégának (agentnek) az effortja, amelynek nevében a beszélgetés beszél — chatben a beszélgetés kollégájáé, különben a projekt alapértelmezett kollégájáé;
a munkát delegáló legközelebbi beszélgetés szintje (az al-beszélgetés a szülőjétől örököl, legfeljebb öt szinttel feljebb);
a routing-szint alapértelmezése, a szinten át routolt üzenetnél és az EYAS háttérhívásainál (lásd Routing és költségkeret — A szint alapértelmezett effortja);
a modell saját alapértelmezése.

Ugyanez a sorrend érvényes mindenhol, ahol egy kolléga vagy specialista fut: interaktív chatben, egy kolléga home-szálában, háttér- és ütemezett futásokban, újrapróbálásoknál és folytatásoknál (a folytatott futás pontosan azt az effortot használja, amelyet az első futása használt), csapattagoknál, delegált feladatoknál és specialistáknál, pipeline-szakaszokban, A2A-feladatoknál, üzenetküldő csatornák válaszainál és God módban. Egy kolléga saját effortja így a chatjében és a csatornákon is érvényes, a saját effort nélküli csapattag vagy specialista pedig a delegáló beszélgetés szintjét örökli — egy Deep beszélgetés ezért Maximális szintre küldi a specialistáit, ami többe kerül. A saját efforttal rendelkező tag vagy specialista megtartja azt. God módban a beszélgetésen beállított effort minden versenyzőre átmásolódik, a Deep mód pedig öröklődik; ezután minden versenyző szintjét az EYAS a saját modelljéhez igazítja, és a keresztértékelés szavazatai is a beszélgetés effortját használják.

Egy Effort-választó, modellenként. A beszélgetés mezősávja, a kolléga-szerkesztő, minden routing-szint és az ütemezett agent-rutin ugyanazt az Erőfeszítés választót használja. Csak azokat a szinteket listázza, amelyeket az adott modell elfogad — például a Nagyon magas szintet azokon a modelleken, amelyek kínálják (Claude Opus 4.7/4.8/5.x, GPT-5.4/5.5/5.6), a Nincs és a Minimális szintet ott, ahol a modellnek van ilyen. A be/ki modell Ki / Be választást mutat. Az effort-vezérlés nélküli modell, vagy amelyről az EYAS-nak nincsenek ellenőrzött adatai, csak az Automatikust kínálja, és egy tipp megmondja, miért; egy tipp azt is jelzi, ha a modell nem mutatja a gondolkodása szövegét. Auto-routolt beszélgetésben, vagy rögzített modell nélküli kollégánál nincs egyetlen rögzített modell: a választó minden olyan szintet kínál, amelyet legalább egy Auto-routing szint (Gyors, Normál, Összetett, Kódfuttatás) modellje elfogad, és minden üzenet szintje ahhoz a modellhez igazodik, amelyen fut.

Az Automatikus megmondja, mit jelent. Az Automatikus az első bejegyzés, és megnevezi, mire esik vissza az adott helyen: Automatikus · Maximális (Mély), Automatikus · Magas (kolléga), Automatikus · Nagyon magas (delegáló beszélgetés), vagy Automatikus · a modell alapértéke (Közepes) — a modell saját gyártói alapértelmezése.

A lista követi a modellt. Ha egy beszélgetés modellje, Deep módja vagy kollégája megváltozik, a lista frissül. Egy új modell soha nem írja át a beszélgetés tárolt effortját: az új modell által nem kínált szint például így látszik: Nagyon magas → Magas (a(z) Opus 4.6 nem kínálja ezt: Nagyon magas), és az EYAS minden kört igazít és rögzít. A kolléga-szerkesztőben és egy routing-szinten az olyan modell választása, amely nem kínálja a mentett szintet, mentés előtt módosítja a szintet, és ezt jelzi: Az erőfeszítés Nagyon magas helyett Magas lett: a kiválasztott modell nem kínálja ezt: Nagyon magas. Az effort-vezérlés nélküli modell Automatikusra állítja.

A mentett szinteket az EYAS a modellhez méri. Ha egy beszélgetésen, kollégán vagy routing-szinten effortot állítasz be, az EYAS a szintet ahhoz a modellhez méri, amelyen fut. Az a szint, amelyet az a modell nem támogat, elutasításra kerül, és semmi nem mentődik — a beszélgetés felsorolja az elfogadott szinteket, egy szint sora pedig ezt írja: A modell nem kínálja ezt az erőfeszítési szintet. Semmi sem mentődött. Az Automatikus mindig elfogadott, és minden szint elfogadott, ha a modell előre nem ismert (Auto-routolt beszélgetés, modell nélküli kolléga, olyan modell, amelyről az EYAS-nak nincs ellenőrzött adata); ezeket minden hívásnál igazítja. Ha csak a modellt változtatod, az soha nem bukik el egy tárolt effort miatt.

Mivel futott az egyes válasz. Minden válasz alatt, a Provider · modell mellett egy kis chip mutatja, milyen efforttal futott ténylegesen a kör: Erőfeszítés: Magas, vagy Erőfeszítés: Nagyon magas → Magas, ha a modell nem kínálta a kért szintet. A tooltipje megnevezi, ki állította be (beszélgetés, Mély, kolléga, delegáló beszélgetés, útválasztási szint, a modell alapértéke). Nincs chip, ha semmit nem kértek és semmi nem ment ki. Minden tárolt válasz megőrzi a kért és a tényleges effortot, hogy honnan jött a szint, és hogy igazítva lett-e — chatnél, delegált és specialista-futásoknál, pipeline-szakaszoknál és csatornáknál. Minden AI-hívás trace-e ugyanezt rögzíti — lásd Observability.

Amit a Providerek oldal mutat. Minden modellsorban van egy reasoning-sor, például Gondolkodás: Alacsony, Közepes, Magas, Nagyon magas, Maximális · alapérték: Közepes, egy badge-dzsel arról, honnan jönnek az adatok: a szolgáltató jelentette (a provider vagy a runtime saját modellistája), vagy EYAS-katalógus, ellenőrizve: ÉÉÉÉ-HH-NN (az EYAS ellenőrzött reasoning-adatainak verziózott katalógusa). Az effort-vezérlés nélküli modellnél Gondolkodás: az erőfeszítés nem állítható; az EYAS által nem ismertnél Gondolkodás: az EYAS nem ismeri (az erőfeszítés Automatikus marad).

API (integrátoroknak). A GET /api/v1/model/effort-options?providerId&modelId (Model olvasási jog) egy modell szintjeit adja vissza; puszta modellazonosítóval vagy aliasszal az egyetlen gazda-provider modelljéét; modell nélkül az Auto-szintek unióját. A GET /api/v1/conversations/:id/effort-options (Conversation olvasási jog, csak a tulajdonos) a szinteket, a tárolt szintet (current) és azt adja vissza, mit örököl az Automatikus (inherited). Az elutasított szintre 400 a válasz EFFORT_UNSUPPORTED kóddal, a szinttel és a modell támogatott levels listájával.

Hogyan alkalmazza az effort-szintet az egyes provider

Az EYAS hívásonként egy szintet számít ki, a fentiek szerint, és minden provider csak lefordítja. Az EYAS minden esetben csak azt küldi, amiről tudja, hogy a válaszoló modell elfogadja; az ellenőrzött adatok nélküli modell nem kap reasoning-paramétert.

Provider	Mit küld az EYAS egy szintre	Honnan jönnek a szintek	Automatikus	Tényleges szint a válasz alatt
Anthropic API	A modell effort-beállítása (ahol van ilyen) plusz gondolkodás — adaptív, vagy tokenkeret, ahol a modell ilyet fogad; a Nincs kikapcsolja a gondolkodást, ahol a modell engedi	Az Anthropic Models API-ja, az általa nem jelentett adatokkal (alapérték, mindig bekapcsolt gondolkodás, keret-tartomány) az EYAS-katalógusból	Semmi; az alapból gondolkodó, de a gondolatmenetét elrejtő modell csak összefoglalót kap kérésre	Az EYAS által küldött szint
Anthropic-kompatibilis endpointok (MiniMax, Synthetic, Xiaomi MiMo)	Semmi	— (nincs ellenőrzött adat)	Mindig	—
OpenAI	`reasoning_effort`, a kimeneti limit `max_completion_tokens`-ként, temperature nélkül	EYAS-katalógus	Semmi	Az EYAS által küldött szint
OpenRouter	`reasoning: { effort }`; az OpenRouter továbbadja a felső modellnek, és igazíthat rajta	Az OpenRouter modellistája (reasoning igen/nem); az ismert családok az EYAS-katalógusból	Semmi	Az EYAS által küldött szint
Kimi API (Moonshot)	`reasoning_effort` (K3) vagy gondolkodás be/ki (K2.6); temperature nélkül	EYAS-katalógus	Semmi	Az EYAS által küldött szint
OpenAI-kompatibilis gatewayek (xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo, Vercel AI Gateway, Qianfan, vLLM)	Semmi — kivéve a `reasoning_effort`-ot az xAI Grok 3 Mini modelljénél	EYAS-katalógus a Grok 3 Mini-hez az xAI-on; más gateway reasoning-vezérlése még nincs ellenőrizve	Mindig, kivéve a Grok 3 Mini-t	Az EYAS által küldött szint (Grok 3 Mini); egyébként —
Gemini	Thinking-szint (Gemini 3) vagy thinking-keret (Gemini 2.5), gondolkodás-összefoglalókkal	EYAS-katalógus; a Google modellistája nem gondolkodónak jelölhet egy modellt	Semmi; az alapból gondolkodó modellek csak az összefoglalóikat kérik	Az EYAS által küldött szint
Ollama	`think`: be/ki, vagy a modell saját, névvel jelölt szintje	Az Ollama modell-információja (a thinking képesség és értékei); a gpt-oss az EYAS-katalógusból	Semmi	Az EYAS által küldött szint
LM Studio	Semmi — a gondolkodást az LM Studio állítja	—	Mindig; a panel az LM Studio saját beállítását mutatja	—
Claude Code CLI	Az az effort, amelyet a futó bináris a modellhez jelentett; a Nincs kikapcsolja a gondolkodást, ahol a modell engedi	Maga a Claude Code runtime, prompt nélkül olvasva	Semmi	A runtime-ból visszaolvasva
Grok CLI	A session reasoning-effort opciója, a prompt előtt beállítva	Maga a Grok CLI, prompt nélkül olvasva	Semmi; a kör rögzíti a Grok által használt szintet	Minden körben a Groktól visszaolvasva
Kimi Code CLI	A modell thinking- vagy normál változata, a sessionben kiválasztva	A Kimi saját modellistája	Megtartja a Kimi által épp futtatott változatot	Minden körben a Kimitől visszaolvasva

Az EYAS által küldött szint azt jelenti, hogy a válasz alatti chip azt a szintet mutatja, amelyet az EYAS a modellhez igazított. Visszaolvasva azt jelenti, hogy a CLI jelenti a ténylegesen futtatott szintet, és ezt rögzíti a chip és a trace, akkor is, ha eltér attól, amit az EYAS kért.

Részletek providerenként.

Anthropic API. Egy Claude modellnél pontosan a támogatott szintek választhatók: Nagyon magas a Fable-en, az Opus 5.5-ön, az Opus 5-ön, az Opus 4.7-en, az Opus 4.8-on és a Sonnet 5-ön van, az Opus 4.6-on és a Sonnet 4.6-on nincs; Ki csak ott van, ahol a modell ki tudja kapcsolni a gondolkodást (a Fable-en és az Opus 5.5-ön nem). A Haiku 4.5-nek és a Sonnet 4.5-nek nincs effort-beállítása, ezért a szintből a modell kimeneti limitjéhez méretezett thinking-keret lesz, és az EYAS megemeli a válaszhossz-limitet, hogy a gondolkodás soha ne vágja le a választ. Az Automatikus semmit nem küld (az Opus 5.5 alapértéke Közepes; az Opus 4.8 kérés nélkül nem gondolkodik). Azok a modellek, amelyek kérés nélkül elrejtik a gondolkodásukat (Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8, Sonnet 5), összefoglalót kapnak kérésre, valahányszor gondolkodnak — az alapból gondolkodók Automatikus mellett is —, így az megjelenik a chatben; ez csak a megjelenítést változtatja. Az EYAS nem küld temperature-t, top_p-t vagy top_k-t azoknak a modelleknek, amelyek elutasítják őket (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), bekapcsolt gondolkodás mellett pedig soha.
Anthropic-kompatibilis endpointok (MiniMax, Synthetic, Xiaomi MiMo): csak Automatikus. Az EYAS nem küld reasoning-vezérlést, amíg egy modell viselkedése nincs ellenőrizve; a temperature a beállított értékkel megy.
OpenAI. Minden GPT-5 generációs modell, amelyet a Chat Completions API kiszolgál, és az o-sorozat megkapja a szintet, mindegyik a saját tartományával: GPT-6 Astra Alacsony–Maximális (nem kapcsolható ki); GPT-5.6 Nincs–Maximális, alapérték Közepes; GPT-5.5 Nincs–Nagyon magas, alapérték Közepes; GPT-5.4 Nincs–Nagyon magas, alapérték Nincs; GPT-5.4 mini / nano és GPT-5.2 Nincs–Nagyon magas, alapérték Nincs; GPT-5.1 Nincs–Magas, alapérték Nincs; GPT-5 / GPT-5 mini / nano Minimális–Magas, alapérték Közepes; GPT-5 pro csak Magas; o1 / o3 / o3-mini / o4-mini Alacsony–Magas, alapérték Közepes. A hiányzó szint a legközelebbire kerül (a Maximális a GPT-5.5-ön Nagyon magas szinten fut). Ezeknek a reasoning-modelleknek az EYAS soha nem küld temperature-t, és a reasoning-modellek kimeneti limitjét (max_completion_tokens) használja — a háttérhívásoknál is, például a memória-rögzítésnél, amelyet korábban a GPT-5.2 és a GPT-5.4 mini / nano elutasíthatott. Explicit szintnél a kis kimeneti limit a szinthez szükséges értékre emelkedik (Alacsony 8k, Közepes 16k, Magas 32k, Nagyon magas/Maximális 64k token, soha a modell saját limitje fölé). Az ellenőrzött adatok nélküli modellek (GPT-4o, GPT-4o mini és a többi) nem kapnak reasoning-paramétert, és megtartják a max_tokens-t és a temperature-t. Egyes OpenAI-modellek csak az OpenAI Responses API-ján léteznek, az EYAS által használt Chat Completions API-n nem: GPT-5.2 pro, GPT-5.4 pro, GPT-5.5 pro, a Codex-modellek (GPT-5 Codex, GPT-5.1 Codex / Codex Max, GPT-5.2 / 5.3 Codex, codex-mini), az o1-pro, az o3-pro és a deep-research modellek. Az OpenAI provideren ezek csak Automatikus szintet kínálnak, és nem tudnak válaszolni; az OpenRouteren át használd őket. A GPT-5.1 mini-nek nincsenek közzétett effort-szintjei, ezért Automatikus marad.
OpenRouter. Az OpenRouter által reasoninget támogatónak jelölt modellek Minimális–Maximális szintet kínálnak; a reasoning nélkül listázott modellek nem kapnak effort-vezérlést. Az ismert családok a valódi szintjeiket mutatják: Claude Opus/Sonnet 4.6 (Ki, Alacsony, Közepes, Magas, Maximális), OpenAI GPT-5.x / GPT-6 Astra / o-sorozat (mint az OpenAI-n), Gemini 3.x (a Gemini thinking-szintjei, így a Nagyon magas Magas szinten fut). Szintén ismert: GPT-5.2 Nincs–Nagyon magas (alapérték Nincs); GPT-5.2 pro Közepes–Nagyon magas; GPT-5.4 pro Közepes–Nagyon magas (alapérték Közepes); GPT-5.5 pro Közepes–Nagyon magas (alapérték Magas); GPT-5.4 mini / nano, mint az OpenAI-n; GPT-5.2 / 5.3 Codex Alacsony–Nagyon magas. Ki csak ott van, ahol a család ki tudja kapcsolni a gondolkodást.
Kimi API (Moonshot). Kimi K3: Alacsony / Magas / Maximális (alapérték Maximális; a Közepes Alacsony szinten fut). Kimi K2.6: gondolkodás be (Magas) vagy ki (Nincs). A Kimi K2.7 Code és a K2.7 Code Highspeed mindig gondolkodik, és nincs effort-vezérlése.
OpenAI-kompatibilis gatewayek: csak Automatikus, a gyártóprefixes azonosítóknál is, például openai/gpt-5.4. Az xAI API provideren a Grok 3 Mini (és a Grok 3 Mini Fast) az egyetlen effort-vezérléssel rendelkező modell: Alacsony vagy Magas (a Közepes Alacsony szinten, a Nagyon magas és a Maximális Magas szinten fut). Mindig gondolkodik, és a gondolatmenete látszik. Az xAI már nem listázza a Grok 3 Mini-t, és az Oracle Cloud 2026-08-15-én kivezette, így lehet, hogy már nem válaszol. A többi Grok modell az xAI API-n az xAI alapértelmezésén gondolkodik: az EYAS Chat Completionsön át beszél az xAI-jal, ahol az xAI ezekhez nem dokumentál effort-paramétert. A Grok CLI provider megtartja az effort-vezérlését.
Gemini. A Gemini 3 modellek (3.8/3.7/3.6/3.5 Flash, 3.5/3.1 Flash-Lite, 3.1 Pro Preview, 3 Flash Preview) thinking-szintet kapnak — Minimális, Alacsony, Közepes vagy Magas. A hiányzó szint a legközelebbire kerül (a 3.8/3.7 Flash-nek és a 3.1 Pro-nak nincs Minimális szintje, így az Alacsony lesz; a Nagyon magas és a Maximális Magas lesz). A Gemini 3 modellek mindig gondolkodnak, így a Nincs a legalacsonyabb szintjükön futtatja őket. A Gemini 2.5 modellek a szintből származtatott thinking-keretet kapnak, a modell tartományán belül (2.5 Pro 128–32 768 token; 2.5 Flash legfeljebb 24 576; Flash-Lite 512–24 576); a Nincs a 2.5 Flash-en és a Flash-Lite-on kikapcsolja a gondolkodást, a 2.5 Pro pedig a legkisebb szintjén fut. A Google a thinking-tokeneket így is, úgy is kiszámlázza. A kis kimeneti limit a szinthez igazodva emelkedik, soha a modell saját limitje fölé. Azok a modellek, amelyeket a Google listája nem gondolkodónak jelöl (például a TTS-változatok), nem kapnak thinking-paramétert.
Ollama. A thinking képességet jelentő modellek Be / Ki választást kapnak: a Nincs kikapcsolja a gondolkodást, bármely magasabb szint bekapcsolja. A gpt-oss Alacsony, Közepes és Magas szintet fogad (alapérték Közepes), és nem kapcsolható ki (a Nincs Alacsony lesz). Egy újabb Ollama, amely jelenti egy modell pontos thinking-értékeit, pontosan azokat kínálja, az Ollama alapértékét megjelölve. Az Automatikus semmit nem küld (a gondolkodó modellek alapból gondolkodnak). A képesség nélküli modell, vagy amelynek képességei nem voltak kiolvashatók, soha nem kap thinking-beállítást — az Ollama elutasítaná a kérést. Explicit szintnél a kis max-tokens érték megemelkedik, hogy maradjon hely a gondolkodásnak.
LM Studio. Az EYAS soha nem küld reasoning- vagy effort-paramétert az LM Studiónak, így ott bármely szint gyakorlatilag Automatikus. Ha az LM Studio jelenti egy modell reasoning-beállítását, az LM Studio panel modellenként mutatja, például: qwen/qwen3-8b — Ennek a modellnek az érvelését maga az LM Studio állítja (ott az alapértelmezés: on). Az EYAS csak megjeleníti, nem módosítja. A régebbi LM Studio-verziók nem mutatnak tippet.
Claude Code CLI, Grok CLI, Kimi Code CLI. Lásd Claude Code modellek és effort, Grok modellek és effort és Kimi modellek és thinking.
Az OpenCode tool-sidecar, nem chat-provider: a modelljét és a gondolkodási változatát az OpenCode oldalon állítod be (lásd OpenCode — Modell és gondolkodás).

Egy ismert modell új verziói. Egy ismert modell dátumbélyeges pillanatképe, -latest aliasa vagy [1m] kontextusváltozata megkapja annak a modellnek a szintjeit — például a gpt-5.4-mini-2026-03-17 vagy a kimi-k3-0115. Egy másik változat (pro, codex, chat, preview, beta, fast, …) vagy egy ismeretlen modellcsalád csak Automatikus szintet kínál, amíg az EYAS nem rendelkezik róla ellenőrzött adatokkal. A szintek soha nem öröklődnek át egyik providerről a másikra.

Claude Code runtime

Az EYAS az általad telepített Claude Code CLI-t futtatja, és mindenhez egyetlen binárist használ: a bejelentkezés ellenőrzéséhez, a provider elérhetőségéhez, az első indításkori automatikus beállításhoz, a modell-felderítéshez és minden beszélgetéskörhöz. Amit az eyas doctor jelent, az fut. A bináris sorrendje:

EYAS_CLAUDE_CODE_BIN — abszolút útvonal a claude futtatható fájlra.
A szerver PATH-ján talált claude.
Végső tartalékként az EYAS Agent SDK függőségébe csomagolt régebbi Claude Code példány (jelenleg 2.1.89). Ilyenkor az eyas doctor figyelmeztet.

Az EYAS_CLAUDE_CODE_BIN szándékosan környezeti változó, nem UI-beállítás. Akkor használd, ha a szolgáltatás PATH-járól hiányzik a claude (launchd/systemd szolgáltatás, konténer), vagy egy adott telepítést akarsz rögzíteni. Ha be van állítva, de érvénytelen (nem abszolút, nem létezik vagy nem futtatható), a Claude Code provider kikapcsolva marad: nincs visszaesés a PATH-ra vagy a csomagolt példányra, a doctor pedig hibát jelez.

Verzióeltérés. Az EYAS SDK-kliense a Claude Code 2.1.89-hez készült. Egy újabb CLI-t változatlanul használ, a doctor pedig version skew figyelmeztetést mutat. A csak újabb CLI-k által ismert opciókat csak azok a runtime-ok kapják meg, amelyeknek megvannak (például az összefoglalt gondolkodást a 2.1.280-tól). A Claude Code nem frissíti magát, amíg az EYAS futtatja (lásd Claude Code izoláció); frissítsd a szokott módon magad, utána pedig nézd meg a doctor sorát (lásd Bizonyított CLI-verziók).

Bejelentkezve, nem csak telepítve. A bejelentkezést az EYAS a claude auth status --json paranccsal ellenőrzi: helyi parancs, nem indít sessiont, nem küld promptot, és semmibe nem kerül. A Claude Code provider csak akkor regisztrálódik — és friss telepítésen csak akkor kapcsol be magától —, ha ez a bináris be van jelentkezve: claude.ai login, ANTHROPIC_API_KEY vagy Bedrock/Vertex beállítás. Az, hogy a claude ott van a PATH-on, nem elég. Ha később jelentkezel be, a Providerek alatt kapcsold ki, majd be a providert, vagy indítsd újra az EYAS-t. A parancs által kiírt fiók e-mail-címét és szervezetét az EYAS soha nem logolja és nem tárolja.

Nincs rejtett modellhívás. Az EYAS soha nem küld tesztpromptot a host CLI-nek, sem ellenőrzéshez, sem a modellek listázásához. A modellistát prompt nélkül magából a runtime-ból olvassa — lásd lent.

Thinking. Az EYAS nem kapcsolja ki a thinkinget a Claude Code körökben, hacsak nem Nincs szintet kérnek. Ha nincs kért effort, a modell saját alapértelmezése érvényes. A kért szint csak olyan effortként megy ki, amelyet az adott runtime a modellhez jelentett; fix thinking-tokenkeretet nem küld. A létráról és arról, honnan jön egy szint, lásd Reasoning effort.

Claude Code modellek és effort

A modellista a runtime-ból jön. Az EYAS megkérdezi a ténylegesen futtatott Claude Code runtime-ot — ugyanazt a binárist, amelyet az eyas doctor jelent —, milyen modelleket kínál. Ez minden provider-induláskor és a Modellek frissítése megnyomásakor megtörténik. Nem küld promptot, semmibe nem kerül, és a saját Claude Code beállításaidtól izoláltan fut; a válaszban szereplő fiókadatokat az EYAS soha nem olvassa és nem tárolja.

Minden bejegyzés megnevezi a konkrét Claude modellt, amelyet az aliasa futtat, például az opus a claude-opus-5-5-öt. A Claude Code (Default) bejegyzés azt a modellt futtatja, amelyet a runtime alapértelmezésként használ.
Azokat a bejegyzéseket, amelyeket a runtime már nem kínál, kikapcsolja és megjelöli, de soha nem törli — például a Fable kikapcsolódik egy olyan runtime-on, amely nem ismeri.
A modellenkénti effort-szintek pontosan azok, amelyeket a runtime jelent, a Nagyon magas szintet is beleértve, ahol kínálja. Az a modell, amelyhez a runtime nem kínál effort-vezérlést, például a Haiku, csak az Automatikust kínálja. Az Automatikus semmit nem küld, így a modell saját alapértelmezése érvényes (például Közepes az Opus 5.5-ön).
Az EYAS soha nem küld olyan szintet, amelyet a futó bináris nem jelentett az adott modellhez. Ha a tárolt szintek egy másik Claude Code verzióból származnak, a következő indulásig vagy frissítésig nem küld szintet.
Az összefoglalt gondolkodást (hogy a modell gondolatmenete látszódjon a chatben) a Claude Code 2.1.280-as vagy újabb verziójától kéri. Egy régebbi Claude Code — az EYAS-szal csomagolt 2.1.89-es példányt is beleértve — nem kínál módot a kérésére: azoknál a modelleknél, amelyek kérés nélkül elrejtik a gondolkodásukat (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), az effort-választó ilyenkor ezt írja: Ez a modell nem mutatja a gondolkodása szövegét. Maguk az effort-szintek nem változnak. Frissítsd a Claude Code-ot 2.1.280-ra vagy újabbra, és frissítsd a modelleket (vagy indítsd újra az EYAS-t), hogy lásd a gondolatmenetet.
Kontextusablak. A Fable, Opus, Sonnet és Haiku bejegyzések 200k-s ablakot listáznak — ezt az ablakot adja a runtime ezeknek a neveknek —, az első induláskor, illetve akkor is, amikor a runtime modellistája nem olvasható. Csak az a bejegyzés listázódik és méreteződik 1M-re, amelyet maga a runtime kínál 1M-es változatként (például Opus (1M context), alias opus[1m]). Ha a runtime nagyobb ablakot jelent a válaszoló modellre, a kontextussáv továbbra is azt használja. Az a bejegyzés, amelyet egy korábbi verzió 1M-mel tárolt, és azóta egyetlen modellolvasás sem erősített meg, a következő induláskor 200k-ra javul, akkor is, ha a modellolvasás továbbra is elbukik; a kikapcsolt bejegyzések kikapcsolva maradnak.
A tényleges effortot minden körben visszaolvassa a runtime-ból: Nagyon magas szintet kérsz, a runtime Magas szintet futtat, és a válasz ezt jelzi; Automatikus mellett a válasz megnevezi, milyen szinten futott ténylegesen a modell.
Minden válasz rögzíti a ténylegesen válaszoló konkrét modellt, a trace-ekben és a memória-attribúcióban. A modell nélküli kör a Claude Code (Default)-hoz rendelődik.

Háttérhívások CLI-n. A háttérbeli modellhívások (memória-rögzítés, címek, biztonsági ellenőrzések) csak akkor használnak egy routing-szintről megadott konkrét Claude Code, Grok CLI vagy Kimi Code CLI modellt, ha az adott CLI saját felderítése kínálta azt a modellt; különben a CLI alapértelmezett modelljén futnak. Hogy az EYAS háttérmunkája most hová megy, azt a Routing és költségkeret — A Háttérben futó modellhívások kártya mutatja.

A háttérhívások CLI-n is megtartják a kimeneti limitjüket. Az EYAS saját kis, egyszeri hívásai — beszélgetéscímek, üzenet-osztályozás, memória-rögzítés, a biztonsági bíró döntése, konszolidáció és hasonló háttérmenetek — maximális válaszhosszt kérnek. A CLI-k nem fogadnak el kimeneti limitet az EYAS-tól, ezért a Claude Code-on, a Grok CLI-n és a Kimi Code CLI-n az EYAS streamelés közben számolja a választ: amint az meghaladja a kért tokenenkénti nagyjából négy karaktert (maxTokens × 4 karakter), az EYAS leállítja a CLI-t (Claude Code: a lekérdezést lezárja; Grok és Kimi: a sessiont megszakítja). A hívás ekkor rendben ér véget az addigi válasszal és max tokens leállási okkal (Elérte a kimeneti limitet), soha nem hibával — ahogy az API providereknél. Csak a válasz számít; a gondolkodás nem fogyasztja a limitet. A toolokat használó chat- és agent-köröket ez nem érinti, mert egy CLI-kör sok modellhívást futtat. A kiadási ellenőrzés ezt a Claude Code 2.1.281-en és a Grok CLI 1.0.41-en bizonyítja; a Kimi Code CLI ugyanazt a kódutat használja, de élőben nem tesztelték.

Claude Code izoláció

Az EYAS a Claude Code-ot mindig izoláltan futtatja. Kapcsoló nincs: a korábbi Gépszintű Claude-konfig betöltése opció megszűnt. A provider panel ezt egy sorban közli, és a host CLAUDE.md-tartalmának behozatalához az adatimportra mutat.

Minden Claude Code futás — chat, agentek, háttérmunka és izolált egyszeri hívások egyaránt:

nem tölt be host settings.json-t (így hookokat és jogosultsági szabályokat sem), egyetlen szintű (user, project vagy local) CLAUDE.md-t sem, host skilleket sem, és projekt .mcp.json-t, fájlrendszer- vagy claude.ai MCP szervereket sem. Egyetlen toolszervere az EYAS saját eyas szervere; a háttérben futó egyszeri hívások egyet sem kapnak;
a Claude Code saját auto-memóriáját kikapcsolva futtatja;
az ideiglenes fájljait — köztük a háttérben futtatott shell-parancsai kimenetét — az adott futás saját mappájában tartja az EYAS workspaces mappáján belül, nem a host /tmp/claude-<uid> mappájában. A mappa a futás végén törlődik; egy összeomlás után maradt mappát a következő indulás törli;
nem ír átiratot a ~/.claude/projects alá, és nem készít fájl-checkpoint-másolatokat, így az EYAS futásai nem jelennek meg a claude --resume listában (a korábbi EYAS-verziók által írt átiratokat nem törli magától);
megtartja a host bejelentkezését: a claude.ai előfizetés, API-kulcs, OAuth token, Bedrock vagy Vertex továbbra is működik.

A vállalati menedzselt policy-beállítások, ahol egy szervezet telepíti őket, továbbra is érvényesek; ezt a szintet az EYAS nem tudja kikapcsolni.

A beszélgetés mappájában lévő projekt-utasításfájlokat (CLAUDE.md, AGENTS.md) sem tölti be automatikusan. A modell a fájltooljaival ettől még megnyithatja őket.

Munkamappa. A Claude Code a beszélgetés első, még érvényes Mappájában dolgozik, különben a beszélgetés saját EYAS workspace-ében. Soha nem fut az EYAS szerver saját könyvtárában (az EYAS home-ban, ahol a kulcsfájl, a vault és az adatbázis van). A beszélgetés nélküli háttérhívások futásonkénti ideiglenes munkamappát használnak, amelyet 7 nap használatlanság után az EYAS eltávolít. A már nem érvényes mentett Mappát kihagyja, figyelmeztetéssel a szervernaplóban. Lásd Beszélgetések — Mappák.

Környezet. A Claude Code csak engedélylistás környezetet kap: PATH, nyelvi beállítás és időzóna, proxyk és CA-csomagok, HOME, valamint az Anthropic / Claude OAuth / Bedrock / Vertex bejelentkezési változók. Ezen felül az EYAS beállítja az izolációs kapcsolóit — CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, CLAUDE_CODE_DISABLE_CLAUDE_MDS=1 és DISABLE_AUTOUPDATER=1 —, a CLAUDE_CODE_TMPDIR-t a futás saját ideiglenes mappájára állítja, és eyas-ként azonosítja magát a Claude Code felé. A szerver többi változója nem kerül át: más providerek API-kulcsai, az EYAS titkai, a CLAUDE_CONFIG_DIR, és annak a Claude Code sessionnek a CLAUDE_CODE_* kapcsolói, amelyből az EYAS-t indították. A bejelentkezés-ellenőrzés (claude auth status) ugyanezt a környezetet használja. A DISABLE_AUTOUPDATER miatt a Claude Code nem frissíti magát, amíg az EYAS futtatja.

Induláskori ellenőrzés. A Claude Code minden futás elején jelenti, mit töltött be, és az EYAS ezt a jelentést ellenőrzi, mielőtt a válaszból bármit felhasználna. Csak az EYAS saját toolszervere csatlakozhat, a jogosultsági módnak default-nak kell lennie, a munkamappának a vártnak, és plugin nem töltődhet be — kivéve azt a két plugint, amely a Claude Code 2.1.281-be be van építve: az agents-md-t és a telemetry-t, és ezeket is csak agents-md@builtin és telemetry@builtin formában fogadja el. Az EYAS kiadás előtti ellenőrzése bizonyította, hogy az EYAS izolációja alatt ártalmatlanok: a munkamappából vagy egy almappájából egyetlen AGENTS.md sem jut el a modellhez. Minden más plugin, egy későbbi Claude Code új beépített pluginja is, továbbra is leállítja a futást. Ha bármi más jelenik meg — például egy MCP szerver vagy plugin a host konfigurációjából, vagy egy menedzselt policy, amely más jogosultsági módot kényszerít —, az EYAS azonnal leállítja a futást. Abból a futásból semmi nem jelenik meg, és a kör CLI-izolációs hibával bukik el, amely a nyelveden megnevezi a sikertelen ellenőrzéseket — például A(z) Claude Code CLI leállt: az EYAS nem tudta megerősíteni, hogy elszigetelten fut (a munkakönyvtár nem az volt, amelyet az EYAS kijelölt). A kör nem került át másik modellhez. Nem próbálja újra, és nem teszi át másik providerre. A javítás a hoston van: távolítsd el a hibás menedzselt beállítást vagy plugint, vagy ellenőrizd, melyik binárisra mutat az EYAS_CLAUDE_CODE_BIN.

A Claude Code saját toolja előbb az EYAS memória-policyján megy át. Mielőtt a Read, Write, Edit, Glob, Grep, Bash, NotebookEdit, WebFetch vagy bármely más Claude Code tool lefut, egy ellenőrzés minden általa érintett útvonalat összevet az EYAS memória-policyjával — beleértve azokat az olvasásokat is, amelyeket a Claude Code a munkamappáján belül magától engedne. Más eszközök memóriáját (~/.claude, ~/.grok, ~/.codex, Obsidian vaultok, a lista többi eleme és a security.foreignMemoryPaths), az EYAS saját adatmappáját és egy másik beszélgetés workspace-ét elutasítja. Az elutasított hívás nem fut le; a Claude Code megkapja az okot — például Memory outside EYAS (Obsidian) — use memory_search / memory_expand from EYAS —, és az EYAS memóriatooljaival folytathatja. A Grep, a Glob, az LS és a rekurzív Bash-keresések azon ítéltetnek meg, amit elérhetnek: az a keresés, amelynek mappája egy védett helyet tartalmaz — például egy Grep a ~ mappában, vagy egy Grep az EYAS checkoutjában, amelyben a data/ van —, Search too broad … elutasítást kap, és a Claude Code szűkebb mappával újrapróbálhatja. Lásd Biztonság és adatvédelem — Memória az EYAS-on kívül. Ezen az ellenőrzésen felül a Claude Code shellparancsai az operációs rendszer fájl-sandboxában futnak, ahol ilyen elérhető — lásd Kernel fájl-sandbox.

EYAS toolok Claude Code-on. A Claude Code a folyamaton belüli eyas MCP szerveren keresztül éri el az EYAS toolokat, a promptjában mcp__eyas__<name> néven. Ez a szerver pontosan azokat a toolokat kínálja, amelyeket az EYAS a futásnak felkínál: az agent Eszközök listáját plusz a memory_search-öt és a memory_expand-ot (üres lista = minden tool). Solo beszélgetésben delegáló toolokat nem kínál. Azokat az EYAS toolokat, amelyeknek a Claude Code-ban van engedélyezett saját megfelelője, nem adja át — read_file, grep és glob (a Read, Glob és Grep), write_file és edit_file, amíg írhat, valamint run_command, git_status és git_diff, amíg használhatja a shelljét: a Claude Code ilyenkor a saját tooljait használja a kör mappáiban, a sandbox és a memória-policy alatt. run_command nélküli listán a git_status és a git_diff ehelyett EYAS toolként kerül átadásra. Minden más EYAS toolt átad, az EYAS böngészőtoolokat (browser_*, a mentett sessionökkel és a browser_totp-vel), az agent_browser_*, a browser_use_* és az opencode_* toolokat is; ezek az EYAS-ban futnak, ugyanazzal a biztonsági kapuval, jóváhagyásokkal és tool-hatókörrel, mint egy API providernél. A memória-drill-down válaszonként 3 hívás, mint minden más providernél. Lásd MCP — CLI MCP tool-paritás.

Az agent Eszközök listája a CLI saját tooljait is korlátozza. A Claude Code-on, a Grok CLI-n és a Kimi Code CLI-n egyaránt az agent Eszközök listája dönti el, hogy a CLI saját beépített tooljai közül melyeket használhatja a modell, nemcsak azt, hogy mely EYAS toolokat ér el a hídon — ugyanúgy, ahogy egy API-modellt korlátoz:

Fájlok írása (a Claude Code Write, Edit és NotebookEdit toolja; a Grok és a Kimi szerkesztő és áthelyező tooljai, valamint azok a fájlírások, amelyeket az EYAS szolgál ki a CLI-nek): csak ha a lista tartalmazza a write_file vagy az edit_file toolt.
Shellparancsok (a Claude Code Bash toolja; a Grok és a Kimi végrehajtó tooljai; a törlés is shellparancsnak számít, ahogy a biztonsági kapu besorolja): csak ha a lista tartalmazza a run_command toolt. A git_status és a git_diff nem ad shellt.
Webes lekérés és webes keresés (a Claude Code WebFetch és WebSearch toolja; a Grok és a Kimi lekérő tooljai, valamint a Grok web_fetch és web_search toolja): csak ha a lista tartalmaz egy webes toolt — research, browser_navigate, agent_browser_run vagy browser_use_exec.
Fájlok olvasása (a Claude Code Read, Glob és Grep toolja; a Grok és a Kimi olvasó, kereső és listázó tooljai) mindig engedélyezett, bármit mond a lista. A beszélgetés mappáin belül marad, a memória-policy és a kernel fájl-sandbox alatt. A memóriakeresés is mindig elérhető.
Az üres lista továbbra is minden toolt jelent, a CLI saját tooljait is.

A Claude Code-on a visszatartott toolokat a modell egyáltalán nem kapja meg. A Grokon és a Kimin azt a visszatartott toolt, amelyet a CLI használni próbál, az EYAS még a biztonsági kapu megkérdezése előtt elutasítja: nincs jóváhagyási kérdés, és a toolsor Elutasítva állapotot mutat (a Grok a saját elutasító szövegét mutatja a soron). A Kimi engedélykérései nem mondják meg, milyen fajta tool kérdez (a Kimi 1.52.0 forráskódjából olvasva; hoston még nem ellenőrizve), ezért az EYAS elutasítja azt a Kimi-kérést, amelyet nem tud besorolni, valahányszor az agent listájából a fájlíró toolok vagy a run_command bármelyike hiányzik — egy ilyen agent a Kimi egyetlen kérdező toolját sem használhatja (fájlírás vagy -csere, shell, háttérfeladatok). A Kimi webes keresése és lekérése soha nem kérdezi az EYAS-t, ezért agentenként nem engedélyezhető; az EYAS izolációs ellenőrzése így is leállítja az ezeket használó kört. Migráció: a szűk listájú meglévő agentek — például egy run_command / write_file nélküli Személyi asszisztens — a Claude Code-on, a Grokon és a Kimin már nem írhatnak fájlt és nem futtathatnak parancsot. Az engedélyezéshez vedd fel a listára a write_file / edit_file és/vagy a run_command toolt, vagy ürítsd ki a listát. Lásd Agentek — Eszközök.

Specialisták. A Claude Code nem indít saját rejtett subagenteket (a beépített Task/Agent toolját nem kapja meg). Amikor egy Claude Code-on futó kolléga szétosztja a munkát, az EYAS-on keresztül, run_specialist-tel indít specialistákat, pontosan úgy, mint a többi providernél — lásd Csapatok és delegálás.

Frissítés. Az a telepítés, amelyen a Gépszintű Claude-konfig betöltése be volt kapcsolva, automatikusan izoláltra vált; a tárolt beállítást az első induláskor eltávolítja, a maradék értéket figyelmen kívül hagyja. A host CLAUDE.md utasításai és a host skillek már nem jutnak el a beszélgetésekhez. Ha ezt a tartalmat meg akarod tartani, importáld egyszer, egyirányúan, a Beállítások → Rendszer → Adat hordozhatóság → Adatok importálása alatt — lásd Adatimport.

Grok CLI és Kimi Code CLI

Az EYAS a Grok CLI-t és a Kimi Code CLI-t teljesen izoláltan futtatja a gép saját Grok-, Kimi- és Claude-beállításaitól.

Saját home. Az EYAS minden CLI-t saját home-mappával indít az EYAS adatmappáján belül — <data dir>/cli-homes/grok-cli és <data dir>/cli-homes/kimi-cli. Az EYAS futásai nem olvassák és nem írják az operátor ~/.grok, ~/.kimi, ~/.claude, ~/.cursor vagy ~/.agents mappáját: nincs host konfig, szabály vagy AGENTS.md, memória, skill, hook, Claude/Cursor-import vagy MCP szerver (például egy Obsidian vault-szerver).

Környezet. Csak egy rövid engedélylista jut el a CLI-hez: PATH, nyelvi beállítás és időzóna, TMPDIR, TERM, USER, LOGNAME, SHELL, proxyváltozók és CA-csomag-változók. Az EYAS titkai, más providerek kulcsai, a szerverkörnyezet XAI_API_KEY-e és a szerver bármely GROK_*, KIMI_* vagy XDG_* beállítása kimarad.

Melyik bináris. Az EYAS_GROK_BIN / EYAS_KIMI_BIN (a futtatható fájl abszolút útvonala) élvez elsőbbséget, különben a PATH-on lévő grok / kimi. Ha a változó be van állítva, de érvénytelen, a provider nem regisztrálódik — nincs visszaesés a PATH-ra. A provider újratöltése (ki, majd be) újra megkeresi a binárist.

Munkamappa. A Grok- vagy Kimi-kör a beszélgetés első érvényes Mappájában fut, különben a beszélgetés saját EYAS workspace-ében, különben egy privát futási munkamappában — soha nem az EYAS szerver saját munkakönyvtárában.

Grok-beállítások, amelyeket az EYAS ír. Az EYAS minden futás előtt megírja a config.toml, a requirements.toml és egy üres trusted_folders.toml fájlt a Grok home-jában; az ottani helyi módosításokat felülírja. Ezek beállítják:

Ask mód. Minden natív Grok tool — fájlolvasás, mappalistázás, keresés, shell, írás/szerkesztés, webes lekérés és keresés, subagentek — előbb az EYAS-t kérdezi, és az EYAS biztonsági kapuja dönt.
Az always-approve zárolva. A --always-approve, a yolo mód és az /always-approve nem működik.
A memória, a memory v2, a session-keresés, a telemetria és a trace-feltöltés, a megosztott leader mód (a Grok --no-leader kapcsolóval indul) és az automatikus frissítés ki van kapcsolva.
Csak az EYAS saját toolszervere (eyas) csatlakozhat.
A mappa soha nem kap bizalmat. A beszélgetésmappa AGENTS.md-je, .grok konfigja, hookjai és MCP szerverei nem töltődnek be automatikusan; a modell a fájltooljaival ettől még megnyithat fájlokat, és minden olvasás az EYAS-t kérdezi.

Kimi-beállítások, amelyeket az EYAS ír. Az EYAS a saját Kimi-konfigjában beállítja a default_yolo = false, telemetry = false és merge_all_available_skills = false értéket, a fájl többi részét (bejelentkezés, alapértelmezett modell) megtartja. A Kimi nem kap saját MCP szervert, az automatikus frissítés ki van kapcsolva, és pontosan kimi acp-ként indul. Azt a modellt, amelyre az EYAS átállítja, a Kimi ugyanebbe a fájlba menti — lásd Kimi modellek és thinking.

A session-fájlok törlődnek. Az átiratokat, a prompt-előzményeket és a tool-naplókat, amelyeket egy CLI az EYAS home-jában ír, minden kör végén törli. Az egy óránál régebbi maradékokat (összeomlás után) induláskor és óránként eltávolítja. Magát az EYAS-beszélgetést ez nem érinti: az EYAS minden körben a saját tárából játssza vissza.

A Grok shellje. A Grok shellparancsai az EYAS Grok home-jával mint HOME-mal futnak, így a host ~/.gitconfig, SSH-kulcsai és shell-konfigurációja nem érhető el — a Grok shelljéből indított git commitoknak például nincs host-identitásuk. Ahol a szerver kínál ilyet, a Grok saját toolai az operációs rendszer fájl-sandboxában is futnak — lásd Kernel fájl-sandbox.

Körlimit. A Groknál és a Kiminél a körlimit a toolhívásokat számolja. Egy chatkör a beszélgetés kollégájának Max. körök értékét használja (különben a projekt alapértelmezett agentjéét), alapból 25-öt; az agent-futások az agent Max. körök értékét; a provider maxTurns beállítása (alap 25) csak a keretet nem megadó hívásokra érvényes. Ha a CLI eggyel több toolhívást indít, mint a limit, az EYAS megszakítja a CLI sessiont: a kör max turns kimenettel zárul, és megtartja a részleges választ. Ez nem hiba, és a plusz toolhívás nem fut le. Ugyanez a keret a Claude Code belső körkorlátja egy chatkörre.

Nincs rögzített időkorlát. Egy Claude Code-, Grok- vagy Kimi-kört nem állít le rögzített időkorlát. Csak akkor áll le, ha a CLI elhallgat: 10 perc üzenet nélkül, amíg nem fut tool, vagy 20 perc üzenet nélkül, amíg tool fut (például egy run_specialist-tel indított specialista, amely akár 15 percig is tarthat, vagy egy hosszú build). A CLI bármely üzenete — streamelt szöveg, egy tool indulása vagy befejezése, egy engedélykérés — újraindítja az órát, és az egész kör hosszára nincs korlát; a Leállítás továbbra is bármikor leállítja. A csend miatt leállított kör időtúllépést jelent, nem általános aborted hibát; a többi időtúllépéshez hasonlóan egyszer újrapróbálható vagy átirányítható, ha még semmi nem streamelődött, a háttérfutást pedig az automatikus újrapróbáló ütemező indíthatja újra. A két korlát a model.cli.idleTimeoutMs és a model.cli.toolTimeoutMs — lásd Konfiguráció — CLI-körök időkorlátja. A körönkénti kulcs, amellyel a Grok és a Kimi EYAS toolokat hív, az utolsó használata után 2 órával jár le, így egy hosszú, sokat dolgozó kör megtartja az EYAS tooljait; a kör végén azonnal visszavonódik.

Slash parancsok. A /-rel kezdődő üzenetet (például /always-approve on) az EYAS <message>…</message> közé csomagolva küldi a Groknak vagy a Kiminek, így a CLI soha nem futtatja saját parancsaként. A modell a szöveget ettől még látja.

A Kimi korlátai. A Kimi izolációja a forráskódjából van levezetve, és gépen még nincs bizonyítva (lásd Bizonyított CLI-verziók). A Kiminek nincs mappabizalmi kapuja: továbbra is beolvassa a beszélgetésmappában lévő AGENTS.md / .kimi/AGENTS.md fájlt, és ha a mappa egy git repón belül van, egészen a repó gyökeréig. A kereső- és webes toolja soha nem kérdezi az EYAS-t, így az ezeket használó Kimi-kört az alábbi izolációs ellenőrzés leállítja. Ugyanezért az EYAS egy Kimi-keresést sem tud túl tágként elutasítani: a Kimi saját Grep és Glob toolja soha nem kérdez, a Kimi Globja a munkamappáján belül marad, a Grepje viszont bármely mappát elfogad, és a Kiminek nincs kernel sandboxa (lásd Biztonság és adatvédelem — Memória az EYAS-on kívül). Az agent Eszközök listája a Kimi és a Grok saját író, shell- és webes tooljait a Claude Code izoláció alatt leírt módon korlátozza.

Mivel a Grok és a Kimi az EYAS saját home-jában fut, a CLI gépen lévő bejelentkezését az EYAS nem használja. Egy olyan telepítésen, amely a host bejelentkezésére támaszkodott, nincs működő Grok- vagy Kimi-modell, amíg valaki egyszer be nem jelentkezik az EYAS számára. Az operátor saját grok / kimi bejelentkezését a hoston az EYAS soha nem olvassa, nem módosítja és nem használja, az EYAS-os bejelentkezés pedig magától frissül.

A Bejelentkezés az EYAS számára kártya három helyen jelenik meg: a Grok CLI / Kimi Code CLI provider panelen, a setup varázsló AI provider lépésében, valahányszor a Grok vagy a Kimi detektálva van, és egy Kezdőlap-bannerként (<CLI>: bejelentkezés szükséges az EYAS számára), ha egy engedélyezett, telepített CLI nincs bejelentkezve (a Bejelentkezés megnyitja a kártyát; az Elrejtés a böngésző-sessionre elrejti a bannert). Be- és kijelentkezni csak tulajdonos és admin tud, és csak ők látják egy függő bejelentkezés linkjét és kódját; a többi szerepkör az állapotot látja.

Eszközkód (Grok és Kimi). Kattints a Bejelentkezés eszközkóddal gombra. Az EYAS a saját mappájában futtatja a CLI saját bejelentkezését, és mutat egy linket (Bejelentkezési oldal megnyitása) és egy kódot. Nyisd meg a linket bármely eszközön, jelentkezz be, és ellenőrizd, hogy az oldal ugyanazt a kódot mutatja. A szerveren nem kell böngésző, így fej nélküli szervereken és Dockerben is működik. A kártya ezt mutatja: Várakozás a kód megerősítésére…, majd Bejelentkezve.

A Mégse leállítja a függő bejelentkezést.
15 perc megerősítés nélkül a bejelentkezés lejár; kezdd újra. A Kimi magától is új kóddal indul újra.
Ha az EYAS nem talál linket a CLI kimenetében, a CLI szövegét változatlanul mutatja, hogy követhesd.
Hibánál a CLI utolsó üzenete és egy Újra gomb jelenik meg.

API-kulcs helyette (csak Grok). Válaszd az Inkább API-kulccsal lehetőséget, és illessz be egy xAI API-kulcsot. Az EYAS titkosítva tárolja a Titkok között grok-cli-api-key néven (Rendszer hatókör), és csak a Grok CLI futásainak adja át, XAI_API_KEY-ként. A használatot az xAI API-fiók fizeti, nem a Grok/SuperGrok előfizetés. Ha eszközkódos bejelentkezés és kulcs is van, a Grok az eszközkódos bejelentkezést használja. A kulcsot a Titkok oldalon is felveheted ezen a néven; az EYAS akkor veszi észre, amikor megnyitod a provider panelt vagy a varázsló kártyáját, amikor a provider újratöltődik, vagy az első olyan kör után, amely bejelentkezési hibával bukik el. A Kiminek az EYAS-ban nincs API-kulcsos lehetősége.

A Kijelentkezés eltávolítja az EYAS Grok- vagy Kimi-hitelesítő adatát az EYAS mappájából, és törli a tárolt API-kulcsot. A Groknál az EYAS a saját mappájában futtatja a grok logout parancsot. A Kiminél az EYAS a saját hitelesítőfájlját törli, és nem futtatja a kimi logout parancsot, mert az az operátor Kimi-tokenjét is törölné az operációs rendszer kulcstartójából. A host bejelentkezéséhez az EYAS soha nem nyúl.

Bejelentkezés nélkül az adott providerre eső beszélgetés- vagy háttérkör azonnal, még a CLI indítása előtt elbukik ezzel: <provider>: nincs bejelentkezve az EYAS számára … jelentkezz be a Providerek oldalon (hibakód cliSignIn). Az EYAS nem próbálja újra, és nem vált csendben másik providerre. A CLI által egy kör közben jelentett hitelesítési hiba ugyanezt az üzenetet adja.

Hol vannak a hitelesítő adatok: <data dir>/cli-homes/grok-cli/.grok/auth.json és <data dir>/cli-homes/kimi-cli/.kimi/credentials/kimi-code.json, olyan mappákban, amelyeket csak az EYAS felhasználója nyithat meg. Az adatkönyvtár mentése tartalmazza őket.

API (integrátoroknak; tulajdonos/admin, GET-hez olvasási jog). A GET /api/v1/model/providers/{grok-cli|kimi-cli}/sign-in ezt adja vissza: {signedIn, method: device|apiKey|null, apiKeySupported, apiKeyStored, session{state: pending|succeeded|failed|expired|cancelled, verificationUrl, userCode, rawPrompt, error}}. A POST {"method":"device"} 202-t ad — amíg függőben van, kérdezd le GET-tel. A POST {"method":"apiKey","apiKey":"…"} 200-at ad (csak Grok; a Kimi 400-at ad). A DELETE kijelentkeztet; a DELETE ?target=session csak egy függő eszközkódos bejelentkezést szakít meg. A többi provider 404-et ad. Aki modelleket nem kezelhet, annak a verificationUrl, userCode, rawPrompt és error null: aki a kódot megerősíti, a saját fiókját köti az EYAS könyvtárához.

A Kimi bejelentkezése a Kimi CLI forráskódját követi, és valódi hoston még nincs ellenőrizve.

Izolációs ellenőrzés minden kör előtt

A Grok CLI és a Kimi Code CLI csak azután fut, hogy az EYAS ellenőrizte az izolációjukat. Az ellenőrzésen elbukó kör izolációs hibával áll le; soha nem próbálja újra, és soha nem teszi át csendben másik modellre.

A Grokot minden kör előtt ellenőrzi, modellhívás nélkül: az EYAS a beszélgetésmappában, az EYAS Grok home-jával futtatja a grok inspect --json parancsot, és visszaolvassa az ott megírt konfigfájlokat. A sikeres ellenőrzést ugyanarra a Grok binárisra, mappára és home-ra 10 percig újrahasznosítja; bármi, ami a home-ba kerül (egy skill, szabály vagy hook), új ellenőrzést kényszerít ki. A Grokot elutasítja, ha:

magától jóváhagyhatná a toolhívásokat (az always-approve zár nem érvényes);
jogosultsági szabályok vagy egy konfigréteg máshonnan jönnek, mint az EYAS saját fájljaiból — például egy rendszerszintű Grok-konfigfájlból, vagy jogosultsági szabályokat hozzáadó menedzselt Claude Code beállításokból;
az EYAS saját hídján kívül más MCP szervert is elindítana (az EYAS engedélylistája által letiltott szerverek rendben vannak);
hookok, pluginek vagy language serverek vannak beállítva;
utasításfájlok, skillek vagy agentek a home-jából vagy a beszélgetés mappáin kívülről jönnek;
a Claude-, Cursor- vagy Codex-importok be vannak kapcsolva;
egy megbízhatónak jelölt projektmappa saját konfigja érvényes.

A Grok gyártó által kezelt beállításfájlja. A grok 1.0.41 a gyártó által kezelt beállítások gyorsítótárát, a managed_config.toml fájlt beírja az EYAS Grok home-jába; normál fióknál ez üres. Az üres fájlt az EYAS elfogadja. Ha a fájl bármilyen beállítást tartalmaz, a kör a fenti ellenőrzésekkel elutasításra kerül (például az eszközjóváhagyás nincs az EYAS-hoz kötve), és a fájl bármely változása azonnal érvényteleníti a sikeres ellenőrzést, még azon a 10 percen belül is, ameddig az egyébként újrahasznosítható.

A beszélgetés mappáin belüli projekt-utasításfájlok (AGENTS.md, CLAUDE.md, .grok/rules) nem okai az elutasításnak: a mappa soha nem kap bizalmat, így a Grok magától nem tölti be őket, de a modell a fájltooljaival elolvashatja őket. Az ilyen mappában lévő projekt-MCP szervereket vagy hookokat a Grok listázza, de soha nem indítja el.

A Kimit az EYAS home-jából ellenőrzi, mert nincs inspect parancsa: a data/cli-homes/kimi-cli/.kimi/config.toml fájlban az automatikus jóváhagyásnak és a host skill-mappák összefésülésének ki kell kapcsolva lennie, hookok és extra skill-mappák nélkül; a mcp.json üres kell legyen; és a home skill-mappáiban nem lehet skill. A Kiminek az adatait is az EYAS Kimi home-jában kell tartania: ha a share mappája máshová mutatna, az ellenőrzés leállítja a kört és a modellfrissítést (az eszközjóváhagyás nincs az EYAS-hoz kötve jelzéssel), így egy modellváltás soha nem írhat azon a home-on kívülre.

A session indulásakor az olyan sessiont, amely magától jóváhagyó módban indul, az EYAS leállítja.

Futás közben az EYAS leállítja a kört, ha a Grok vagy a Kimi úgy indít vagy fejez be egy natív toolt, hogy az EYAS nem döntött róla (fájlolvasás vagy -írás, keresés, listázás, shell, web, subagent, tool-keresés, vagy nem az EYAS-hoz tartozó MCP tool), vagy ha a saját memóriatoolját hívja. Az EYAS ekkor megszakítja a sessiont, izolációs hibával zárja a kört, és semmit nem használ fel abból, amit a CLI ezután mond. Az EYAS saját tooljai (memória, board és így tovább — a Grok use_tool-lal, eyas__<name> néven éri el őket) nem részei ennek az ellenőrzésnek, mert az EYAS minden ilyen hívásról maga dönt — lásd lent: Az EYAS toolokról ugyanúgy születik döntés.

A chatüzenet például így szól: A(z) Grok CLI leállt: az EYAS nem tudta megerősíteni, hogy elszigetelten fut (nem az EYAS-hoz tartozó MCP-szerverek, hookok). A kör nem került át másik modellhez. Utána egy Szolgáltatóbeállítások megnyitása link következik. Az ellenőrzések, amelyeket megnevezhet: az eszközjóváhagyás nincs az EYAS-hoz kötve; nem az EYAS-hoz tartozó MCP-szerverek; hookok; bővítmények; a beszélgetésen kívülről származó utasítások vagy készségek; a CLI saját memóriája; importálás más MI-eszközökből; megosztott vezérlőfolyamat (leader); megbízhatónak jelölt projektmappa; EYAS-jóváhagyás nélkül lefutott eszköz; az ellenőrzés nem tudott lefutni.

Újraellenőrzéshez szüntesd meg az okot — például az extra MCP szervert, hookot, skillt vagy AGENTS.md-t az EYAS Grok- vagy Kimi-home-jában, vagy egy rendszerszintű Grok-konfigot —, és küldd el újra az üzenetet. Minden kör újra ellenőriz. A provider újratöltése vagy újbóli engedélyezése, illetve az EYAS újraindítása betöltéskor lefuttatja a Grok ellenőrzését, a provider panel Ellenőrzés most gombja pedig ugyanezeket az ellenőrzéseket futtatja modellhívás nélkül (lásd lent: Futtatókörnyezet és Izoláció a provider panelen). Az EYAS home-okat az eyas doctor ellenőrzi (lásd Bizonyított CLI-verziók).

Futtatókörnyezet és Izoláció a provider panelen. Válaszd ki a Claude Code CLI, a Grok CLI vagy a Kimi Code CLI kártyáját a Providerek alatt:

Futtatókörnyezet — hogyan találta meg az EYAS a binárist, a verziója és az útvonala. Források: A gépen telepített CLI (PATH), Üzemeltetői felülírás (környezeti változó) (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN) vagy Beépített futtatókörnyezet (tartalék) (csak Claude Code). A verzió a CLI sajátja; a verziót nem jelentő CLI-nél ismeretlen verzió áll. További sorok: A(z) X verzió eltér a várt Y verziótól (a Claude Code bináris eltér attól a verziótól, amelyhez az EYAS rögzített Agent SDK-ja készült); A PATH-on lévő CLI-t (verzió) az EYAS nem használja. (egy felülírás elrejt egy másik CLI-t a PATH-on); Nincs bejelentkezve (csak Claude Code — a Grok és a Kimi a bejelentkezését a Bejelentkezés az EYAS számára kártyán mutatja); Nincs használható futtatókörnyezet — telepítsd a CLI-t, vagy állítsd be a felülírást; valamint a nem futtatható fájlra mutató felülírásnál: A felülíró környezeti változó be van állítva, de nem futtatható fájlra mutat, ezért az EYAS ehhez a szolgáltatóhoz semmilyen programot nem futtat (a PATH-ra sem tér át). Javítsd vagy töröld.
Izoláció — egy állapotjelvény (Ellenőrizve, Sikertelen ellenőrzés, Még nincs ellenőrizve, Bejelentkezés szükséges) és egy mondat arról, hogyan tartja az EYAS izoláltan a CLI-t, és mikor ellenőrzi: a Claude Code-ot minden kör elején, abból, amit induláskor jelent (kör nélkül nincs ellenőrzés); a Grokot minden kör előtt a grok inspect paranccsal, modellhívás nélkül; a Kimi EYAS-os home-ját minden kör előtt, és a Kimi csak akkor számít ellenőrzöttnek, ha ezen a szerveren már elindult egy sessionje, és minden ellenőrzés sikeres volt. Utána Utolsó ellenőrzés: <idő> vagy Az EYAS indulása óta nem volt ellenőrzés. — az állapotot a memóriában tartja, így az EYAS újraindításakor alaphelyzetbe áll —, és egy Sikertelen ellenőrzések lista ugyanazokkal a címkékkel, mint a chat izolációs hibája, mindegyik a nyers részletével.
Egy sor, amely a telepített verziót összeveti azzal a verzióval, amelyen az EYAS élő izolációs kiadási ellenőrzése sikeres volt: sikeres volt ezen a verzión (verzióval és dátummal); legutóbb egy másik verzión volt sikeres, nem a telepítetten; Gépen még nincs ellenőrizve — az ellenőrzés még soha nem futott ezzel a CLI-vel, így az izolációja csak a CLI forráskódján alapul (ma a Kimi); vagy a CLI nem jelentett verziót. Minden sor azzal zárul, hogy minden kört továbbra is ellenőriz.
Fennmaradó kockázat: CLI-nként egy mondat. A Claude Code megosztja a szerver bejelentkezését, a kiadási ellenőrzés pedig API-kulccsal, valódi modellhívás nélkül futott, így arra, amit csak egy claude.ai-fiókos bejelentkezés hoz (a fiókkal szinkronizált skillek, a fiók memóriája, távolról kezelt beállítások), nem terjed ki. A kiadási ellenőrzés API-kulccsal jelentkeztette be a Grokot; azt nem figyelték meg, hogy grok.com-os bejelentkezéssel a Grok szinkronizál-e sessionöket az xAI felé. A Kimi saját kereső- és webes toolja nem kérdezi előbb az EYAS-t: ha ilyen fut, az EYAS leállítja a kört, de addigra a tool már lefutott, és az eredménye eljuthatott a Kimi modelljéhez.
Ellenőrzés most (Grok CLI és Kimi Code CLI; ownerek és adminok, akik kezelhetik a modelleket) — csak akkor látszik, ha a provider engedélyezve van, és a CLI-je megtalálható. Modellhívás nélkül újrafuttatja azokat az ellenőrzéseket, amelyeket a provider betöltése futtat: a Grok grok inspect ellenőrzését, a Kimi home-jának visszaolvasását, majd bejelentkezett állapotban egy prompt nélküli session-indítást, amely a modellistát is frissíti. Így a Kimi Még nincs ellenőrizve állapotból Ellenőrizve állapotba kerülhet. A Claude Code-nak nincs Ellenőrzés most gombja: minden kör elején ellenőrzi az EYAS. A hibák: Az azonnali ellenőrzéshez a szolgáltatónak engedélyezve kell lennie, és a CLI-jének elérhetőnek kell lennie. vagy Az ellenőrzés nem sikerült: <hiba>. A blokk be- vagy kijelentkezés után, valamint a provider be- vagy kikapcsolása után újratöltődik.

A Grok és a Kimi panelje már nem állítja, hogy a session-folytatás és a toolhasználat a gép bejelentkezését használja, vagy hogy a CLI a saját gépszintű konfigját és memóriáját tölti be: ez megszűnt igaz lenni, amikor a Grok és a Kimi az EYAS saját home-jában kezdett futni. A Kimi Code CLI alapból engedélyezve marad; a panel egyértelműen megmondja, hogy az izolációja hoston még nincs ellenőrizve.

API (integrátoroknak). A GET /api/v1/model/providers/{claude-code|grok-cli|kimi-cli}/isolation (olvasási jog a modellekhez; bármely más provider 404, session nélkül 401) ezt adja vissza: {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}, ahol a runtime {available: true, path, version, source: override|host|sdk-bundled, expectedVersion, skew} vagy {available: false, error: override-invalid|not-found|no-policy}. A POST …/isolation/verify a modellek kezelésének jogát igényli (különben 403), lefuttatja az ellenőrzéseket, és ugyanezt a nézetet adja vissza; a Claude Code, illetve a nem engedélyezett vagy nem megtalált provider 409 {code: 'verifyUnavailable'} választ ad.

Jóváhagyások. Az EYAS egy CLI jogosultsági kérdésére mindig csak egyszeri engedéllyel (allow once) válaszol. Ha a CLI csak mindig engedélyez vagy sessionre szóló lehetőséget kínál, az EYAS cancelled-del válaszol. Az elutasítás egyszeri elutasítás (reject once).

Az EYAS toolokról ugyanúgy születik döntés. Az EYAS saját tooljairól, amelyeket a Grok és a Kimi az eszközhídon át ér el (memória, board, dokumentumok, e-mail, böngésző, Odoo és így tovább), pontosan úgy születik döntés, mint az API providereknél és a Claude Code-nál:

Egy általad figyelt chatben vagy egy csatornás beszélgetésben az a hívás, amelyet a biztonsági kapu engedélyez, lefut. Egy jóváhagyást igénylőként megjelölt tool már nem vár a Jóváhagyások sorában csak azért, mert a modell Grok vagy Kimi, és az autonómia-szintek a figyelt chatekre nem vonatkoznak. Az a hívás, amelyet a kapu eszkalál, jóváhagyási kártyát mutat a beszélgetésben és egy bejegyzést a Jóváhagyások között; a chat nem áll meg.
Háttérfutásokban (ütemezett, csapat-, pipeline-futás, vagy bármely nem figyeltként megjelölt futás) az autonómia-létra érvényes: egy Értesítés vagy Jóváhagyás szintű kategóriába eső hívás jóváhagyásra vár, egy olyan hívás pedig, amelyet a kapu eszkalál, mindig emberre vár, akkor is, ha a kategóriája Automatikus szinten van (korábban egy ilyen hívás a Grokon és a Kimin kérdezés nélkül lefutott). A felügyelt futás a CLI körének végén Jóváhagyásra vár állapotban megáll, és a jóváhagyás pontosan azt a hívást engedi egyszer lefutni.
Ha egy folytatott vagy újrapróbált futás megismétel egy olyan EYAS toolhívást, amelyet az eredeti futás már befejezett (például ugyanazt az e-mailt vagy számlát), az EYAS még a futása előtt elutasítja; a toolsor Kihagyva állapotot mutat ezzel: already executed on the original run — duplicate side effect prevented. Ugyanaz a tool más argumentumokkal továbbra is lefut.
Az agent Eszközök listáján kívüli toolt az EYAS még a biztonsági kapu megkérdezése előtt Elutasítva állapottal elutasítja, így soha nem keletkezik belőle jóváhagyási bejegyzés. Futó biztonsági kapu nélkül minden hídon át érkező EYAS toolhívás elutasításra kerül.

A kiadási ellenőrzés a telepített Grok CLI-n bizonyította. Ugyanezek a döntések vonatkoznak a Kimire is, mert az EYAS-ban születnek; hogy egy valódi Kimi-bináris hogyan jelenti ezeket a hívásokat a saját streamjében (ebből épül fel egy folytatás ismétlésellenőrzése), azt hoston még nem ellenőrizték. Lásd MCP — Hogyan védett a híd.

Az elutasított hívás véget vet a Grok válaszának. Ha az EYAS elutasítja a Grok egyik toolhívását — például egy EYAS-on kívüli memória olvasását —, a Grok befejezi azt a választ (a grok 1.0.41-en ellenőrizve). A chat az elutasított tool-sort mutatja, utána semmit, és a Grok modellje nem látja az EYAS indoklását, ezért kérd újra az adott lépés nélkül. A Claude Code ezzel szemben folytatja, és megkapja az indoklást.

Fájlhozzáférés. Azok a fájlok, amelyeket a Grok vagy a Kimi az EYAS-on keresztül olvas vagy ír, a beszélgetés mappáira korlátozódnak (a még érvényes Mappákra, plusz a munkamappára), feloldott szimbolikus linkekkel — egy linkelt mappa alatti új fájlnál is. A .. kitöréseket, az érzékeny fájlokat, és ha nincs mappa, minden fájlt elutasít. Ezután a memória-policy érvényes (más eszközök memóriáját, az Obsidian vaultokat, az EYAS saját adatmappáját és más beszélgetések workspace-eit elutasítja). Minden fájlműveletet egyszer ítél meg: azt az olvasást vagy írást, amelyet a toolhívás jogosultsági kérdésén keresztül már jóváhagytak, újabb kérdés nélkül kiszolgálja. A részleges olvasás (kezdősor és sorszám) támogatott.

Háttérmunka. A Grokot és a Kimit az EYAS csak addig használja háttérhívásokhoz (címek, biztonsági bíró és így tovább), amíg az izolációjuk ellenőrzött: a Grokot a betöltéskori ellenőrzése, az Ellenőrzés most vagy bármely kör sikeres session-indítása után; a Kimit csak azután, hogy ezen a hoston elindult egy sessionje (bejelentkezett állapotban az Ellenőrzés most elindít egyet). Egy ilyen hívás nem kap EYAS toolokat, minden jogosultsági és fájlkérését elutasítja, és az első toolhívása véget vet neki. A válasza az EYAS által kért kimeneti limitben marad (lásd Claude Code modellek és effort).

Mit kap a Grok és a Kimi

Az EYAS rendszerpromptja, ellenőrizve. A Kimi minden üzenet elején megkapja az EYAS rendszerpromptját, EYAS rendszerutasításként jelölve. A Grok a saját alapértelmezett rendszerpromptját lecserélheti az EYAS-éra, de csak akkor rögzíti, melyik promptot használta, amikor a modellt már megkérdezte, ezért az EYAS minden kör után ellenőriz — a saját Grok home-jában, mielőtt az adott kör session-fájljai törlődnének. Az EYAS indulása utáni első körökben, vagy a grok program cseréje után a promptot mindkét úton elküldi (Grok-rendszerpromptként és az üzenet elején), így egyetlen válasz sem függ ellenőrizetlen úttól. Ha az ellenőrzés sikeres, a későbbi körök már csak Grok-rendszerpromptként küldik, és minden kör újra ellenőriz. Ha a modell az EYAS promptja nélkül válaszolt, az EYAS figyelmeztetést naplóz, és onnantól (újraindításig vagy új grok programig) az üzenet elején küldi a promptot. Semmit nem kell beállítani.
A teljes előzmény, képekkel együtt. Minden kör visszajátssza az EYAS beszélgetés-előzményét, a korábbi körök képeivel együtt, a helyükön. A képeket csak akkor adja át, ha a telepített CLI minden futás elején jelzi, hogy fogad képbemenetet. Ha nem, minden kép helyére egy rövid megjegyzés kerül a modellnek, például [image omitted (image/png): this model cannot see images], így a modell tudja, hogy volt ott kép; a beviteli mező küldés előtt figyelmeztet, a kör pedig értesítést mutat (lásd Képek és a képet nem látó modellek). A teljes előzmény képekkel együtt való visszajátszása minden körben prompt-tokenekbe kerül, ahogy az API providereknél is.
A Kép badge a CLI-t követi. A Grok CLI és a Kimi Code CLI modelljeinek Kép badge-e azt követi, amit a CLI minden körben jelent. A Grok CLI 1.0.40 nem jelent képbemenetet, így a Grok CLI modelleken a Kép ki van kapcsolva. A Kimi modellek az első jelentő körig megtartják az alapértéküket. Újraindítás után egy első kör előtti Modellek frissítése újra az alapértéket mutathatja; a következő kör kijavítja.

Grok modellek és effort

Az EYAS a Grok modelljeit, és hogy melyik milyen reasoning-effort szinteket fogad, magából a Grok CLI-ből olvassa ki: az EYAS Grok home-jában prompt küldése nélkül nyit egy sessiont, így nincs modellhívás és nincs költség. Például a grok-4.6 és a grok-4.7 low, medium, high és xhigh szintet kínál; a grok-4.5 low, medium és high szintet; a reasoning-vezérlés nélküli modell egyet sem. Ez minden provider-betöltéskor (EYAS indulás, provider újratöltés) és a Modellek frissítése megnyomásakor megtörténik, és kimarad, amíg a Grok nincs bejelentkezve az EYAS számára. Azt a modellt, amelyet a CLI már nem kínál, megjelöli és kikapcsolja, de soha nem törli, és egy Grok modell effort-választási lehetőségei azt követik, amit ténylegesen elfogad.

Minden körben az EYAS az üzenet elküldése előtt beállítja a választott effortot a Grok sessionben, és visszaolvassa, milyen szintet alkalmazott a Grok. A nem támogatott szintet előbb a modell által elfogadott legközelebbire igazítja (a max a grok-4.5-ön high-ként fut). Ha a Grok még így is elutasít egy szintet, a kör a Grok saját szintjén fut, és a kör ezt rögzíti. Az Automatikus semmit nem küld: a modell a saját alapértelmezésén fut (a jelenlegi Grok modelleknél high), és a kör rögzíti, melyik szint volt az. Az operátor saját ~/.grok konfigurációja, az alapértelmezett effortjával együtt, semmiről nem dönt. Minden Grok-kör azt a modellt is rögzíti, amelyet a Grok ténylegesen futtatott, ahogy a Grok jelenti.

Kimi modellek és thinking

A kimi acp figyelmen kívül hagyja a --model és a --thinking kapcsolót, ezért az EYAS minden körben megnyitja a Kimi sessiont, ellenőrzi az izolációját, majd a prompt elküldése előtt átállítja a választott modellre és thinking-változatra.

Honnan jönnek a modellek. A Kimi saját modellistájából — a saját konfigja modelljeiből, például kimi-code/kimi-for-coding a Kimi Code bejelentkezés után. Az EYAS prompt és modellhívás nélkül olvassa ki, egyetlen session megnyitásával a saját Kimi home-jában: a háttérben minden provider-betöltéskor (csak amíg a Kimi be van jelentkezve az EYAS számára) és a Modellek frissítése gomb megnyomásakor. A sorok neve Kimi Code CLI (<modellnév>). A Kimi Code CLI alapértelmezett sor azt a modellt futtatja, amelyre a Kimi épp be van állítva.
Thinking modellenként, a Kimi listája alapján. A normál és thinking-változattal is rendelkező modell Be / Ki effort-választást kap (Nincs = thinking ki, Magas = thinking be). A mindig gondolkodó modell csak a Magas szintet kínálja (a Nincs Magas lesz). A thinking nélküli modell nem kínál effort-vezérlést. Az Automatikus megtartja azt a thinking-állapotot, amelyen a Kimi épp fut, modellváltáskor is. Minden kör után az EYAS visszaolvassa, melyik modell és változat futott ténylegesen, és ezt rögzíti tényleges modellként és effortként.
A Kimi megjegyzi az utolsó választást. Amikor az EYAS modellt vált, a Kimi elmenti a saját konfigfájljába (az EYAS Kimi home-jában, soha nem a ~/.kimi-ben), és onnantól ezt használja alapértelmezésként. A Kimi Code CLI alapértelmezett sor így azt a modellt futtatja, amelyet az EYAS legutóbb bármelyik beszélgetésben kiválasztott. Stabil választáshoz egy konkrét Kimi modellt válassz.
Amíg a lista nincs kiolvasva (még nincs bejelentkezés, vagy a kiolvasás elbukott), a provider panel ezt írja: Az EYAS még nem olvasta be a Kimi modelllistáját, ezért nem tud modellt rögzíteni, és a gondolkodást sem tudja be- vagy kikapcsolni: a Kimi azt a modellt futtatja, amelyre saját maga be van állítva. Jelentkeztesd be a Kimit az EYAS számára, majd kattints a „Modellek frissítése” gombra. Ebben az állapotban az EYAS nem küld modell- vagy thinking-választást.
A Kimi által nem kínált modell a prompt előtt leállítja a kört egy hibával, amely szerint a Kimi nem kínálja azt a modellt. Soha nem cseréli le csendben egy másik modellre.
Kivezetett sorok. A rögzített Kimi Code CLI (K3), (K2.7 Code) és (K2.6) sorok Moonshot API-modelleket neveztek meg, nem Kimi CLI-modelleket, és mindig a Kimi alapértelmezését futtatták. Az első frissítés vagy felderítés után A legutóbbi frissítés már nem kínálta jelölést kapnak, és kikapcsolnak (soha nem törlődnek). Azokat a routing-szinteket, szint-tartalékokat és a Kimi provider alapértelmezését, amelyeket maga az EYAS állított rájuk, induláskor automatikusan a Kimi Code CLI (alapértelmezett) sorra állítja — hiszen mindig is azt futtatták. Az általad ezek egyikéhez rögzített beszélgetés vagy agent a nem kínálja hibával áll le; válassz helyette egy felderített Kimi modellt. Egy új, csak Kimis telepítésen minden routing-szint a Kimi Code CLI soron indul, tartalék nélkül; az agent-varázsló Opus/Sonnet/Haiku szintjei Kiminél szintén erre képeződnek le, és a költségkeret-visszaminősítésnek nincs Kimi Code CLI lépése.
Költségbecslés. A felderített Kimi Code CLI modelleket az EYAS a Kimi Code CLI alapértelmezett díjon árazza (0,95 $ be / 4 $ ki millió tokenenként).

Ez a kimi-cli 1.52.0 forráskódja alapján készült, és valódi Kimi telepítésen még nincs ellenőrizve.

Kernel fájl-sandbox

Amikor a Claude Code vagy a Grok CLI a saját tooljait futtatja — a Claude Code shellparancsait; a Grok shelljét, grepjét, fájllistázását és subagent-olvasásait —, maga az operációs rendszer tiltja meg ezeknek a tooloknak, hogy olvassák vagy írják:

más AI-toolok memóriáját (~/.claude, ~/.grok, ~/.codex, ~/.gemini, ~/.kimi, ~/.cursor, ~/.codeium, az OpenCode adatai), az EYAS által ismert Obsidian vaultokat és a security.foreignMemoryPaths útvonalait;
az EYAS saját privát adatait: a vaultot, az adatbázist, a kulcsokat és a többi CLI EYAS-os home-ját;
más beszélgetések workspace-eit.

A beszélgetés saját mappái írhatók maradnak. A sandbox macOS Seatbelt (beépített) vagy Linux bubblewrap. Az EYAS továbbra is ellenőriz minden toolhívást, amelyet lát; a sandbox azt is elkapja, amit egy shellparancs olyan módon ér el, amelyet az EYAS a parancs szövegéből nem tud kiolvasni.

CLI	Mi fut a sandboxban
Claude Code	Minden tooloket használó kör a shellparancsait a sandboxban futtatja. Linuxon bubblewrap (`bwrap`) és `socat` kell hozzá. A Claude Code saját shell-állapota (`~/.claude/shell-snapshots`, `~/.claude/session-env`) és a programmappája olvasható marad; a `~/.claude` többi része tiltott.
Grok CLI	Minden tooloket használó kör egy EYAS-os sandbox-profil alatt indítja a Grokot, amelyet az EYAS a saját Grok home-jában lévő `sandbox.toml`-ba ír (`eyas-<hash>` néven). A Grok ezt nem lazíthatja. Linuxon bubblewrap kell hozzá.
Kimi Code CLI	Nincs kernel sandboxa (Nem támogatott).

A tool nélküli háttérhívásoknak (címek, memória-menetek, a biztonsági bíró) nem kell sandbox, és soha nem kerülnek elutasításra annak hiánya miatt.

security.cliSandbox (config/local.yaml):

auto (alapértelmezett): ahol elérhető, használja a sandboxot. Ahol nem, a CLI ettől még futtatja a tooljait, a chat pedig beszélgetésenként egyszer értesítést mutat: A(z) <CLI> ezen a szerveren kernel fájl-sandbox nélkül futtatja a saját eszközeit. Az EYAS továbbra is ellenőriz minden eszközhívást, amit lát; az okot a szolgáltató beállításai mutatják. auto módban a Claude Code kérheti, hogy egy parancsot a sandboxon kívül futtasson (például egyet, amelynek a ~/.npm kell). Egy ilyen parancs mindig emberi jóváhagyásra vár a Jóváhagyások sorában — soha nem az AI-bíróra, soha nem az autonómia-létrára —, ott ezzel az indokkal: A shell command asked to run outside the kernel file sandbox…. A jóváhagyás pontosan azt az egy parancsot engedi lefutni egyszer; az autonóm futások ezen parkolnak.
required: sandbox híján a tooloket használó CLI-kört még a CLI indulása előtt elutasítja: A(z) <CLI> nem indult el: a beállításaid kernel fájl-sandboxot követelnek meg a CLI saját eszközeihez (security.cliSandbox: required), de ezen a szerveren nincs elérhető hozzá. A kört nem próbálja újra, és nem adja át másik modellnek, a tooloket használó Kimi-köröket pedig mindig elutasítja. required mellett a Claude Code soha nem futtathat parancsot a sandboxon kívül (a kérését figyelmen kívül hagyja), és nem indul el, ha a sandbox nem tud elindulni.
off nincs. Bármely más érték konfigurációs hiba: az EYAS nem indul el, a hibaüzenet pedig megnevezi a security.cliSandbox beállítást.

Hol látod. Egy CLI provider panelján van egy Kernel fájl-sandbox sor: Aktív, Ezen a szerveren nem érhető el az okkal (a bubblewrap nincs telepítve; a socat nincs telepítve; a bubblewrap itt nem tud sandboxot létrehozni, általában mert a user namespace-ek ki vannak kapcsolva; nem támogatott operációs rendszer), vagy Nem támogatott (Kimi). A required megjegyzést is mutatja, és Claude Code-nál auto módban ezt: Egy parancs, amely a sandboxon kívül akar futni, mindig a jóváhagyásodra vár. Az eyas doctor-nak van egy CLI sandbox sora (lásd CLI), a Biztonsági események pedig minden bekapcsolt CLI állapotát mutatja (lásd Biztonság és adatvédelem). A GET /api/v1/model/providers és a GET /api/v1/model/providers/:id a claude-code, a grok-cli és a kimi-cli providernél fileSandbox {status: active|unavailable|unsupported, reason, mode} mezőt ad vissza.

Docker és Kubernetes. Az EYAS image nem tartalmazza a bubblewrapot (LGPL licencű, így a telepítése az üzemeltető döntése). A kernel réteghez egy Linux hostnak vagy konténernek bubblewrap (a Claude Code-hoz socat is) és nem privilegizált user namespace-ek kellenek. Nélkülük az EYAS továbbra is elutasít minden kérést, amelyet lát, és nem érhető el állapotot mutat; required mellett a tooloket használó CLI-körök elutasításra kerülnek. Lásd Docker és Kubernetes.

Korlátok. Linuxon a Grok tiltólistája azokra a fájlokra terjed ki, amelyek a session indulásakor léteznek. A csak a .obsidian mappája alapján ismert vault akkor kerül bele, amikor az EYAS már találkozott egy benne lévő útvonallal (egy regisztrált vault vagy egy security.foreignMemoryPaths bejegyzés mindig számít). A Kiminek nincs kernel rétege.

Bizonyított CLI-verziók

Minden támogatott CLI-verziót az EYAS kiadás előtt ellenőriz: a valódi Claude Code-ot és Grok CLI-t (és ahol telepítve van, a Kimi Code CLI-t) a saját providerein keresztül futtatja egy csapdákkal teli, eldobható home-ban (mindent engedő host beállítások, nyomot hagyó hookok és MCP szerverek, CLAUDE.md, AGENTS.md, skillek, egy Obsidian-stílusú vault), és bizonyítja, hogy ezek közül semmi nem töltődik be, hogy az EYAS memória-policyja és a kernel sandbox távol tartja a vaultot és az EYAS adatmappáját, és hogy az EYAS-on kívüli memória elutasított olvasása elutasított marad. A részletek: Biztonság és adatvédelem — Hogyan bizonyított az izoláció.

CLI	Legutóbb bizonyított verzió
Claude Code	2.1.281
Grok CLI	1.0.41
Kimi Code CLI	Még nincs bizonyítva

Ellenőrizd a telepítésedet az eyas doctor-ral. CLI-nként egy CLI isolation sora van — CLI isolation (Claude Code), CLI isolation (Grok CLI), CLI isolation (Kimi Code CLI). Mindegyik mutatja, melyik binárist futtatja az EYAS: hogyan találta meg (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN, claude/grok/kimi on PATH vagy SDK-bundled), az útvonalát és a verzióját, majd:

isolation proven on this version (<dátum>) — rendben;
figyelmeztetés, ha a verzió eltér a legutóbb bizonyítottól, ha a bináris nem jelent verziót, vagy ha a CLI-t még soha nem bizonyították (ma a Kimit). A figyelmeztetés hozzáteszi, hogy az EYAS minden sessiont induláskor továbbra is ellenőriz: az ezen az oldalon leírt ellenőrzések a telepített verziótól függetlenül futnak;
not installed — rendben. Az érvénytelen EYAS_*_BIN hiba, a javítással együtt.

A Groknál és a Kiminél a sor az EYAS home-jukat is ellenőrzi, <data dir>/cli-homes/<provider>:

még nincs létrehozva — rendben, az első futás létrehozza;
szimbolikus link vagy nem mappa — hiba: az EYAS nem hajlandó futtatni a CLI-t; töröld, a következő futás újra létrehozza;
más felhasználók számára olvasható — figyelmeztetés, mert a CLI bejelentkezését tartalmazza; javítás: chmod 700 <mappa>;
egy ott lévő, az EYAS által kezelt fájl (a Grok config.toml, requirements.toml, trusted_folders.toml fájlja; a Kimi mcp.json-ja és az EYAS kulcsai a config.toml-ban) megváltozott, mióta az EYAS megírta — figyelmeztetés. Az EYAS ezeket a fájlokat a következő futás előtt újraírja, így a két futás közötti változás azt jelenti, hogy valami más szerkeszti azt a mappát.

A doctor csak olvas: csak a --version parancsot futtatja. Lásd CLI — Mit ellenőriz a doctor.

Ugyanaz a chat minden providernél

Egy beszélgetés ugyanúgy néz ki, bármelyik provider válaszol is.

Élő szöveg. A Claude Code élőben gépeli ki a válaszát és a gondolkodását, ahogy a modell írja, az API providerekhez hasonlóan.
Toolhívásonként egy sor, közös névvel. A tool-sorok azokat a neveket használják, amelyeket az EYAS minden providernél használ — read_file, run_command, edit_file, write_file, grep, glob, web_fetch, web_search —, így a fájlszerkesztések és -írások mindenhol diffként jelennek meg. Az EYAS saját toolja a sima nevén jelenik meg (memory_search, nem mcp__eyas__memory_search). Grokon és Kimin a sor nem a CLI szabad szöveges címét mutatja.
Bemenet, kimenet és időtartam. A sor mutatja, mit kértek a tooltól (a fájlt, a parancsot, a keresést, egy szerkesztés útvonalát a régi és az új szöveggel), mit adott vissza — a nagyon hosszú kimenetet 64 KiB-nál levágja, és levágottként jelöli —, és mennyi ideig tartott.
A sor csak akkor zárul le, amikor a tool végzett. Soha nem jelöli előre késznek: az elbukó vagy a tool-hívás kerete miatt kimaradó hívás sikertelenként jelenik meg, a hibával együtt.
Az elutasított hívás nem jelenik meg sikeresként. Az EYAS által elutasított hívás — a biztonsági kapu, a memória-policy miatt, jóváhagyásra várva, vagy egy folytatott futás által már elvégzett művelet ismétléseként — a saját státuszát mutatja (Elutasítva, Jóváhagyásra vár, Kihagyva) az EYAS indoklásával, soha nem zöld pipát. Azokat a hívásokat, amelyekről a CLI a tool-hívás limitjének elérése után kérdez, kihagyottként rögzíti. A jóváhagyást igénylő hívás jóváhagyó kártyát nyit a beszélgetésben, és bejegyzést kap a Jóváhagyások sorában. Lásd Beszélgetések — Tool-nyomkövetés.
A körlimit megtartja a választ. Ha egy kör eléri a körlimitjét, az addig megírt válasz megmarad, és válaszként mentődik; a kör Elérte a körlimitet kimenettel zárul, nem hibával. A valódi hiba továbbra is hibaként jelenik meg, és a részleges válasz akkor is megmarad.
Körönként egy lezárás. Egy válasz minden providernél pontosan egyszer mentődik és jelenik meg.
Ugyanaz a futásfa. A beszélgetés run tree / workflow panelje minden providernél megjelenik, API-nál és CLI-nél is, az éppen futó toollal, a körszámmal (CLI-nél a saját belső lépéseivel), a tokenekkel és a futás költségével. Lásd Beszélgetések — Run tree.
A tömörítés nem ír memóriát. Ha egy CLI egy hosszú kör közben tömöríti a saját kontextusát, a kör kontextus tömörítve értesítést mutat, és semmi nem íródik az EYAS memóriájába. Az EYAS memóriáját csak az EYAS táplálja.
A hibaüzenetek a megfelelő CLI-t nevezik meg. A Kimi hibája Kimi Code CLI-t mond, soha nem Grok CLI-t.

Miért ért véget a kör. Minden API provider ugyanazokat az okokat rögzíti: befejezve, toolhasználat, elérte a kimeneti limitet, stop-szekvencia, vagy elutasítva. Az elutasítva lefedi az Anthropic refusalját, az OpenAI content filterét és a modell elutasító üzenetét, a Gemini biztonsági osztályú leállásait (safety, prohibited content, blocklist, recitation, personal data, image safety) és azt a promptot, amelyet a Gemini egyenesen blokkolt. Az OpenAI elutasító üzenete az asszisztens válaszaként jelenik meg üres válasz helyett. A kimeneti tokenlimit miatt levágott válasz max tokens, és az így levágott toolhívás soha nem fut le. A chat ezeket a kimeneteket a válasz alatti badge-ként mutatja — lásd Beszélgetések — A kör kimenete.

A tokenszámok minden providernél ugyanazt jelentik, a CLI-ket is beleértve: az input tokenek azok a prompt-tokenek, amelyeket nem a provider cache-e szolgált ki; a cache-olvasásokat (és Anthropicnál a cache-írásokat) külön számolja; a reasoning- vagy thinking-tokenek az output tokenek részei. Az a kör, amelyre a provider nem jelentett használatot, Nincs jelentett felhasználás jelölést kap, és nem mutat árat; a trace-ét az EYAS soha nem árazza helyettesítő tokenszámokból. Az Observability a CLI saját hurkában futtatott toolokat is számolja — a Claude Code, a Grok CLI és a Kimi Code CLI körei nem mutatnak 0 toolhívást. Lásd Observability — Usage.

Toolhívás

API- és lokális providereknél a tool-hurkot az EYAS futtatja: a modell toolt kér, az EYAS lefuttatja, visszaküldi az eredményt, a modell pedig folytatja a választ. Minden hívás egy élő sor a beszélgetésben.

Provider	Mire számíts
Anthropic, Anthropic-kompatibilis endpointok (MiniMax, Synthetic, Xiaomi MiMo, …)	Az EYAS toolok futnak, a memóriatoolok is. Bekapcsolt gondolkodással — bármely effort-szinten, vagy olyan modellen, ahol mindig be van kapcsolva — a modell aláírt gondolatmenete (a redaktált gondolatmenettel együtt) változatlanul visszamegy ugyanannak a válasznak a következő kérésében, így a toolt használó, gondolkodó körök megbízhatóan működnek. Az Anthropic-kompatibilis providerek a streamelt válaszoknál is jelentik a cache-elt input tokeneket.
OpenAI	Az EYAS toolok futnak, a memóriatoolok is
Gemini	Az EYAS toolok futnak, a memóriakeresés is. A Gemini gondolkodási aláírása minden toolhívással visszamegy, így az újabb Gemini modellek a tool-hurkon át is megtartják a gondolatmenetüket. A hibát jelentő tool hibaként jut el a Geminihez. A Gemini gondolkodás-összefoglalói gondolkodásként jelennek meg a beszélgetésben, soha nem a válasz szövegében vagy a tárolt válaszban.
OpenAI-kompatibilis endpointok, Kimi API, OpenRouter	Az EYAS toolok futnak. Ha a backend normál stop-ot jelez, de közben toolokat is kér, a hurok nem ér véget idő előtt — a kért toolok lefutnak. Az ezektől a backendektől visszakapott gondolatmenet (például a DeepSeek reasoneré) gondolkodásként jelenik meg, és soha nem keveredik a válaszba. A Kimi API és az OpenRouter ugyanannak a válasznak a toolhívásos köreiben visszakapja a saját gondolatmenetét, ahogy megkövetelik.
LM Studio	Ugyanazt az OpenAI-kompatibilis kapcsolatot használja, mint a fentiek, így a toolhívások és az eredményeik (a memóriakeresés is) szabványos function callinggal jutnak a modellhez.
Ollama	Az EYAS toolok futnak. Minden tool-eredmény viseli a tool nevét, így a modell több hívásnál is tudja, melyik eredmény melyik hívásé. A gondolkodó modell gondolatmenete gondolkodásként streamelődik, a választól elkülönítve.
Claude Code CLI, Grok CLI, Kimi Code CLI	A hurkot a CLI futtatja; az EYAS toolokat MCP-n éri el — lásd MCP

A gondolatmenet a providerénél marad. A tool-hurokban visszajátszott gondolatmenet (Anthropic-család, Kimi API, OpenRouter) csak egy válaszon belül érvényes: nem tárolódik a beszélgetéssel, és a későbbi körökben nem kerül elküldésre. Ha egy kör másik providerre esik át, a gondolatmenetet annál a providernél elhagyja, és a válasz nélküle folytatódik. Ha egy leállt vagy elbukott háttérfutás az utolsó checkpointjától folytatódik, a modell egyszer újrakezdi a gondolkodást. A gondolatmenet soha nem jut el másik providerhez vagy modellhez, szövegként sem; a natív OpenAI kapcsolat pedig egyáltalán nem küld vissza gondolatmenetet.

Toolhívásonként egy sor. Egyes OpenAI-kompatibilis backendek — gyakran lokális szerverek — hívásazonosító nélkül streamelik a toolhívást. Egy ilyen hívás pontosan egy tool-sorként jelenik meg. Ez az OpenAI-ra, az OpenAI-kompatibilis providerekre, a Kimi API-ra, az OpenRouterre és az LM Studióra vonatkozik.

Tool nélküli modellek. Az a modell, amely a modellistán nem támogat toolokat — például egy Ollama-modell, amelynek a szervere nem jelez tool-képességet, vagy egy modell, amelynél kikapcsoltad a tool-támogatást —, nem kap sem toolokat, sem tool-listát a promptjában. Ha mégis toolt kér, az EYAS nem futtatja le, és a kör a modell szövegével zárul. A promptja sem mondja már neki, hogy toolokat hívjon: a memória- és megalapozási szabályok azt mondják, hogy amit az EYAS felidézett, az a <eyas-memory> blokkban érkezik, és hogy tovább nem kereshet, skill-listát és agent-névsort pedig nem kap, mert azok csak toolhívásokon át működnek. Lásd Promptok — A memória-szerződés.

Képek és a képet nem látó modellek

Hogy mely modellek látnak képet, azt a modellkatalógus adja meg: a modellistán a Kép badge. A Grok CLI-nél és a Kimi Code CLI-nél a badge azt követi, amit a telepített CLI jelent.

Ha a beszélgetés modellje nem lát képet, minden csatolt kép a helyén egy rövid megjegyzésként jut el a modellhez ([image omitted (image/png): this model cannot see images]). A modell tudja, hogy volt ott kép, de azt nem, mit ábrázol. A kört az EYAS nem utasítja el.
A kör alatt értesítés jelenik meg: A modell nem látta a képeket (N): a(z) <modell> nem lát képet… A válasszal együtt tárolódik, így újratöltés után is ott van. A szám a korábbi körök képeit is tartalmazza, így egy ilyen modellen az értesítés minden körben megjelenik, amíg a beszélgetésben képek vannak.
A beviteli mező küldés előtt figyelmeztet: csatolt képnél, olyan modellel, amely nem lát képet, a beviteli mező fölött egy chip ezt írja: A(z) <modell> nem lát képet: csak azt tudja meg, hogy kép van csatolva. God módban a chip nem jelenik meg; Auto-routingos beszélgetésnél a beszélgetésnél mutatott modell (a Normál szint) alapján dönt.
Ha az EYAS-nak nincs katalógusadata egy modellről, a képeket változatlanul küldi, és a provider dönt. Ha azt akarod, hogy a modell olvassa a képeket, válts Kép badge-dzsel rendelkező modellre.
A Claude Code a beszélgetés korábbi köreinek képeit is látja, nem csak a legutóbbi üzenetét: minden kör újraküldi az összes korábbi képet, ugyanúgy, ahogy az API providerek, így a képekben gazdag beszélgetések nagyobb promptokat küldenek.

Prompt-cache (Anthropic API)

Az Anthropic API provideren (közvetlen API-kulccsal) a prompt-cache automatikus — nincs hozzá beállítás.

Rendszerprompt. Az EYAS rendszerpromptja nem változik körről körre, mert az aktuális idő és a felidézett memória az aktuális üzenetedhez csatolva utazik. Az EYAS ezért a rendszerpromptot (az előtte lévő tooldefiníciókkal együtt) cache-elésre jelöli, és minden későbbi kör és toollépés az Anthropic cache-éből olvassa vissza.
Korábbi beszélgetés. A beszélgetés az aktuális üzenetedig szintén jelölést kap, így a következő kör visszaolvassa, ahelyett hogy újra teljes árat fizetne érte.
Toollépések. Egy toolt használó körben minden toollépés visszaolvassa az előző kérést.
Élettartam és költség. A cache 5 percig él, és minden azt használó kérés frissíti; hosszabb szünet után az első kérés újra megírja. Egy cache-írás a normál input-ár 1,25-szöröse; egy olvasás nagyjából 0,1-szerese (vagy a modell saját közzétett cache-olvasási díja, amely egyes újabb modelleknél alacsonyabb). A modell minimális cache-elhető hosszánál (modelltől függően 512–4096 token) rövidebb promptok egyszerűen nem cache-elődnek.
Hol látod. A tokenhasználat és a költségek az Anthropic API-hívásoknál cache-olvasási és cache-írási tokeneket is mutatnak.
Az Anthropic-kompatibilis, harmadik féltől származó endpointok nem kapnak cache-paramétert, mert egy ilyen endpoint elutasíthatja. A Claude Code maga kezeli a saját cache-ét.

Lokális runtime-ok

LM Studio

A beszélgetés vagy az agent hőmérséklete, maximális kimeneti tokenszáma és stop-szekvenciái a beállított értékkel mennek. Ha nincs beállítva, a modell LM Studio-beli alapértelmezése érvényes.
A modellt meg nem nevező kérés az LM Studióban éppen betöltött modellt kéri. A válaszon látható modell az LM Studio által jelentett azonosító.
A hívások a kliens szokásos időkorlátját (10 perc) használják, a megszakadt kapcsolatot pedig újrapróbálják.
Az LM_STUDIO_URL (alap http://localhost:1234) végződhet perjellel.
A gondolkodás az LM Studio saját beállítása marad: az EYAS soha nem küld reasoning- vagy effort-paramétert, a panel pedig modellenként mutatja az LM Studio által jelentett beállítást (lásd Hogyan alkalmazza az effort-szintet az egyes provider).

Ollama

A Modellek frissítése minden modell képességeit az Ollama szervertől olvassa — betöltéskor, a háttérben és frissítéskor —, így a toolokat nem támogató modellek ilyenként jelölődnek, a gondolkodó modellek pedig megkapják a thinking-vezérlésüket (lásd Hogyan alkalmazza az effort-szintet az egyes provider). Egy régebbi Ollama, amely nem jelent képességeket, bekapcsolva hagyja a toolokat.
Az Ollama alapkontextusa 4096 token. Ha egy kérés a válasszal együtt ennél többet igényel, az EYAS a num_ctx-et a következő kettőhatványra állítja (8192, 16384, …), legfeljebb a modell modellistán szereplő kontextusablakáig. Kis kéréseknél az Ollama alapértéke érintetlen marad. Az OLLAMA_CONTEXT_LENGTH továbbra is érvényes, amikor az EYAS nem állít num_ctx-et. A nagyobb num_ctx csak azoknál a kéréseknél növeli az Ollama memóriahasználatát, amelyeknek kell.

A Leállítás leállítja a lokális generálást. LM Studión és Ollamán a Leállítás azonnal leállítja a futó generálást, így a GPU rögtön felszabadul.

Kontextusablak

Az EYAS minden kör promptját ahhoz a modellhez méretezi, amelyik válaszol. Az ablak a modellistából jön (a modellenkénti kontextusméret-badge), a CLI-modelleknél is: egy 1M-es ablakkal listázott Claude Code modell 1M-et használ. A Claude Code csak a runtime saját 1M-es változatait listázza 1M-mel (például Opus (1M context)); a Fable, Opus, Sonnet és Haiku bejegyzései 200k-t listáznak, akkor is, mielőtt a runtime jelentette volna a modelljeit, így a kontextusméret-badge, a kontextussáv és a prompt méretezése az első indulástól egyezik. A CLI-k ismert ablakai — Claude Code 200k, Grok 500k, Kimi 256k — csak tartalékok arra a modellre, amelyhez a listában nincs ablak, az a modell pedig, amelyről semmi nem ismert, 200k-t használ. Nagyobb ablaknál az állítható promptszakaszok több helyet kapnak; a kis lokális modellek olyan promptot kapnak, amely helyet hagy a beszélgetésnek. Lásd Promptok — a modellhez méretezve.

A beszélgetés kontextussávja ugyanezt az ablakot használja, és ahol a provider jelenti, az utolsó modellhívás valódi promptméretét (Anthropic és Anthropic-kompatibilis, az OpenAI-család az OpenRouterrel, a Kimi API-val és az LM Studióval együtt, Gemini, Claude Code). Ha a runtime jelenti a válaszoló modell ablakát (a Claude Code ezt teszi), az nyer a modellistával szemben. Az Ollama, a Grok CLI és a Kimi Code CLI nem jelent használható, hívásonkénti promptméretet, így náluk a sáv becslés. Lásd Beszélgetések — Kontextus-összeállítás.

Adatvédelem: mit kap az egyes provider

Az adatvédelmi policy a modell felé tartó személyes adatot maszkolja, próbálkozásonként és célonként. Hogy egy provider lokális-e (maszkolatlanul kapja a szöveget), azt annak az endpointnak a hosztja dönti el, ahová küld — soha nem a provider neve:

Lokális: loopback endpoint (localhost, 127.x.x.x, ::1) vagy az adatvédelmi policyban lokális hostként felsorolt host. A helyi Ollama vagy LM Studio lokális.
Távoli (maszkolt): minden más — távoli OLLAMA_HOST, fel nem sorolt LAN-hostok, felhő API-k és minden CLI provider (Claude Code, Grok CLI, Kimi Code CLI), mert az EYAS nem látja, hová küldi a forgalmát egy CLI.

Ha egy hívás másik providerre esik át, minden próbálkozás a saját céljára maszkolódik. Ha arra építettél, hogy egy távoli Ollama host mentes, vedd fel azt a hostot a policy lokális hostjai közé. Azokat a memóriatool-eredményeket, amelyeket egy CLI az EYAS tool bridge-en kér le, ugyanígy maszkolja. Az általad küldött új üzenetet, amely block osztályú értéket tartalmaz (például egy IBAN-t), tárolás előtt elutasítja, ha távoli modellhez menne — a CLI providereket is beleértve —, és felajánlja, hogy maszkolva küldd el. A beépített OpenAI provider minden kérésnél kikapcsolja az OpenAI tárolt completionjeit is. Lásd Biztonság és adatvédelem.

Mezők és vezérlők

Provider panel

Szakasz	Jelentés
● Aktív	Badge a panel címe mellett: a provider be van kapcsolva és fut; különben Inaktív
Hitelesítés	API-kulcs, a gépen lévő Claude Code bejelentkezés, vagy a Bejelentkezés az EYAS számára kártya (Grok CLI, Kimi Code CLI)
CLI auth (Claude Code)	Nem kell API-kulcs. A Claude Code csak a bejelentkezését osztja meg ezzel a szerverrel: jelentkezz be a `claude` CLI-vel azzal a felhasználóval, amelyként az EYAS fut. A Claude Code csak akkor érhető el, ha az a CLI be van jelentkezve.
Claude Code izolációs sor	Az EYAS izoláltan futtatja a Claude Code-ot: nem tölt be a gépről CLAUDE.md-t, beállításokat, hookokat, skilleket, MCP szervereket vagy auto-memóriát, és nem hagy átiratot a ~/.claude/projects alatt. Csak a bejelentkezés közös a géppel. A host `CLAUDE.md`-tartalmához a Beállítások → Rendszer → Adat hordozhatóság → Adatok importálása lehetőségre mutat.
Bejelentkezés az EYAS számára	Csak Grok CLI / Kimi Code CLI — Bejelentkezés eszközkóddal, Inkább API-kulccsal (Grok), Mégse, Kijelentkezés — lásd Bejelentkezés a Grokba és a Kimibe az EYAS számára
Kernel fájl-sandbox	Claude Code / Grok CLI / Kimi Code CLI — Aktív, Ezen a szerveren nem érhető el (az okkal) vagy Nem támogatott, plusz a `required` megjegyzés és Claude Code-nál `auto` módban: Egy parancs, amely a sandboxon kívül akar futni, mindig a jóváhagyásodra vár. — lásd Kernel fájl-sandbox
Kimi modell-megjegyzés	Kimi Code CLI, amíg az EYAS nem olvasta be a Kimi modellistáját: Az EYAS még nem olvasta be a Kimi modelllistáját, ezért nem tud modellt rögzíteni, és a gondolkodást sem tudja be- vagy kikapcsolni…
API-kulcs mezők	Titkosítva a Titkok között; Kulcs elmentve / Nincs kulcs / Kulcs eltávolítása
Modellista	Modellek egyenkénti be- és kikapcsolása; Eszközök / Kép / kontextusméret badge-ek; Futtatott modell: <modell>, ha a konkrét modell eltér a sor azonosítójától; A legutóbbi frissítés már nem kínálta azokon a sorokon, amelyeket a legutóbbi frissítés nem adott vissza; egy Gondolkodás sor a modell effort-szintjeivel és alapértékével, és hogy honnan jönnek az adatok (a szolgáltató jelentette / EYAS-katalógus, ellenőrizve: …); LM Studión az LM Studio által jelentett gondolkodás-beállítás
Modellek frissítése	Újratölti a provider modellistáját (minden providernél). Hibánál: A frissítés nem sikerült. A modelllista változatlan maradt.

A Claude Code CLI, a Grok CLI és a Kimi Code CLI panelje a Futtatókörnyezet sort és az Izoláció blokkot is mutatja, a Groknál és a Kiminél Ellenőrzés most gombbal — lásd Futtatókörnyezet és Izoláció a provider panelen az Izolációs ellenőrzés minden kör előtt alatt. A kártyáik alcíme: Claude Code CLI, az EYAS izoláltan futtatja, Grok CLI az EYAS saját könyvtárában (ACP) és Kimi Code CLI az EYAS saját könyvtárában (ACP).

Kapcsolódó fülek

Routing és költségkeret (Útválasztási szintek + Költségkeret fül). Az Útválasztási szintek fül a Háttérben futó modellhívások kártyával nyílik, amely megmutatja, hová megy most az EYAS háttérmunkája — lásd Routing és költségkeret — A Háttérben futó modellhívások kártya.
AI-elemzés — független benchmark iframe