Proveedores

Para qué sirve. Los proveedores son los backends LLM de esta instancia: APIs cloud, CLI del host (Claude Code, Grok, Kimi) y runtimes locales (Ollama, LM Studio, vLLM). Activas un proveedor, guardas su clave, eliges modelos y el enrutado lo usa. Esta página explica también cómo mantiene EYAS las CLI apartadas de la configuración propia de la máquina: Claude Code siempre corre aislado, Grok y Kimi corren en su propio directorio personal de EYAS con un inicio de sesión para EYAS, y un turno se detiene cuando EYAS no puede confirmar ese aislamiento.

Ruta: /providers. Subtítulo: Enrutamiento de IA, configuración de proveedores y control de presupuesto. Pestañas: Niveles de enrutamiento · Proveedores · Presupuesto · Análisis de IA.

Cuándo usarlo

Tras el setup: proveedor Activado, clave de API, modelos.
Tienes claude / grok / kimi en el host y quieres un proveedor CLI sin clave.
Grok CLI o Kimi Code CLI muestra Inicio de sesión necesario — inicia su sesión para EYAS (ver Iniciar sesión de Grok y Kimi para EYAS).
EYAS debe ejecutar una instalación concreta de una CLI (EYAS_CLAUDE_CODE_BIN, EYAS_GROK_BIN, EYAS_KIMI_BIN) — ver Runtime de Claude Code y Grok CLI y Kimi Code CLI.
Un turno se detuvo con un error de aislamiento de CLI y necesitas saber qué cambiar en el host.
Actualizaste Claude Code, Grok CLI o Kimi Code CLI y quieres saber si el aislamiento de EYAS está probado en esa versión (ver Versiones de CLI probadas).
El panel de un proveedor CLI dice que el Sandbox de archivos del kernel está No disponible en este servidor, o quieres que los turnos de CLI lo exijan (ver Sandbox de archivos del kernel).
Una fila de modelo dice La última actualización ya no lo ofrece, o quieres saber qué modelo concreto ejecuta una fila.
Quieres saber qué niveles de esfuerzo de razonamiento ofrece un modelo, qué significa Automático para él y cómo aplica el nivel cada proveedor (ver Esfuerzo de razonamiento y Cómo aplica cada proveedor el nivel de esfuerzo).

Flujo típico

Proveedores (/providers) → pestaña Proveedores.
Elige una tarjeta. Activado / Desactivado la habilita para el enrutado. Autenticación admite una clave de API (cifrada en Secretos); Claude Code usa el login de Claude Code de esta máquina; Grok CLI y Kimi Code CLI muestran una tarjeta Iniciar sesión para EYAS.
Activa modelos. Actualizar modelos recarga la lista de modelos del proveedor — el mismo botón para todos los proveedores, API o CLI. Los modelos que el proveedor ya no ofrece se desactivan y se marcan, nunca se borran.
Niveles y gasto: Enrutado y presupuesto.

Funciones

Cada tarjeta muestra la identidad, el estado y el interruptor.

Elemento	Significado
Activado / Desactivado	Habilita el proveedor para el enrutado
N/M modelos activados	Cuántos modelos están activos
CLI no encontrada	Falta el binario en el host
Sin clave API	Necesita una clave
Error de autenticación	Credenciales rechazadas — vuelve a introducir la clave o el login
Inicio de sesión necesario	Insignia roja en Grok CLI / Kimi Code CLI: la CLI no tiene la sesión iniciada para EYAS (tooltip: <CLI> no tiene la sesión iniciada para EYAS. Abre el proveedor para iniciar sesión.)

Proveedores integrados (tal como aparecen en las tarjetas)

Proveedor	Papel
Anthropic	Claude — los modelos que puede usar tu clave de API, leídos de la lista de modelos de Anthropic (lista integrada de reserva: Fable 5.1, Fable 5, Opus 5.5, Opus 5, Opus 4.8, Sonnet 5, Sonnet 4.6, Haiku 4.5)
OpenAI	Integrados GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o, GPT-4o mini; Actualizar modelos lista el resto
OpenRouter	Pasarela multiproveedor (más de 100 modelos)
Gemini	Google Gemini 3.x (2.5 tras una actualización, donde tu clave aún tenga acceso)
Kimi	API de Moonshot (K3, K2.7 Code, K2.6)
Claude Code CLI	El CLI de Claude Code de esta máquina (`claude`), siempre aislado — ver Aislamiento de Claude Code
Grok CLI	ACP (`grok agent --no-leader stdio`) en su propio directorio personal de EYAS — herramientas de EYAS por el puente MCP de CLI
Kimi Code CLI	ACP (`kimi acp`) en su propio directorio personal de EYAS — el mismo puente
Ollama / LM Studio / vLLM	Runtimes locales — ver Runtimes locales
xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo Gateway, Vercel AI Gateway, Qianfan, MiniMax, Synthetic, Xiaomi MiMo, …	APIs cloud tal como aparecen en las tarjetas

Un solo nombre en todas partes. Los nombres de esta tabla son los que EYAS muestra en todas las pantallas: las tarjetas y el panel de proveedores, los selectores de proveedor de los niveles de enrutado, el selector de modelo y la barra superior de la conversación, la línea Respondido por bajo cada respuesta, los mensajes de error del chat, el selector de modelo de un colega, la tarjeta Asignaciones de modelo en Ajustes, el asistente de setup y la tarjeta de inicio de sesión y el aviso de Inicio de Grok/Kimi. Claude Code siempre es Claude Code CLI. Kimi Code CLI, Kimi y los proveedores compatibles (xAI, Mistral, Groq, MiniMax, Xiaomi MiMo, …) muestran su nombre de producto, nunca un id como kimi-cli. Quien no puede leer el catálogo de modelos (el rol invitado) ve ids de proveedor en su lugar.

API (integradores). Cada fila de GET /api/v1/model/providers, y el detalle GET /api/v1/model/providers/:id, llevan el nombre de producto name y un kind: cli (Claude Code, Grok CLI, Kimi Code CLI), local (Ollama, LM Studio, vLLM) o api (cualquier API alojada y cualquier id desconocido).

Continuidad de la conversación

EYAS guarda la conversación, no el proveedor. En cada turno EYAS envía al modelo la conversación entera desde su propio almacén. Ningún proveedor CLI guarda ni reanuda una sesión propia: Claude Code, Grok CLI y Kimi Code CLI empiezan de cero en cada turno y reciben los turnos anteriores como un bloque de historial de la conversación. Grok y Kimi abren siempre una sesión ACP nueva y nunca cargan una anterior.

Así, una conversación conserva su contexto cuando cambias de proveedor o de modelo, y el almacén de sesiones propio de un CLI nunca es fuente de contexto ni de memoria. La misma continuidad vale para todos los proveedores.

Las imágenes pegadas en turnos anteriores también forman parte de ese historial en Grok CLI y Kimi Code CLI, cada una en el punto de la conversación en que se envió. Ver Qué reciben Grok y Kimi.

El coste que Claude Code informa para un turno es el gasto de ese turno y se suma tal cual.

API de modelo en bruto (integradores). POST /api/v1/model/complete y POST /api/v1/model/stream (permiso use Model) validan su cuerpo. Campos aceptados: provider, model, messages (1–1000 elementos; rol user o assistant; el contenido es una cadena o una lista de bloques de texto/imagen), system, maxTokens (entero positivo), temperature (0–2), stopSequences (como mucho 16) y un effort opcional (un nivel de none a max, o auto). Cualquier otra clave se descarta, incluidas sessionId, metadata, cwd, isolated, tools y thinking. Por eso estas llamadas se gobiernan como autónomas (se aplica la escalera de autonomía), no pueden reanudar una sesión de proveedor y thinking no tiene efecto ahí. La respuesta, y el evento done del stream, llevan effortOutcome: el nivel pedido, el nivel realmente enviado al modelo y su origen (request). Un cuerpo inválido devuelve 400 con { error: 'ValidationError', issues }.

Modelos y Actualizar modelos

Actualizar modelos pregunta al proveedor qué modelos ofrece y guarda, para cada fila, el modelo concreto que ejecuta (por ejemplo el id de modelo de Grok, o el alias que usa Claude Code). Un modelo encontrado por una actualización sigue funcionando tras reiniciar EYAS.

Cada fila de modelo muestra una línea pequeña Ejecuta <modelo> cuando el modelo concreto difiere del id propio de la fila.
Una actualización correcta no solo añade modelos. Un modelo que el proveedor ya no ofrece se desactiva y se marca La última actualización ya no lo ofrece. Nunca se borra. Si una actualización posterior vuelve a ofrecerlo, se reactiva automáticamente — salvo que lo hubieras desactivado tú. Puedes activar a mano un modelo marcado; entonces queda bajo tu control.
Si la actualización falla (proveedor inalcanzable, sin sesión iniciada, sin clave) o el proveedor no lista ningún modelo, no cambia nada y el panel dice La actualización falló. La lista de modelos no ha cambiado. OpenAI, Gemini, OpenRouter, Kimi (API) y los endpoints compatibles con OpenAI informan de ese fallo en vez de mostrar en silencio la lista de modelos integrada de EYAS.

Agentes que solo nombran un modelo. Un agente, especialista o destino de enrutado que nombra un id de modelo sin proveedor llega al proveedor que tiene ese modelo en su lista de modelos activados — por ejemplo un modelo de Grok encontrado por Actualizar modelos, o un modelo más nuevo de OpenAI. Un modelo desactivado o desconocido, un modelo cuyo proveedor está apagado y un id de modelo que ofrecen dos proveedores siguen fallando con No provider found for model. EYAS nunca adivina.

Qué modelo ejecuta una CLI.

Grok CLI: la fila por defecto Grok CLI (<modelo>) ejecuta el modelo que tenga por defecto el propio Grok CLI instalado. Cualquier otra fila de Grok ejecuta exactamente el modelo que nombra, también tras un reinicio. Una conversación o un agente fijado a un modelo de Grok que la CLI ya no ofrece falla antes de enviar nada: Model ‘<id>’ cannot be run by this CLI: Grok CLI does not offer it (the session would run <default>). Elige otro modelo o actualiza la lista.
Claude Code: la lista de modelos sale del runtime de Claude Code que ejecuta EYAS (ver Modelos y esfuerzo de Claude Code). Cada fila nombra el modelo concreto de Claude que ejecuta su alias, por ejemplo opus ejecuta claude-opus-5-5. La fila Claude Code (Default) ejecuta el modelo que el runtime use por defecto. Un nombre de modelo completo también funciona.
Kimi Code CLI: la lista de modelos sale del propio Kimi, y EYAS cambia cada sesión al modelo que elegiste (ver Modelos y razonamiento de Kimi). La fila por defecto Kimi Code CLI ejecuta el modelo que Kimi tenga configurado en ese momento.
Un id de modelo que no nombra ningún modelo (por ejemplo solo grok-cli-) hace fallar el turno con un error claro en lugar de ejecutar otra cosa.

Listas de modelos de las API.

Anthropic: al añadir una clave de API, EYAS lee de la Models API de Anthropic los modelos que esa clave puede usar. Es una llamada de listado gratuita, no una llamada al modelo, y trae la ventana de contexto, el límite de salida y los niveles de esfuerzo de cada modelo. Si no se puede llegar a la Models API, se usa la lista integrada. Las instalaciones existentes conservan su lista guardada hasta que pulsas Actualizar modelos; entonces aparecen modelos más nuevos como Opus 5.5, Opus 5, Sonnet 5 y Fable 5.1, y las filas antiguas (Opus 4.7, Opus 4.6) siguen funcionando mientras estén guardadas.
OpenAI: antes de la primera actualización, la lista integrada es GPT-5.6, GPT-5.5, GPT-5.4, GPT-5 mini, o3-mini, GPT-4o y GPT-4o mini. GPT-4 Turbo ya no viene integrado; Actualizar modelos lo sigue listando si OpenAI lo ofrece. Un modelo actualizado que EYAS ya conoce conserva su ventana de contexto y su límite de salida.
OpenRouter: Actualizar modelos lee también qué modelos marca OpenRouter como compatibles con razonamiento. La lista integrada es Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.5, Gemini 3.1 Pro preview y GPT-4o.
Kimi API: Kimi K2.5 ya no viene integrado; solo aparece si Moonshot aún lo lista al pulsar Actualizar modelos.
Gemini: la lista integrada contiene los modelos 3.x actuales; los retirados gemini-2.0-flash, gemini-2.5-pro-preview-05-06 y gemini-2.5-flash-preview-05-20 han desaparecido. Las instalaciones existentes conservan sus filas antiguas hasta que pulsas Actualizar modelos, que desactiva y marca lo que la API ya no ofrece. La familia 2.5 solo aparece tras una actualización si tu clave aún tiene acceso (Google limita 2.5 a los proyectos que ya la usaban). Una petición que no nombra ningún modelo de Gemini va a gemini-3.8-flash.
Ollama: cuando el proveedor está activado y es alcanzable, EYAS lee de Ollama las capacidades de cada modelo al cargar, en segundo plano y al pulsar Actualizar modelos. Los modelos que Ollama ya no lista se marcan La última actualización ya no lo ofrece y se desactivan también tras una carga. Un Ollama desactivado o inalcanzable nunca se contacta.

API (integradores). GET /api/v1/model/providers/:id y GET /api/v1/model/models devuelven por modelo realModelId, missing (true cuando la última actualización ya no lo ofrecía) y la capacidad de razonamiento efectiva. POST /api/v1/model/providers/:id/models/refresh devuelve las listas missing y restored, o 502 con ModelDiscoveryFailed / ModelDiscoveryEmpty.

Esfuerzo de razonamiento

El esfuerzo de razonamiento se decide por modelo, en el momento en que un modelo responde de verdad. Cuando cambia el modelo — enrutado, un reintento o un fallback —, EYAS vuelve a calcular el nivel para el nuevo modelo.

Un nivel que el modelo no admite se ajusta al más cercano que sí admite. Máximo en un modelo cuyo tope es Muy alto corre como Muy alto; Muy alto en un modelo que no lo tiene corre como Alto.
Un modelo que no puede desactivar el razonamiento recibe su nivel más bajo cuando se pide Ninguno.
Un modelo del que EYAS no tiene datos verificados no recibe ningún parámetro de razonamiento (Automático: el valor por defecto del propio modelo). EYAS nunca envía un valor adivinado.
Los presupuestos de thinking de los modelos que usan un presupuesto de tokens (por ejemplo Claude Haiku 4.5 o Gemini 2.5) se dimensionan a partir del límite de salida del propio modelo y siempre dejan sitio a la respuesta, así que Máximo no puede superar el límite del modelo.

