Fournisseurs

À quoi ça sert. Les fournisseurs sont les backends LLM de cette instance : API cloud, CLI hôte (Claude Code, Grok, Kimi) et runtimes locaux (Ollama, LM Studio, vLLM). Tu actives un fournisseur, tu ranges sa clé, tu choisis des modèles, puis le routage l’utilise. Cette page explique aussi comment EYAS tient les CLI à l’écart de la configuration propre de la machine : Claude Code tourne toujours isolé, Grok et Kimi tournent dans leur propre home EYAS et sont connectés pour EYAS, et un tour s’arrête quand EYAS ne peut pas confirmer cette isolation.

Route : /providers. Sous-titre : Routage IA, configuration des fournisseurs et contrôle du budget. Onglets : Niveaux de routage · Fournisseurs · Budget · Analyse IA.

Quand l’utiliser

Après le setup : fournisseur Activé, clé API, modèles.
claude / grok / kimi sont installés sur l’hôte et tu veux un fournisseur CLI sans clé.
Grok CLI ou Kimi Code CLI affiche Connexion requise — connecte-le pour EYAS (voir Connecter Grok et Kimi pour EYAS).
EYAS doit lancer une install précise d’une CLI (EYAS_CLAUDE_CODE_BIN, EYAS_GROK_BIN, EYAS_KIMI_BIN) — voir Runtime Claude Code et Grok CLI et Kimi Code CLI.
Un tour s’est arrêté avec une erreur d’isolation CLI et tu dois savoir quoi changer sur l’hôte.
Tu as mis à jour Claude Code, Grok CLI ou Kimi Code CLI et tu veux savoir si l’isolation d’EYAS est prouvée sur cette version (voir Versions de CLI prouvées).
Le panneau d’un fournisseur CLI indique que le Sandbox de fichiers du noyau est Indisponible sur ce serveur, ou tu veux que les tours CLI l’exigent (voir Sandbox de fichiers du noyau).
Une ligne de modèle affiche N’est plus proposé par la dernière actualisation, ou tu veux savoir quel modèle concret exécute une ligne.
Tu veux savoir quels niveaux d’effort de raisonnement un modèle propose, ce que signifie Automatique pour lui, et comment chaque fournisseur applique le niveau (voir Effort de raisonnement et Comment chaque fournisseur applique le niveau d’effort).

Déroulement typique

Fournisseurs (/providers) → onglet Fournisseurs.
Choisis une carte. Activé / Désactivé l’active pour le routage. Authentification : clé API (chiffrée dans Secrets) ; Claude Code utilise la connexion Claude Code de cette machine ; Grok CLI et Kimi Code CLI affichent une carte Se connecter pour EYAS.
Active les modèles. Actualiser les modèles recharge la liste des modèles du fournisseur — le même bouton pour chaque fournisseur, API ou CLI. Les modèles que le fournisseur ne propose plus sont désactivés et marqués, jamais supprimés.
Niveaux et dépense : Routage et budget.

Fonctions

Chaque carte affiche l’identité, la santé et l’interrupteur.

Élément	Signification
Activé / Désactivé	Active le fournisseur pour le routage
N/M modèles activés	Combien de modèles sont actifs
CLI introuvable	Binaire hôte absent
Aucune clé API	Il faut une clé
Erreur d’authentification	Identifiants refusés — ressaisir la clé ou la connexion
Connexion requise	Badge rouge sur Grok CLI / Kimi Code CLI : la CLI n’est pas connectée pour EYAS (infobulle : <CLI> n’est pas connecté pour EYAS. Ouvrez le fournisseur pour vous connecter.)

Fournisseurs intégrés (tels que listés sur les cartes)

Fournisseur	Rôle
Anthropic	Claude — les modèles que ta clé API peut utiliser, lus dans la liste des modèles d’Anthropic (liste intégrée de repli : Fable 5.1, Fable 5, Opus 5.5, Opus 5, Opus 4.8, Sonnet 5, Sonnet 4.6, Haiku 4.5)
OpenAI	GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o, GPT-4o mini intégrés ; Actualiser les modèles liste le reste
OpenRouter	Passerelle multi-fournisseurs (plus de 100 modèles)
Gemini	Google Gemini 3.x (2.5 après une actualisation, là où ta clé y a encore accès)
Kimi	API Moonshot (K3, K2.7 Code, K2.6)
Claude Code CLI	La CLI Claude Code de cette machine (`claude`), toujours isolée — voir Isolation de Claude Code
Grok CLI	ACP (`grok agent --no-leader stdio`) dans son propre home EYAS — outils EYAS via le pont CLI MCP
Kimi Code CLI	ACP (`kimi acp`) dans son propre home EYAS — même pont
Ollama / LM Studio / vLLM	Runtimes locaux — voir Runtimes locaux
xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo Gateway, Vercel AI Gateway, Qianfan, MiniMax, Synthetic, Xiaomi MiMo, …	API cloud telles que listées sur les cartes

Un seul nom partout. Les noms de ce tableau sont ceux qu’EYAS affiche sur chaque écran : les cartes et le panneau des fournisseurs, les sélecteurs de fournisseur des niveaux de routage, le sélecteur de modèle et la barre du haut de la conversation, la ligne Répondu par sous chaque réponse, les messages d’erreur du chat, le sélecteur de modèle d’un collègue, la carte Affectations de modèles dans les Paramètres, l’assistant de setup, ainsi que la carte de connexion et le bandeau d’Accueil de Grok/Kimi. Claude Code s’appelle toujours Claude Code CLI. Kimi Code CLI, Kimi et les fournisseurs compatibles (xAI, Mistral, Groq, MiniMax, Xiaomi MiMo, …) affichent leur nom de produit, jamais un identifiant comme kimi-cli. Qui ne peut pas lire le catalogue de modèles (le rôle invité) voit à la place les identifiants des fournisseurs.

API (intégrateurs). Chaque ligne de GET /api/v1/model/providers, et le détail GET /api/v1/model/providers/:id, portent le nom de produit name et un kind : cli (Claude Code, Grok CLI, Kimi Code CLI), local (Ollama, LM Studio, vLLM) ou api (toute API hébergée et tout identifiant inconnu).

Continuité des conversations

EYAS garde la conversation, pas le fournisseur. À chaque tour, EYAS envoie au modèle toute la conversation depuis son propre stockage. Aucun fournisseur CLI ne garde ni ne reprend de session à lui : Claude Code, Grok CLI et Kimi Code CLI repartent de zéro à chaque tour et reçoivent les tours précédents dans un bloc d’historique de conversation. Grok et Kimi ouvrent toujours une nouvelle session ACP et n’en chargent jamais une ancienne.

Une conversation garde donc son contexte quand tu changes de fournisseur ou de modèle, et le stockage de sessions d’une CLI n’est jamais une source de contexte ni de mémoire. La même continuité vaut pour tous les fournisseurs.

Les images collées lors de tours précédents font aussi partie de cet historique sur Grok CLI et Kimi Code CLI, chacune à l’endroit de la conversation où elle a été envoyée. Voir Ce que reçoivent Grok et Kimi.

Le coût que Claude Code rapporte pour un tour est la dépense de ce tour-là, ajoutée telle quelle.

API modèle brute (intégrateurs). POST /api/v1/model/complete et POST /api/v1/model/stream (permission use Model) valident leur corps. Champs acceptés : provider, model, messages (1 à 1000 éléments ; rôle user ou assistant ; contenu en chaîne ou en liste de blocs texte/image), system, maxTokens (entier positif), temperature (0 à 2), stopSequences (16 au plus) et un effort facultatif (un niveau de none à max, ou auto). Toute autre clé est écartée, dont sessionId, metadata, cwd, isolated, tools et thinking. Ces appels sont donc gouvernés comme autonomes (l’échelle d’autonomie s’applique), ne peuvent pas reprendre une session de fournisseur, et thinking n’y a aucun effet. La réponse, et l’événement done du flux, portent effortOutcome : le niveau demandé, le niveau réellement envoyé au modèle, et sa source (request). Un corps invalide renvoie 400 avec { error: 'ValidationError', issues }.

Modèles et Actualiser les modèles

Actualiser les modèles demande au fournisseur quels modèles il propose et enregistre, pour chaque ligne, le modèle concret qu’elle exécute (par exemple l’identifiant du modèle Grok, ou l’alias qu’utilise Claude Code). Un modèle trouvé par une actualisation continue de fonctionner après un redémarrage d’EYAS.

Chaque ligne de modèle affiche une petite ligne Exécute <modèle> quand le modèle concret diffère de l’identifiant de la ligne.
Une actualisation réussie ne fait pas qu’ajouter des modèles. Un modèle que le fournisseur ne propose plus est désactivé et marqué N’est plus proposé par la dernière actualisation. Il n’est jamais supprimé. Si une actualisation ultérieure le propose de nouveau, il est réactivé automatiquement — sauf si tu l’avais désactivé toi-même. Tu peux réactiver à la main un modèle marqué ; il reste alors sous ton contrôle.
Si l’actualisation échoue (fournisseur injoignable, non connecté, pas de clé) ou si le fournisseur ne liste aucun modèle, rien ne change et le panneau affiche L’actualisation a échoué. La liste des modèles est restée inchangée. OpenAI, Gemini, OpenRouter, Kimi (API) et les points de terminaison compatibles OpenAI signalent un tel échec au lieu d’afficher en silence la liste de modèles intégrée d’EYAS.

Agents qui ne nomment qu’un modèle. Un agent, un spécialiste ou une cible de routage qui nomme un identifiant de modèle sans fournisseur atteint le fournisseur qui a ce modèle dans sa liste de modèles activés — par exemple un modèle Grok trouvé par Actualiser, ou un modèle OpenAI plus récent. Un modèle désactivé ou inconnu, un modèle dont le fournisseur est éteint, et un identifiant de modèle que deux fournisseurs proposent tous deux échouent toujours avec No provider found for model. EYAS ne devine jamais.

Quel modèle exécute une CLI.

Grok CLI : la ligne par défaut Grok CLI (<modèle>) exécute le modèle par défaut de la Grok CLI installée elle-même. Chaque autre ligne Grok exécute exactement le modèle qu’elle nomme, y compris après un redémarrage. Une conversation ou un agent épinglé sur un modèle Grok que la CLI ne propose plus échoue avant tout envoi : Model ‘<id>’ cannot be run by this CLI: Grok CLI does not offer it (the session would run <default>). Choisis un autre modèle ou actualise la liste.
Claude Code : la liste des modèles vient du runtime Claude Code qu’EYAS lance (voir Modèles et effort de Claude Code). Chaque ligne nomme le modèle Claude concret qu’exécute son alias, par exemple opus exécute claude-opus-5-5. La ligne Claude Code (Default) exécute le modèle que le runtime utilise par défaut. Un nom de modèle complet fonctionne aussi.
Kimi Code CLI : la liste des modèles vient de Kimi lui-même, et EYAS bascule chaque session sur le modèle que tu as choisi (voir Modèles Kimi et réflexion). La ligne par défaut Kimi Code CLI exécute le modèle sur lequel Kimi est réglé en ce moment.
Un identifiant qui ne désigne aucun modèle (par exemple juste grok-cli-) fait échouer le tour avec une erreur claire au lieu d’exécuter autre chose.

Listes de modèles des API.

Anthropic : quand tu ajoutes une clé API, EYAS lit dans l’API Models d’Anthropic les modèles que cette clé peut utiliser. C’est un appel de liste gratuit, pas un appel modèle, et il apporte la fenêtre de contexte, la limite de sortie et les niveaux d’effort de chaque modèle. Si l’API Models est injoignable, la liste intégrée est utilisée. Les installs existantes gardent leur liste enregistrée jusqu’à ce que tu appuies sur Actualiser les modèles ; les modèles plus récents comme Opus 5.5, Opus 5, Sonnet 5 et Fable 5.1 apparaissent alors, et les lignes plus anciennes (Opus 4.7, Opus 4.6) continuent de fonctionner tant qu’elles sont enregistrées.
OpenAI : avant la première actualisation, la liste intégrée est GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o et GPT-4o mini. GPT-4 Turbo n’est plus intégré ; Actualiser les modèles le liste encore si OpenAI le propose. Un modèle actualisé qu’EYAS connaît déjà garde sa fenêtre de contexte et sa limite de sortie.
OpenRouter : Actualiser les modèles lit aussi quels modèles OpenRouter marque comme prenant en charge le raisonnement. La liste intégrée est Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.5, Gemini 3.1 Pro preview et GPT-4o.
Kimi API : Kimi K2.5 n’est plus intégré ; il n’apparaît que si Moonshot le liste encore lors de Actualiser les modèles.
Gemini : la liste intégrée contient les modèles 3.x actuels ; les modèles retirés gemini-2.0-flash, gemini-2.5-pro-preview-05-06 et gemini-2.5-flash-preview-05-20 ont disparu. Les installs existantes gardent leurs anciennes lignes jusqu’à ce que tu appuies sur Actualiser les modèles, qui désactive et marque ce que l’API ne propose plus. La famille 2.5 n’apparaît après une actualisation que si ta clé y a encore accès (Google réserve 2.5 aux projets qui l’utilisaient déjà). Une requête qui ne nomme aucun modèle Gemini va à gemini-3.8-flash.
Ollama : quand le fournisseur est activé et joignable, EYAS lit les capacités de chaque modèle auprès d’Ollama au chargement, en arrière-plan et lors de Actualiser les modèles. Les modèles qu’Ollama ne liste plus sont marqués N’est plus proposé par la dernière actualisation et désactivés après un chargement aussi. Un Ollama désactivé ou injoignable n’est jamais contacté.

API (intégrateurs). GET /api/v1/model/providers/:id et GET /api/v1/model/models renvoient par modèle realModelId, missing (vrai quand la dernière actualisation ne le proposait plus) et la capacité de raisonnement effective. POST /api/v1/model/providers/:id/models/refresh renvoie les listes missing et restored, ou 502 avec ModelDiscoveryFailed / ModelDiscoveryEmpty.

Effort de raisonnement

L’effort de raisonnement se décide par modèle, au moment où un modèle répond réellement. Quand le modèle change — routage, nouvelle tentative ou fallback —, EYAS recalcule le niveau pour le nouveau modèle.

Un niveau que le modèle ne prend pas en charge est ajusté au plus proche qu’il accepte. Maximum sur un modèle qui plafonne à Très élevé tourne en Très élevé ; Très élevé sur un modèle qui ne l’a pas tourne en Élevé.
Un modèle qui ne peut pas couper le raisonnement reçoit son niveau le plus bas quand Aucun est demandé.
Un modèle sur lequel EYAS n’a aucune donnée vérifiée ne reçoit aucun paramètre de raisonnement (Automatique : le défaut propre du modèle). EYAS n’envoie jamais une valeur devinée.
Les budgets de réflexion des modèles qui prennent un budget de tokens (par exemple Claude Haiku 4.5 ou Gemini 2.5) sont dimensionnés d’après la limite de sortie propre du modèle et laissent toujours de la place à la réponse : Maximum ne peut pas dépasser la limite du modèle.

L’échelle. L’échelle complète est Aucun, Minimal, Faible, Moyen, Élevé, Très élevé, Maximum, plus Automatique. Automatique n’enregistre rien à cet endroit : le niveau vient alors de plus bas dans l’ordre ci-dessous, et quand rien n’en fixe un, rien n’est envoyé et le défaut propre du modèle s’applique.

D’où vient le niveau (la première correspondance gagne) :

l’Effort propre de la conversation ;
Maximum quand la conversation est en mode Deep ;
l’effort réglé sur le collègue (agent) au nom duquel parle la conversation — dans un chat, le collègue de la conversation, sinon le collègue par défaut du projet ;
le niveau de la conversation la plus proche qui a délégué le travail (une sous-conversation hérite de son parent, jusqu’à cinq niveaux plus haut) ;
le défaut du niveau de routage, pour un message routé par un niveau et pour les appels d’arrière-plan d’EYAS (voir Routage et budget — Effort par défaut du niveau) ;
le défaut propre du modèle.

Le même ordre s’applique partout où un collègue ou un spécialiste tourne : chat interactif, fil d’accueil d’un collègue, exécutions d’arrière-plan et planifiées, nouvelles tentatives et reprises (une exécution reprise utilise exactement l’effort de sa première exécution), membres d’équipe, tâches déléguées et spécialistes, étapes de pipeline, tâches A2A, réponses sur les canaux de messagerie, et God Mode. L’effort propre d’un collègue s’applique donc dans son chat et sur les canaux, et un membre d’équipe ou un spécialiste sans effort propre hérite du niveau de la conversation qui délègue — une conversation Deep envoie donc ses spécialistes en Maximum, ce qui coûte plus cher. Un membre ou un spécialiste qui a son propre effort le garde. En God Mode, un effort réglé sur la conversation est copié sur chaque concurrent et le mode Deep leur est transmis ; le niveau de chaque concurrent est ensuite ajusté à son propre modèle, et les votes de la revue croisée utilisent aussi l’effort de la conversation.

Un seul sélecteur Effort, par modèle. La barre de champs de la conversation, l’éditeur de collègue, chaque niveau de routage et une routine d’agent planifiée utilisent tous le même sélecteur Effort. Il ne liste que les niveaux qu’accepte le modèle concerné — par exemple Très élevé sur les modèles qui le proposent (Claude Opus 4.7/4.8/5.x, GPT-5.4/5.5/5.6), Aucun et Minimal là où le modèle les a. Un modèle à bascule affiche Désactivé / Activé. Un modèle sans réglage d’effort, ou sur lequel EYAS n’a pas de données vérifiées, ne propose qu’Automatique, et une indication dit pourquoi ; une indication signale aussi quand un modèle n’affiche pas le texte de son raisonnement. Dans une conversation en routage automatique, ou pour un collègue sans modèle fixe, aucun modèle unique n’est fixé : le sélecteur propose chaque niveau qu’accepte au moins un modèle d’un niveau de routage automatique (Rapide, Standard, Complexe, Exécution de code), et le niveau de chaque message est ajusté au modèle sur lequel il tourne.

Automatique dit ce qu’il signifie. Automatique est la première entrée et nomme ce sur quoi il se rabat à cet endroit : Automatique · Maximum (Profond), Automatique · Élevé (collègue), Automatique · Très élevé (conversation qui délègue), ou Automatique · défaut du modèle (Moyen) — le défaut propre du fournisseur du modèle.

La liste suit le modèle. Quand le modèle, le mode Deep ou le collègue d’une conversation change, la liste se met à jour. Un nouveau modèle ne réécrit jamais l’effort enregistré d’une conversation : un niveau que le nouveau modèle n’a pas s’affiche par exemple Très élevé → Élevé (Opus 4.6 ne propose pas Très élevé), et chaque tour est ajusté et enregistré. Dans l’éditeur de collègue et sur un niveau de routage, choisir un modèle qui ne propose pas le niveau enregistré le modifie avant l’enregistrement et le signale : Effort ajusté de Très élevé à Élevé : le modèle choisi ne propose pas Très élevé. Un modèle sans réglage d’effort le ramène à Automatique.

Les niveaux enregistrés sont vérifiés contre le modèle. Quand tu règles un effort sur une conversation, un collègue ou un niveau de routage, EYAS vérifie le niveau contre le modèle sur lequel il tourne. Un niveau que ce modèle ne prend pas en charge est refusé et rien n’est enregistré — la conversation liste les niveaux qu’il accepte, et une ligne de niveau indique Le modèle ne propose pas ce niveau d’effort. Rien n’a été enregistré. Automatique est toujours accepté, et tout niveau l’est aussi quand le modèle n’est pas connu d’avance (une conversation en routage automatique, un collègue sans modèle, un modèle sur lequel EYAS n’a pas de données vérifiées) ; ceux-là sont ajustés à chaque appel. Changer seulement le modèle n’échoue jamais à cause d’un effort enregistré.

Ce avec quoi chaque réponse a tourné. Sous chaque réponse, à côté de Fournisseur · modèle, une petite puce montre l’effort avec lequel le tour a réellement tourné : Effort : Élevé, ou Effort : Très élevé → Élevé quand le modèle ne proposait pas le niveau demandé. Son info-bulle nomme qui l’a fixé (conversation, Profond, collègue, conversation qui délègue, niveau de routage, défaut du modèle). Il n’y a pas de puce quand rien n’a été demandé ni envoyé. Chaque réponse enregistrée garde l’effort demandé et l’effort effectif, l’origine du niveau et s’il a été ajusté — pour le chat, les exécutions déléguées et de spécialiste, les étapes de pipeline et les canaux. La trace de chaque appel IA enregistre la même chose — voir Observabilité.

Ce qu’affiche la page Fournisseurs. Chaque ligne de modèle a une ligne de raisonnement, par exemple Raisonnement : Faible, Moyen, Élevé, Très élevé, Maximum · défaut Moyen, avec un badge qui dit d’où viennent ces données : signalé par le fournisseur (la propre liste de modèles du fournisseur ou du runtime), ou catalogue EYAS, vérifié le AAAA-MM-JJ (le catalogue versionné d’EYAS des données de raisonnement vérifiées). Un modèle sans réglage d’effort affiche Raisonnement : aucun réglage d’effort ; un modèle qu’EYAS ne connaît pas affiche Raisonnement : inconnu d’EYAS (l’effort reste Automatique).

API (intégrateurs). GET /api/v1/model/effort-options?providerId&modelId (lecture Model) renvoie les niveaux d’un modèle ; avec un identifiant de modèle nu ou un alias, les niveaux du modèle de son unique fournisseur ; sans modèle, l’union des niveaux de routage automatique. GET /api/v1/conversations/:id/effort-options (lecture Conversation, propriétaire seulement) renvoie les niveaux, le niveau enregistré (current) et ce dont Automatique hérite (inherited). Un niveau refusé renvoie 400 avec le code EFFORT_UNSUPPORTED, le niveau et les levels pris en charge par le modèle.

Comment chaque fournisseur applique le niveau d’effort

EYAS détermine un niveau par appel, comme ci-dessus, et chaque fournisseur ne fait que le traduire. Dans tous les cas, EYAS n’envoie que ce que le modèle qui répond est connu pour accepter ; un modèle sans données vérifiées ne reçoit aucun paramètre de raisonnement.

Fournisseur	Ce qu’EYAS envoie pour un niveau	D’où viennent les niveaux	Automatique	Niveau effectif sous la réponse
API Anthropic	Le réglage d’effort du modèle (quand il en a un) plus la réflexion — adaptative, ou un budget de tokens là où le modèle en prend un ; Aucun coupe la réflexion là où le modèle le permet	L’API Models d’Anthropic, avec les données qu’elle ne signale pas (défaut, toujours actif, plage de budget) depuis le catalogue EYAS	Rien ; un modèle qui réfléchit par défaut mais cache son raisonnement reçoit seulement la demande d’un résumé	Le niveau qu’EYAS a envoyé
Points de terminaison compatibles Anthropic (MiniMax, Synthetic, Xiaomi MiMo)	Rien	— (aucune donnée vérifiée)	Toujours	—
OpenAI	`reasoning_effort`, avec la limite de sortie en `max_completion_tokens` et sans température	Catalogue EYAS	Rien	Le niveau qu’EYAS a envoyé
OpenRouter	`reasoning: { effort }` ; OpenRouter le transmet au modèle en amont et peut l’ajuster	La liste des modèles d’OpenRouter (raisonnement oui/non) ; les familles connues depuis le catalogue EYAS	Rien	Le niveau qu’EYAS a envoyé
API Kimi (Moonshot)	`reasoning_effort` (K3) ou réflexion activée/désactivée (K2.6) ; sans température	Catalogue EYAS	Rien	Le niveau qu’EYAS a envoyé
Passerelles compatibles OpenAI (xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo, Vercel AI Gateway, Qianfan, vLLM)	Rien — sauf `reasoning_effort` pour Grok 3 Mini d’xAI	Catalogue EYAS pour Grok 3 Mini sur xAI ; le réglage du raisonnement d’aucune autre passerelle n’est encore vérifié	Toujours, sauf Grok 3 Mini	Le niveau qu’EYAS a envoyé (Grok 3 Mini) ; sinon —
Gemini	Un niveau de réflexion (Gemini 3) ou un budget de réflexion (Gemini 2.5), avec les résumés de pensée	Catalogue EYAS ; la liste des modèles de Google peut marquer un modèle comme sans réflexion	Rien ; les modèles qui réfléchissent par défaut reçoivent seulement la demande de leurs résumés	Le niveau qu’EYAS a envoyé
Ollama	`think` : activé/désactivé, ou le niveau nommé propre au modèle	Les informations de modèle d’Ollama (la capacité thinking et ses valeurs) ; gpt-oss depuis le catalogue EYAS	Rien	Le niveau qu’EYAS a envoyé
LM Studio	Rien — le raisonnement se règle dans LM Studio	—	Toujours ; le panneau affiche le réglage propre de LM Studio	—
Claude Code CLI	L’effort que le binaire en cours a signalé pour le modèle ; Aucun coupe la réflexion là où le modèle le permet	Le runtime Claude Code lui-même, lu sans prompt	Rien	Relu dans le runtime
Grok CLI	L’option d’effort de raisonnement de la session, réglée avant le prompt	La Grok CLI elle-même, lue sans prompt	Rien ; le tour enregistre le niveau utilisé par Grok	Relu auprès de Grok à chaque tour
Kimi Code CLI	La variante à réflexion ou normale du modèle, choisie dans la session	La propre liste de modèles de Kimi	Garde la variante que Kimi exécute en ce moment	Relu auprès de Kimi à chaque tour

Le niveau qu’EYAS a envoyé signifie que la puce sous la réponse montre le niveau après qu’EYAS l’a ajusté au modèle. Relu signifie que la CLI rapporte le niveau avec lequel elle a réellement tourné, et c’est ce que la puce et la trace enregistrent, même quand il diffère de ce qu’EYAS a demandé.

Détails par fournisseur.