La escala. La escala completa es Ninguno, Mínimo, Bajo, Medio, Alto, Muy alto, Máximo, más Automático. Automático no guarda nada en ese punto: el nivel sale entonces de más abajo en el orden siguiente y, cuando nada fija uno, no se envía nada y se aplica el valor por defecto del propio modelo.

De dónde sale el nivel (gana la primera coincidencia):

el Esfuerzo propio de la conversación;
Máximo cuando la conversación está en modo Deep;
el esfuerzo fijado en el colega (agente) con cuya voz habla la conversación — en un chat, el colega de la conversación; si no, el colega por defecto del proyecto;
el nivel de la conversación más cercana que delegó el trabajo (una subconversación hereda de su padre, hasta cinco niveles hacia arriba);
el valor por defecto del nivel de enrutado, para un mensaje enrutado por un nivel y para las llamadas en segundo plano de EYAS (ver Enrutado y presupuesto — Esfuerzo por defecto del nivel);
el valor por defecto del propio modelo.

El mismo orden se aplica dondequiera que se ejecute un colega o un especialista: chat interactivo, el hilo de inicio de un colega, ejecuciones en segundo plano y programadas, reintentos y reanudaciones (una ejecución reanudada usa exactamente el esfuerzo que usó su primera ejecución), miembros de equipo, tareas delegadas y especialistas, etapas de pipeline, tareas A2A, respuestas en canales de mensajería y Modo Dios. Así, el esfuerzo propio de un colega se aplica en su chat y en los canales, y un miembro de equipo o especialista sin esfuerzo propio hereda el nivel de la conversación que delega — una conversación Deep manda por tanto a sus especialistas a Máximo, lo que cuesta más. Un miembro o especialista con esfuerzo propio lo conserva. En Modo Dios, un esfuerzo fijado en la conversación se copia a cada participante y el modo Deep se transmite; después, el nivel de cada participante se ajusta a su propio modelo, y los votos de la revisión cruzada también usan el esfuerzo de la conversación.

Un único selector de esfuerzo, por modelo. La barra de campos de la conversación, el editor del colega, cada nivel de enrutado y una rutina de agente programada usan el mismo selector Esfuerzo. Lista solo los niveles que acepta el modelo correspondiente — por ejemplo Muy alto en los modelos que lo ofrecen (Claude Opus 4.7/4.8/5.x, GPT-5.4/5.5/5.6), Ninguno y Mínimo donde el modelo los tiene. Un modelo de encendido/apagado muestra Desactivado / Activado. Un modelo sin control de esfuerzo, o uno del que EYAS no tiene datos verificados, solo ofrece Automático, y una pista explica por qué; otra pista indica cuándo un modelo no muestra el texto de su razonamiento. En una conversación con auto-enrutado, o para un colega sin modelo fijo, no hay un único modelo fijado: el selector ofrece todos los niveles que acepta al menos un modelo de los niveles de auto-enrutado (Rápido, Estándar, Complejo, Ejecución de código), y el nivel de cada mensaje se ajusta al modelo en el que se ejecuta.

Automático dice qué significa. Automático es la primera entrada y nombra aquello a lo que recurre en ese sitio: Automático · Máximo (Profundo), Automático · Alto (colega), Automático · Muy alto (conversación que delega) o Automático · predeterminado del modelo (Medio) — el valor por defecto del propio fabricante del modelo.

La lista sigue al modelo. Cuando cambia el modelo de una conversación, el modo Deep o el colega, la lista se actualiza. Un modelo nuevo nunca reescribe el esfuerzo guardado de una conversación: un nivel que falta en el nuevo modelo se muestra, por ejemplo, como Muy alto → Alto (Opus 4.6 no ofrece Muy alto), y cada turno se ajusta y se registra. En el editor del colega y en un nivel de enrutado, elegir un modelo que no ofrece el nivel guardado lo cambia antes de guardar y lo avisa: Esfuerzo ajustado de Muy alto a Alto: el modelo elegido no ofrece Muy alto. Un modelo sin control de esfuerzo lo cambia a Automático.

Los niveles guardados se comprueban contra el modelo. Cuando fijas un esfuerzo en una conversación, en un colega o en un nivel de enrutado, EYAS comprueba el nivel contra el modelo en el que corre. Un nivel que ese modelo no admite se rechaza y no se guarda nada — la conversación lista los niveles que acepta, y una fila de nivel dice El modelo no ofrece este nivel de esfuerzo. No se guardó nada. Automático siempre se acepta, y también cualquier nivel cuando el modelo no se conoce de antemano (una conversación con auto-enrutado, un colega sin modelo, un modelo del que EYAS no tiene datos verificados); esos se ajustan en cada llamada. Cambiar solo el modelo nunca falla por un esfuerzo guardado.

Con qué se ejecutó cada respuesta. Bajo cada respuesta, junto a Proveedor · modelo, un pequeño chip muestra el esfuerzo con el que se ejecutó realmente el turno: Esfuerzo: Alto, o Esfuerzo: Muy alto → Alto cuando el modelo no ofrecía el nivel pedido. Su tooltip dice quién lo fijó (conversación, Profundo, colega, conversación que delega, nivel de enrutamiento, predeterminado del modelo). No hay chip cuando no se pidió ni se envió nada. Cada respuesta guardada conserva el esfuerzo pedido y el efectivo, de dónde vino el nivel y si se ajustó — para el chat, las ejecuciones delegadas y de especialistas, las etapas de pipeline y los canales. La traza de cada llamada de IA registra lo mismo — ver Observabilidad.

Qué muestra la página de Proveedores. Cada fila de modelo tiene una línea de razonamiento, por ejemplo Razonamiento: Bajo, Medio, Alto, Muy alto, Máximo · predeterminado Medio, con una insignia que dice de dónde salen los datos: informado por el proveedor (la lista de modelos propia del proveedor o del runtime) o catálogo de EYAS, verificado el AAAA-MM-DD (el catálogo versionado de EYAS con datos de razonamiento verificados). Un modelo sin control de esfuerzo muestra Razonamiento: sin control de esfuerzo; uno que EYAS no conoce muestra Razonamiento: desconocido para EYAS (el esfuerzo queda en Automático).

API (integradores). GET /api/v1/model/effort-options?providerId&modelId (read sobre Model) devuelve los niveles de un modelo; con un id de modelo o alias a secas, los niveles del modelo de su único proveedor propietario; sin modelo, la unión de los niveles de auto-enrutado. GET /api/v1/conversations/:id/effort-options (read sobre Conversation, solo el propietario) devuelve los niveles, el nivel guardado (current) y lo que hereda Automático (inherited). Un nivel rechazado devuelve 400 con el código EFFORT_UNSUPPORTED, el nivel y los levels que admite el modelo.

Cómo aplica cada proveedor el nivel de esfuerzo

EYAS calcula un nivel por llamada, como se describe arriba, y cada proveedor solo lo traduce. En todos los casos EYAS envía solo lo que se sabe que acepta el modelo que responde; un modelo sin datos verificados no recibe ningún parámetro de razonamiento.

Proveedor	Qué envía EYAS para un nivel	De dónde salen los niveles	Automático	Nivel efectivo bajo la respuesta
API de Anthropic	El ajuste de esfuerzo del modelo (donde lo tiene) más thinking — adaptativo, o un presupuesto de tokens donde el modelo lo admite; Ninguno apaga el thinking donde el modelo lo permite	La Models API de Anthropic, con los datos que no informa (predeterminado, siempre activo, rango de presupuesto) del catálogo de EYAS	Nada; a un modelo que piensa por defecto pero oculta su razonamiento solo se le pide un resumen	El nivel que envió EYAS
Endpoints compatibles con Anthropic (MiniMax, Synthetic, Xiaomi MiMo)	Nada	— (sin datos verificados)	Siempre	—
OpenAI	`reasoning_effort`, con el límite de salida como `max_completion_tokens` y sin temperatura	Catálogo de EYAS	Nada	El nivel que envió EYAS
OpenRouter	`reasoning: { effort }`; OpenRouter lo pasa al modelo de origen y puede ajustarlo	La lista de modelos de OpenRouter (razonamiento sí/no); las familias conocidas, del catálogo de EYAS	Nada	El nivel que envió EYAS
Kimi API (Moonshot)	`reasoning_effort` (K3) o thinking activado/desactivado (K2.6); sin temperatura	Catálogo de EYAS	Nada	El nivel que envió EYAS
Pasarelas compatibles con OpenAI (xAI, Mistral, Groq, Together, DeepSeek, Cerebras, Venice, Hugging Face, NVIDIA, Z.AI, Kilo, Vercel AI Gateway, Qianfan, vLLM)	Nada — salvo `reasoning_effort` para Grok 3 Mini de xAI	Catálogo de EYAS para Grok 3 Mini en xAI; todavía no se ha verificado el control de razonamiento de ninguna otra pasarela	Siempre, salvo Grok 3 Mini	El nivel que envió EYAS (Grok 3 Mini); si no, —
Gemini	Un nivel de thinking (Gemini 3) o un presupuesto de thinking (Gemini 2.5), con resúmenes de pensamiento	Catálogo de EYAS; la lista de modelos de Google puede marcar un modelo como sin thinking	Nada; a los modelos que piensan por defecto solo se les piden sus resúmenes	El nivel que envió EYAS
Ollama	`think`: activado/desactivado, o el nivel con nombre propio del modelo	La información de modelo de Ollama (la capacidad thinking y sus valores); gpt-oss, del catálogo de EYAS	Nada	El nivel que envió EYAS
LM Studio	Nada — el razonamiento se configura en LM Studio	—	Siempre; el panel muestra el ajuste propio de LM Studio	—
Claude Code CLI	El esfuerzo que el binario en ejecución informó para el modelo; Ninguno apaga el thinking donde el modelo lo permite	El propio runtime de Claude Code, leído sin prompt	Nada	Releído del runtime
Grok CLI	La opción de esfuerzo de razonamiento de la sesión, fijada antes del prompt	El propio Grok CLI, leído sin prompt	Nada; el turno registra el nivel que usó Grok	Releído de Grok en cada turno
Kimi Code CLI	La variante con razonamiento o la normal del modelo, elegida en la sesión	La lista de modelos propia de Kimi	Mantiene la variante que Kimi ejecuta ahora	Releído de Kimi en cada turno

El nivel que envió EYAS significa que el chip bajo la respuesta muestra el nivel después de que EYAS lo ajustara al modelo. Releído significa que la CLI informa del nivel con el que corrió de verdad, y eso es lo que registran el chip y la traza, aunque difiera de lo que pidió EYAS.

Detalles por proveedor.

API de Anthropic. Las opciones de un modelo Claude son exactamente los niveles que admite: Muy alto existe en Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8 y Sonnet 5, pero no en Opus 4.6 ni en Sonnet 4.6; Desactivado solo se ofrece donde el modelo puede apagar el razonamiento (no en Fable ni en Opus 5.5). Haiku 4.5 y Sonnet 4.5 no tienen ajuste de esfuerzo, así que el nivel se convierte en un presupuesto de thinking dimensionado según el límite de salida del modelo, y EYAS sube el límite de longitud de la respuesta para que el razonamiento nunca corte la respuesta. Automático no envía nada (Opus 5.5 usa Medio por defecto; Opus 4.8 no piensa si no se le pide). A los modelos que ocultan su razonamiento salvo que se les pida (Fable, Opus 5.5, Opus 5, Opus 4.7, Opus 4.8, Sonnet 5) se les pide un resumen del razonamiento siempre que piensan — también en Automático para los que piensan por defecto —, para que se vea en el chat; esto solo cambia lo que se muestra. EYAS no envía temperatura, top_p ni top_k a los modelos que los rechazan (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), y nunca junto con thinking activado.
Endpoints compatibles con Anthropic (MiniMax, Synthetic, Xiaomi MiMo): solo Automático. EYAS no envía ningún control de razonamiento hasta que se verifique el comportamiento de un modelo; la temperatura se pasa tal como está fijada.
OpenAI. Todos los modelos de la generación GPT-5 que sirve la API de Chat Completions, y la serie o, reciben el nivel, cada uno con su propio rango: GPT-6 Astra Bajo–Máximo (no se puede desactivar); GPT-5.6 Ninguno–Máximo, predeterminado Medio; GPT-5.5 Ninguno–Muy alto, predeterminado Medio; GPT-5.4 Ninguno–Muy alto, predeterminado Ninguno; GPT-5.4 mini / nano y GPT-5.2 Ninguno–Muy alto, predeterminado Ninguno; GPT-5.1 Ninguno–Alto, predeterminado Ninguno; GPT-5 / GPT-5 mini / nano Mínimo–Alto, predeterminado Medio; GPT-5 pro solo Alto; o1 / o3 / o3-mini / o4-mini Bajo–Alto, predeterminado Medio. Un nivel que falta pasa al más cercano (Máximo en GPT-5.5 corre como Muy alto). A estos modelos de razonamiento EYAS nunca envía una temperatura y usa el límite de salida de los modelos de razonamiento (max_completion_tokens) — incluidas las llamadas en segundo plano como la captura de memoria, que antes GPT-5.2 y GPT-5.4 mini / nano podían rechazar. Con un nivel explícito, un límite de salida pequeño se sube a lo que necesita el nivel (Bajo 8k, Medio 16k, Alto 32k, Muy alto/Máximo 64k tokens, nunca por encima del límite propio del modelo). Los modelos sin datos verificados (GPT-4o, GPT-4o mini y otros) no reciben ningún parámetro de razonamiento y conservan max_tokens y la temperatura. Algunos modelos de OpenAI solo existen en la Responses API de OpenAI, no en la API de Chat Completions que usa EYAS: GPT-5.2 pro, GPT-5.4 pro, GPT-5.5 pro, los modelos Codex (GPT-5 Codex, GPT-5.1 Codex / Codex Max, GPT-5.2 / 5.3 Codex, codex-mini), o1-pro, o3-pro y los modelos de deep research. En el proveedor OpenAI se quedan solo en Automático y no pueden responder; úsalos a través de OpenRouter. GPT-5.1 mini no tiene niveles de esfuerzo publicados, así que se queda en Automático.
OpenRouter. Los modelos que OpenRouter marca como compatibles con razonamiento ofrecen Mínimo–Máximo; los modelos que lista sin razonamiento no tienen control de esfuerzo. Las familias conocidas muestran sus niveles reales: Claude Opus/Sonnet 4.6 (Desactivado, Bajo, Medio, Alto, Máximo), OpenAI GPT-5.x / GPT-6 Astra / serie o (como en OpenAI), Gemini 3.x (los niveles de thinking de Gemini, así que Muy alto corre como Alto). También conocidos: GPT-5.2 Ninguno–Muy alto (predeterminado Ninguno); GPT-5.2 pro Medio–Muy alto; GPT-5.4 pro Medio–Muy alto (predeterminado Medio); GPT-5.5 pro Medio–Muy alto (predeterminado Alto); GPT-5.4 mini / nano como en OpenAI; GPT-5.2 / 5.3 Codex Bajo–Muy alto. Desactivado solo se ofrece donde la familia puede apagar el razonamiento.
Kimi API (Moonshot). Kimi K3: Bajo / Alto / Máximo (predeterminado Máximo; Medio corre como Bajo). Kimi K2.6: razonamiento activado (Alto) o desactivado (Ninguno). Kimi K2.7 Code y K2.7 Code Highspeed razonan siempre y no tienen control de esfuerzo.
Pasarelas compatibles con OpenAI: solo Automático, incluidos los ids con prefijo de fabricante como openai/gpt-5.4. En el proveedor xAI API, Grok 3 Mini (y Grok 3 Mini Fast) es el único modelo con control de esfuerzo: Bajo o Alto (Medio corre como Bajo; Muy alto y Máximo corren como Alto). Siempre razona, y su razonamiento se muestra. xAI ya no lista Grok 3 Mini, y Oracle Cloud lo retiró el 2026-08-15, así que puede que ya no responda. Los demás modelos Grok de la API de xAI razonan al nivel por defecto de xAI: EYAS habla con xAI por Chat Completions, donde xAI no documenta ningún parámetro de esfuerzo para ellos. El proveedor Grok CLI conserva su control de esfuerzo.
Gemini. Los modelos Gemini 3 (3.8/3.7/3.6/3.5 Flash, 3.5/3.1 Flash-Lite, 3.1 Pro Preview, 3 Flash Preview) reciben un nivel de thinking — Mínimo, Bajo, Medio o Alto. Un nivel que falta pasa al más cercano (3.8/3.7 Flash y 3.1 Pro no tienen Mínimo, así que pasa a Bajo; Muy alto y Máximo pasan a Alto). Los modelos Gemini 3 piensan siempre, así que Ninguno los ejecuta en su nivel más bajo. Los modelos Gemini 2.5 reciben un presupuesto de thinking derivado del nivel, dentro del rango del modelo (2.5 Pro 128–32.768 tokens; 2.5 Flash hasta 24.576; Flash-Lite 512–24.576); Ninguno apaga el thinking en 2.5 Flash y Flash-Lite, mientras que 2.5 Pro corre en su nivel más pequeño. Google factura los tokens de thinking en cualquier caso. Un límite de salida pequeño se sube para que quepa el nivel, nunca por encima del límite propio del modelo. Los modelos que la lista de Google marca como sin thinking (por ejemplo las variantes TTS) no reciben ningún parámetro de thinking.
Ollama. Los modelos que informan de la capacidad thinking reciben Activado / Desactivado: Ninguno apaga el thinking, cualquier nivel superior lo enciende. gpt-oss acepta Bajo, Medio y Alto (predeterminado Medio) y no se puede desactivar (Ninguno pasa a Bajo). Un Ollama reciente que informa de los valores exactos de thinking de un modelo recibe exactamente esos, con el predeterminado de Ollama marcado. Automático no envía nada (los modelos con thinking piensan por defecto). Un modelo sin la capacidad, o cuyas capacidades no se pudieron leer, nunca recibe un ajuste de thinking — Ollama rechazaría la petición. Con un nivel explícito, un ajuste pequeño de tokens máximos se sube para dejar sitio al thinking.
LM Studio. EYAS nunca envía un parámetro de razonamiento ni de esfuerzo a LM Studio, así que cualquier nivel es allí en la práctica Automático. Cuando LM Studio informa del ajuste de razonamiento de un modelo, el panel de LM Studio lo muestra por modelo, por ejemplo qwen/qwen3-8b — El razonamiento de este modelo se configura en el propio LM Studio (valor predeterminado allí: on). EYAS lo muestra y no lo cambia. Las versiones antiguas de LM Studio no muestran ninguna pista.
Claude Code CLI, Grok CLI, Kimi Code CLI. Ver Modelos y esfuerzo de Claude Code, Modelos y esfuerzo de Grok y Modelos y razonamiento de Kimi.
OpenCode es un sidecar de herramientas, no un proveedor de chat: su modelo y su variante de razonamiento se fijan en la página de OpenCode (ver OpenCode — Modelo y razonamiento).

Nuevas versiones de un modelo conocido. Una instantánea con fecha, un alias -latest o una variante de contexto [1m] de un modelo que EYAS conoce recibe los niveles de ese modelo — por ejemplo gpt-5.4-mini-2026-03-17 o kimi-k3-0115. Una variante distinta (pro, codex, chat, preview, beta, fast, …) o una familia de modelos desconocida se queda solo en Automático hasta que EYAS tenga datos verificados de ella. Los niveles nunca pasan de un proveedor a otro.

Runtime de Claude Code

EYAS ejecuta el CLI de Claude Code que instalaste y usa un solo binario para todo: la comprobación de sesión, la disponibilidad del proveedor, la autoconfiguración del primer arranque, el descubrimiento de modelos y cada turno de conversación. Lo que informa eyas doctor es lo que corre. El binario se elige en este orden:

EYAS_CLAUDE_CODE_BIN — ruta absoluta al ejecutable claude.
El claude que se encuentre en el PATH del servidor.
Como último recurso, la copia más antigua de Claude Code incluida en la dependencia Agent SDK de EYAS (hoy 2.1.89). eyas doctor avisa cuando se usa.

EYAS_CLAUDE_CODE_BIN es a propósito una variable de entorno, no un ajuste de la UI. Úsala cuando el PATH del servicio no tiene claude (servicios launchd/systemd, contenedores) o para fijar una instalación concreta. Si está definida pero no es válida (no absoluta, inexistente o no ejecutable), el proveedor Claude Code queda apagado: no hay fallback al PATH ni a la copia incluida, y doctor informa de un fallo.

Desfase de versión. El cliente SDK de EYAS se construyó para Claude Code 2.1.89. Un CLI más nuevo se usa tal cual, y doctor muestra un aviso de version skew. Las opciones que solo entienden los CLI más nuevos se envían solo a los runtimes que las tienen (por ejemplo el thinking resumido, a partir de 2.1.280). Claude Code no se actualiza solo mientras EYAS lo ejecuta (ver Aislamiento de Claude Code); actualízalo tú como de costumbre y revisa después su línea de doctor (ver Versiones de CLI probadas).

Con sesión iniciada, no solo instalado. EYAS comprueba la sesión con claude auth status --json, un comando local que no abre sesión, no envía prompt y no cuesta nada. El proveedor Claude Code se registra — y una instalación nueva lo enciende automáticamente — solo cuando ese binario tiene la sesión iniciada: login de claude.ai, ANTHROPIC_API_KEY o una configuración Bedrock/Vertex. Que claude esté en el PATH no basta. Si inicias sesión más tarde, apaga y vuelve a encender el proveedor en Proveedores, o reinicia EYAS. El correo y la organización de la cuenta que imprime el comando nunca se registran ni se guardan.

Sin llamadas ocultas al modelo. EYAS nunca envía un prompt de prueba al CLI del host para comprobarlo ni para listar sus modelos. La lista de modelos se lee del propio runtime, sin prompt — ver más abajo.

Thinking. EYAS no apaga el thinking en los turnos de Claude Code salvo que se pida Ninguno. Si no se pide ningún esfuerzo, se aplica el valor por defecto del propio modelo. Un nivel pedido solo se envía como el esfuerzo que ese runtime informó para el modelo; no se envían presupuestos fijos de tokens de thinking. Para la escala y de dónde sale un nivel, ver Esfuerzo de razonamiento.

Modelos y esfuerzo de Claude Code

La lista de modelos sale del runtime. EYAS pregunta al runtime de Claude Code que ejecuta de verdad — el mismo binario que informa eyas doctor — qué modelos ofrece. Lo hace cada vez que arranca el proveedor y cuando pulsas Actualizar modelos. No envía ningún prompt, no cuesta nada y se ejecuta aislado de tus propios ajustes de Claude Code; los datos de la cuenta que vienen en esa respuesta nunca se leen ni se guardan.

Cada entrada nombra el modelo concreto de Claude que ejecuta su alias, por ejemplo opus ejecuta claude-opus-5-5. La entrada Claude Code (Default) ejecuta el modelo que el runtime use por defecto.
Las entradas que el runtime deja de ofrecer se desactivan y se marcan, nunca se borran — por ejemplo, Fable se desactiva en un runtime que no lo conoce.
Los niveles de esfuerzo por modelo son exactamente los que informa el runtime, incluido Muy alto donde lo ofrece. Un modelo para el que el runtime no ofrece control de esfuerzo, como Haiku, solo ofrece Automático. Automático no envía nada, así que se aplica el valor por defecto del propio modelo (por ejemplo Medio en Opus 5.5).
EYAS nunca envía un nivel que el binario en ejecución no haya informado para ese modelo. Si los niveles guardados vienen de otra versión de Claude Code, no se envía ningún nivel hasta el siguiente arranque o actualización.
El thinking resumido (para que el razonamiento del modelo se vea en el chat) se pide a Claude Code 2.1.280 o posterior. Un Claude Code más antiguo — incluida la copia 2.1.89 que trae EYAS — no ofrece forma de pedirlo: para los modelos que ocultan su thinking salvo que se les pida (Fable, Opus 5.5, Opus 5, Opus 4.7/4.8, Sonnet 5), el selector de esfuerzo dice entonces Este modelo no muestra el texto de su razonamiento. Los niveles de esfuerzo en sí no cambian. Actualiza Claude Code a 2.1.280 o posterior y actualiza los modelos (o reinicia EYAS) para ver el razonamiento.
Ventana de contexto. Las entradas Fable, Opus, Sonnet y Haiku indican una ventana de 200k — la que el runtime da a esos nombres —, también en el primer arranque o mientras no se puede leer la lista de modelos del runtime. Solo una entrada que el propio runtime ofrece como su variante de 1M (por ejemplo Opus (1M context), alias opus[1m]) se lista y se dimensiona con 1M. Cuando el runtime informa de una ventana mayor para el modelo que respondió, la barra de contexto sigue usando esa. Una entrada que una versión anterior guardó con 1M, y que ninguna lectura de modelos ha confirmado desde entonces, se corrige a 200k en el siguiente arranque, aunque la lectura de modelos siga fallando; las entradas que desactivaste siguen desactivadas.
El esfuerzo efectivo se relee del runtime en cada turno: pides Muy alto, el runtime ejecuta Alto y la respuesta lo dice; con Automático, la respuesta nombra el nivel que usó realmente el modelo.
Cada respuesta registra el modelo concreto que respondió, en las trazas y en la atribución de la memoria. Un turno sin modelo elegido se atribuye a Claude Code (Default).

Llamadas en segundo plano en una CLI. Las llamadas al modelo en segundo plano (captura de memoria, títulos, controles de seguridad) usan un modelo concreto de Claude Code, Grok CLI o Kimi Code CLI de un nivel de enrutado solo cuando el descubrimiento propio de esa CLI ofreció ese modelo; si no, se ejecutan con el modelo por defecto de la CLI. Adónde va ahora mismo el trabajo en segundo plano de EYAS lo muestra Enrutado y presupuesto — Tarjeta de llamadas de modelo en segundo plano.

Las llamadas en segundo plano conservan su límite de salida en una CLI. Las pequeñas llamadas únicas propias de EYAS — títulos de conversación, clasificación de mensajes, captura de memoria, el veredicto del juez de seguridad, consolidación y pasadas en segundo plano similares — piden una longitud máxima de respuesta. Las CLI no aceptan ningún límite de salida de EYAS, así que en Claude Code, Grok CLI y Kimi Code CLI EYAS cuenta la respuesta mientras llega: en cuanto supera unos cuatro caracteres por token pedido (maxTokens × 4 caracteres), EYAS detiene la CLI (Claude Code: se cierra la consulta; Grok y Kimi: se cancela la sesión). La llamada termina entonces con normalidad, con la respuesta hasta ese punto y el motivo de parada max tokens (Límite de salida alcanzado), nunca con un error — como en los proveedores de API. Solo cuenta la respuesta; el razonamiento no gasta el límite. Los turnos de chat y de agente con herramientas no se ven afectados, porque un turno de CLI ejecuta muchas llamadas al modelo. La comprobación de publicación lo demuestra en Claude Code 2.1.281 y Grok CLI 1.0.41; Kimi Code CLI usa el mismo camino de código, pero no se ha probado en vivo.

Aislamiento de Claude Code

EYAS ejecuta Claude Code siempre aislado. No hay interruptor: la antigua opción Cargar config Claude del host ha desaparecido. El panel del proveedor lo dice en una línea y remite a la importación de datos para traer el contenido de CLAUDE.md del host.

Cada ejecución de Claude Code — chat, agentes, trabajo en segundo plano y llamadas únicas aisladas por igual:

no carga settings.json del host (así que ni hooks ni reglas de permisos), ningún CLAUDE.md de ningún nivel (usuario, proyecto o local), ninguna skill del host, ni el .mcp.json del proyecto, servidores MCP de sistema de archivos o de claude.ai. Su único servidor de herramientas es el servidor eyas propio de EYAS; las llamadas únicas en segundo plano no reciben ninguno;
corre con la auto-memoria propia de Claude Code desactivada;
guarda sus archivos temporales, incluida la salida de los comandos de shell que ejecuta en segundo plano, en una carpeta propia de esa ejecución dentro de la carpeta de workspaces de EYAS — no en el /tmp/claude-<uid> del host. La carpeta se borra al terminar la ejecución; la que deje un fallo se borra en el siguiente arranque;
no escribe ninguna transcripción en ~/.claude/projects ni hace copias de checkpoint de archivos, así que las ejecuciones de EYAS no aparecen en claude --resume (las transcripciones que escribieron versiones anteriores de EYAS no se borran automáticamente);
conserva el inicio de sesión del host: una suscripción de claude.ai, una clave de API, un token OAuth, Bedrock o Vertex siguen funcionando.