API Anthropic. Les choix pour un modèle Claude sont exactement les niveaux qu’il prend en charge : Très élevé existe sur Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8 et Sonnet 5, mais pas sur Opus 4.6 ni Sonnet 4.6 ; Désactivé n’est proposé que là où le modèle peut couper le raisonnement (pas sur Fable ni Opus 5.5). Haiku 4.5 et Sonnet 4.5 n’ont pas de réglage d’effort : le niveau devient donc un budget de réflexion dimensionné d’après la limite de sortie du modèle, et EYAS relève la limite de longueur de la réponse pour que le raisonnement ne coupe jamais la réponse. Automatique n’envoie rien (Opus 5.5 vaut Moyen par défaut ; Opus 4.8 ne réfléchit pas sauf demande). Les modèles qui cachent leur raisonnement sauf demande (Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8, Sonnet 5) reçoivent la demande d’un résumé de raisonnement chaque fois qu’ils réfléchissent — en Automatique aussi pour ceux qui réfléchissent par défaut —, qui s’affiche donc dans le chat ; cela ne change que ce qui est affiché. EYAS n’envoie pas de température, de top_p ni de top_k aux modèles qui les refusent (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), et jamais avec une réflexion activée.
Points de terminaison compatibles Anthropic (MiniMax, Synthetic, Xiaomi MiMo) : seulement Automatique. EYAS n’envoie aucun réglage de raisonnement tant que le comportement d’un modèle n’est pas vérifié ; la température est transmise telle que réglée.
OpenAI. Chaque modèle de la génération GPT-5 que sert l’API Chat Completions, et la série o, reçoivent le niveau, chacun avec sa propre plage : GPT-6 Astra Faible–Maximum (ne peut pas être coupé) ; GPT-5.6 Aucun–Maximum, défaut Moyen ; GPT-5.5 Aucun–Très élevé, défaut Moyen ; GPT-5.4 Aucun–Très élevé, défaut Aucun ; GPT-5.4 mini / nano et GPT-5.2 Aucun–Très élevé, défaut Aucun ; GPT-5.1 Aucun–Élevé, défaut Aucun ; GPT-5 / GPT-5 mini / nano Minimal–Élevé, défaut Moyen ; GPT-5 pro Élevé seulement ; o1 / o3 / o3-mini / o4-mini Faible–Élevé, défaut Moyen. Un niveau absent passe au plus proche (Maximum sur GPT-5.5 tourne en Très élevé). À ces modèles de raisonnement, EYAS n’envoie jamais de température et utilise la limite de sortie des modèles de raisonnement (max_completion_tokens) — appels d’arrière-plan comme la capture mémoire compris, qui pouvaient auparavant être rejetés par GPT-5.2 et GPT-5.4 mini / nano. Avec un niveau explicite, une petite limite de sortie est relevée à ce dont le niveau a besoin (Faible 8k, Moyen 16k, Élevé 32k, Très élevé/Maximum 64k tokens, jamais au-dessus de la limite propre du modèle). Les modèles sans données vérifiées (GPT-4o, GPT-4o mini et autres) ne reçoivent aucun paramètre de raisonnement et gardent max_tokens et la température. Certains modèles OpenAI n’existent que sur l’API Responses d’OpenAI, pas sur l’API Chat Completions qu’utilise EYAS : GPT-5.2 pro, GPT-5.4 pro, GPT-5.5 pro, les modèles Codex (GPT-5 Codex, GPT-5.1 Codex / Codex Max, GPT-5.2 / 5.3 Codex, codex-mini), o1-pro, o3-pro et les modèles deep-research. Sur le fournisseur OpenAI, ils restent en Automatique seulement et ne peuvent pas répondre ; utilise-les via OpenRouter. GPT-5.1 mini n’a pas de niveaux d’effort publiés : il reste donc en Automatique.
OpenRouter. Les modèles qu’OpenRouter marque comme prenant en charge le raisonnement proposent Minimal–Maximum ; les modèles qu’il liste sans raisonnement n’ont pas de réglage d’effort. Les familles connues affichent leurs vrais niveaux : Claude Opus/Sonnet 4.6 (Désactivé, Faible, Moyen, Élevé, Maximum), OpenAI GPT-5.x / GPT-6 Astra / série o (comme sur OpenAI), Gemini 3.x (les niveaux de réflexion de Gemini, donc Très élevé tourne en Élevé). Également connus : GPT-5.2 Aucun–Très élevé (défaut Aucun) ; GPT-5.2 pro Moyen–Très élevé ; GPT-5.4 pro Moyen–Très élevé (défaut Moyen) ; GPT-5.5 pro Moyen–Très élevé (défaut Élevé) ; GPT-5.4 mini / nano comme sur OpenAI ; GPT-5.2 / 5.3 Codex Faible–Très élevé. Désactivé n’est proposé que là où la famille peut couper le raisonnement.
API Kimi (Moonshot). Kimi K3 : Faible / Élevé / Maximum (défaut Maximum ; Moyen tourne en Faible). Kimi K2.6 : raisonnement activé (Élevé) ou désactivé (Aucun). Kimi K2.7 Code et K2.7 Code Highspeed raisonnent toujours et n’ont pas de réglage d’effort.
Passerelles compatibles OpenAI : seulement Automatique, identifiants préfixés par un fournisseur comme openai/gpt-5.4 compris. Sur le fournisseur API xAI, Grok 3 Mini (et Grok 3 Mini Fast) est le seul modèle avec un réglage d’effort : Faible ou Élevé (Moyen tourne en Faible ; Très élevé et Maximum tournent en Élevé). Il raisonne toujours, et son raisonnement est affiché. xAI ne liste plus Grok 3 Mini, et Oracle Cloud l’a retiré le 2026-08-15 : il se peut donc qu’il ne réponde plus. Les autres modèles Grok sur l’API xAI raisonnent au défaut d’xAI : EYAS parle à xAI via Chat Completions, où xAI ne documente pour eux aucun paramètre d’effort. Le fournisseur Grok CLI garde son réglage d’effort.
Gemini. Les modèles Gemini 3 (3.8/3.7/3.6/3.5 Flash, 3.5/3.1 Flash-Lite, 3.1 Pro Preview, 3 Flash Preview) prennent un niveau de réflexion — Minimal, Faible, Moyen ou Élevé. Un niveau absent passe au plus proche (3.8/3.7 Flash et 3.1 Pro n’ont pas Minimal, qui devient Faible ; Très élevé et Maximum deviennent Élevé). Les modèles Gemini 3 réfléchissent toujours : Aucun les fait donc tourner à leur niveau le plus bas. Les modèles Gemini 2.5 prennent un budget de réflexion dérivé du niveau, dans la plage du modèle (2.5 Pro 128–32 768 tokens ; 2.5 Flash jusqu’à 24 576 ; Flash-Lite 512–24 576) ; Aucun coupe la réflexion sur 2.5 Flash et Flash-Lite, tandis que 2.5 Pro tourne à son niveau le plus bas. Google facture les tokens de réflexion dans tous les cas. Une petite limite de sortie est relevée pour tenir le niveau, jamais au-dessus de la limite propre du modèle. Les modèles que la liste de Google marque comme sans réflexion (par exemple les variantes TTS) ne reçoivent aucun paramètre de réflexion.
Ollama. Les modèles qui signalent la capacité thinking reçoivent Activé / Désactivé : Aucun coupe la réflexion, tout niveau plus haut l’active. gpt-oss prend Faible, Moyen et Élevé (défaut Moyen) et ne peut pas être coupé (Aucun devient Faible). Un Ollama récent qui signale les valeurs de réflexion exactes d’un modèle reçoit exactement celles-là, avec le défaut d’Ollama marqué. Automatique n’envoie rien (les modèles à réflexion réfléchissent par défaut). Un modèle sans cette capacité, ou dont les capacités n’ont pas pu être lues, ne reçoit jamais de réglage de réflexion — Ollama refuserait la requête. Avec un niveau explicite, un petit réglage max-tokens est relevé pour laisser de la place à la réflexion.
LM Studio. EYAS n’envoie jamais de paramètre de raisonnement ou d’effort à LM Studio : tout niveau y revient donc à Automatique. Quand LM Studio signale le réglage de raisonnement d’un modèle, le panneau LM Studio l’affiche par modèle, par exemple qwen/qwen3-8b — Le raisonnement de ce modèle se règle dans LM Studio lui-même (valeur par défaut : on). EYAS l’affiche sans le modifier. Les versions plus anciennes de LM Studio n’affichent pas d’indication.
Claude Code CLI, Grok CLI, Kimi Code CLI. Voir Modèles et effort de Claude Code, Modèles et effort de Grok et Modèles Kimi et réflexion.
OpenCode est un sidecar d’outils, pas un fournisseur de chat : son modèle et sa variante de raisonnement se règlent sur la page OpenCode (voir OpenCode — Modèle et raisonnement).

Nouvelles versions d’un modèle connu. Un instantané daté, un alias -latest ou une variante de contexte [1m] d’un modèle qu’EYAS connaît reçoit les niveaux de ce modèle — par exemple gpt-5.4-mini-2026-03-17 ou kimi-k3-0115. Une autre variante (pro, codex, chat, preview, beta, fast, …) ou une famille de modèles inconnue reste en Automatique seulement jusqu’à ce qu’EYAS ait des données vérifiées pour elle. Les niveaux ne passent jamais d’un fournisseur à un autre.

Runtime Claude Code

EYAS lance la CLI Claude Code que tu as installée, et utilise un seul binaire pour tout : la vérification de connexion, la disponibilité du fournisseur, l’auto-setup du premier démarrage, la découverte des modèles et chaque tour de conversation. Ce qu’affiche eyas doctor est ce qui tourne. Le binaire est choisi dans cet ordre :

EYAS_CLAUDE_CODE_BIN — un chemin absolu vers l’exécutable claude.
Le claude trouvé sur le PATH du serveur.
En dernier recours, l’ancienne copie de Claude Code embarquée dans la dépendance Agent SDK d’EYAS (actuellement 2.1.89). eyas doctor avertit quand elle est utilisée.

EYAS_CLAUDE_CODE_BIN est une variable d’environnement à dessein, pas un réglage d’UI. Utilise-la quand le PATH du service n’a pas claude (services launchd/systemd, conteneurs) ou pour épingler une install précise. Si elle est définie mais invalide (pas absolue, absente ou non exécutable), le fournisseur Claude Code reste éteint : il n’y a aucun repli vers le PATH ni vers la copie embarquée, et doctor signale un échec.

Décalage de version. Le client SDK d’EYAS a été construit pour Claude Code 2.1.89. Une CLI plus récente est utilisée telle quelle, et doctor affiche un avertissement version skew. Les options que seules les CLI plus récentes comprennent ne sont envoyées qu’aux runtimes qui les ont (par exemple la réflexion résumée, à partir de 2.1.280). Claude Code ne se met pas à jour lui-même pendant qu’EYAS le lance (voir Isolation de Claude Code) ; mets-le à jour toi-même comme d’habitude, puis regarde sa ligne doctor (voir Versions de CLI prouvées).

Connecté, pas seulement installé. EYAS vérifie la connexion avec claude auth status --json, une commande locale qui n’ouvre aucune session, n’envoie aucun prompt et ne coûte rien. Le fournisseur Claude Code s’enregistre — et une install neuve l’active automatiquement — seulement quand ce binaire est connecté : login claude.ai, ANTHROPIC_API_KEY, ou une configuration Bedrock/Vertex. Que claude soit simplement sur le PATH ne suffit pas. Si tu te connectes plus tard, éteins puis rallume le fournisseur sous Fournisseurs, ou redémarre EYAS. L’e-mail et l’organisation du compte que la commande affiche ne sont jamais logués ni stockés.

Pas d’appels modèle cachés. EYAS n’envoie jamais de prompt de test à la CLI hôte pour la vérifier ou lister ses modèles. La liste des modèles est lue dans le runtime lui-même, sans prompt — voir ci-dessous.

Réflexion (thinking). EYAS ne coupe pas la réflexion sur les tours Claude Code, sauf si Aucun est demandé. Quand aucun effort n’est demandé, le défaut propre du modèle s’applique. Un niveau demandé n’est envoyé que comme l’effort que ce runtime a signalé pour le modèle ; aucun budget fixe de tokens de réflexion n’est envoyé. Pour l’échelle et l’origine d’un niveau, voir Effort de raisonnement.

Modèles et effort de Claude Code

La liste des modèles vient du runtime. EYAS demande au runtime Claude Code qu’il lance réellement — le même binaire que celui qu’affiche eyas doctor — quels modèles il propose. Cela se produit à chaque démarrage du fournisseur et quand tu appuies sur Actualiser les modèles. Aucun prompt n’est envoyé, cela ne coûte rien et tourne isolé de tes propres réglages Claude Code ; les détails du compte contenus dans cette réponse ne sont jamais lus ni stockés.

Chaque entrée nomme le modèle Claude concret qu’exécute son alias, par exemple opus exécute claude-opus-5-5. L’entrée Claude Code (Default) exécute le modèle que le runtime utilise par défaut.
Les entrées que le runtime cesse de proposer sont désactivées et marquées, jamais supprimées — par exemple Fable est désactivé sur un runtime qui ne le connaît pas.
Les niveaux d’effort par modèle sont exactement ceux que signale le runtime, y compris Très élevé là où il le propose. Un modèle pour lequel le runtime ne propose aucun réglage d’effort, comme Haiku, ne propose qu’Automatique. Automatique n’envoie rien : le défaut propre du modèle s’applique (par exemple Moyen sur Opus 5.5).
EYAS n’envoie jamais un niveau que le binaire en cours n’a pas signalé pour ce modèle. Si les niveaux enregistrés viennent d’une autre version de Claude Code, aucun niveau n’est envoyé jusqu’au prochain démarrage ou à la prochaine actualisation.
La réflexion résumée (pour que le raisonnement du modèle soit visible dans le chat) est demandée à partir de Claude Code 2.1.280. Un Claude Code plus ancien — y compris la copie 2.1.89 embarquée avec EYAS — n’offre aucun moyen de la demander : pour les modèles qui cachent leur réflexion sauf demande (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), le sélecteur d’effort dit alors Ce modèle n’affiche pas le texte de son raisonnement. Les niveaux d’effort eux-mêmes ne changent pas. Mets Claude Code à jour en 2.1.280 ou plus récent et actualise les modèles (ou redémarre EYAS) pour voir le raisonnement.
Fenêtre de contexte. Les entrées Fable, Opus, Sonnet et Haiku indiquent une fenêtre de 200k — celle que le runtime donne à ces noms —, y compris au premier démarrage ou tant que la liste des modèles du runtime ne peut pas être lue. Seule une entrée que le runtime propose lui-même comme sa variante 1M (par exemple Opus (1M context), alias opus[1m]) est listée et dimensionnée à 1M. Quand le runtime indique une fenêtre plus grande pour le modèle qui a répondu, la barre de contexte utilise toujours celle-là. Une entrée qu’une version antérieure a enregistrée à 1M, et qu’aucune lecture des modèles n’a confirmée depuis, est corrigée à 200k au démarrage suivant, même si la lecture des modèles continue d’échouer ; les entrées que tu as désactivées restent désactivées.
L’effort effectif est relu dans le runtime à chaque tour : tu demandes Très élevé et le runtime exécute Élevé, et la réponse le dit ; avec Automatique, la réponse nomme le niveau que le modèle a réellement utilisé.
Chaque réponse enregistre le modèle concret qui a répondu, dans les traces et l’attribution mémoire. Un tour sans modèle choisi est attribué à Claude Code (Default).

Appels d’arrière-plan sur une CLI. Les appels modèle d’arrière-plan (capture mémoire, titres, contrôles de sécurité) n’utilisent un modèle précis de Claude Code, Grok CLI ou Kimi Code CLI venu d’un niveau de routage que si la découverte propre de cette CLI a proposé ce modèle ; sinon ils tournent sur le modèle par défaut de la CLI. Où part en ce moment le travail d’arrière-plan d’EYAS, c’est Routage et budget — Appels de modèle en arrière-plan qui le montre.

Les appels d’arrière-plan gardent leur limite de sortie sur une CLI. Les petits appels ponctuels propres d’EYAS — titres de conversation, tri des messages, capture mémoire, verdict du juge de sécurité, consolidation et passes d’arrière-plan semblables — demandent une longueur de réponse maximale. Les CLI ne prennent aucune limite de sortie d’EYAS : sur Claude Code, Grok CLI et Kimi Code CLI, EYAS compte donc la réponse au fil du flux : dès qu’elle dépasse environ quatre caractères par token demandé (maxTokens × 4 caractères), EYAS arrête la CLI (Claude Code : la requête est fermée ; Grok et Kimi : la session est annulée). L’appel se termine alors normalement avec la réponse obtenue jusque-là et la raison d’arrêt max tokens (Limite de sortie atteinte), jamais avec une erreur — comme sur les fournisseurs API. Seule la réponse compte ; le raisonnement n’entame pas la limite. Les tours de chat et d’agent avec outils ne sont pas concernés, car un tour de CLI exécute de nombreux appels au modèle. La vérification de publication le prouve sur Claude Code 2.1.281 et Grok CLI 1.0.41 ; Kimi Code CLI utilise le même chemin de code mais n’a pas été testé en direct.

Isolation de Claude Code

EYAS lance toujours Claude Code isolé. Il n’y a pas d’interrupteur : l’ancienne option Charger la config Claude de l’hôte a disparu. Le panneau du fournisseur le dit en une ligne et renvoie à l’import de données pour faire entrer le contenu CLAUDE.md de l’hôte.

Chaque exécution de Claude Code — chat, agents, travail d’arrière-plan et appels ponctuels isolés :

ne charge ni settings.json de l’hôte (donc ni hooks ni règles de permission), ni CLAUDE.md à aucun niveau (utilisateur, projet ou local), ni skills de l’hôte, ni .mcp.json de projet, ni serveurs MCP du système de fichiers ou de claude.ai. Son seul serveur d’outils est le serveur eyas propre à EYAS ; les appels ponctuels d’arrière-plan n’en reçoivent aucun ;
tourne avec l’auto-mémoire propre de Claude Code désactivée ;
garde ses fichiers temporaires, y compris la sortie des commandes shell qu’il lance en arrière-plan, dans un dossier propre à cette exécution, dans le dossier des workspaces d’EYAS — pas dans le /tmp/claude-<uid> de l’hôte. Le dossier est supprimé à la fin de l’exécution ; celui qu’un plantage a laissé est supprimé au démarrage suivant ;
n’écrit aucune transcription sous ~/.claude/projects et ne fait aucune copie de checkpoint de fichiers : les exécutions EYAS n’apparaissent donc pas dans claude --resume (les transcriptions écrites par des versions antérieures d’EYAS ne sont pas supprimées automatiquement) ;
garde la connexion de l’hôte : un abonnement claude.ai, une clé API, un jeton OAuth, Bedrock ou Vertex continuent de fonctionner.

Les réglages de politique gérés par une entreprise, là où une organisation les déploie, s’appliquent toujours ; EYAS ne peut pas désactiver ce niveau.

Les fichiers d’instructions de projet dans le dossier d’une conversation (CLAUDE.md, AGENTS.md) ne sont pas non plus chargés automatiquement. Le modèle peut toujours les ouvrir avec ses outils fichier.

Dossier de travail. Claude Code travaille dans le premier Dossier de la conversation qui passe encore la validation, sinon dans l’espace de travail EYAS propre de la conversation. Il ne tourne jamais dans le répertoire propre du serveur EYAS (le home EYAS, où vivent le fichier de clé, le coffre et la base). Les appels d’arrière-plan sans conversation utilisent un dossier de travail temporaire par exécution, supprimé après 7 jours d’inutilisation. Un Dossier enregistré qui ne passe plus la validation est ignoré, avec un avertissement dans le log du serveur. Voir Conversations — Dossiers.

Environnement. Claude Code ne reçoit qu’un environnement en liste blanche : PATH, locale et fuseau horaire, proxys et bundles CA, HOME, et les variables de connexion Anthropic / Claude OAuth / Bedrock / Vertex. Par-dessus, EYAS pose ses interrupteurs d’isolation — CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, CLAUDE_CODE_DISABLE_CLAUDE_MDS=1 et DISABLE_AUTOUPDATER=1 —, fait pointer CLAUDE_CODE_TMPDIR vers le dossier temporaire propre à l’exécution et s’identifie auprès de Claude Code comme eyas. Les autres variables du serveur ne sont pas transmises : les clés API des autres fournisseurs, les secrets EYAS, CLAUDE_CONFIG_DIR, et les interrupteurs CLAUDE_CODE_* d’une session Claude Code depuis laquelle EYAS aurait été démarré. La vérification de connexion (claude auth status) utilise le même environnement. À cause de DISABLE_AUTOUPDATER, Claude Code ne se met pas à jour lui-même pendant qu’EYAS le lance.

Vérification au démarrage. Claude Code rapporte ce qu’il a chargé au début de chaque exécution, et EYAS vérifie ce rapport avant d’utiliser quoi que ce soit de la réponse. Seul le serveur d’outils propre à EYAS peut être connecté, le mode de permission doit être default, le dossier de travail doit être celui attendu, et aucun plugin ne peut être chargé — sauf les deux plugins intégrés à Claude Code 2.1.281, agents-md et telemetry, acceptés seulement sous la forme agents-md@builtin et telemetry@builtin. La vérification d’EYAS avant chaque version a prouvé qu’ils sont inoffensifs sous son isolation : aucun AGENTS.md du dossier de travail ou d’un sous-dossier n’atteint le modèle. Tout autre plugin, y compris un nouveau plugin intégré d’une version ultérieure de Claude Code, arrête toujours l’exécution. Si autre chose apparaît — par exemple un serveur MCP ou un plugin venu de la configuration de l’hôte, ou une politique gérée qui impose un autre mode de permission —, EYAS arrête l’exécution aussitôt. Rien de cette exécution n’est affiché, et le tour échoue avec une erreur d’isolation CLI qui nomme les vérifications en échec dans votre langue — par exemple Claude Code CLI a été arrêté : EYAS n’a pas pu confirmer qu’il s’exécute isolé (le dossier de travail n’était pas celui choisi par EYAS). Le tour n’a pas été confié à un autre modèle. Il n’est pas retenté et n’est pas confié à un autre fournisseur. La correction se fait sur l’hôte : retire le réglage géré ou le plugin en cause, ou vérifie vers quel binaire pointe EYAS_CLAUDE_CODE_BIN.

Les outils propres de Claude Code passent d’abord la politique mémoire d’EYAS. Avant que Read, Write, Edit, Glob, Grep, Bash, NotebookEdit, WebFetch ou tout autre outil de Claude Code ne s’exécute, une vérification compare chaque chemin qu’il touche à la politique mémoire d’EYAS — y compris les lectures que Claude Code s’autoriserait sinon tout seul dans son dossier de travail. La mémoire d’autres outils (~/.claude, ~/.grok, ~/.codex, les coffres Obsidian, le reste de la liste et security.foreignMemoryPaths), le dossier de données propre d’EYAS et l’espace de travail d’une autre conversation sont refusés. Un appel refusé ne s’exécute pas ; Claude Code reçoit la raison — par exemple Memory outside EYAS (Obsidian) — use memory_search / memory_expand from EYAS — et peut continuer avec les outils mémoire d’EYAS. Grep, Glob, LS et les recherches Bash récursives sont jugés sur tout ce qu’ils peuvent atteindre : une recherche dont le dossier contient un emplacement protégé — par exemple un Grep de ~, ou un Grep du checkout d’EYAS, qui contient data/ — est refusée comme Search too broad …, et Claude Code peut réessayer sur un dossier plus restreint. Voir Sécurité et confidentialité — Mémoire hors d’EYAS. En plus de cette vérification, les commandes shell de Claude Code tournent dans le sandbox de fichiers du système d’exploitation là où il est disponible — voir Sandbox de fichiers du noyau.

Les outils EYAS sur Claude Code. Claude Code atteint les outils EYAS via le serveur MCP in-process eyas, nommés mcp__eyas__<nom> dans son prompt. Ce serveur propose exactement les outils qu’EYAS propose à l’exécution : la liste Outils de l’agent plus memory_search et memory_expand (une liste vide signifie tous les outils). Dans une conversation Solo, il ne propose aucun outil de délégation. Les outils EYAS pour lesquels Claude Code a un équivalent propre autorisé ne sont pas transmis — read_file, grep et glob (ses Read, Glob et Grep), write_file et edit_file tant qu’il peut écrire, et run_command, git_status et git_diff tant qu’il peut utiliser son shell : Claude Code utilise alors ses propres outils dans les dossiers du tour, sous le sandbox et la politique mémoire. Sur une liste sans run_command, git_status et git_diff sont transmis à la place comme outils EYAS. Tous les autres outils EYAS sont transmis, y compris les outils navigateur d’EYAS (browser_*, avec les sessions enregistrées et browser_totp), agent_browser_*, browser_use_* et opencode_* ; ils tournent dans EYAS sous le même portail de sécurité, les mêmes approbations et la même portée d’outils que sur un fournisseur API. L’exploration de la mémoire compte 3 appels par réponse, comme sur tous les autres fournisseurs. Voir MCP — parité d’outils CLI MCP.

La liste Outils de l’agent limite aussi les outils propres de la CLI. Sur Claude Code, Grok CLI et Kimi Code CLI de la même façon, la liste Outils d’un agent décide quels outils intégrés propres de la CLI le modèle peut utiliser, et pas seulement quels outils EYAS il atteint via le pont — de la même façon qu’elle limite un modèle API :

Écriture de fichiers (Write, Edit et NotebookEdit de Claude Code ; les outils d’édition et de déplacement de Grok et Kimi, et les écritures de fichiers qu’EYAS sert à la CLI) : seulement quand la liste contient write_file ou edit_file.
Commandes shell (Bash de Claude Code ; les outils d’exécution de Grok et Kimi ; une suppression compte aussi comme commande shell, comme la classe le portail de sécurité) : seulement quand la liste contient run_command. git_status et git_diff n’accordent pas le shell.
Récupération et recherche web (WebFetch et WebSearch de Claude Code ; les outils de récupération de Grok et Kimi, et web_fetch et web_search de Grok) : seulement quand la liste contient un outil web — research, browser_navigate, agent_browser_run ou browser_use_exec.
Lecture de fichiers (Read, Glob et Grep de Claude Code ; les outils de lecture, de recherche et de liste de Grok et Kimi) : toujours permise, quoi que dise la liste. Elle reste dans les dossiers de la conversation, sous la politique mémoire et le sandbox de fichiers du noyau. La recherche en mémoire est toujours disponible aussi.
Une liste vide signifie toujours tous les outils, outils propres de la CLI compris.

Sur Claude Code, les outils retenus ne sont pas du tout proposés au modèle. Sur Grok et Kimi, un outil retenu que la CLI tente d’utiliser est refusé par EYAS avant que le portail de sécurité soit consulté : il n’y a pas de demande d’approbation, et la ligne d’outil affiche Refusé (Grok affiche son propre texte de rejet sur la ligne). Les demandes de permission de Kimi ne disent pas quel type d’outil demande (lu dans le source de Kimi 1.52.0 ; pas encore vérifié sur un hôte) : EYAS refuse donc une demande Kimi qu’il ne peut pas classer dès que la liste de l’agent n’a pas les outils d’écriture de fichiers ou run_command — un tel agent ne peut utiliser aucun des outils de Kimi qui demandent (écriture ou remplacement de fichier, shell, tâches d’arrière-plan). La recherche et la récupération web de Kimi ne demandent jamais rien à EYAS : elles ne peuvent donc pas être permises par agent ; la vérification d’isolation d’EYAS arrête toujours un tour qui les utilise. Migration : les agents existants avec une liste restreinte — par exemple un Assistant personnel sans run_command / write_file — ne peuvent plus écrire de fichiers ni lancer de commandes sur Claude Code, Grok ou Kimi. Pour le permettre, ajoute write_file / edit_file et/ou run_command à la liste, ou vide la liste. Voir Agents — Outils.

Spécialistes. Claude Code ne lance pas de sous-agents cachés à lui (son outil intégré Task/Agent n’est pas proposé). Quand un collègue sur Claude Code répartit le travail, il lance les spécialistes via EYAS avec run_specialist, exactement comme sur les autres fournisseurs — voir Équipes et délégation.

Mise à jour. Une install qui avait Charger la config Claude de l’hôte activé passe automatiquement en isolé ; le réglage enregistré est supprimé au premier démarrage, et toute valeur restante est ignorée. Les instructions CLAUDE.md et les skills de l’hôte n’atteignent plus les conversations. Pour garder ce contenu, importe-le une fois, à sens unique, avec Paramètres → Système → Portabilité des données → Importer des données — voir Import de données.

Grok CLI et Kimi Code CLI

EYAS lance Grok CLI et Kimi Code CLI entièrement isolées de la configuration Grok, Kimi et Claude propre de la machine.

Home propre. EYAS démarre chaque CLI avec son propre dossier home dans le dossier de données d’EYAS — <répertoire de données>/cli-homes/grok-cli et <répertoire de données>/cli-homes/kimi-cli. Les exécutions EYAS ne lisent ni n’écrivent les ~/.grok, ~/.kimi, ~/.claude, ~/.cursor ou ~/.agents de l’opérateur : ni config, règles ou AGENTS.md de l’hôte, ni mémoire, skills, hooks, imports Claude/Cursor ou serveurs MCP (par exemple un serveur de coffre Obsidian).

Environnement. Seule une courte liste blanche atteint la CLI : PATH, locale et fuseau horaire, TMPDIR, TERM, USER, LOGNAME, SHELL, variables de proxy et de bundle CA. Les secrets EYAS, les clés des autres fournisseurs, un XAI_API_KEY dans l’environnement du serveur et tout réglage GROK_*, KIMI_* ou XDG_* du serveur sont écartés.

Quel binaire. EYAS_GROK_BIN / EYAS_KIMI_BIN (le chemin absolu de l’exécutable) ont la priorité, sinon grok / kimi sur le PATH. Si la variable est définie mais invalide, le fournisseur n’est pas enregistré — il n’y a pas de repli vers le PATH. Recharger le fournisseur (désactiver puis activer) retrouve le binaire.

Dossier de travail. Un tour Grok ou Kimi tourne dans le premier Dossier valide de la conversation, sinon dans l’espace de travail EYAS propre de la conversation, sinon dans un dossier de travail privé de l’exécution — jamais dans le répertoire de travail propre du serveur EYAS.

Réglages Grok qu’EYAS écrit. Avant chaque exécution, EYAS écrit config.toml, requirements.toml et un trusted_folders.toml vide dans son home Grok ; les modifications locales y sont remplacées. Ils fixent :

Mode demande. Chaque outil natif de Grok — lire un fichier, lister un dossier, chercher, shell, écrire/modifier, récupération et recherche web, sous-agents — demande d’abord à EYAS, et c’est le portail de sécurité d’EYAS qui décide.
L’approbation automatique est verrouillée. --always-approve, le mode yolo et /always-approve ne fonctionnent pas.
La mémoire, la mémoire v2, la recherche de sessions, la télémétrie et l’envoi de traces, le mode leader partagé (Grok est démarré avec --no-leader) et la mise à jour automatique sont désactivés.
Seul le serveur d’outils propre à EYAS (eyas) peut se connecter.
La confiance de dossier n’est jamais accordée. Les AGENTS.md, config .grok, hooks et serveurs MCP du dossier d’une conversation ne sont pas chargés automatiquement ; le modèle peut toujours ouvrir des fichiers avec ses outils fichier, et chaque lecture demande à EYAS.

Réglages Kimi qu’EYAS écrit. EYAS pose default_yolo = false, telemetry = false et merge_all_available_skills = false dans sa propre config Kimi et garde tout le reste de ce fichier (connexion, modèle par défaut). Kimi ne reçoit aucun serveur MCP à lui, la mise à jour automatique est désactivée, et il est démarré exactement comme kimi acp. Kimi enregistre aussi dans ce même fichier le modèle sur lequel EYAS le bascule — voir Modèles Kimi et réflexion.

Les fichiers de session sont supprimés. Les transcriptions, l’historique des prompts et les journaux d’outils qu’une CLI écrit dans son home EYAS sont supprimés à la fin de chaque tour. Les restes de plus d’une heure (après un crash) sont supprimés au démarrage et toutes les heures. La conversation EYAS elle-même n’est pas concernée : EYAS la rejoue depuis son propre stockage à chaque tour.

Le shell de Grok. Les commandes shell de Grok tournent avec le home Grok d’EYAS comme HOME : le ~/.gitconfig, les clés SSH et la configuration shell de l’hôte ne sont donc pas disponibles — par exemple, les commits git depuis le shell de Grok n’ont pas l’identité de l’hôte. Là où le serveur en propose un, les propres outils de Grok tournent aussi dans le sandbox de fichiers du système d’exploitation — voir Sandbox de fichiers du noyau.

Limite de tours. Pour Grok et Kimi, la limite de tours compte les appels d’outils. Un tour de chat utilise les Tours max. du collègue de la conversation (sinon ceux de l’agent par défaut du projet), ou 25 par défaut ; les exécutions d’agent utilisent les Tours max. de l’agent ; le réglage maxTurns du fournisseur (25 par défaut) ne s’applique qu’aux appels qui ne fixent aucun budget. Quand la CLI démarre un appel d’outil de plus que la limite, EYAS annule la session CLI : le tour se termine en max turns et garde la réponse partielle. Ce n’est pas une erreur, et l’appel d’outil en trop ne s’exécute pas. Le même budget est le plafond de tours interne de Claude Code pour un tour de chat.