Los ajustes de política gestionados por la empresa, donde una organización los despliega, siguen aplicándose; EYAS no puede desactivar ese nivel.

Los archivos de instrucciones de proyecto dentro de la carpeta de una conversación (CLAUDE.md, AGENTS.md) tampoco se cargan automáticamente. El modelo aún puede abrirlos con sus herramientas de archivo.

Carpeta de trabajo. Claude Code trabaja en la primera Carpeta de la conversación que sigue pasando la validación y, si no, en el workspace de EYAS propio de la conversación. Nunca corre en el directorio propio del servidor de EYAS (el home de EYAS, donde viven el archivo de claves, el vault y la base de datos). Las llamadas en segundo plano sin conversación usan una carpeta temporal por ejecución, que se borra tras 7 días sin uso. Una Carpeta guardada que ya no pasa la validación se omite, con un aviso en el log del servidor. Ver Conversaciones — Carpetas.

Entorno. Claude Code solo recibe un entorno en lista blanca: PATH, locale y zona horaria, proxies y paquetes de CA, HOME, y las variables de inicio de sesión de Anthropic / Claude OAuth / Bedrock / Vertex. Además, EYAS fija sus interruptores de aislamiento — CLAUDE_CODE_DISABLE_AUTO_MEMORY=1, CLAUDE_CODE_DISABLE_CLAUDE_MDS=1 y DISABLE_AUTOUPDATER=1 —, apunta CLAUDE_CODE_TMPDIR a la carpeta temporal propia de la ejecución y se identifica ante Claude Code como eyas. Las demás variables del servidor no se pasan: las claves de API de otros proveedores, los secretos de EYAS, CLAUDE_CONFIG_DIR y los interruptores CLAUDE_CODE_* de una sesión de Claude Code desde la que se arrancó EYAS. La comprobación de sesión (claude auth status) usa el mismo entorno. Por DISABLE_AUTOUPDATER, Claude Code no se actualiza solo mientras EYAS lo ejecuta.

Comprobación al arrancar. Claude Code informa al principio de cada ejecución de lo que cargó, y EYAS revisa ese informe antes de usar nada de la respuesta. Solo puede estar conectado el servidor de herramientas propio de EYAS, el modo de permisos debe ser default, la carpeta de trabajo debe ser la esperada, y no puede haber ningún plugin cargado — salvo los dos plugins que Claude Code 2.1.281 trae integrados, agents-md y telemetry, que solo se aceptan como agents-md@builtin y telemetry@builtin. La comprobación previa a cada versión de EYAS demostró que son inofensivos bajo su aislamiento: ningún AGENTS.md de la carpeta de trabajo ni de una subcarpeta llega al modelo. Cualquier otro plugin, incluido un nuevo plugin integrado de una versión posterior de Claude Code, sigue deteniendo la ejecución. Si aparece cualquier otra cosa — por ejemplo un servidor MCP o un plugin de la configuración del host, o una política gestionada que fuerza otro modo de permisos —, EYAS detiene la ejecución al instante. No se muestra nada de esa ejecución, y el turno falla con un error de aislamiento de CLI que nombra las comprobaciones fallidas en tu idioma — por ejemplo Claude Code CLI se detuvo: EYAS no pudo confirmar que se ejecuta aislado (la carpeta de trabajo no era la que eligió EYAS). El turno no se pasó a otro modelo. No se reintenta ni se pasa a otro proveedor. El arreglo está en el host: quita el ajuste gestionado o el plugin que molesta, o comprueba a qué binario apunta EYAS_CLAUDE_CODE_BIN.

Las herramientas propias de Claude Code pasan primero la política de memoria de EYAS. Antes de que se ejecute Read, Write, Edit, Glob, Grep, Bash, NotebookEdit, WebFetch o cualquier otra herramienta de Claude Code, una comprobación compara cada ruta que toca con la política de memoria de EYAS — incluidas las lecturas que Claude Code permitiría por su cuenta dentro de su carpeta de trabajo. Se rechazan la memoria de otras herramientas (~/.claude, ~/.grok, ~/.codex, bóvedas de Obsidian, el resto de la lista y security.foreignMemoryPaths), la carpeta de datos propia de EYAS y el workspace de otra conversación. Una llamada rechazada no se ejecuta; Claude Code recibe el motivo — por ejemplo Memory outside EYAS (Obsidian) — use memory_search / memory_expand from EYAS — y puede seguir con las herramientas de memoria de EYAS. Grep, Glob, LS y las búsquedas recursivas con Bash se juzgan por todo lo que pueden alcanzar: una cuya carpeta contiene un sitio protegido — por ejemplo un Grep de ~, o un Grep del checkout de EYAS, que contiene data/ — se rechaza como Search too broad …, y Claude Code puede reintentar en una carpeta más concreta. Ver Seguridad y privacidad — Memoria fuera de EYAS. Además de esa comprobación, los comandos de shell de Claude Code se ejecutan dentro del sandbox de archivos del sistema operativo donde lo hay — ver Sandbox de archivos del kernel.

Herramientas de EYAS en Claude Code. Claude Code llega a las herramientas de EYAS a través del servidor MCP in-process eyas, con el nombre mcp__eyas__<nombre> en su prompt. Ese servidor ofrece exactamente las herramientas que EYAS ofrece a la ejecución: la lista Herramientas del agente más memory_search y memory_expand (una lista vacía significa todas). En una conversación Solo no ofrece herramientas de delegación. Las herramientas de EYAS para las que Claude Code tiene un equivalente propio concedido no se pasan — read_file, grep y glob (sus Read, Glob y Grep), write_file y edit_file mientras pueda escribir, y run_command, git_status y git_diff mientras pueda usar su shell —: Claude Code usa entonces sus propias herramientas en las carpetas del turno, bajo el sandbox y la política de memoria. En una lista sin run_command, git_status y git_diff se pasan como herramientas de EYAS. Todas las demás herramientas de EYAS se pasan, incluidas las de navegador de EYAS (browser_*, con las sesiones guardadas y browser_totp), agent_browser_*, browser_use_* y opencode_*; se ejecutan en EYAS con el mismo security gate, las mismas aprobaciones y el mismo ámbito de herramientas que en un proveedor de API. El drill-down de memoria cuenta 3 llamadas por respuesta, como en cualquier otro proveedor. Ver MCP — Paridad de herramientas CLI MCP.

La lista Herramientas del agente también limita las herramientas propias de la CLI. En Claude Code, Grok CLI y Kimi Code CLI por igual, la lista Herramientas de un agente decide qué herramientas integradas propias de la CLI puede usar el modelo, no solo a qué herramientas de EYAS llega por el puente — igual que limita a un modelo de API:

Escribir archivos (Write, Edit y NotebookEdit de Claude Code; las herramientas de edición y de movimiento de Grok y Kimi, y las escrituras de archivos que EYAS sirve a la CLI): solo cuando la lista contiene write_file o edit_file.
Comandos de shell (Bash de Claude Code; las herramientas de ejecución de Grok y Kimi; un borrado también cuenta como comando de shell, tal como lo clasifica el security gate): solo cuando la lista contiene run_command. git_status y git_diff no conceden el shell.
Búsqueda y descarga web (WebFetch y WebSearch de Claude Code; las herramientas de descarga de Grok y Kimi, y web_fetch y web_search de Grok): solo cuando la lista contiene una herramienta web — research, browser_navigate, agent_browser_run o browser_use_exec.
Leer archivos (Read, Glob y Grep de Claude Code; las herramientas de lectura, búsqueda y listado de Grok y Kimi) siempre está permitido, diga lo que diga la lista. Se queda dentro de las carpetas de la conversación bajo la política de memoria y el sandbox de archivos del kernel. La búsqueda en memoria también está siempre disponible.
Una lista vacía sigue significando todas las herramientas, incluidas las propias de la CLI.

En Claude Code, las herramientas retenidas ni siquiera se ofrecen al modelo. En Grok y Kimi, EYAS rechaza una herramienta retenida que la CLI intenta usar antes de preguntar al security gate: no hay petición de aprobación, y la fila de la herramienta muestra Denegado (Grok muestra su propio texto de rechazo en la fila). Las peticiones de permiso de Kimi no dicen qué tipo de herramienta pregunta (leído del código fuente de Kimi 1.52.0; aún sin verificar en un equipo), así que EYAS rechaza una petición de Kimi que no puede clasificar siempre que a la lista del agente le falten las herramientas de escritura de archivos o run_command — un agente así no puede usar ninguna de las herramientas de Kimi que preguntan (escribir o reemplazar archivos, shell, tareas en segundo plano). La búsqueda y la descarga web de Kimi nunca preguntan a EYAS, así que no se pueden permitir por agente; la comprobación de aislamiento de EYAS sigue deteniendo un turno que las usa. Migración: los agentes existentes con una lista estrecha — por ejemplo un Asistente personal sin run_command / write_file — ya no pueden escribir archivos ni ejecutar comandos en Claude Code, Grok ni Kimi. Para permitirlo, añade write_file / edit_file y/o run_command a la lista, o vacía la lista. Ver Agentes — Herramientas.

Especialistas. Claude Code no arranca subagentes ocultos propios (no se le ofrece su herramienta integrada Task/Agent). Cuando un colega en Claude Code reparte trabajo, lanza especialistas a través de EYAS con run_specialist, igual que en los demás proveedores — ver Equipos y delegación.

Actualización. Una instalación que tenía Cargar config Claude del host activado pasa a aislado automáticamente; el ajuste guardado se elimina en el primer arranque, y cualquier valor que quede se ignora. Las instrucciones de CLAUDE.md y las skills del host ya no llegan a las conversaciones. Para conservar ese contenido, impórtalo una vez, en un solo sentido, con Ajustes → Sistema → Portabilidad de datos → Importar datos — ver Importación de datos.

Grok CLI y Kimi Code CLI

EYAS ejecuta Grok CLI y Kimi Code CLI totalmente aislados de la configuración propia de Grok, Kimi y Claude de la máquina.

Directorio personal propio. EYAS arranca cada CLI con su propio directorio personal dentro de la carpeta de datos de EYAS — <data dir>/cli-homes/grok-cli y <data dir>/cli-homes/kimi-cli. Las ejecuciones de EYAS no leen ni escriben ~/.grok, ~/.kimi, ~/.claude, ~/.cursor ni ~/.agents del operador: ni config, reglas o AGENTS.md del host, ni memoria, skills, hooks, importaciones de Claude/Cursor o servidores MCP (por ejemplo un servidor de una bóveda de Obsidian).

Entorno. A la CLI solo le llega una lista blanca corta: PATH, locale y zona horaria, TMPDIR, TERM, USER, LOGNAME, SHELL, variables de proxy y variables de paquetes de CA. Los secretos de EYAS, las claves de otros proveedores, una XAI_API_KEY del entorno del servidor y cualquier ajuste GROK_*, KIMI_* o XDG_* del servidor se descartan.

Qué binario. EYAS_GROK_BIN / EYAS_KIMI_BIN (la ruta absoluta al ejecutable) tienen prioridad; si no, grok / kimi en el PATH. Si la variable está definida pero no es válida, el proveedor no se registra — no hay fallback al PATH. Recargar el proveedor (apagar y encender) vuelve a buscar el binario.

Carpeta de trabajo. Un turno de Grok o Kimi corre en la primera Carpeta válida de la conversación, si no en el workspace de EYAS propio de la conversación y, si no, en una carpeta temporal privada de la ejecución — nunca en el directorio de trabajo propio del servidor de EYAS.

Ajustes de Grok que escribe EYAS. Antes de cada ejecución EYAS escribe config.toml, requirements.toml y un trusted_folders.toml vacío en su directorio personal de Grok; las ediciones locales ahí se sustituyen. Fijan:

Modo preguntar. Cada herramienta nativa de Grok — leer archivo, listar carpeta, buscar, shell, escribir/editar, fetch y búsqueda web, subagentes — pregunta primero a EYAS, y decide el gate de seguridad de EYAS.
Aprobar siempre está bloqueado. --always-approve, el modo yolo y /always-approve no funcionan.
La memoria, memory v2, la búsqueda de sesiones, la telemetría y la subida de trazas, el modo líder compartido (Grok arranca con --no-leader) y la autoactualización están desactivados.
Solo puede conectarse el servidor de herramientas propio de EYAS (eyas).
Nunca se concede confianza a una carpeta. El AGENTS.md, la config .grok, los hooks y los servidores MCP de una carpeta de conversación no se cargan automáticamente; el modelo aún puede abrir archivos con sus herramientas de archivo, y cada lectura pregunta a EYAS.

Ajustes de Kimi que escribe EYAS. EYAS fija default_yolo = false, telemetry = false y merge_all_available_skills = false en su propia config de Kimi y conserva todo lo demás de ese archivo (login, modelo por defecto). Kimi no recibe servidores MCP propios, la autoactualización está desactivada y se arranca exactamente como kimi acp. Kimi guarda además en ese mismo archivo el modelo al que EYAS lo cambia — ver Modelos y razonamiento de Kimi.

Los archivos de sesión se borran. Las transcripciones, el historial de prompts y los logs de herramientas que una CLI escribe en su directorio personal de EYAS se borran al terminar cada turno. Los restos de más de una hora (tras una caída) se eliminan al arrancar y cada hora. La conversación de EYAS no se ve afectada: EYAS la reproduce desde su propio almacén en cada turno.

La shell de Grok. Los comandos de shell de Grok corren con el directorio personal de Grok de EYAS como HOME, así que el ~/.gitconfig, las claves SSH y la configuración de shell del host no están disponibles — por ejemplo, los commits de git desde la shell de Grok no tienen identidad del host. Donde el servidor lo ofrece, las herramientas propias de Grok se ejecutan además dentro del sandbox de archivos del sistema operativo — ver Sandbox de archivos del kernel.

Límite de turnos. En Grok y Kimi el límite de turnos cuenta llamadas a herramientas. Un turno de chat usa los Turnos máx. del colega de la conversación (si no, los del agente por defecto del proyecto), o 25 por defecto; las ejecuciones de agente usan los Turnos máx. del agente; el ajuste maxTurns del proveedor (25 por defecto) solo se aplica a las llamadas que no fijan ningún presupuesto. Cuando la CLI arranca una llamada a herramienta más de las permitidas, EYAS cancela la sesión de la CLI: el turno termina como max turns y conserva la respuesta parcial. No es un error, y la llamada extra no se ejecuta. El mismo presupuesto es el tope interno de turnos de Claude Code para un turno de chat.