Pas de limite de temps fixe. Un tour Claude Code, Grok ou Kimi n’est pas arrêté au bout d’une durée fixe. Il ne s’arrête que quand la CLI se tait : 10 minutes sans message quand aucun outil ne tourne, ou 20 minutes sans message pendant qu’un outil tourne (par exemple un spécialiste lancé avec run_specialist, qui peut prendre jusqu’à 15 minutes, ou un long build). Tout message de la CLI — texte diffusé, un outil qui démarre ou se termine, une demande de permission — relance le compteur, et le tour entier n’a pas de limite ; Arrêter le termine toujours à tout moment. Un tour arrêté pour silence signale un délai dépassé (timeout), pas une erreur générique aborted ; comme les autres délais dépassés, il peut être retenté une fois ou basculer quand rien n’a encore été diffusé, et une exécution d’arrière-plan peut être relancée par le planificateur de nouvelles tentatives automatiques. Les deux limites sont model.cli.idleTimeoutMs et model.cli.toolTimeoutMs — voir Configuration — Délais des tours CLI. La clé par tour qui permet à Grok et Kimi d’appeler les outils EYAS expire 2 heures après sa dernière utilisation : un tour long et chargé garde donc ses outils EYAS ; elle est révoquée dès la fin du tour.

Commandes slash. Un message qui commence par / (par exemple /always-approve on) est envoyé à Grok ou Kimi entouré de <message>…</message>, pour que la CLI ne l’exécute jamais comme l’une de ses propres commandes. Le modèle voit toujours le texte.

Limites de Kimi. L’isolation de Kimi est déduite de son code source et n’a pas encore été prouvée sur une machine (voir Versions de CLI prouvées). Kimi n’a pas de contrôle de confiance de dossier : il lit toujours AGENTS.md / .kimi/AGENTS.md dans le dossier de la conversation, et jusqu’à la racine du dépôt git englobant quand le dossier est dans un dépôt. Ses outils de recherche et web ne demandent jamais à EYAS : un tour Kimi qui les utilise est donc arrêté par la vérification d’isolation ci-dessous. Pour la même raison, EYAS ne peut pas refuser une recherche Kimi comme trop large : les propres Grep et Glob de Kimi ne demandent jamais rien, le Glob de Kimi reste dans son dossier de travail mais son Grep accepte n’importe quel dossier, et Kimi n’a pas de sandbox noyau (voir Sécurité et confidentialité — Mémoire hors d’EYAS). La liste Outils de l’agent limite les propres outils d’écriture, shell et web de Kimi et de Grok comme décrit sous Isolation de Claude Code.

Comme Grok et Kimi tournent dans le home propre à EYAS, la connexion de la CLI sur l’ordinateur n’est pas utilisée. Une install qui s’appuyait sur la connexion de l’hôte n’a plus de modèle Grok ou Kimi fonctionnel tant que quelqu’un ne s’est pas connecté une fois pour EYAS. La connexion grok / kimi propre à l’opérateur sur l’hôte n’est jamais lue, modifiée ni utilisée, et la connexion EYAS se rafraîchit d’elle-même.

La carte Se connecter pour EYAS apparaît à trois endroits : le panneau du fournisseur Grok CLI / Kimi Code CLI, l’étape Fournisseur d’IA de l’assistant de setup dès que Grok ou Kimi est détecté, et un bandeau de l’Accueil, <CLI> doit être connecté pour EYAS, quand une CLI activée et installée n’est pas connectée (Se connecter ouvre la carte ; Ignorer masque le bandeau pour la session du navigateur). Seuls les propriétaires et administrateurs peuvent se connecter ou se déconnecter, et eux seuls voient le lien et le code d’une connexion en attente ; les autres rôles voient l’état.

Code d’appareil (Grok et Kimi). Clique sur Se connecter avec un code d’appareil. EYAS lance la connexion propre de la CLI dans son propre dossier et affiche un lien (Ouvrir la page de connexion) et un code. Ouvre le lien sur n’importe quel appareil, connecte-toi, et vérifie que la page affiche le même code. Aucun navigateur n’est nécessaire sur le serveur : cela fonctionne donc sur les serveurs headless et dans Docker. La carte affiche En attente de la confirmation du code…, puis Connecté.

Annuler arrête une connexion en attente.
Après 15 minutes sans confirmation, la connexion expire ; recommence. Kimi redémarre aussi de lui-même avec un nouveau code.
Si EYAS ne trouve pas de lien dans la sortie de la CLI, il affiche le texte de la CLI tel quel pour que tu puisses le suivre.
Un échec affiche le dernier message de la CLI et Réessayer.

Clé API à la place (Grok seulement). Choisis Utiliser plutôt une clé d’API et colle une clé API xAI. EYAS la stocke chiffrée dans Secrets sous grok-cli-api-key (portée Système) et ne la transmet qu’aux exécutions de Grok CLI, en XAI_API_KEY. L’utilisation est facturée au compte API xAI, pas à un abonnement Grok/SuperGrok. Si une connexion par code d’appareil et une clé existent toutes deux, Grok utilise la connexion par code d’appareil. Tu peux aussi ajouter la clé sur la page Secrets sous ce nom ; EYAS la prend en compte à l’ouverture du panneau du fournisseur ou de la carte de l’assistant, au rechargement du fournisseur, ou après le premier tour qui échoue avec l’erreur de connexion. Kimi n’a pas d’option de clé API dans EYAS.

Se déconnecter retire l’identifiant Grok ou Kimi d’EYAS du dossier d’EYAS et supprime la clé API enregistrée. Pour Grok, EYAS lance grok logout dans son propre dossier. Pour Kimi, EYAS supprime son propre fichier d’identifiants et ne lance pas kimi logout, car cette commande effacerait aussi le jeton Kimi de l’opérateur du trousseau du système. La connexion de l’hôte n’est jamais touchée.

Sans connexion, un tour de conversation ou d’arrière-plan sur ce fournisseur échoue aussitôt, avant le démarrage de la CLI, avec <fournisseur> n’est pas connecté pour EYAS … connectez-vous dans Fournisseurs (code d’erreur cliSignIn). EYAS ne le retente pas et ne bascule pas en silence vers un autre fournisseur. Un échec d’authentification que la CLI signale pendant un tour donne le même message.

Où vivent les identifiants : <répertoire de données>/cli-homes/grok-cli/.grok/auth.json et <répertoire de données>/cli-homes/kimi-cli/.kimi/credentials/kimi-code.json, dans des dossiers que seul l’utilisateur EYAS peut ouvrir. Une sauvegarde du répertoire de données les contient.

API (intégrateurs, propriétaires/administrateurs ; accès en lecture pour GET). GET /api/v1/model/providers/{grok-cli|kimi-cli}/sign-in renvoie {signedIn, method: device|apiKey|null, apiKeySupported, apiKeyStored, session{state: pending|succeeded|failed|expired|cancelled, verificationUrl, userCode, rawPrompt, error}}. POST {"method":"device"} renvoie 202 — interroge GET tant que c’est en attente. POST {"method":"apiKey","apiKey":"…"} renvoie 200 (Grok seulement ; Kimi renvoie 400). DELETE déconnecte ; DELETE ?target=session annule seulement une connexion par code d’appareil en attente. Les autres fournisseurs renvoient 404. Qui ne peut pas gérer les modèles reçoit verificationUrl, userCode, rawPrompt et error à null : celui qui confirme le code lie son propre compte au dossier d’EYAS.

La connexion de Kimi suit le code source de la CLI Kimi et n’est pas encore vérifiée sur un vrai hôte.

Vérification d’isolation avant chaque tour

Grok CLI et Kimi Code CLI ne tournent qu’après qu’EYAS a vérifié qu’elles sont isolées. Un tour qui échoue à une vérification s’arrête avec une erreur d’isolation ; il n’est jamais retenté ni confié discrètement à un autre modèle.

Grok est vérifié avant chaque tour, sans appel modèle : EYAS lance grok inspect --json dans le dossier de la conversation, avec son home Grok EYAS, et relit les fichiers de config qu’il y a écrits. Une vérification réussie est réutilisée pendant 10 minutes pour le même binaire Grok, le même dossier et le même home ; tout ce qui est déposé dans le home (une skill, une règle ou un hook) force une nouvelle vérification. Grok est refusé quand :

il pourrait approuver des appels d’outils de lui-même (le verrou d’approbation automatique n’est pas en vigueur) ;
des règles de permission ou une couche de config viennent d’ailleurs que des fichiers propres à EYAS — par exemple un fichier de config Grok global au système, ou des réglages gérés de Claude Code qui ajoutent des règles de permission ;
il démarrerait un serveur MCP autre que le pont propre à EYAS (les serveurs que la liste blanche d’EYAS a désactivés ne posent pas de problème) ;
des hooks, des plugins ou des serveurs de langage sont configurés ;
des fichiers d’instructions, des skills ou des agents viennent de son home ou d’en dehors des dossiers de la conversation ;
les imports Claude, Cursor ou Codex sont activés ;
la config propre d’un dossier de projet marqué comme fiable s’applique.

Le fichier de réglages gérés par l’éditeur de Grok. grok 1.0.41 écrit un cache des réglages gérés par l’éditeur, managed_config.toml, dans son home Grok EYAS ; pour un compte normal, il est vide. Un fichier vide est accepté. Un fichier qui contient un réglage quelconque refuse le tour avec les vérifications ci-dessus (par exemple approbation des outils non liée à EYAS), et tout changement de ce fichier invalide aussitôt une vérification réussie, même pendant les 10 minutes où elle est normalement réutilisée.

Les fichiers d’instructions de projet (AGENTS.md, CLAUDE.md, .grok/rules) dans les dossiers de la conversation ne sont pas une raison de refus : le dossier n’est jamais marqué comme fiable, donc Grok ne les charge pas de lui-même, mais le modèle peut les lire avec ses outils fichier. Les serveurs MCP ou hooks de projet dans un tel dossier sont listés par Grok mais jamais démarrés.

Kimi est vérifié depuis son home EYAS, parce qu’il n’a pas de commande d’inspection : dans data/cli-homes/kimi-cli/.kimi/config.toml, l’approbation automatique doit être désactivée, la fusion des dossiers de skills de l’hôte désactivée, sans hooks ni dossiers de skills supplémentaires ; mcp.json doit être vide ; et les dossiers de skills du home ne doivent contenir aucune skill. Kimi doit aussi garder ses données dans le home Kimi d’EYAS : si son dossier de partage pointait ailleurs, la vérification arrête le tour et l’actualisation des modèles (affiché comme approbation des outils non liée à EYAS), si bien qu’un changement de modèle ne peut jamais écrire hors de ce home.

Au démarrage de la session, une session qui commence dans un mode qui approuve des appels d’outils de lui-même est arrêtée.

Pendant le tour, EYAS arrête le tour si Grok ou Kimi démarre ou termine un outil natif sans qu’EYAS ait décidé à son sujet (lecture ou écriture de fichier, recherche, liste, shell, web, sous-agent, recherche d’outil, ou un outil MCP qui n’est pas celui d’EYAS), ou appelle son propre outil de mémoire. EYAS annule alors la session, termine le tour avec l’erreur d’isolation, et n’utilise rien de ce que la CLI dit ensuite. Les outils propres d’EYAS (mémoire, tableau, etc. — atteints par Grok via use_tool sous la forme eyas__<nom>) ne font pas partie de cette vérification, car EYAS décide lui-même de chacun de ces appels — voir Les outils EYAS reçoivent les mêmes décisions plus bas.

Le message du chat se lit par exemple : Grok CLI a été arrêté : EYAS n’a pas pu confirmer qu’il s’exécute isolé (serveurs MCP autres que ceux d’EYAS, hooks). Le tour n’a pas été confié à un autre modèle. Il est suivi d’un lien Ouvrir les réglages du fournisseur. Les vérifications qu’il peut nommer sont : approbation des outils non liée à EYAS ; serveurs MCP autres que ceux d’EYAS ; hooks ; plugins ou extensions ; instructions ou skills venant d’en dehors de la conversation ; la mémoire propre de la CLI ; imports depuis d’autres outils d’IA ; un processus leader partagé ; un dossier de projet marqué comme fiable ; un outil exécuté sans l’approbation d’EYAS ; la vérification n’a pas pu s’exécuter.

Pour revérifier, supprime la cause — par exemple le serveur MCP, le hook, la skill ou l’AGENTS.md en trop dans le home Grok ou Kimi d’EYAS, ou une config Grok globale au système — et renvoie le message. Chaque tour revérifie. Recharger ou réactiver le fournisseur, ou redémarrer EYAS, lance la vérification de Grok au chargement, et Vérifier maintenant sur le panneau du fournisseur lance les mêmes vérifications sans appel au modèle (voir Environnement d’exécution et Isolation sur le panneau du fournisseur plus bas). Les homes EYAS sont vérifiés par eyas doctor (voir Versions de CLI prouvées).

Environnement d’exécution et Isolation sur le panneau du fournisseur. Sélectionne la carte Claude Code CLI, Grok CLI ou Kimi Code CLI sous Fournisseurs :

Environnement d’exécution — comment EYAS a trouvé le binaire, sa version et son chemin. Sources : CLI de l’hôte dans le PATH, Remplacement par l’opérateur (variable d’environnement) (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN) ou Environnement d’exécution intégré (secours) (Claude Code seulement). La version est celle de la CLI ; une CLI qui n’en indique aucune affiche version inconnue. Lignes supplémentaires : La version X diffère de la version attendue (Y) (le binaire Claude Code diffère de la version pour laquelle l’Agent SDK épinglé d’EYAS a été construit) ; Une CLI du PATH (version) n’est pas utilisée. (un remplacement masque une autre CLI du PATH) ; Non connecté (Claude Code seulement — Grok et Kimi affichent leur connexion sur la carte Se connecter pour EYAS) ; Aucun environnement d’exécution utilisable — installez la CLI ou définissez le remplacement ; et, pour un remplacement qui ne désigne pas un fichier exécutable, La variable de remplacement est définie mais ne désigne pas un fichier exécutable : EYAS n’exécute donc aucun binaire pour ce fournisseur (sans jamais se rabattre sur le PATH). Corrigez-la ou supprimez-la.
Isolation — un badge d’état (Vérifiée, Vérification échouée, Pas encore vérifiée, Connexion requise) et une phrase sur la façon dont EYAS garde la CLI isolée et le moment où il vérifie : Claude Code au début de chaque tour, à partir de ce qu’il indique au démarrage (il n’y a pas de vérification sans tour) ; Grok avant chaque tour avec grok inspect, sans appel au modèle ; le home EYAS de Kimi avant chaque tour, et Kimi ne compte comme vérifiée qu’après qu’une session a démarré sur ce serveur avec toutes les vérifications réussies. Ensuite Dernière vérification : <heure> ou Pas vérifiée depuis le démarrage d’EYAS. — l’état est gardé en mémoire, il se réinitialise donc au redémarrage d’EYAS — et une liste Vérifications échouées avec les mêmes libellés que l’erreur d’isolation du chat, chacun avec son détail brut.
Une ligne qui compare la version installée à celle sur laquelle la vérification de publication d’isolation d’EYAS en direct a réussi : réussie sur cette version (avec version et date) ; réussie pour la dernière fois sur une autre version, pas sur celle installée ; Pas encore vérifiée sur un hôte — la vérification n’a jamais tourné avec cette CLI, son isolation repose donc uniquement sur le code source de la CLI (Kimi aujourd’hui) ; ou la CLI n’a indiqué aucune version. Chaque ligne se termine en rappelant que chaque tour reste vérifié.
Risque résiduel : une phrase par CLI. Claude Code partage la connexion du serveur, et la vérification de publication a utilisé une clé API sans véritable appel au modèle : ce qu’apporte seulement une connexion avec un compte claude.ai (skills synchronisées avec le compte, mémoire du compte, paramètres gérés à distance) n’est pas couvert. La vérification de publication a connecté Grok avec une clé API ; on n’a pas observé si une connexion grok.com fait synchroniser des sessions avec xAI. Les outils de recherche et web propres à Kimi ne demandent pas d’abord l’accord d’EYAS : EYAS arrête le tour dès que l’un d’eux s’exécute, mais il s’est alors déjà exécuté et son résultat peut déjà atteindre le modèle de Kimi.
Vérifier maintenant (Grok CLI et Kimi Code CLI ; propriétaires et admins, qui peuvent gérer les modèles) — affiché seulement quand le fournisseur est activé et que sa CLI a été trouvée. Il relance les vérifications qu’un chargement du fournisseur exécute, sans appel au modèle : la vérification grok inspect de Grok, la relecture du home de Kimi, puis, si la CLI est connectée, un démarrage de session sans prompt, qui actualise aussi la liste des modèles. Kimi peut ainsi passer de Pas encore vérifiée à Vérifiée. Claude Code n’a pas de Vérifier maintenant : il est vérifié au début de chaque tour. Les erreurs se lisent « Vérifier maintenant » exige que le fournisseur soit activé et que sa CLI soit trouvée. ou La vérification a échoué : <erreur>. Le bloc se recharge après une connexion ou une déconnexion et après l’activation ou la désactivation du fournisseur.

Les panneaux Grok et Kimi ne disent plus que la reprise de session et l’usage des outils passent par la connexion de l’hôte, ni que la CLI charge sa propre config et sa mémoire au niveau de la machine : ce n’est plus vrai depuis que Grok et Kimi tournent dans le home propre d’EYAS. Kimi Code CLI reste activé par défaut ; le panneau dit clairement que son isolation n’est pas encore vérifiée sur un hôte.

API (intégrateurs). GET /api/v1/model/providers/{claude-code|grok-cli|kimi-cli}/isolation (accès en lecture aux modèles ; tout autre fournisseur donne 404, sans session 401) renvoie {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}, où runtime vaut {available: true, path, version, source: override|host|sdk-bundled, expectedVersion, skew} ou {available: false, error: override-invalid|not-found|no-policy}. POST …/isolation/verify exige le droit de gérer les modèles (sinon 403), lance les vérifications et renvoie la même vue ; Claude Code, ou un fournisseur non activé ou introuvable, renvoie 409 {code: 'verifyUnavailable'}.

Approbations. EYAS ne répond jamais à une demande de permission d’une CLI autrement que par autoriser une fois. Si la CLI ne propose qu’une option toujours autoriser ou valable pour toute la session, EYAS répond annulé. Un refus est refuser une fois.

Les outils EYAS reçoivent les mêmes décisions. Les outils propres d’EYAS que Grok et Kimi atteignent via le pont d’outils (mémoire, tableau, documents, e-mail, navigateur, Odoo, etc.) sont décidés exactement comme sur les fournisseurs API et Claude Code :

Dans un chat que tu suis, ou une conversation de canal, un appel que le portail de sécurité autorise s’exécute. Un outil marqué comme demandant une approbation n’attend plus dans la file Approbations du seul fait que le modèle est Grok ou Kimi, et les niveaux d’autonomie ne s’appliquent pas aux chats suivis. Un appel que le portail escalade affiche une carte d’approbation dans la conversation et une entrée dans Approbations ; le chat n’est pas mis en pause.
Dans les exécutions en arrière-plan (planifiées, d’équipe, de pipeline, ou toute exécution non marquée comme suivie), l’échelle d’autonomie s’applique : un appel dans une catégorie en Avis ou Approuver attend une approbation, et un appel que le portail escalade attend toujours une personne, même quand sa catégorie est en Auto (avant, un tel appel s’exécutait sans demander sur Grok et Kimi). Une exécution supervisée se met en pause comme En attente d’approbation une fois le tour de la CLI terminé, et l’approbation laisse exactement cet appel s’exécuter une fois.
Une exécution reprise ou relancée qui répète un appel d’outil EYAS que l’exécution d’origine a déjà terminé (le même e-mail ou la même facture, par exemple) est refusée avant de s’exécuter ; la ligne d’outil affiche Ignoré avec already executed on the original run — duplicate side effect prevented. Le même outil avec d’autres arguments s’exécute toujours.
Un outil hors de la liste Outils de l’agent est refusé comme Refusé avant que le portail de sécurité soit consulté : il ne crée donc jamais d’entrée d’approbation. Sans portail de sécurité en marche, chaque appel d’outil EYAS passé par le pont est refusé.

Prouvé sur le Grok CLI installé par la vérification de publication. Les mêmes décisions s’appliquent à Kimi, car elles sont prises dans EYAS ; la façon dont un vrai binaire Kimi rapporte ces appels dans son propre flux (sur lequel se construit la vérification des doublons d’une reprise) n’a pas encore été vérifiée sur un hôte. Voir MCP — Comment le pont est sécurisé.

Un appel refusé termine une réponse de Grok. Quand EYAS refuse l’un des appels d’outils de Grok — par exemple une lecture de mémoire hors d’EYAS —, Grok termine cette réponse (vérifié sur grok 1.0.41). Le chat affiche la ligne d’outil refusée et rien après, et le modèle de Grok ne voit pas la raison d’EYAS : redemande donc sans cette étape. Claude Code, lui, continue et reçoit la raison.

Accès aux fichiers. Les fichiers que Grok ou Kimi lisent ou écrivent via EYAS sont limités aux dossiers de la conversation (les Dossiers qui passent encore la validation, plus le dossier de travail), avec les liens symboliques résolus — y compris pour un nouveau fichier sous un dossier lié. Les échappements .., les fichiers sensibles et, quand il n’y a aucun dossier, tous les fichiers sont refusés. Ensuite, la politique mémoire s’applique (la mémoire d’autres outils, les coffres Obsidian, le dossier de données propre d’EYAS et les espaces de travail des autres conversations sont refusés). Chaque opération de fichier est jugée une seule fois : une lecture ou une écriture déjà approuvée par la demande de permission de l’appel d’outil est servie sans redemander. Les lectures partielles (ligne de départ et nombre de lignes) sont prises en charge.

Travail d’arrière-plan. Grok et Kimi ne servent aux appels d’arrière-plan d’EYAS (titres, juge de sécurité, etc.) que tant que leur isolation est vérifiée : Grok après la réussite de sa vérification au chargement, de Vérifier maintenant ou du démarrage de session d’un tour ; Kimi seulement après qu’une session a démarré sur cet hôte (un Vérifier maintenant avec la CLI connectée en démarre une). Un tel appel ne reçoit aucun outil EYAS, chaque demande de permission et de fichier est refusée, et son premier appel d’outil y met fin. Sa réponse est tenue à la limite de sortie qu’EYAS demande (voir Modèles et effort de Claude Code).

Ce que reçoivent Grok et Kimi

Le prompt système d’EYAS, vérifié. Kimi reçoit le prompt système d’EYAS en tête de chaque message, marqué comme instructions système d’EYAS. Grok peut remplacer son propre prompt système par défaut par celui d’EYAS, mais il n’enregistre quel prompt il a utilisé qu’une fois le modèle interrogé : EYAS vérifie donc après chaque tour — dans son propre home Grok, avant la suppression des fichiers de session de ce tour. Lors des premiers tours après le démarrage d’EYAS, ou après le remplacement du programme grok, le prompt est envoyé des deux façons (comme prompt système de Grok et en tête du message) : aucune réponse ne dépend donc d’un chemin non vérifié. Une fois la vérification réussie, les tours suivants ne l’envoient plus que comme prompt système de Grok, et chaque tour est revérifié. Si le modèle a répondu sans le prompt d’EYAS, EYAS logue un avertissement et envoie désormais le prompt en tête du message (jusqu’au redémarrage ou à un nouveau programme grok). Il n’y a rien à configurer.
Tout l’historique, images comprises. Chaque tour rejoue l’historique de conversation d’EYAS, y compris les images des tours précédents à leur place. Les images ne sont transmises que si la CLI installée indique, au début de chaque exécution, qu’elle accepte les images en entrée. Sinon, chaque image est remplacée par une courte note au modèle, par exemple [image omitted (image/png): this model cannot see images], pour que le modèle sache qu’il y en avait une ; le compositeur avertit avant l’envoi et le tour affiche un avis (voir Images et modèles qui ne peuvent pas les voir). Rejouer tout l’historique, images comprises, coûte des tokens de prompt à chaque tour, comme c’est déjà le cas sur les fournisseurs API.
Le badge Vision suit la CLI. Le badge Vision des modèles Grok CLI et Kimi Code CLI suit ce que la CLI rapporte à chaque tour. Grok CLI 1.0.40 ne rapporte pas d’entrée image : les modèles Grok CLI affichent donc Vision désactivé. Les modèles Kimi gardent leur défaut jusqu’à ce que le premier tour rapporte. Après un redémarrage, un Actualiser les modèles avant le premier tour peut réafficher le défaut ; le tour suivant le corrige.

Modèles et effort de Grok

EYAS lit les modèles de Grok, et les niveaux d’effort de raisonnement que chacun accepte, depuis la Grok CLI elle-même : il ouvre une session dans son home Grok EYAS sans envoyer de prompt, donc sans appel modèle ni coût. Par exemple, grok-4.6 et grok-4.7 proposent low, medium, high et xhigh ; grok-4.5 propose low, medium et high ; un modèle sans contrôle du raisonnement n’en propose aucun. Cela a lieu à chaque chargement du fournisseur (démarrage d’EYAS, rechargement du fournisseur) et quand tu appuies sur Actualiser les modèles, et c’est sauté tant que Grok n’est pas connecté pour EYAS. Un modèle que la CLI ne propose plus est marqué et désactivé, jamais supprimé, et les choix d’effort d’un modèle Grok correspondent à ce qu’il accepte réellement.

À chaque tour, EYAS règle l’effort choisi dans la session Grok avant l’envoi du message, et relit le niveau que Grok a appliqué. Un niveau non pris en charge est d’abord ramené au plus proche que le modèle accepte (max sur grok-4.5 tourne en high). Si Grok refuse encore un niveau, le tour tourne au niveau propre de Grok, et c’est celui que le tour enregistre. Automatique n’envoie rien : le modèle tourne à son propre défaut (high pour les modèles Grok actuels), et le tour enregistre de quel niveau il s’agissait. La configuration ~/.grok propre à l’opérateur, y compris son effort par défaut, ne décide de rien. Chaque tour Grok enregistre aussi le modèle que Grok a réellement exécuté, tel que Grok le rapporte.

Modèles Kimi et réflexion

kimi acp ignore les options --model et --thinking : à chaque tour, EYAS ouvre donc la session Kimi, vérifie qu’elle est isolée, puis la bascule sur le modèle et la variante de réflexion choisis avant d’envoyer le prompt.

D’où viennent les modèles. La propre liste de modèles de Kimi — les modèles de sa propre config, par exemple kimi-code/kimi-for-coding après la connexion Kimi Code. EYAS la lit sans prompt et sans appel modèle, en ouvrant une session dans son propre home Kimi : en arrière-plan à chaque chargement du fournisseur (seulement tant que Kimi est connecté pour EYAS) et quand tu cliques sur Actualiser les modèles. Les lignes s’appellent Kimi Code CLI (<nom du modèle>). La ligne par défaut Kimi Code CLI exécute le modèle sur lequel Kimi est réglé en ce moment.
La réflexion par modèle, d’après ce que Kimi liste. Un modèle avec une variante normale et une variante à réflexion reçoit un choix d’effort Activé / Désactivé (Aucun = réflexion désactivée, Élevé = réflexion activée). Un modèle qui réfléchit toujours ne propose qu’Élevé (Aucun devient Élevé). Un modèle sans réflexion ne propose aucun réglage d’effort. Automatique garde la réflexion avec laquelle Kimi tourne en ce moment, y compris quand le modèle change. Après chaque tour, EYAS relit quel modèle et quelle variante ont réellement tourné et les enregistre comme modèle et effort effectifs.
Kimi se souvient du dernier choix. Quand EYAS change de modèle, Kimi l’enregistre dans son propre fichier de config (dans le home Kimi d’EYAS, jamais ~/.kimi) et l’utilise ensuite comme défaut. La ligne par défaut Kimi Code CLI exécute donc le modèle qu’EYAS a sélectionné le plus récemment, dans n’importe quelle conversation. Pour un choix stable, choisis un modèle Kimi précis.
Avant que la liste soit lue (pas encore connecté, ou la lecture a échoué), le panneau du fournisseur indique : EYAS n’a pas encore lu la liste des modèles de Kimi : il ne peut donc ni fixer un modèle ni activer ou désactiver la réflexion, et Kimi exécute le modèle sur lequel il est lui-même réglé. Connectez Kimi pour EYAS, puis cliquez sur « Actualiser les modèles ». Dans cet état, EYAS n’envoie aucun choix de modèle ni de réflexion.
Un modèle que Kimi ne propose pas arrête le tour avant le prompt, avec une erreur qui dit que Kimi ne propose pas ce modèle. Il n’est jamais remplacé en silence par un autre modèle.
Lignes retirées. Les lignes fixes Kimi Code CLI (K3), (K2.7 Code) et (K2.6) nommaient des modèles de l’API Moonshot, pas des modèles de la CLI Kimi, et exécutaient toujours le défaut de Kimi. Après la première actualisation ou découverte, elles sont marquées N’est plus proposé par la dernière actualisation et désactivées (jamais supprimées). Les niveaux de routage, les fallbacks de niveau et le défaut du fournisseur Kimi qu’EYAS lui-même avait réglés sur elles sont déplacés automatiquement, au démarrage, vers Kimi Code CLI (la ligne par défaut) — ce qu’ils exécutaient de toute façon. Une conversation ou un agent que tu avais épinglé sur l’une d’elles s’arrête avec l’erreur ne propose pas ; choisis plutôt l’un des modèles Kimi découverts. Sur une nouvelle install Kimi seul, tous les niveaux de routage démarrent sur Kimi Code CLI, sans fallback ; les niveaux Opus/Sonnet/Haiku de l’assistant de création d’agent correspondent aussi à elle pour Kimi, et les rétrogradations de budget n’ont pas d’étape Kimi Code CLI.
Estimations de coût. Les modèles Kimi Code CLI découverts sont tarifés au tarif par défaut de Kimi Code CLI (0,95 $ en entrée / 4 $ en sortie par million de tokens).