Sin límite de tiempo fijo. Un turno de Claude Code, Grok o Kimi no se detiene tras un tiempo fijo. Solo se detiene cuando la CLI se queda callada: 10 minutos sin ningún mensaje mientras no hay herramienta en marcha, o 20 minutos sin ningún mensaje mientras una herramienta está en marcha (por ejemplo un especialista lanzado con run_specialist, que puede tardar hasta 15 minutos, o una compilación larga). Cualquier mensaje de la CLI — texto en streaming, una herramienta que empieza o termina, una solicitud de permiso — vuelve a poner el reloj a cero, y no hay límite para el turno entero; Detener lo sigue terminando en cualquier momento. Un turno detenido por silencio informa de un timeout, no de un error genérico aborted; como otros timeouts, puede reintentarse una vez o pasar a otro modelo cuando todavía no se había transmitido nada, y el programador de reintentos automáticos puede reintentar una ejecución en segundo plano. Los dos límites son model.cli.idleTimeoutMs y model.cli.toolTimeoutMs — ver Configuración — Tiempos de espera de los turnos de CLI. La clave por turno que permite a Grok y Kimi llamar a las herramientas de EYAS caduca 2 horas después de su último uso, así que un turno largo y con actividad conserva sus herramientas de EYAS; se revoca en cuanto termina el turno.

Comandos con barra. Un mensaje que empieza por / (por ejemplo /always-approve on) se envía a Grok o Kimi envuelto en <message>…</message>, así que la CLI nunca lo ejecuta como uno de sus propios comandos. El modelo sigue viendo el texto.

Límites de Kimi. El aislamiento de Kimi se deriva de su código fuente y aún no se ha probado en una máquina (ver Versiones de CLI probadas). Kimi no tiene control de confianza de carpetas: sigue leyendo AGENTS.md / .kimi/AGENTS.md en la carpeta de la conversación, y hasta la raíz del repositorio git que la contiene cuando la carpeta está dentro de uno. Sus herramientas de búsqueda y web nunca preguntan a EYAS, así que un turno de Kimi que las usa lo detiene la comprobación de aislamiento de abajo. Por la misma razón, EYAS no puede rechazar una búsqueda de Kimi por demasiado amplia: Grep y Glob propios de Kimi nunca preguntan, el Glob de Kimi se queda dentro de su carpeta de trabajo pero su Grep acepta cualquier carpeta, y Kimi no tiene sandbox del kernel (ver Seguridad y privacidad — Memoria fuera de EYAS). La lista Herramientas del agente limita las herramientas propias de escritura, shell y web de Kimi y de Grok como se describe en Aislamiento de Claude Code.

Como Grok y Kimi corren en el directorio personal propio de EYAS, no se usa el inicio de sesión de la CLI en el equipo. Una instalación que dependía del inicio de sesión del host no tiene ningún modelo de Grok o Kimi funcionando hasta que alguien inicie sesión una vez para EYAS. El inicio de sesión propio de grok / kimi del operador en el host nunca se lee, se cambia ni se usa, y el inicio de sesión de EYAS se renueva solo.

La tarjeta Iniciar sesión para EYAS aparece en tres sitios: el panel del proveedor Grok CLI / Kimi Code CLI, el paso de proveedor de IA del asistente de setup siempre que se detecta Grok o Kimi, y un aviso en Inicio, <CLI> necesita iniciar sesión para EYAS, cuando una CLI activada e instalada no tiene la sesión iniciada (Iniciar sesión abre la tarjeta; Descartar oculta el aviso durante la sesión del navegador). Solo propietarios y administradores pueden iniciar o cerrar sesión, y solo ellos ven el enlace y el código de un inicio de sesión pendiente; los demás roles ven el estado.

Código de dispositivo (Grok y Kimi). Pulsa Iniciar sesión con un código de dispositivo. EYAS ejecuta el login propio de la CLI en su propia carpeta y muestra un enlace (Abrir la página de inicio de sesión) y un código. Abre el enlace en cualquier dispositivo, inicia sesión y comprueba que la página muestra el mismo código. El servidor no necesita navegador, así que funciona en servidores sin interfaz y en Docker. La tarjeta muestra Esperando a que confirmes el código… y luego Sesión iniciada.

Cancelar detiene un inicio de sesión pendiente.
Tras 15 minutos sin confirmación el inicio de sesión caduca; vuelve a empezar. Kimi además reinicia solo con un código nuevo.
Si EYAS no encuentra un enlace en la salida de la CLI, muestra el texto de la CLI tal cual para que puedas seguirlo.
Un fallo muestra el último mensaje de la CLI y Reintentar.

Clave de API en su lugar (solo Grok). Elige Usar una clave de API en su lugar y pega una clave de API de xAI. EYAS la guarda cifrada en Secretos como grok-cli-api-key (ámbito System) y solo la pasa a las ejecuciones de Grok CLI, como XAI_API_KEY. El uso se factura a la cuenta de la API de xAI, no a una suscripción de Grok/SuperGrok. Si existen a la vez un inicio de sesión por dispositivo y una clave, Grok usa el inicio de sesión por dispositivo. También puedes añadir la clave en la página Secretos con ese nombre; EYAS la recoge cuando se abre el panel del proveedor o la tarjeta del asistente, cuando se recarga el proveedor, o tras el primer turno que falla con el error de inicio de sesión. Kimi no tiene opción de clave de API en EYAS.

Cerrar sesión elimina la credencial de Grok o Kimi de EYAS de la carpeta de EYAS y borra la clave de API guardada. En Grok, EYAS ejecuta grok logout dentro de su propia carpeta. En Kimi, EYAS borra su propio archivo de credenciales y no ejecuta kimi logout, porque ese comando también borraría el token de Kimi del operador del llavero del sistema operativo. El inicio de sesión del host nunca se toca.

Sin sesión iniciada, un turno de conversación o en segundo plano en ese proveedor falla al instante, antes de arrancar la CLI, con <proveedor> no tiene la sesión iniciada para EYAS … inicia sesión en Proveedores (código de error cliSignIn). EYAS no lo reintenta ni cambia en silencio a otro proveedor. Un fallo de autenticación que la CLI informe durante un turno da el mismo mensaje.

Dónde viven las credenciales: <data dir>/cli-homes/grok-cli/.grok/auth.json y <data dir>/cli-homes/kimi-cli/.kimi/credentials/kimi-code.json, en carpetas que solo puede abrir el usuario de EYAS. Una copia de seguridad del directorio de datos las contiene.

API (integradores; propietarios/administradores, acceso de lectura para GET). GET /api/v1/model/providers/{grok-cli|kimi-cli}/sign-in devuelve {signedIn, method: device|apiKey|null, apiKeySupported, apiKeyStored, session{state: pending|succeeded|failed|expired|cancelled, verificationUrl, userCode, rawPrompt, error}}. POST {"method":"device"} devuelve 202 — consulta GET mientras está pendiente. POST {"method":"apiKey","apiKey":"…"} devuelve 200 (solo Grok; Kimi devuelve 400). DELETE cierra la sesión; DELETE ?target=session solo cancela un inicio de sesión por dispositivo pendiente. Los demás proveedores devuelven 404. Quien no puede gestionar modelos recibe verificationUrl, userCode, rawPrompt y error como null: quien confirma el código vincula su propia cuenta al directorio de EYAS.

El inicio de sesión de Kimi sigue el código fuente de la CLI de Kimi y aún no se ha verificado en un host real.

Comprobación de aislamiento antes de cada turno

Grok CLI y Kimi Code CLI solo corren después de que EYAS haya comprobado que están aislados. Un turno que no pasa una comprobación se detiene con un error de aislamiento; nunca se reintenta ni se pasa discretamente a otro modelo.

Grok se comprueba antes de cada turno, sin llamada al modelo: EYAS ejecuta grok inspect --json en la carpeta de la conversación, con su directorio personal de Grok de EYAS, y relee los archivos de config que escribió ahí. Una comprobación superada se reutiliza durante 10 minutos para el mismo binario de Grok, carpeta y directorio personal; cualquier cosa plantada en el directorio personal (una skill, una regla o un hook) obliga a comprobar de nuevo. Grok se rechaza cuando:

podría aprobar llamadas a herramientas por su cuenta (el bloqueo de aprobar siempre no está en vigor);
las reglas de permisos o una capa de config vienen de cualquier sitio que no sean los archivos propios de EYAS — por ejemplo un archivo de config de Grok para todo el sistema, o ajustes gestionados de Claude Code que añaden reglas de permisos;
arrancaría un servidor MCP distinto del puente propio de EYAS (los servidores que la lista blanca de EYAS ha desactivado están bien);
hay hooks, plugins o servidores de lenguaje configurados;
los archivos de instrucciones, las skills o los agentes vienen de su directorio personal o de fuera de las carpetas de la conversación;
las importaciones de Claude, Cursor o Codex están activadas;
se aplica la config propia de una carpeta de proyecto de confianza.

El archivo de ajustes gestionados por el fabricante de Grok. grok 1.0.41 escribe una caché de ajustes gestionados por el fabricante, managed_config.toml, en su directorio personal de Grok de EYAS; para una cuenta normal está vacía. Un archivo vacío se acepta. Un archivo con cualquier ajuste rechaza el turno con las comprobaciones de arriba (por ejemplo la aprobación de herramientas no está vinculada a EYAS), y cualquier cambio en él invalida al instante una comprobación superada, incluso dentro de los 10 minutos en que normalmente se reutiliza.

Los archivos de instrucciones de proyecto (AGENTS.md, CLAUDE.md, .grok/rules) dentro de las carpetas de la conversación no son motivo de rechazo: la carpeta nunca es de confianza, así que Grok no los carga por su cuenta, pero el modelo puede leerlos con sus herramientas de archivo. Los servidores MCP o hooks de proyecto de esa carpeta los lista Grok, pero nunca se arrancan.

Kimi se comprueba desde su directorio personal de EYAS, porque no tiene comando de inspección: en data/cli-homes/kimi-cli/.kimi/config.toml la autoaprobación debe estar desactivada, la fusión de carpetas de skills del host desactivada, sin hooks y sin carpetas de skills extra; mcp.json debe estar vacío; y las carpetas de skills del directorio personal no deben contener skills. Kimi también debe guardar sus datos en el directorio personal de Kimi de EYAS: si su carpeta compartida apuntara a cualquier otro sitio, la comprobación detiene el turno y la actualización de modelos (se muestra como la aprobación de herramientas no está vinculada a EYAS), así que un cambio de modelo nunca puede escribir fuera de ese directorio.

Al arrancar la sesión, se detiene una sesión que empieza en un modo que aprueba llamadas a herramientas por su cuenta.

Mientras corre el turno, EYAS detiene el turno si Grok o Kimi empieza o termina una herramienta nativa sin que EYAS haya decidido sobre ella (lectura o escritura de archivo, búsqueda, listado, shell, web, subagente, búsqueda de herramientas o una herramienta MCP que no es de EYAS), o llama a su propia herramienta de memoria. EYAS cancela entonces la sesión, termina el turno con el error de aislamiento y no usa nada de lo que diga la CLI después. Las herramientas propias de EYAS (memoria, tablero, etc. — a las que Grok llega con use_tool como eyas__<nombre>) no forman parte de esta comprobación, porque EYAS decide él mismo cada una de esas llamadas — ver Las herramientas de EYAS reciben las mismas decisiones más abajo.

El mensaje del chat dice, por ejemplo: Grok CLI se detuvo: EYAS no pudo confirmar que se ejecuta aislado (servidores MCP que no son de EYAS, hooks). El turno no se pasó a otro modelo. Le sigue un enlace Abrir la configuración del proveedor. Las comprobaciones que puede nombrar son: la aprobación de herramientas no está vinculada a EYAS; servidores MCP que no son de EYAS; hooks; plugins o extensiones; instrucciones o skills de fuera de la conversación; la memoria propia de la CLI; importaciones de otras herramientas de IA; un proceso líder compartido; una carpeta de proyecto marcada como de confianza; una herramienta que se ejecutó sin la aprobación de EYAS; la comprobación no pudo ejecutarse.

Para volver a verificar, quita la causa — por ejemplo el servidor MCP, hook, skill o AGENTS.md de más en el directorio personal de Grok o Kimi de EYAS, o una config de Grok para todo el sistema — y vuelve a enviar el mensaje. Cada turno vuelve a comprobar. Recargar o reactivar el proveedor, o reiniciar EYAS, ejecuta la comprobación de Grok al cargar, y Verificar ahora en el panel del proveedor ejecuta las mismas comprobaciones sin llamar al modelo (ver Entorno de ejecución y Aislamiento en el panel del proveedor más abajo). Los directorios personales de EYAS los revisa eyas doctor (ver Versiones de CLI probadas).

Entorno de ejecución y Aislamiento en el panel del proveedor. Selecciona la tarjeta de Claude Code CLI, Grok CLI o Kimi Code CLI en Proveedores:

Entorno de ejecución — cómo encontró EYAS el binario, su versión y su ruta. Orígenes: CLI del host en el PATH, Sustitución del operador (variable de entorno) (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN) o Entorno de ejecución incluido (alternativa) (solo Claude Code). La versión es la propia de la CLI; una CLI que no informa de ninguna muestra versión desconocida. Líneas extra: La versión X difiere de la esperada (Y) (el binario de Claude Code difiere de la versión para la que se construyó el Agent SDK fijado de EYAS); Una CLI del PATH (versión) no se usa. (una sustitución oculta otra CLI del PATH); Sin sesión iniciada (solo Claude Code — Grok y Kimi muestran su inicio de sesión en la tarjeta Iniciar sesión para EYAS); No se encontró un entorno de ejecución utilizable: instala la CLI o define la sustitución; y, para una sustitución que no apunta a un archivo ejecutable, La variable de sustitución está definida pero no apunta a un archivo ejecutable, así que EYAS no ejecuta ningún binario para este proveedor (nunca recurre al PATH). Corrígela o elimínala.
Aislamiento — una insignia de estado (Verificado, Comprobación fallida, Aún sin verificar, Inicio de sesión necesario) y una frase sobre cómo mantiene EYAS aislada la CLI y cuándo lo comprueba: Claude Code al inicio de cada turno, a partir de lo que informa al arrancar (no hay comprobación sin turno); Grok antes de cada turno con grok inspect, sin llamar al modelo; el directorio de EYAS de Kimi antes de cada turno, y Kimi solo cuenta como verificado cuando ya se ha iniciado en este servidor una sesión que superó todas las comprobaciones. Luego Última comprobación: <hora> o Sin comprobar desde que se inició EYAS. — el estado se guarda en memoria, así que se reinicia cuando EYAS se reinicia — y una lista Comprobaciones fallidas con las mismas etiquetas que el error de aislamiento del chat, cada una con su detalle en bruto.
Una línea que compara la versión instalada con la versión en la que se superó la comprobación de aislamiento en vivo de las versiones de EYAS: superada en esta versión (con versión y fecha); superada por última vez en otra versión, no en la instalada; Aún sin verificar en un equipo — la comprobación nunca se ha ejecutado con esta CLI, así que su aislamiento se basa solo en el código fuente de la CLI (Kimi hoy); o la CLI no informó de su versión. Cada línea termina recordando que cada turno se sigue comprobando.
Riesgo restante: una frase por CLI. Claude Code comparte el inicio de sesión del servidor, y la comprobación de versiones se hizo con una clave API y sin una llamada real al modelo, así que lo que solo aporta un inicio de sesión con una cuenta de claude.ai (skills sincronizadas con la cuenta, memoria de la cuenta, ajustes gestionados de forma remota) no está cubierto. La comprobación de versiones inició sesión en Grok con una clave API; no se observó si, con un inicio de sesión de grok.com, Grok sincroniza sesiones con xAI. Las herramientas de búsqueda y web propias de Kimi no piden permiso a EYAS antes: EYAS detiene el turno cuando se ejecuta una, pero para entonces ya se ha ejecutado y su resultado puede llegar ya al modelo de Kimi.
Verificar ahora (Grok CLI y Kimi Code CLI; propietarios y administradores, que pueden gestionar modelos) — solo aparece cuando el proveedor está activado y se encontró su CLI. Vuelve a ejecutar las comprobaciones que ejecuta la carga del proveedor, sin llamar al modelo: la comprobación grok inspect de Grok, la relectura del directorio de Kimi y luego, con la sesión iniciada, el arranque de una sesión sin prompt, que también actualiza la lista de modelos. Así Kimi puede pasar de Aún sin verificar a Verificado. Claude Code no tiene Verificar ahora: se comprueba al inicio de cada turno. Los errores dicen Verificar ahora requiere que el proveedor esté activado y que se encuentre su CLI. o La verificación falló: <error>. El bloque se recarga tras iniciar o cerrar sesión y tras activar o desactivar el proveedor.

Los paneles de Grok y Kimi ya no dicen que la reanudación de sesión y el uso de herramientas usan el inicio de sesión del host ni que la CLI carga su propia configuración y memoria a nivel de máquina: eso dejó de ser cierto cuando Grok y Kimi empezaron a ejecutarse en el directorio propio de EYAS. Kimi Code CLI sigue activado por defecto; el panel dice claramente que su aislamiento aún no está verificado en un equipo.

API (integradores). GET /api/v1/model/providers/{claude-code|grok-cli|kimi-cli}/isolation (acceso de lectura a los modelos; cualquier otro proveedor es 404, sin sesión 401) devuelve {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}, donde runtime es {available: true, path, version, source: override|host|sdk-bundled, expectedVersion, skew} o {available: false, error: override-invalid|not-found|no-policy}. POST …/isolation/verify necesita el derecho a gestionar modelos (si no, 403), ejecuta las comprobaciones y devuelve la misma vista; Claude Code, o un proveedor que no está activado o no se encuentra, devuelve 409 {code: 'verifyUnavailable'}.

Aprobaciones. EYAS solo responde a la petición de permiso de una CLI con permitir una vez. Si la CLI solo ofrece una opción de permitir siempre o para toda la sesión, EYAS responde cancelado. Un rechazo es rechazar una vez.

Las herramientas de EYAS reciben las mismas decisiones. Las herramientas propias de EYAS a las que Grok y Kimi llegan por el puente de herramientas (memoria, tablero, documentos, correo, navegador, Odoo, etc.) se deciden exactamente igual que en los proveedores de API y en Claude Code:

En un chat que estás atendiendo, o en una conversación de canal, una llamada que el security gate permite se ejecuta. Una herramienta marcada como que requiere aprobación ya no espera en la cola de Aprobaciones solo porque el modelo sea Grok o Kimi, y los niveles de autonomía no se aplican a los chats atendidos. Una llamada que el gate escala muestra una tarjeta de aprobación en la conversación y una entrada en Aprobaciones; el chat no se pausa.
En las ejecuciones en segundo plano (programadas, de equipo, de pipeline o cualquier ejecución no marcada como atendida) se aplica la escala de autonomía: una llamada de una categoría en Aviso o Aprobar espera aprobación, y una llamada que el gate escala siempre espera a una persona, aunque su categoría esté en Auto (antes, una llamada así se ejecutaba sin preguntar en Grok y Kimi). Una ejecución supervisada se pausa como Esperando aprobación cuando termina el turno de la CLI, y aprobarla deja que exactamente esa llamada se ejecute una vez.
Una ejecución reanudada o reintentada que repite una llamada a herramienta de EYAS que la ejecución original ya completó (el mismo correo o la misma factura, por ejemplo) se rechaza antes de ejecutarse; la fila de la herramienta muestra Omitido con already executed on the original run — duplicate side effect prevented. La misma herramienta con otros argumentos sigue ejecutándose.
Una herramienta fuera de la lista Herramientas del agente se rechaza como Denegado antes de preguntar al security gate, así que nunca crea una entrada de aprobación. Sin un security gate en marcha, se rechaza cada llamada puenteada a una herramienta de EYAS.

Demostrado en el Grok CLI instalado con la comprobación de publicación. Las mismas decisiones se aplican a Kimi, porque se toman en EYAS; cómo informa de estas llamadas un binario real de Kimi en su propio flujo (del que se construye la comprobación de duplicados de una reanudación) aún no se ha verificado en un equipo. Ver MCP — Cómo se protege el puente.

Una llamada rechazada termina una respuesta de Grok. Cuando EYAS rechaza una de las llamadas a herramienta de Grok — por ejemplo una lectura de memoria fuera de EYAS —, Grok termina esa respuesta (verificado con grok 1.0.41). El chat muestra la fila de herramienta rechazada y nada después, y el modelo de Grok no ve el motivo de EYAS, así que vuelve a pedirlo sin ese paso. Claude Code, en cambio, continúa y recibe el motivo.

Acceso a archivos. Los archivos que Grok o Kimi leen o escriben a través de EYAS se limitan a las carpetas de la conversación (las Carpetas que siguen pasando la validación, más la carpeta de trabajo), con los enlaces simbólicos resueltos — también para un archivo nuevo bajo una carpeta enlazada. Se rechazan las salidas con .., los archivos sensibles y, cuando no hay carpeta, todos los archivos. Después se aplica la política de memoria (se rechazan la memoria de otras herramientas, las bóvedas de Obsidian, la carpeta de datos propia de EYAS y los workspaces de otras conversaciones). Cada operación de archivo se juzga una vez: una lectura o escritura ya aprobada en la petición de permiso de la llamada se sirve sin volver a preguntar. Se admiten lecturas parciales (línea de inicio y número de líneas).

Trabajo en segundo plano. Grok y Kimi se usan para las llamadas en segundo plano de EYAS (títulos, el juez de seguridad, etc.) solo mientras su aislamiento está verificado: Grok tras superar su comprobación al cargar, Verificar ahora o el inicio de sesión de cualquier turno; Kimi solo después de que haya arrancado una sesión en este host (un Verificar ahora con la sesión iniciada arranca una). Una llamada así no recibe herramientas de EYAS, se rechaza toda petición de permiso y de archivo, y su primera llamada a herramienta la termina. Su respuesta se ciñe al límite de salida que pide EYAS (ver Modelos y esfuerzo de Claude Code).

Qué reciben Grok y Kimi

El system prompt de EYAS, comprobado. Kimi recibe el system prompt de EYAS al principio de cada mensaje, marcado como instrucciones de sistema de EYAS. Grok puede sustituir su propio system prompt por defecto por el de EYAS, pero solo registra qué prompt usó una vez que se ha preguntado al modelo, así que EYAS lo comprueba tras cada turno — en su propio directorio personal de Grok, antes de que se borren los archivos de sesión de ese turno. En los primeros turnos tras arrancar EYAS, o tras sustituir el programa grok, el prompt se envía por las dos vías (como system prompt de Grok y al principio del mensaje), así que ninguna respuesta depende de una vía sin comprobar. Cuando la comprobación pasa, los turnos siguientes lo envían solo como system prompt de Grok, y cada turno se vuelve a comprobar. Si el modelo respondió sin el prompt de EYAS, EYAS escribe un aviso en el log y desde entonces envía el prompt al principio del mensaje (hasta reiniciar o hasta un nuevo programa grok). No hay nada que configurar.
El historial entero, imágenes incluidas. Cada turno reproduce el historial de la conversación de EYAS, incluidas las imágenes de turnos anteriores en su sitio. Las imágenes solo se pasan cuando la CLI instalada dice, al empezar cada ejecución, que acepta entrada de imagen. Cuando no, cada imagen se sustituye por una nota breve para el modelo, por ejemplo [image omitted (image/png): this model cannot see images], para que el modelo sepa que había una; el compositor avisa antes de enviar y el turno muestra un aviso (ver Imágenes y modelos que no pueden verlas). Reproducir el historial completo, imágenes incluidas, cuesta tokens de prompt en cada turno, como ya ocurre en los proveedores de API.
La insignia Visión sigue a la CLI. La insignia Visión de los modelos de Grok CLI y Kimi Code CLI sigue lo que la CLI informa en cada turno. Grok CLI 1.0.40 no informa de entrada de imagen, así que los modelos de Grok CLI muestran Visión desactivada. Los modelos de Kimi conservan su valor por defecto hasta que el primer turno informe. Tras un reinicio, un Actualizar modelos antes del primer turno puede volver a mostrar el valor por defecto; el siguiente turno lo corrige.

Modelos y esfuerzo de Grok

EYAS lee los modelos de Grok, y los niveles de esfuerzo de razonamiento que acepta cada uno, del propio Grok CLI: abre una sesión en su directorio personal de Grok de EYAS sin enviar ningún prompt, así que no hay llamada al modelo ni coste. Por ejemplo, grok-4.6 y grok-4.7 ofrecen low, medium, high y xhigh; grok-4.5 ofrece low, medium y high; un modelo sin control de razonamiento no ofrece ninguno. Esto ocurre cada vez que se carga el proveedor (arranque de EYAS, recarga del proveedor) y cuando pulsas Actualizar modelos, y se omite mientras Grok no tiene la sesión iniciada para EYAS. Un modelo que la CLI deja de ofrecer se marca y se desactiva, nunca se borra, y las opciones de esfuerzo de un modelo de Grok coinciden con lo que acepta de verdad.

En cada turno EYAS fija el esfuerzo elegido dentro de la sesión de Grok antes de enviar el mensaje, y relee el nivel que aplicó Grok. Un nivel no admitido se lleva primero al más cercano que el modelo acepta (max en grok-4.5 corre como high). Si Grok aun así rechaza un nivel, el turno corre al nivel propio de Grok, y eso es lo que registra el turno. Automático no envía nada: el modelo corre a su propio valor por defecto (high en los modelos actuales de Grok), y el turno registra qué nivel fue. La configuración propia ~/.grok del operador, incluido su esfuerzo por defecto, no decide nada. Cada turno de Grok registra además el modelo que Grok ejecutó de verdad, tal como lo informa Grok.

Modelos y razonamiento de Kimi

kimi acp ignora las opciones --model y --thinking, así que en cada turno EYAS abre la sesión de Kimi, comprueba que está aislada y después la cambia al modelo y a la variante de razonamiento elegidos antes de enviar el prompt.

De dónde salen los modelos. La lista de modelos propia de Kimi — los modelos de su propia config, por ejemplo kimi-code/kimi-for-coding tras el inicio de sesión de Kimi Code. EYAS la lee sin prompt y sin llamada al modelo, abriendo una sesión en su propio directorio personal de Kimi: en segundo plano cada vez que se carga el proveedor (solo mientras Kimi tiene la sesión iniciada para EYAS) y cuando haces clic en Actualizar modelos. Las filas se llaman Kimi Code CLI (<nombre del modelo>). La fila por defecto Kimi Code CLI ejecuta el modelo que Kimi tenga configurado en ese momento.
Razonamiento por modelo, según lo que lista Kimi. Un modelo con una variante normal y una de razonamiento recibe una opción de esfuerzo Activado / Desactivado (Ninguno = razonamiento apagado, Alto = razonamiento encendido). Un modelo que siempre razona solo ofrece Alto (Ninguno pasa a Alto). Un modelo sin razonamiento no ofrece control de esfuerzo. Automático mantiene el razonamiento que Kimi esté ejecutando en ese momento, también cuando cambia el modelo. Tras cada turno, EYAS relee qué modelo y qué variante se ejecutaron de verdad y lo registra como el modelo y el esfuerzo efectivos.
Kimi recuerda la última elección. Cuando EYAS cambia el modelo, Kimi lo guarda en su propio archivo de config (dentro del directorio personal de Kimi de EYAS, nunca en ~/.kimi) y lo usa desde entonces como predeterminado. Así, la fila por defecto Kimi Code CLI ejecuta el modelo que EYAS eligió más recientemente en cualquier conversación. Para una elección estable, elige un modelo de Kimi concreto.
Antes de leer la lista (sin sesión iniciada todavía, o si la lectura falló), el panel del proveedor dice: EYAS aún no ha leído la lista de modelos de Kimi, así que no puede fijar un modelo ni activar o desactivar el razonamiento: Kimi ejecuta el modelo que tiene configurado. Inicia sesión en Kimi para EYAS y luego haz clic en «Actualizar modelos». En ese estado EYAS no envía ninguna elección de modelo ni de razonamiento.
Un modelo que Kimi no ofrece detiene el turno antes del prompt con un error que dice que Kimi no ofrece ese modelo. Nunca se sustituye en silencio por otro modelo.
Filas retiradas. Las filas fijas Kimi Code CLI (K3), (K2.7 Code) y (K2.6) nombraban modelos de la API de Moonshot, no modelos de Kimi CLI, y siempre ejecutaban el predeterminado de Kimi. Tras la primera actualización o descubrimiento se marcan La última actualización ya no lo ofrece y se desactivan (nunca se borran). Los niveles de enrutado, los fallbacks de nivel y el predeterminado del proveedor Kimi que EYAS mismo había puesto en ellas pasan automáticamente, al arrancar, a Kimi Code CLI (la fila por defecto) — que es lo que siempre ejecutaron. Una conversación o un agente que fijaste a una de ellas se detiene con el error no lo ofrece; elige en su lugar uno de los modelos de Kimi descubiertos. En una instalación nueva solo con Kimi, todos los niveles de enrutado empiezan en Kimi Code CLI, sin fallback; los niveles Opus/Sonnet/Haiku del asistente de agentes para Kimi también se asignan a ella, y las degradaciones por presupuesto no tienen paso de Kimi Code CLI.
Estimaciones de coste. Los modelos de Kimi Code CLI descubiertos se tarifican con la tarifa por defecto de Kimi Code CLI (0,95 $ de entrada / 4 $ de salida por millón de tokens).