Ceci est construit à partir du code source de kimi-cli 1.52.0 et n’a pas encore été vérifié sur une vraie install de Kimi.

Sandbox de fichiers du noyau

Quand Claude Code ou Grok CLI exécute ses propres outils — les commandes shell de Claude Code ; le shell, grep, la liste de fichiers et les lectures de sous-agent de Grok —, le système d’exploitation lui-même empêche ces outils de lire ou d’écrire :

la mémoire des autres outils IA (~/.claude, ~/.grok, ~/.codex, ~/.gemini, ~/.kimi, ~/.cursor, ~/.codeium, les données d’OpenCode), les coffres Obsidian qu’EYAS connaît et les chemins de security.foreignMemoryPaths ;
les données privées propres d’EYAS : le coffre, la base, les clés et les homes EYAS des autres CLI ;
les espaces de travail des autres conversations.

Les propres dossiers de la conversation restent accessibles en écriture. Le sandbox est macOS Seatbelt (intégré) ou Linux bubblewrap. EYAS continue de vérifier chaque appel d’outil qu’il voit ; le sandbox attrape en plus ce qu’une commande shell atteint par des voies qu’EYAS ne peut pas lire dans le texte de la commande.

CLI	Ce qui tourne dans le sandbox
Claude Code	Chaque tour avec outils exécute ses commandes shell dans le sandbox. Sous Linux, il a besoin de bubblewrap (`bwrap`) et de `socat`. L’état shell propre de Claude Code (`~/.claude/shell-snapshots`, `~/.claude/session-env`) et son dossier de programme restent lisibles ; le reste de `~/.claude` est bloqué.
Grok CLI	Chaque tour avec outils démarre Grok sous un profil de sandbox EYAS, écrit dans `sandbox.toml` dans son home propre à EYAS (nommé `eyas-<hash>`). Grok ne peut pas l’assouplir. Sous Linux, il a besoin de bubblewrap.
Kimi Code CLI	N’a pas de sandbox noyau (Non pris en charge).

Les appels d’arrière-plan sans outils (titres, passes mémoire, juge de sécurité) n’ont pas besoin de sandbox et ne sont jamais refusés faute d’en avoir un.

security.cliSandbox (config/local.yaml) :

auto (défaut) utilise le sandbox là où il est disponible. Ailleurs, la CLI exécute quand même ses outils, et le chat affiche un avis unique par conversation : <CLI> exécute ses propres outils sans sandbox de fichiers du noyau sur ce serveur. EYAS vérifie toujours chaque appel d’outil qu’il voit ; les paramètres du fournisseur indiquent pourquoi. En auto, Claude Code peut demander à exécuter une commande hors du sandbox (par exemple une commande qui a besoin de ~/.npm). Une telle commande attend toujours l’approbation d’une personne dans la file des Approbations — jamais le juge IA, jamais l’échelle d’autonomie —, expliquée là comme Une commande shell a demandé à s’exécuter hors du sandbox de fichiers du noyau…. L’approuver laisse exactement cette commande s’exécuter une fois ; les exécutions autonomes se parquent dessus.
required refuse un tour CLI avec outils avant le démarrage de la CLI quand aucun sandbox n’est disponible : <CLI> n’a pas été démarré : vos paramètres exigent un sandbox de fichiers du noyau pour les outils propres de la CLI (security.cliSandbox: required), et aucun n’est disponible pour elle sur ce serveur. Le tour n’est pas retenté ni confié à un autre modèle, et les tours Kimi avec outils sont toujours refusés. Avec required, Claude Code ne peut jamais exécuter une commande hors du sandbox (sa demande est ignorée), et il refuse de démarrer si le sandbox ne peut pas démarrer.
Il n’y a pas de off. Toute autre valeur est une erreur de configuration : EYAS ne démarre pas, et l’erreur nomme security.cliSandbox.

Où tu le vois. Le panneau d’un fournisseur CLI a une ligne Sandbox de fichiers du noyau : Actif, Indisponible sur ce serveur avec la raison (bubblewrap pas installé ; socat pas installé ; bubblewrap ne peut pas créer de sandbox ici, généralement parce que les espaces de noms utilisateur sont désactivés ; système d’exploitation non pris en charge), ou Non pris en charge (Kimi). Elle affiche aussi la note required et, pour Claude Code en auto, Une commande qui demande à s’exécuter hors du sandbox attend toujours votre approbation. eyas doctor a une ligne CLI sandbox (voir CLI), et Événements de sécurité montre l’état de chaque CLI activée (voir Sécurité et confidentialité). GET /api/v1/model/providers et GET /api/v1/model/providers/:id portent fileSandbox {status: active|unavailable|unsupported, reason, mode} pour claude-code, grok-cli et kimi-cli.

Docker et Kubernetes. L’image EYAS n’inclut pas bubblewrap (il est sous LGPL : l’installer est le choix de l’opérateur). Un hôte ou conteneur Linux a besoin de bubblewrap (et de socat pour Claude Code) plus des espaces de noms utilisateur non privilégiés pour la couche noyau. Sans eux, EYAS refuse toujours chaque requête qu’il voit et affiche Indisponible ; avec required, les tours CLI avec outils sont refusés. Voir Docker et Kubernetes.

Limites. Sous Linux, la liste d’interdiction de Grok couvre les fichiers qui existent au démarrage de la session. Un coffre connu seulement par son dossier .obsidian est ajouté dès qu’EYAS a rencontré un chemin à l’intérieur (un coffre enregistré ou une entrée de security.foreignMemoryPaths compte toujours). Kimi n’a pas de couche noyau.

Versions de CLI prouvées

Chaque version de CLI qu’EYAS prend en charge est vérifiée avant publication : EYAS lance les vrais Claude Code et Grok CLI (et Kimi Code CLI là où elle est installée) via ses propres fournisseurs dans un home jetable rempli de pièges (réglages de l’hôte qui autorisent tout, hooks et serveurs MCP qui laisseraient une trace, CLAUDE.md, AGENTS.md, skills, un coffre de style Obsidian) et prouve que rien de tout cela n’est chargé, que la politique mémoire d’EYAS et le sandbox du noyau tiennent le coffre et le dossier de données d’EYAS à l’écart, et qu’une lecture refusée de mémoire hors d’EYAS reste refusée. Les détails sont dans Sécurité et confidentialité — Comment l’isolation est prouvée.

CLI	Dernière version prouvée
Claude Code	2.1.281
Grok CLI	1.0.41
Kimi Code CLI	Pas encore prouvée

Vérifie ton install avec eyas doctor. Il a une ligne CLI isolation par CLI — CLI isolation (Claude Code), CLI isolation (Grok CLI), CLI isolation (Kimi Code CLI). Chacune montre le binaire qu’EYAS lance : comment il a été trouvé (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN, claude/grok/kimi on PATH ou SDK-bundled), son chemin et sa version, puis :

isolation proven on this version (<date>) — ok ;
un avertissement quand la version diffère de la dernière prouvée, quand le binaire ne rapporte aucune version, ou quand la CLI n’a jamais été prouvée (Kimi aujourd’hui). L’avertissement ajoute qu’EYAS vérifie toujours chaque session au démarrage : les vérifications de cette page tournent quelle que soit la version installée ;
not installed — ok. Un EYAS_*_BIN invalide est un échec, avec le remède.

Pour Grok et Kimi, la ligne vérifie aussi leur home EYAS, <répertoire de données>/cli-homes/<fournisseur> :

pas encore créé — ok, la première exécution le crée ;
un lien symbolique ou pas un dossier — un échec : EYAS refuse de lancer la CLI ; supprime-le, la prochaine exécution le recrée ;
lisible par d’autres utilisateurs — un avertissement, car il contient la connexion de la CLI ; remède : chmod 700 <dossier> ;
un fichier qu’EYAS y gère (les config.toml, requirements.toml, trusted_folders.toml de Grok ; le mcp.json de Kimi et les clés d’EYAS dans config.toml) a changé depuis qu’EYAS l’a écrit — un avertissement. EYAS réécrit ces fichiers avant la prochaine exécution : un changement entre deux exécutions signifie donc que quelque chose d’autre modifie ce dossier.

Doctor ne fait que lire : il lance seulement --version. Voir CLI — Ce que vérifie doctor.

Le même chat sur tous les fournisseurs

Une conversation a le même aspect quel que soit le fournisseur qui y répond.

Texte en direct. Claude Code tape sa réponse et sa réflexion en direct, au fur et à mesure que le modèle les écrit, comme les fournisseurs API.
Une ligne par appel d’outil, avec le nom commun. Les lignes d’outil utilisent les noms qu’EYAS utilise sur tous les fournisseurs — read_file, run_command, edit_file, write_file, grep, glob, web_fetch, web_search —, si bien que les modifications et écritures de fichiers s’affichent partout sous forme de diff. Les outils propres d’EYAS apparaissent sous leur nom simple (memory_search, pas mcp__eyas__memory_search). Sur Grok et Kimi, la ligne n’affiche pas le titre libre de la CLI.
Entrée, sortie et durée. Une ligne montre ce qui a été demandé à l’outil (le fichier, la commande, la recherche, le chemin d’une modification avec l’ancien et le nouveau texte), ce qu’il a renvoyé — une sortie très longue est coupée à 64 Kio et marquée comme coupée — et combien de temps il a pris.
Une ligne ne se clôt qu’une fois l’outil terminé. Elle n’est jamais marquée comme finie à l’avance : un appel qui échoue, ou qui est ignoré par le budget d’appels d’outils, s’affiche en échec, avec l’erreur.
Les appels refusés ne sont pas affichés comme réussis. Un appel qu’EYAS a refusé — par le portail de sécurité, par la politique mémoire, pendant qu’il attend une approbation, ou comme répétition d’une action qu’une exécution reprise avait déjà menée — affiche son propre statut (Refusé, Approbation requise, Ignoré) avec la raison d’EYAS, jamais une coche verte. Les appels qu’une CLI demande après que la limite d’appels d’outils est atteinte sont enregistrés comme ignorés. Un appel qui demande une approbation fait apparaître une carte d’approbation dans la conversation et une entrée dans la file des Approbations. Voir Conversations — Trace des outils.
La limite de tours garde la réponse. Quand un tour atteint sa limite de tours, la réponse écrite jusque-là est gardée et enregistrée comme réponse ; le tour se termine en Limite de tours atteinte, pas en erreur. Un vrai échec s’affiche toujours en erreur, et la réponse partielle est gardée là aussi.
Une seule fin par tour. Une réponse est enregistrée et affichée exactement une fois, sur tous les fournisseurs.
Le même arbre d’exécution. Le panneau arbre d’exécution / flux de travail d’une conversation apparaît pour tous les fournisseurs, API et CLI, avec l’outil en cours en direct, le compteur de tours (pour une CLI, ses propres étapes internes), les tokens et le coût de l’exécution. Voir Conversations — Arbre d’exécution.
La compaction n’écrit pas de mémoire. Si une CLI compacte son propre contexte pendant un long tour, le tour affiche un avis contexte compacté et rien n’est écrit dans la mémoire EYAS. La mémoire EYAS n’est alimentée que par EYAS.
Les messages d’erreur nomment la bonne CLI. Un échec de Kimi dit Kimi Code CLI, jamais Grok CLI.

Pourquoi un tour s’est terminé. Chaque fournisseur API enregistre les mêmes raisons : terminé, utilisation d’outil, limite de sortie atteinte, séquence d’arrêt, ou refusé. Refusé couvre le refus d’Anthropic, le filtre de contenu d’OpenAI et le message de refus du modèle, les arrêts de classe sécurité de Gemini (sécurité, contenu interdit, liste de blocage, récitation, données personnelles, sécurité des images) et un prompt que Gemini a bloqué d’emblée. Un message de refus d’OpenAI s’affiche comme réponse de l’assistant au lieu d’une réponse vide. Une réponse coupée par la limite de tokens de sortie est enregistrée comme max tokens, et un appel d’outil coupé de cette façon n’est jamais exécuté. Le chat affiche ces issues sous forme de badge sous la réponse — voir Conversations — Issue du tour.

Les compteurs de tokens ont le même sens sur tous les fournisseurs, CLI comprises : les tokens d’entrée sont les tokens du prompt qui n’ont pas été servis depuis le cache du fournisseur ; les lectures en cache (et, sur Anthropic, les écritures en cache) sont comptées à part ; les tokens de raisonnement ou de réflexion font partie des tokens de sortie. Un tour pour lequel le fournisseur n’a rapporté aucun usage est marqué Utilisation non communiquée et n’affiche aucun prix ; sa trace n’est jamais tarifée à partir de comptes de tokens de substitution. L’observabilité compte aussi les outils qu’une CLI a exécutés dans sa propre boucle — les tours Claude Code, Grok CLI et Kimi Code CLI n’affichent plus 0 appel d’outil. Voir Observabilité — Usage.

Appels d’outils

Sur les fournisseurs API et locaux, EYAS fait tourner la boucle d’outils lui-même : le modèle demande un outil, EYAS l’exécute, renvoie le résultat, et le modèle continue sa réponse. Chaque appel apparaît comme une ligne en direct dans la conversation.

Fournisseur	À quoi s’attendre
Anthropic, points de terminaison compatibles Anthropic (MiniMax, Synthetic, Xiaomi MiMo, …)	Les outils EYAS tournent, outils mémoire compris. Avec le raisonnement activé — n’importe quel niveau d’effort, ou un modèle où il est toujours actif —, le raisonnement signé du modèle (raisonnement expurgé compris) repart inchangé dans la requête suivante de la même réponse : les tours qui utilisent des outils avec raisonnement fonctionnent de façon fiable. Les fournisseurs compatibles Anthropic rapportent aussi les tokens d’entrée en cache pour les réponses en streaming.
OpenAI	Les outils EYAS tournent, outils mémoire compris
Gemini	Les outils EYAS tournent, recherche mémoire comprise. La signature de raisonnement de Gemini est renvoyée avec chaque appel d’outil, pour que les modèles Gemini récents gardent leur raisonnement au fil d’une boucle d’outils. Un outil qui signale une erreur est envoyé à Gemini comme une erreur. Les résumés de pensée de Gemini s’affichent comme raisonnement dans la conversation, jamais dans le texte de la réponse ni dans la réponse enregistrée.
Points de terminaison compatibles OpenAI, Kimi API, OpenRouter	Les outils EYAS tournent. Un backend qui signale un stop normal tout en demandant des outils ne termine pas la boucle trop tôt — les outils demandés tournent. Le texte de raisonnement que ces backends renvoient (par exemple celui de DeepSeek reasoner) s’affiche comme réflexion, jamais mêlé à la réponse. Kimi API et OpenRouter récupèrent leur propre raisonnement sur les tours d’appel d’outils de la même réponse, comme ils l’exigent.
LM Studio	Utilise la même connexion compatible OpenAI que les fournisseurs ci-dessus : les appels d’outils et leurs résultats (recherche mémoire comprise) atteignent le modèle par l’appel de fonctions standard.
Ollama	Les outils EYAS tournent. Chaque résultat d’outil porte le nom de l’outil, pour que le modèle sache quel résultat appartient à quel appel quand il en a fait plusieurs. Le raisonnement d’un modèle à réflexion est diffusé comme réflexion, séparé de la réponse.
Claude Code CLI, Grok CLI, Kimi Code CLI	La CLI fait tourner la boucle ; les outils EYAS lui parviennent par MCP — voir MCP

Le raisonnement reste avec son fournisseur. Le raisonnement rejoué dans une boucle d’outils (famille Anthropic, Kimi API, OpenRouter) ne vaut qu’au sein d’une seule réponse : il n’est pas stocké avec la conversation et n’est pas envoyé aux tours suivants. Si un tour bascule vers un autre fournisseur, le raisonnement est abandonné pour ce fournisseur et la réponse continue sans lui. Quand une exécution d’arrière-plan arrêtée ou échouée reprend depuis son dernier checkpoint, le modèle recommence son raisonnement une fois. Le raisonnement n’est jamais envoyé à un autre fournisseur ou modèle, pas même sous forme de texte ; la connexion OpenAI native ne renvoie jamais de raisonnement du tout.

Une ligne par appel d’outil. Certains backends compatibles OpenAI — souvent des serveurs locaux — diffusent un appel d’outil sans identifiant d’appel. Un tel appel apparaît comme exactement une ligne d’outil. Cela vaut pour OpenAI, les fournisseurs compatibles OpenAI, Kimi API, OpenRouter et LM Studio.

Modèles sans outils. Un modèle marqué sans support des outils dans la liste des modèles — par exemple un modèle Ollama dont le serveur ne signale aucune capacité d’outils, ou un modèle pour lequel tu as désactivé le support des outils — ne reçoit ni outils ni liste d’outils dans son prompt. S’il demande quand même un outil, EYAS ne l’exécute pas et le tour se termine sur le texte du modèle. Son prompt cesse aussi de lui dire d’appeler des outils : les règles de mémoire et d’ancrage disent que ce qu’EYAS a rappelé arrive dans le bloc <eyas-memory> et qu’il ne peut pas chercher plus loin, et il ne reçoit ni liste de skills ni liste d’agents, qui ne fonctionnent que par des appels d’outils. Voir Prompts — Le contrat mémoire.

Images et modèles qui ne peuvent pas les voir

Quels modèles peuvent voir des images, c’est le catalogue de modèles qui le dit : le badge Vision de la liste des modèles. Pour Grok CLI et Kimi Code CLI, le badge suit ce que rapporte la CLI installée.

Quand le modèle de la conversation ne peut pas voir d’images, chaque image jointe arrive au modèle sous forme d’une courte note à sa place ([image omitted (image/png): this model cannot see images]). Le modèle sait qu’il y avait une image, mais pas ce qu’elle montre. Le tour n’est pas refusé.
Un avis apparaît sous ce tour : Images non transmises au modèle (N) : <modèle> ne peut pas voir d’images… Il est enregistré avec la réponse, et reste donc là après un rechargement. Le compte inclut les images des tours précédents : sur un tel modèle, l’avis apparaît donc à chaque tour tant que la conversation contient des images.
Le compositeur avertit avant l’envoi : avec une image jointe et un modèle qui ne peut pas voir d’images, une puce au-dessus de la saisie indique <modèle> ne peut pas voir d’images : il saura seulement qu’une image est jointe. La puce n’apparaît pas en Mode Dieu ; pour une conversation en routage automatique, elle se base sur le modèle affiché pour la conversation (le niveau Standard).
Si EYAS n’a aucune information de catalogue pour un modèle, les images sont envoyées telles quelles et le fournisseur décide. Passe à un modèle avec le badge Vision pour que les images soient lues.
Claude Code voit les images des tours précédents d’une conversation, pas seulement celles du dernier message : chaque tour renvoie toutes les images précédentes, comme le font les fournisseurs API, si bien que les conversations riches en images envoient des prompts plus gros.

Mise en cache du prompt (API Anthropic)

Sur le fournisseur API Anthropic (clé API directe), la mise en cache du prompt est automatique — il n’y a aucun réglage.

Prompt système. Le prompt système d’EYAS ne change pas d’un tour à l’autre, parce que l’heure courante et la mémoire rappelée voyagent avec ton message courant. EYAS marque donc le prompt système (avec les définitions d’outils qui le précèdent) pour la mise en cache, et chaque tour et chaque étape d’outil suivants le relisent depuis le cache d’Anthropic.
Conversation antérieure. La conversation jusqu’à ton message courant est marquée aussi : le tour suivant la relit au lieu de la payer à nouveau plein tarif.
Étapes d’outil. Dans un tour qui utilise des outils, chaque étape d’outil relit la requête précédente.
Durée de vie et coût. Le cache dure 5 minutes et est rafraîchi par chaque requête qui l’utilise ; après une pause plus longue, la première requête l’écrit à nouveau. Une écriture en cache coûte 1,25× le prix d’entrée normal ; une lecture coûte environ 0,1× (ou le tarif de lecture de cache publié du modèle, plus bas sur certains modèles récents). Les prompts plus courts que la longueur minimale mise en cache du modèle (512 à 4096 tokens selon le modèle) ne sont tout simplement pas mis en cache.
Où le voir. L’usage de tokens et les coûts affichent les tokens de lecture et d’écriture en cache pour les appels à l’API Anthropic.
Les points de terminaison tiers compatibles Anthropic ne reçoivent aucun paramètre de mise en cache, car un tel point de terminaison peut le refuser. Claude Code gère sa propre mise en cache.

Runtimes locaux

LM Studio

La température, le nombre maximal de tokens de sortie et les séquences d’arrêt de la conversation ou de l’agent sont envoyés tels que réglés. Quand rien n’est réglé, le défaut propre du modèle dans LM Studio s’applique.
Une requête qui ne nomme aucun modèle demande le modèle actuellement chargé dans LM Studio. Le modèle affiché sur une réponse est l’identifiant que rapporte LM Studio.
Les appels utilisent le délai standard du client (10 minutes), et une connexion perdue est retentée.
LM_STUDIO_URL (défaut http://localhost:1234) peut se terminer par une barre oblique.
Le raisonnement reste le réglage propre de LM Studio : EYAS n’envoie jamais de paramètre de raisonnement ou d’effort, et le panneau affiche le réglage que LM Studio signale par modèle (voir Comment chaque fournisseur applique le niveau d’effort).

Ollama

Actualiser les modèles lit les capacités de chaque modèle depuis le serveur Ollama — au chargement, en arrière-plan et lors de l’actualisation —, donc les modèles sans support des outils sont marqués comme tels et les modèles à réflexion reçoivent leur réglage de réflexion (voir Comment chaque fournisseur applique le niveau d’effort). Un Ollama plus ancien qui ne rapporte pas de capacités garde les outils activés.
Le contexte par défaut d’Ollama est de 4096 tokens. Quand une requête plus sa réponse ont besoin de plus, EYAS règle num_ctx sur la puissance de deux suivante (8192, 16384, …), plafonnée à la fenêtre de contexte du modèle dans la liste des modèles. Les petites requêtes laissent le défaut d’Ollama intact. OLLAMA_CONTEXT_LENGTH s’applique toujours quand EYAS ne règle pas num_ctx. Un num_ctx plus grand n’augmente la consommation mémoire d’Ollama que pour les requêtes qui en ont besoin.

Arrêter annule la génération locale. Sur LM Studio et Ollama, Arrêter arrête aussitôt la génération en cours : le GPU est libre dès que tu arrêtes.

Fenêtre de contexte

EYAS construit le prompt de chaque tour pour le modèle qui y répond. La fenêtre vient de la liste des modèles (le badge de taille de contexte de chaque modèle), pour les modèles CLI aussi : un modèle Claude Code listé avec une fenêtre de 1M utilise 1M. Claude Code ne liste 1M que pour les variantes 1M propres du runtime (par exemple Opus (1M context)) ; ses entrées Fable, Opus, Sonnet et Haiku indiquent 200k, y compris avant que le runtime ait rapporté ses modèles, si bien que le badge de taille de contexte, la barre de contexte et le dimensionnement du prompt concordent dès le premier démarrage. Les fenêtres connues des CLI — Claude Code 200k, Grok 500k, Kimi 256k — ne servent que de repli pour un modèle dont la liste n’a pas la fenêtre, et un modèle dont on ne sait rien utilise 200k. Les fenêtres plus grandes donnent plus de place aux sections ajustables du prompt ; les petits modèles locaux reçoivent un prompt qui laisse de la place à la conversation. Voir Prompts — dimensionné pour le modèle.

La barre de contexte de la conversation utilise la même fenêtre et, là où le fournisseur la rapporte, la taille réelle du prompt du dernier appel au modèle (Anthropic et compatibles Anthropic, la famille OpenAI y compris OpenRouter, Kimi API et LM Studio, Gemini, Claude Code). Quand le runtime indique la fenêtre du modèle qui a répondu (Claude Code le fait), elle l’emporte sur la liste des modèles. Ollama, Grok CLI et Kimi Code CLI ne rapportent pas de taille de prompt par appel exploitable : leur barre est donc une estimation. Voir Conversations — Composition du contexte.

Confidentialité : ce que reçoit chaque fournisseur

La politique de confidentialité masque les données personnelles en route vers un modèle, par tentative et par destination. Qu’un fournisseur compte comme local (texte envoyé non masqué) dépend de l’hôte vers lequel il envoie, jamais du nom du fournisseur :

Local : un point de terminaison loopback (localhost, 127.x.x.x, ::1) ou un hôte listé comme hôte local dans la politique de confidentialité. Un Ollama ou LM Studio local est local.
Distant (masqué) : tout le reste — un OLLAMA_HOST distant, les hôtes du LAN non listés, les API cloud, et tous les fournisseurs CLI (Claude Code, Grok CLI, Kimi Code CLI), car EYAS ne peut pas voir où une CLI envoie son trafic.

Si un appel bascule vers un autre fournisseur, chaque tentative est masquée pour sa propre destination. Si tu comptais sur l’exemption d’un hôte Ollama distant, ajoute cet hôte aux hôtes locaux de la politique. Les résultats des outils mémoire qu’une CLI récupère via le pont d’outils EYAS sont masqués de la même façon. Un nouveau message que tu envoies et qui contient une valeur de classe block (par exemple un IBAN) est refusé avant d’être stocké quand il partirait vers un modèle distant — fournisseurs CLI compris —, avec la proposition de l’envoyer masqué. Le fournisseur OpenAI intégré refuse aussi, pour chaque requête, les complétions stockées d’OpenAI. Voir Sécurité et confidentialité.

Champs et commandes

Panneau du fournisseur

Section	Signification
● Actif	Badge à côté du titre du panneau : le fournisseur est activé et tourne ; sinon il indique Inactif
Authentification	Clé API, la connexion Claude Code de cette machine, ou la carte Se connecter pour EYAS (Grok CLI, Kimi Code CLI)
Auth CLI (Claude Code)	Aucune clé API n’est nécessaire. Claude Code ne partage que sa connexion avec ce serveur : connectez-vous avec la CLI `claude` sous l’utilisateur qui exécute EYAS. Claude Code n’est disponible qu’une fois cette CLI connectée.
Ligne d’isolation de Claude Code	EYAS exécute Claude Code de façon isolée : aucun CLAUDE.md, paramètre, hook, skill, serveur MCP ni auto-mémoire de l’hôte n’est chargé, et aucune transcription n’est conservée sous ~/.claude/projects. Seule la connexion est partagée avec l’hôte. Elle renvoie à Paramètres → Système → Portabilité des données → Importer des données pour le contenu `CLAUDE.md` de l’hôte.
Se connecter pour EYAS	Grok CLI / Kimi Code CLI seulement — Se connecter avec un code d’appareil, Utiliser plutôt une clé d’API (Grok), Annuler, Se déconnecter — voir Connecter Grok et Kimi pour EYAS
Sandbox de fichiers du noyau	Claude Code / Grok CLI / Kimi Code CLI — Actif, Indisponible sur ce serveur (avec la raison) ou Non pris en charge, plus la note `required` et, pour Claude Code en `auto`, Une commande qui demande à s’exécuter hors du sandbox attend toujours votre approbation. — voir Sandbox de fichiers du noyau
Note sur les modèles Kimi	Kimi Code CLI, tant qu’EYAS n’a pas lu la liste des modèles de Kimi : EYAS n’a pas encore lu la liste des modèles de Kimi : il ne peut donc ni fixer un modèle ni activer ou désactiver la réflexion…
Champs de clé API	Chiffrés dans Secrets ; Clé enregistrée / Aucune clé / Supprimer la clé
Liste des modèles	Activer/désactiver chaque modèle ; badges Outils / Vision / taille de contexte ; Exécute <modèle> quand le modèle concret diffère de l’identifiant de la ligne ; N’est plus proposé par la dernière actualisation sur les lignes que la dernière actualisation n’a pas renvoyées ; une ligne Raisonnement avec les niveaux d’effort et le défaut du modèle, et d’où viennent ces données (signalé par le fournisseur / catalogue EYAS, vérifié le …) ; sur LM Studio, le réglage de raisonnement que signale LM Studio
Actualiser les modèles	Recharge la liste des modèles du fournisseur (tous les fournisseurs). En cas d’échec : L’actualisation a échoué. La liste des modèles est restée inchangée.

Les panneaux Claude Code CLI, Grok CLI et Kimi Code CLI affichent aussi la ligne Environnement d’exécution et le bloc Isolation, avec Vérifier maintenant pour Grok et Kimi — voir Environnement d’exécution et Isolation sur le panneau du fournisseur sous Vérification d’isolation avant chaque tour. Leurs sous-titres de carte se lisent Claude Code CLI, exécutée isolée par EYAS, Grok CLI dans le dossier propre d’EYAS (ACP) et Kimi Code CLI dans le dossier propre d’EYAS (ACP).

Onglets liés

Routage et budget (onglets Niveaux de routage + Budget). L’onglet Niveaux de routage s’ouvre sur la carte Appels de modèle en arrière-plan, qui montre où part en ce moment le travail d’arrière-plan d’EYAS — voir Routage et budget — Appels de modèle en arrière-plan.
Analyse IA — iframe de benchmarks indépendants intégrée