Esto se ha construido a partir del código fuente de kimi-cli 1.52.0 y aún no se ha verificado con una instalación real de Kimi.

Sandbox de archivos del kernel

Cuando Claude Code o Grok CLI ejecuta sus propias herramientas — los comandos de shell de Claude Code; el shell, grep, el listado de archivos y las lecturas de subagentes de Grok —, el propio sistema operativo impide que esas herramientas lean o escriban:

la memoria de otras herramientas de IA (~/.claude, ~/.grok, ~/.codex, ~/.gemini, ~/.kimi, ~/.cursor, ~/.codeium, los datos de OpenCode), las bóvedas de Obsidian que EYAS conoce y las rutas de security.foreignMemoryPaths;
los datos privados de EYAS: el vault, la base de datos, las claves y los directorios personales de EYAS de otras CLI;
los workspaces de otras conversaciones.

Las carpetas propias de la conversación siguen siendo escribibles. El sandbox es macOS Seatbelt (integrado) o Linux bubblewrap. EYAS sigue comprobando cada llamada a herramienta que ve; el sandbox atrapa además lo que un comando de shell alcanza por caminos que EYAS no puede leer en el texto del comando.

CLI	Qué se ejecuta en el sandbox
Claude Code	Cada turno con herramientas ejecuta sus comandos de shell en el sandbox. En Linux necesita bubblewrap (`bwrap`) y `socat`. El estado de shell propio de Claude Code (`~/.claude/shell-snapshots`, `~/.claude/session-env`) y su carpeta de programa siguen siendo legibles; el resto de `~/.claude` queda bloqueado.
Grok CLI	Cada turno con herramientas arranca Grok bajo un perfil de sandbox de EYAS, escrito en `sandbox.toml` dentro de su directorio personal propio de EYAS (con el nombre `eyas-<hash>`). Grok no puede relajarlo. En Linux necesita bubblewrap.
Kimi Code CLI	No tiene sandbox del kernel (No compatible).

Las llamadas en segundo plano sin herramientas (títulos, pasadas de memoria, el juez de seguridad) no necesitan sandbox y nunca se rechazan por no tenerlo.

security.cliSandbox (config/local.yaml):

auto (por defecto) usa el sandbox donde está disponible. Donde no, la CLI sigue ejecutando sus herramientas, y el chat muestra un aviso único por conversación: <CLI> ejecuta sus propias herramientas sin sandbox de archivos del kernel en este servidor. EYAS sigue revisando cada llamada a herramienta que ve; la configuración del proveedor muestra el motivo. En auto, Claude Code puede pedir ejecutar un comando fuera del sandbox (por ejemplo uno que necesita ~/.npm). Ese comando siempre espera la aprobación de una persona en la cola de Aprobaciones — nunca el juez de IA, nunca la escala de autonomía —, explicado allí como Un comando de shell pidió ejecutarse fuera del sandbox de archivos del kernel…. Aprobarlo deja que exactamente ese comando se ejecute una vez; las ejecuciones autónomas se aparcan en él.
required rechaza un turno de CLI con herramientas antes de que arranque la CLI cuando no hay sandbox disponible: <CLI> no se inició: tu configuración exige un sandbox de archivos del kernel para las herramientas propias de la CLI (security.cliSandbox: required), y en este servidor no hay ninguno disponible para ella. El turno no se reintenta ni se pasa a otro modelo, y los turnos de Kimi con herramientas se rechazan siempre. Con required, Claude Code nunca puede ejecutar un comando fuera del sandbox (su petición se ignora), y se niega a arrancar si el sandbox no puede arrancar.
No hay off. Cualquier otro valor es un error de configuración: EYAS no arranca y el error nombra security.cliSandbox.

Dónde se ve. El panel de un proveedor CLI tiene una fila Sandbox de archivos del kernel: Activo, No disponible en este servidor con el motivo (bubblewrap no está instalado; socat no está instalado; bubblewrap no puede crear un sandbox aquí, normalmente porque los espacios de nombres de usuario están desactivados; sistema operativo no compatible) o No compatible (Kimi). También muestra la nota de required y, para Claude Code en auto, Un comando que pide ejecutarse fuera del sandbox siempre espera tu aprobación. eyas doctor tiene una línea CLI sandbox (ver CLI), y Eventos de seguridad muestra el estado de cada CLI activada (ver Seguridad y privacidad). GET /api/v1/model/providers y GET /api/v1/model/providers/:id llevan fileSandbox {status: active|unavailable|unsupported, reason, mode} para claude-code, grok-cli y kimi-cli.

Docker y Kubernetes. La imagen de EYAS no incluye bubblewrap (es LGPL, así que instalarlo es decisión del operador). Un host o contenedor Linux necesita bubblewrap (y socat para Claude Code) más user namespaces sin privilegios para la capa del kernel. Sin ellos, EYAS sigue rechazando cada petición que ve y muestra No disponible; con required, los turnos de CLI con herramientas se rechazan. Ver Docker y Kubernetes.

Límites. En Linux, la lista de denegación de Grok cubre los archivos que existen al arrancar la sesión. Una bóveda que solo se conoce por su carpeta .obsidian se añade en cuanto EYAS ha encontrado una ruta dentro de ella (una bóveda registrada o una entrada de security.foreignMemoryPaths cuentan siempre). Kimi no tiene capa del kernel.

Versiones de CLI probadas

Cada versión de CLI que admite EYAS se comprueba antes de publicar: EYAS ejecuta el Claude Code y el Grok CLI reales (y Kimi Code CLI donde está instalado) a través de sus propios proveedores en un directorio personal desechable lleno de trampas (ajustes del host que lo permiten todo, hooks y servidores MCP que dejarían rastro, CLAUDE.md, AGENTS.md, skills, una bóveda al estilo Obsidian) y demuestra que no se carga nada de eso, que la política de memoria de EYAS y el sandbox del kernel mantienen fuera la bóveda y la carpeta de datos de EYAS, y que una lectura rechazada de memoria fuera de EYAS sigue rechazada. Los detalles están en Seguridad y privacidad — Cómo se demuestra el aislamiento.

CLI	Última versión probada
Claude Code	2.1.281
Grok CLI	1.0.41
Kimi Code CLI	Aún no probado

Revisa tu instalación con eyas doctor. Tiene una línea CLI isolation por CLI — CLI isolation (Claude Code), CLI isolation (Grok CLI), CLI isolation (Kimi Code CLI). Cada una muestra el binario que ejecuta EYAS: cómo se encontró (EYAS_CLAUDE_CODE_BIN / EYAS_GROK_BIN / EYAS_KIMI_BIN, claude/grok/kimi on PATH o SDK-bundled), su ruta y su versión, y después:

isolation proven on this version (<fecha>) — correcto;
un aviso cuando la versión difiere de la última probada, cuando el binario no informa de versión, o cuando la CLI nunca se probó (hoy, Kimi). El aviso añade que EYAS sigue comprobando cada sesión al arrancar: las comprobaciones de esta página se ejecutan sea cual sea la versión instalada;
not installed — correcto. Un EYAS_*_BIN no válido es un fallo, con el remedio.

Para Grok y Kimi la línea revisa también su directorio personal de EYAS, <data dir>/cli-homes/<proveedor>:

aún no creado — correcto, la primera ejecución lo crea;
un enlace simbólico o algo que no es una carpeta — un fallo: EYAS se niega a ejecutar la CLI; bórralo y la siguiente ejecución lo vuelve a crear;
legible por otros usuarios — un aviso, porque guarda el inicio de sesión de la CLI; remedio: chmod 700 <carpeta>;
un archivo que EYAS gestiona ahí (config.toml, requirements.toml, trusted_folders.toml de Grok; mcp.json de Kimi y las claves de EYAS en config.toml) ha cambiado desde que EYAS lo escribió — un aviso. EYAS reescribe esos archivos antes de la siguiente ejecución, así que un cambio entre dos ejecuciones significa que otra cosa edita esa carpeta.

Doctor solo lee: únicamente ejecuta --version. Ver CLI — Qué comprueba doctor.

El mismo chat en todos los proveedores

Una conversación se ve igual sea cual sea el proveedor que responde.

Texto en vivo. Claude Code escribe su respuesta y su thinking en vivo, a medida que el modelo los escribe, como los proveedores de API.
Una fila por llamada a herramienta, con el nombre común. Las filas de herramientas usan los nombres que EYAS usa en todos los proveedores — read_file, run_command, edit_file, write_file, grep, glob, web_fetch, web_search —, así que las ediciones y escrituras de archivos se ven como un diff en todas partes. Las herramientas propias de EYAS aparecen con su nombre simple (memory_search, no mcp__eyas__memory_search). En Grok y Kimi la fila no muestra el título de texto libre de la CLI.
Entrada, salida y duración. Una fila muestra qué se le pidió a la herramienta (el archivo, el comando, la búsqueda, la ruta de una edición con el texto antiguo y el nuevo), qué devolvió — una salida muy larga se corta a 64 KiB y se marca como cortada — y cuánto tardó.
Una fila solo se cierra cuando la herramienta terminó. Nunca se marca como hecha por adelantado: una llamada que falla, o que se omite por el presupuesto de llamadas, aparece como fallida, con el error.
Las llamadas rechazadas no aparecen como correctas. Una llamada que EYAS rechazó — por el gate de seguridad, por la política de memoria, mientras espera una aprobación, o como repetición de una acción que una ejecución reanudada ya realizó — muestra su propio estado (Denegado, Requiere aprobación, Omitido) con el motivo de EYAS, nunca una marca verde. Las llamadas por las que una CLI pregunta después de alcanzar el límite de llamadas se registran como omitidas. Una llamada que necesita aprobación abre una tarjeta de aprobación en la conversación y una entrada en la cola de Aprobaciones. Ver Conversaciones — Traza de herramientas.
El límite de turnos conserva la respuesta. Cuando un turno alcanza su límite de turnos, la respuesta escrita hasta ese momento se conserva y se guarda como réplica; el turno termina como Límite de turnos alcanzado, no como error. Un fallo real sigue apareciendo como error, y también entonces se conserva la respuesta parcial.
Un solo final por turno. Una respuesta se guarda y se muestra exactamente una vez en todos los proveedores.
El mismo árbol de ejecución. El panel de árbol de ejecución / flujo de trabajo de una conversación aparece para todos los proveedores, de API y CLI, con la herramienta actual en vivo, el recuento de turnos (en una CLI, sus propios pasos internos), los tokens y el coste de la ejecución. Ver Conversaciones — Árbol de ejecución.
La compactación no escribe memoria. Si una CLI compacta su propio contexto durante un turno largo, el turno muestra un aviso de contexto compactado y no se escribe nada en la memoria de EYAS. La memoria de EYAS solo la alimenta EYAS.
Los mensajes de error nombran la CLI correcta. Un fallo de Kimi dice Kimi Code CLI, nunca Grok CLI.

Por qué terminó un turno. Todos los proveedores de API registran los mismos motivos: terminado, uso de herramienta, límite de salida alcanzado, secuencia de parada o rechazado. Rechazado cubre el rechazo de Anthropic, el filtro de contenido de OpenAI y el mensaje de rechazo del modelo, las paradas de clase seguridad de Gemini (safety, contenido prohibido, lista de bloqueo, recitación, datos personales, seguridad de imagen) y un prompt que Gemini bloqueó directamente. Un mensaje de rechazo de OpenAI se muestra como respuesta del asistente en lugar de una respuesta vacía. Una respuesta cortada por el límite de tokens de salida se registra como max tokens, y una llamada a herramienta cortada así nunca se ejecuta. El chat muestra estos resultados como una insignia bajo la respuesta — ver Conversaciones — Resultado del turno.

Los recuentos de tokens significan lo mismo en todos los proveedores, CLI incluidas: los tokens de entrada son los tokens del prompt que no salieron de la caché del proveedor; las lecturas de caché (y, en Anthropic, las escrituras de caché) se cuentan aparte; los tokens de razonamiento o thinking forman parte de los tokens de salida. Un turno del que el proveedor no informó uso se marca como Uso no informado y no muestra precio; su traza nunca se tarifica a partir de recuentos de tokens de relleno. Observabilidad cuenta también las herramientas que una CLI ejecutó en su propio bucle — los turnos de Claude Code, Grok CLI y Kimi Code CLI ya no muestran 0 llamadas a herramientas. Ver Observabilidad — Usage.

Llamadas a herramientas

En los proveedores API y locales, EYAS ejecuta el bucle de herramientas: el modelo pide una herramienta, EYAS la ejecuta, le devuelve el resultado y el modelo sigue con su respuesta. Cada llamada se ve como una fila en vivo en la conversación.

Proveedor	Qué esperar
Anthropic, endpoints compatibles con Anthropic (MiniMax, Synthetic, Xiaomi MiMo, …)	Las herramientas de EYAS corren, incluidas las de memoria. Con el razonamiento activado — cualquier nivel de esfuerzo, o un modelo en el que siempre está activado —, el razonamiento firmado del modelo (incluido el razonamiento censurado) vuelve sin cambios en la siguiente petición de la misma respuesta, así que los turnos con herramientas y razonamiento funcionan de forma fiable. Los proveedores compatibles con Anthropic informan también de los tokens de entrada cacheados en las respuestas en streaming.
OpenAI	Las herramientas de EYAS corren, incluidas las de memoria
Gemini	Las herramientas de EYAS corren, incluida la búsqueda de memoria. La firma de razonamiento de Gemini se reenvía con cada llamada a herramienta, así que los modelos Gemini más nuevos conservan su razonamiento a lo largo del bucle. Una herramienta que informa de un error se envía a Gemini como error. Los resúmenes de pensamiento de Gemini se ven como razonamiento en la conversación, nunca en el texto de la respuesta ni en la respuesta guardada.
Endpoints compatibles con OpenAI, Kimi API, OpenRouter	Las herramientas de EYAS corren. Un backend que informa un stop normal mientras pide herramientas no corta el bucle antes de tiempo — las herramientas pedidas se ejecutan. El texto de razonamiento que devuelven estos backends (por ejemplo el de DeepSeek reasoner) se muestra como thinking, nunca mezclado con la respuesta. Kimi API y OpenRouter reciben de vuelta su propio razonamiento en los turnos de llamada a herramienta de la misma respuesta, como exigen.
LM Studio	Usa la misma conexión compatible con OpenAI que los anteriores, así que las llamadas a herramientas y sus resultados (búsqueda de memoria incluida) llegan al modelo por function calling estándar.
Ollama	Las herramientas de EYAS corren. Cada resultado lleva el nombre de la herramienta, para que el modelo sepa qué resultado corresponde a qué llamada cuando hizo varias. El razonamiento de un modelo con thinking llega como thinking, separado de la respuesta.
Claude Code CLI, Grok CLI, Kimi Code CLI	El CLI ejecuta el bucle; las herramientas de EYAS le llegan por MCP — ver MCP

El razonamiento se queda con su proveedor. El razonamiento que se reenvía dentro de un bucle de herramientas (familia Anthropic, Kimi API, OpenRouter) solo vale dentro de una respuesta: no se guarda con la conversación ni se envía en turnos posteriores. Si un turno salta a otro proveedor, el razonamiento se descarta para ese proveedor y la respuesta sigue sin él. Cuando una ejecución en segundo plano detenida o fallida se reanuda desde su último checkpoint, el modelo empieza su razonamiento de nuevo una vez. El razonamiento nunca se envía a otro proveedor ni a otro modelo, ni siquiera como texto; la conexión nativa de OpenAI nunca reenvía razonamiento.

Una fila por llamada. Algunos backends compatibles con OpenAI — a menudo servidores locales — emiten una llamada a herramienta sin id de llamada. Esa llamada aparece como exactamente una fila. Vale para OpenAI, proveedores compatibles con OpenAI, Kimi API, OpenRouter y LM Studio.

Modelos sin herramientas. Un modelo marcado en la lista de modelos como sin soporte de herramientas — por ejemplo un modelo de Ollama cuyo servidor no informa de capacidad de herramientas, o un modelo en el que desactivaste el soporte de herramientas — no recibe herramientas ni lista de herramientas en su prompt. Si aun así pide una, EYAS no la ejecuta y el turno termina con el texto del modelo. Su prompt también deja de decirle que llame a herramientas: las reglas de memoria y fundamentación dicen que lo que EYAS recuperó llega en el bloque <eyas-memory> y que no puede buscar más, y no recibe la lista de skills ni la plantilla de agentes, que solo funcionan con llamadas a herramientas. Ver Prompts — El contrato de memoria.

Imágenes y modelos que no pueden verlas

Qué modelos pueden ver imágenes lo dice el catálogo de modelos: la insignia Visión de la lista de modelos. Para Grok CLI y Kimi Code CLI, la insignia sigue lo que informa la CLI instalada.

Cuando el modelo de la conversación no puede ver imágenes, cada imagen adjunta le llega al modelo como una nota breve en su lugar ([image omitted (image/png): this model cannot see images]). El modelo sabe que había una imagen, pero no lo que muestra. El turno no se rechaza.
Bajo ese turno aparece un aviso: Imágenes no mostradas al modelo (N): <modelo> no puede ver imágenes… Se guarda con la respuesta, así que sigue ahí tras recargar. El recuento incluye las imágenes de turnos anteriores, así que en un modelo así el aviso aparece en cada turno mientras la conversación contenga imágenes.
El compositor avisa antes de enviar: con una imagen adjunta y un modelo que no puede ver imágenes, un chip sobre la entrada dice <modelo> no puede ver imágenes: solo sabrá que hay una imagen adjunta. El chip no aparece en Modo Dios; en una conversación con auto-enrutado se basa en el modelo que se muestra para la conversación (el nivel Estándar).
Si EYAS no tiene información de catálogo de un modelo, las imágenes se envían tal cual y decide el proveedor. Cambia a un modelo con la insignia Visión para que las imágenes se lean.
Claude Code ve las imágenes de turnos anteriores de una conversación, no solo las del último mensaje: cada turno reenvía todas las imágenes anteriores, igual que los proveedores de API, así que las conversaciones con muchas imágenes envían prompts más grandes.

Caché de prompts (API de Anthropic)

En el proveedor de la API de Anthropic (clave de API directa), la caché de prompts es automática — no hay ningún ajuste.

System prompt. El system prompt de EYAS no cambia de un turno a otro, porque la hora actual y la memoria recordada viajan con tu mensaje actual. Por eso EYAS marca el system prompt (junto con las definiciones de herramientas que van antes) para caché, y cada turno y cada paso de herramienta posteriores lo leen de la caché de Anthropic.
Conversación anterior. La conversación hasta tu mensaje actual también se marca, así que el siguiente turno la lee de la caché en lugar de pagarla de nuevo a precio completo.
Pasos de herramienta. En un turno con herramientas, cada paso de herramienta lee de la caché la petición anterior.
Duración y coste. La caché dura 5 minutos y se renueva con cada petición que la usa; tras una pausa más larga, la primera petición la vuelve a escribir. Una escritura en caché cuesta 1,25× el precio normal de entrada; una lectura cuesta alrededor de 0,1× (o la tarifa de lectura de caché publicada del propio modelo, más baja en algunos modelos nuevos). Los prompts más cortos que la longitud mínima cacheable del modelo (de 512 a 4096 tokens, según el modelo) simplemente no se cachean.
Dónde se ve. El uso de tokens y los costes muestran los tokens de lectura y de escritura de caché de las llamadas a la API de Anthropic.
A los endpoints de terceros compatibles con Anthropic no se les envía ningún parámetro de caché, porque un endpoint así puede rechazarlo. Claude Code gestiona su propia caché.

Runtimes locales

LM Studio

La temperatura, los tokens máximos de salida y las secuencias de parada de la conversación o del agente se envían tal como están. Si no hay ninguno, se aplica el valor por defecto del propio modelo en LM Studio.
Una petición que no nombra modelo pide el modelo que LM Studio tiene cargado. El modelo que se muestra en una respuesta es el id que informa LM Studio.
Las llamadas usan el timeout estándar del cliente (10 minutos), y una conexión caída se reintenta.
LM_STUDIO_URL (por defecto http://localhost:1234) puede terminar en barra.
El razonamiento sigue siendo un ajuste propio de LM Studio: EYAS nunca envía un parámetro de razonamiento ni de esfuerzo, y el panel muestra por modelo el ajuste que informa LM Studio (ver Cómo aplica cada proveedor el nivel de esfuerzo).

Ollama

Actualizar modelos lee las capacidades de cada modelo en el servidor Ollama — al cargar, en segundo plano y al actualizar —, así que los modelos sin soporte de herramientas quedan marcados como tales y los modelos con thinking reciben su control de thinking (ver Cómo aplica cada proveedor el nivel de esfuerzo). Un Ollama antiguo que no informa capacidades mantiene las herramientas activas.
El contexto por defecto de Ollama es de 4096 tokens. Cuando una petición más su respuesta necesita más, EYAS pone num_ctx en la siguiente potencia de dos (8192, 16384, …), con tope en la ventana de contexto del modelo en la lista de modelos. Las peticiones pequeñas dejan intacto el valor por defecto de Ollama. OLLAMA_CONTEXT_LENGTH sigue aplicándose siempre que EYAS no pone num_ctx. Un num_ctx mayor sube el uso de memoria de Ollama solo en las peticiones que lo necesitan.

Detener cancela la generación local. En LM Studio y Ollama, Detener termina al instante la generación en curso, así que la GPU queda libre en cuanto paras.

Ventana de contexto

EYAS construye el prompt de cada turno para el modelo que lo responde. La ventana sale de la lista de modelos (la insignia de tamaño de contexto de cada modelo), también para los modelos CLI: un modelo de Claude Code listado con una ventana de 1M usa 1M. Claude Code lista 1M solo para las variantes de 1M del propio runtime (por ejemplo Opus (1M context)); sus entradas Fable, Opus, Sonnet y Haiku indican 200k, también antes de que el runtime haya informado de sus modelos, así que la insignia de tamaño de contexto, la barra de contexto y el dimensionado del prompt coinciden desde el primer arranque. Las ventanas conocidas de las CLI — Claude Code 200k, Grok 500k, Kimi 256k — solo son el recurso para un modelo del que la lista no tiene ventana, y un modelo del que no se sabe nada usa 200k. Las ventanas grandes dan más sitio a las secciones ajustables del prompt; los modelos locales pequeños reciben un prompt que deja sitio a la conversación. Ver Prompts — a la medida del modelo.

La barra de contexto de la conversación usa la misma ventana y, donde el proveedor lo informa, el tamaño real del prompt de la última llamada al modelo (Anthropic y compatibles con Anthropic, la familia OpenAI incluidos OpenRouter, Kimi API y LM Studio, Gemini, Claude Code). Cuando el runtime informa de la ventana del modelo que respondió (Claude Code lo hace), esa gana sobre la lista de modelos. Ollama, Grok CLI y Kimi Code CLI no informan de un tamaño de prompt por llamada utilizable, así que su barra es una estimación. Ver Conversaciones — Composición del contexto.

Privacidad: qué recibe cada proveedor

La política de privacidad enmascara los datos personales camino de un modelo, por intento y por destino. Que un proveedor cuente como local (texto sin enmascarar) depende del host del endpoint al que envía, nunca del nombre del proveedor:

Local: un endpoint loopback (localhost, 127.x.x.x, ::1) o un host listado como host local en la política de privacidad. Un Ollama o LM Studio local es local.
Remoto (enmascarado): todo lo demás — un OLLAMA_HOST remoto, hosts de la LAN no listados, APIs cloud y todos los proveedores CLI (Claude Code, Grok CLI, Kimi Code CLI), porque EYAS no puede ver adónde envía un CLI su tráfico.

Si una llamada salta a otro proveedor, cada intento se enmascara para su propio destino. Si contabas con que un host Ollama remoto estuviera exento, añade ese host a los hosts locales de la política. Los resultados de herramientas de memoria que una CLI obtiene por el puente de herramientas de EYAS se enmascaran igual. Un mensaje nuevo que envías con un valor de clase block (por ejemplo un IBAN) se rechaza antes de guardarse cuando iría a un modelo remoto — proveedores CLI incluidos —, con la opción de enviarlo enmascarado. El proveedor OpenAI integrado además excluye cada petición de las stored completions de OpenAI. Ver Seguridad y privacidad.

Campos y controles

Panel del proveedor

Sección	Significado
● Activo	Insignia junto al título del panel: el proveedor está encendido y en marcha; si no, dice Inactivo
Autenticación	Clave de API, el login de Claude Code de esta máquina, o la tarjeta Iniciar sesión para EYAS (Grok CLI, Kimi Code CLI)
Autenticación CLI (Claude Code)	No hace falta clave API. Claude Code solo comparte su inicio de sesión con este servidor: inicia sesión con la `claude` CLI como el usuario con el que se ejecuta EYAS. Claude Code solo está disponible cuando ese CLI tiene la sesión iniciada.
Línea de aislamiento de Claude Code	EYAS ejecuta Claude Code aislado: no carga CLAUDE.md, ajustes, hooks, skills, servidores MCP ni la auto-memoria del host, y no guarda ninguna transcripción en ~/.claude/projects. Solo el inicio de sesión se comparte con el host. Remite a Ajustes → Sistema → Portabilidad de datos → Importar datos para el contenido de `CLAUDE.md` del host.
Iniciar sesión para EYAS	Solo Grok CLI / Kimi Code CLI — Iniciar sesión con un código de dispositivo, Usar una clave de API en su lugar (Grok), Cancelar, Cerrar sesión — ver Iniciar sesión de Grok y Kimi para EYAS
Sandbox de archivos del kernel	Claude Code / Grok CLI / Kimi Code CLI — Activo, No disponible en este servidor (con el motivo) o No compatible, más la nota de `required` y, para Claude Code en `auto`, Un comando que pide ejecutarse fuera del sandbox siempre espera tu aprobación. — ver Sandbox de archivos del kernel
Nota de modelo de Kimi	Kimi Code CLI, hasta que EYAS haya leído la lista de modelos de Kimi: EYAS aún no ha leído la lista de modelos de Kimi, así que no puede fijar un modelo ni activar o desactivar el razonamiento…
Campos de clave de API	Cifrados en Secretos; Clave guardada / Sin clave / Quitar clave
Lista de modelos	Activar/desactivar modelos; insignias Herramientas / Visión / tamaño de contexto; Ejecuta <modelo> cuando el modelo concreto difiere del id de la fila; La última actualización ya no lo ofrece en las filas que la última actualización no devolvió; una línea Razonamiento con los niveles de esfuerzo del modelo y su predeterminado, y de dónde salen los datos (informado por el proveedor / catálogo de EYAS, verificado el …); en LM Studio, el ajuste de razonamiento que informa LM Studio
Actualizar modelos	Recarga la lista de modelos del proveedor (todos los proveedores). Si falla: La actualización falló. La lista de modelos no ha cambiado.

Los paneles de Claude Code CLI, Grok CLI y Kimi Code CLI también muestran la línea Entorno de ejecución y el bloque Aislamiento, con Verificar ahora para Grok y Kimi — ver Entorno de ejecución y Aislamiento en el panel del proveedor en Comprobación de aislamiento antes de cada turno. Los subtítulos de sus tarjetas dicen Claude Code CLI, ejecutada aislada por EYAS, Grok CLI en el directorio propio de EYAS (ACP) y Kimi Code CLI en el directorio propio de EYAS (ACP).

Pestañas relacionadas

Enrutado y presupuesto (pestañas Niveles de enrutamiento + Presupuesto). La pestaña Niveles de enrutamiento empieza con la tarjeta Llamadas de modelo en segundo plano, que muestra adónde va ahora mismo el trabajo en segundo plano de EYAS — ver Enrutado y presupuesto — Tarjeta de llamadas de modelo en segundo plano.
Análisis de IA — iframe integrado con benchmarks independientes