Claude Code /advisor Command: Un Segundo Cerebro para Modelos Bloqueados
Pasé un sábado entero intentando romper el nuevo comando /advisor de Claude Code.
No en el sentido de "encontrar el bug y abrir un ticket." Sino en el sentido de: "Me he quemado suficientes veces con slash commands nuevos y brillantes como para no confiar en ninguno hasta que no le haya lanzado código de producción feo encima." Mi campo de pruebas fue un servicio de facturación que llevo semanas refactorizando — una aplicación Laravel 11 con el tipo de casos límite que expone cada debilidad de un modelo de IA para programar. Actualizaciones prorrateadas. Downgrades a mitad de ciclo. Lógica de dunning que tiene que sobrevivir un fallo parcial del webhook de Stripe.
El resultado me sorprendió. No porque /advisor me salvara de una catástrofe — no lo hizo. Sino porque detectó dos problemas que llevaba tres días mirando fijamente sin verlos. Un fallo lógico en la ventana de prorrateo y un bug sutil de zona horaria en el cálculo de renovación. Sonnet 4.6 funcionaba como mi ejecutor principal. Cuando llegó al patrón de bloqueo en mi tercer intento, llamó a Opus 4.6 a través de /advisor y regresó con un análisis de dos párrafos que sonaba como la revisión de código de un ingeniero senior.
Fue entonces cuando me di cuenta de que este comando no se trata realmente de consejos. Se trata de que Anthropic está construyendo los andamios para Mythos.
Déjame explicar lo que quiero decir — y por qué el slash command /advisor puede ser la funcionalidad más importante que Claude Code ha lanzado este trimestre, aunque la mayoría de los desarrolladores lo descarten como una actualización menor de calidad de vida.
Qué hace /advisor en realidad (y qué no)
El comando /advisor te permite configurar un modelo secundario que se invoca cuando tu modelo principal se topa con dificultades. Ese es el resumen ejecutivo. La realidad es más matizada, y la matiz importa.
Así funciona la configuración actual. Ejecutas /advisor dentro de Claude Code, eliges un modelo de la lista (ahora mismo Sonnet 4.6 u Opus 4.6 — sin otras opciones, sin endpoints personalizados, sin Haiku), y a partir de ese momento Claude Code tiene la capacidad de invocar ese modelo de forma autónoma cuando decide que necesita una segunda opinión. No llamas al advisor manualmente. No escribes "pregúntale al advisor sobre esto." El modelo principal toma la decisión de forma autónoma basándose en señales de contexto.
Esa última parte me tropezó la primera vez. Seguía esperando un prompt o un diálogo de confirmación. No existe ninguno. La llamada al advisor ocurre en silencio, a mitad de una respuesta, y el consejo se pliega de nuevo en el contexto de la sesión como si siempre hubiera estado ahí.
Tres cosas que necesitas entender sobre cómo funciona esto realmente:
El advisor tiene el contexto conversacional completo. Cuando el modelo principal llama a /advisor, el modelo secundario recibe el transcript completo — tu solicitud original, cada llamada a herramienta, cada archivo leído, cada salida de comando, cada paso de razonamiento. Sin parámetros. Sin filtrado. Sin cherry-picking. Ve lo que vio tu modelo principal, en el mismo orden, con las mismas restricciones.
El advisor no puede tocar el mundo exterior. Sin acceso al sistema de archivos. Sin comandos de shell. Sin peticiones web. Sin servidores MCP. El advisor existe puramente para razonar sobre el historial de conversación y devolver orientación. Este es un límite arquitectónico duro, no un permiso que puedas cambiar.
El consejo se convierte en parte de la memoria compartida. Una vez que el advisor responde, su análisis persiste en el contexto de la sesión. Llamadas posteriores al advisor ven consejos anteriores. Si los resultados empíricos contradicen lo que el advisor recomendó, Claude Code saca el conflicto a la superficie en lugar de anular silenciosamente la orientación. Obtienes un momento explícito de "el advisor dijo X, pero la salida del test muestra Y — ¿consultamos de nuevo?"
Ese tercer comportamiento es el que no esperaba, y es el que cambió mi opinión sobre la funcionalidad.
Los cuatro disparadores que llaman al advisor
Pasé la primera hora de pruebas intentando descubrir cuándo Claude Code realmente recurre al advisor. La documentación es escasa. El comportamiento es parcialmente emergente. Así que ejecuté un montón de escenarios controlados y observé los registros.
Cuatro patrones activan de forma fiable una llamada al advisor. Si entiendes estos, sabrás si /advisor vale la pena activarlo para tu flujo de trabajo o si simplemente va a consumir tokens de contexto que nunca utiliza.
Disparador 1: Antes de escribir o interpretar de forma sustancial. Cuando el modelo está a punto de escribir un bloque significativo de código, generar un archivo nuevo o hacer un salto interpretativo de los requisitos a la implementación, hace una pausa y le pide al advisor una verificación de cordura primero. Este es el patrón de "medir dos veces, cortar una." Las tareas reactivas simples — renombrar una variable, corregir una errata, ajustar un margen — se saltan esto por completo.
Disparador 2: En la meta percibida. Cuando el modelo principal cree que la tarea está completa, llama al advisor para verificar la salida antes de declarar el éxito. Esto detectó un bug en mi código de facturación que Sonnet 4.6 se había convencido a sí mismo de que estaba resuelto. El advisor marcó un caso límite faltante en la lógica de prorrateo, y Sonnet volvió atrás y lo corrigió sin que yo dijera una palabra.
Disparador 3: Errores recurrentes o bucles que no convergen. Si el modelo intenta la misma solución tres veces y los tests siguen fallando, o si está rebotando entre dos enfoques incompatibles, se llama al advisor. Este es el patrón que más me importa porque es el que solía agotar toda mi tarde. Conoces el bucle — el modelo arregla una cosa, rompe otra, arregla esa, regresa la primera, y eventualmente tienes que intervenir manualmente y desenredar todo el lío.
Disparador 4: Puntos de control en tareas de múltiples pasos. Para cualquier tarea con múltiples fases (el tipo donde Claude Code construye una lista de tareas al inicio), el advisor se llama al menos dos veces. Una vez antes de confirmar trabajo sustancial. Una vez al completar. Esta es la red de seguridad predeterminada para los flujos de trabajo donde las cosas más a menudo salen mal.
¿Qué no activa una llamada al advisor? Ajustes menores de UI. Refactorizaciones únicas. Correcciones reactivas a problemas sencillos. Cualquier cosa sobre la que el modelo principal tenga confianza. El sistema es deliberadamente conservador — no quiere quemar tokens en problemas que no necesitan una segunda opinión.
Pero hay un problema con ese conservadurismo. Si tu modelo principal es demasiado confiado — y cualquiera que haya usado Sonnet 4.6 el tiempo suficiente sabe que puede serlo — el advisor no se llamará cuando debería. El juicio para invocar al advisor vive dentro del mismo modelo cuyo juicio estás intentando auditar. Esa es una tensión de diseño que no creo que esté completamente resuelta todavía, y volveré a ella en la sección de "sinceridad total."
Por ahora, déjame mostrarte cómo se ven las combinaciones de modelos en la práctica.
Las tres combinaciones que probé (y cuál gana)
Realmente solo hay tres formas de configurar /advisor ahora mismo, y ejecuté las tres en la misma refactorización de facturación durante el fin de semana. Esto es lo que encontré.
Combinación 1: Sonnet 4.6 principal + Opus 4.6 advisor
Esta es la combinación hacia la que Anthropic parece estar orientando a los usuarios, y después de probarla entiendo por qué. Sonnet 4.6 funciona como tu modelo de ejecución. Es rápido, es barato, es suficientemente bueno para el 85% del trabajo de programación que hago día a día. Cuando se bloquea, Opus 4.6 entra como advisor y aplica su razonamiento más profundo al problema.
La aritmética de costes aquí es genuinamente interesante. Sonnet 4.6 cuesta aproximadamente la mitad de lo que cuesta Opus 4.6 por millón de tokens. El advisor solo se invoca en disparadores específicos, por lo que no estás pagando tarifas de Opus para toda la sesión — solo en los momentos de bloqueo. En mi sesión del sábado, ejecuté unas 42 rondas de Sonnet 4.6 con exactamente 6 llamadas al advisor a Opus 4.6. El desglose de tokens resultó más barato que ejecutar Opus 4.6 como modelo principal para la misma sesión, con un margen que importaría a escala.
¿En cuanto a calidad? Obtuve resultados comparables a lo que me habría dado una sesión pura de Opus 4.6, porque cada momento que importó tuvo a Opus en el bucle de todas formas.
Combinación 2: Opus 4.6 principal + Sonnet 4.6 advisor
Esta es la combinación invertida, que probé principalmente por curiosidad. El resultado: no es genial. Sonnet 4.6 es un modelo capaz, pero cuando Opus 4.6 ya está luchando, pedirle a Sonnet que audite el razonamiento es como pedirle a un ingeniero junior que revise la decisión de arquitectura de un ingeniero senior. Las llamadas al advisor volvían con acuerdo ("tu enfoque parece correcto") o sugerencias superficiales que Opus ya había considerado y descartado.
No recomiendo esta configuración. Si Opus es tu modelo principal, es mejor generar un subagente con su propio context window para manejar los momentos de bloqueo — que es, incidentalmente, el enfoque que uso por defecto cuando ejecuto Opus como ejecutor.
Combinación 3: Opus 4.6 principal + Opus 4.6 advisor
Sí, puedes configurar el mismo modelo como principal y advisor. No, no es inútil — pero no es tan potente como las combinaciones que usan modelos distintos, porque pierdes el efecto de ojos frescos. La ventaja del advisor proviene en parte de abordar el problema desde un ángulo diferente. Cuando el advisor es literalmente el mismo modelo con los mismos sesgos, la perspectiva novedosa se reduce.
Dicho esto, esta combinación aún superó a Opus sin supervisión en mi test de errores recurrentes, porque la llamada al advisor fuerza una pausa reflexiva que el modelo principal no habría tomado por sí solo. El paso metacognitivo importa incluso cuando la cognición proviene de la misma fuente.
El ganador para la mayoría de los desarrolladores: Sonnet 4.6 principal, Opus 4.6 advisor. Más barato que Opus puro. Más inteligente que Sonnet puro. El flujo de trabajo más limpio que he probado.
Recorriendo una llamada real al advisor, paso a paso
Déjame mostrarte exactamente cómo se ve esto en la práctica, porque la descripción abstracta no captura la experiencia. Usaré el escenario del bug de facturación porque fue mi caso de prueba más limpio.
Paso 1: Configurar el advisor.
Dentro de Claude Code, ejecuté el comando:
/advisor
El prompt preguntó qué modelo configurar. Seleccioné Opus 4.6. Claude Code confirmó: "Advisor configurado. Se consultará a Opus 4.6 para decisiones complejas y verificaciones de finalización de tareas." Eso fue todo. Sin más configuración. Sin parámetros de muestreo. Sin personalización del prompt.
Paso 2: Lanzar la tarea principal.
Le pedí a Claude Code (con Sonnet 4.6 como principal) que auditara la lógica de prorrateo en mi clase SubscriptionBillingService y corrigiera cualquier bug que encontrara. Sonnet 4.6 leyó el archivo, trazó el flujo a través de tres clases dependientes y propuso una corrección para lo que identificó como un error de desplazamiento por uno en el cálculo de días prorrateados.
Paso 3: Sonnet aplica la corrección y ejecuta los tests.
La corrección superó 14 de los 16 tests existentes. Dos tests fallaron — ambos relacionados con el manejo de zonas horarias en los límites de renovación. Sonnet intentó una segunda corrección. Los mismos dos tests fallaron. Probó un tercer enfoque. El mismo patrón de fallo.
Aquí es donde se activa el disparador de error recurrente.
Paso 4: Sonnet llama a /advisor.
La salida de consola hizo explícita la llamada:
[advisor invoked: recurring test failure on timezone-sensitive cases]
Sin interacción de mi parte. Sonnet hizo la llamada de forma autónoma. Opus 4.6 recibió el transcript completo — mi solicitud original, el contenido del archivo, los fallos de los tests, los tres intentos de corrección — y devolvió un análisis estructurado.
Paso 5: El consejo regresa.
La respuesta de Opus 4.6 identificó dos problemas que Sonnet había pasado por alto. Primero: la lógica de prorrateo estaba usando la zona horaria local del servidor en lugar de la zona horaria de suscripción del usuario, lo que significaba que las renovaciones cercanas a la medianoche UTC se calculaban en el período de facturación incorrecto. Segundo: los fixtures de test que Sonnet había estado actualizando eran en sí mismos incorrectos, razón por la cual las correcciones de Sonnet seguían pareciendo correctas pero los tests seguían fallando — los tests estaban validando el bug, no la corrección.
Ninguno de los dos problemas era obvio desde el análisis en solitario de Sonnet. Ambos eran obvios en retrospectiva una vez que Opus los señaló.
Paso 6: Sonnet integra el consejo.
Sonnet 4.6 no copió la respuesta del advisor palabra por palabra. Tomó la orientación, reescribió la lógica de prorrateo para usar la zona horaria del usuario, luego marcó independientemente el problema del fixture de test para mi revisión — "El advisor señaló que los fixtures pueden estar validando un comportamiento incorrecto. Recomiendo revisar tests/Unit/ProrationTest.php líneas 84-110 antes de modificarlos, ya que esto cambia la semántica de los tests."
Esa última parte es el comportamiento que me convenció de /advisor. Sonnet no aplicó el consejo ciegamente. Se detuvo en el lugar donde el consejo tenía implicaciones en las que yo debería intervenir.
Paso 7: Verificación.
Aprobé la revisión de los fixtures. Sonnet actualizó los tests, volvió a ejecutar la suite, y los 16 tests pasaron. Tiempo total desde la primera corrección fallida hasta la ejecución de tests en verde: menos de cuatro minutos. Tiempo de depuración manual que habría invertido en el mismo problema, basándome en cuánto tiempo llevaba ya bloqueado: probablemente otras dos horas.
Los consejos pro que nadie está mencionando todavía
Algunas cosas que aprendí durante las pruebas que no están en la documentación del anuncio.
Consejo 1: Las llamadas al advisor aparecen en el registro de tokens, pero como un ítem separado. Puedes ver exactamente cuánto costó el advisor frente al modelo principal. Esto es sorprendentemente útil para calibrar si la funcionalidad está ganando su peso en cualquier proyecto dado. Estoy rastreando la ratio en mis proyectos de prueba y probablemente publicaré los datos en un artículo de seguimiento.
Consejo 2: El advisor persiste a través de operaciones /compact. Si compactas tu conversación para liberar contexto, la orientación previa del advisor sobrevive a la compactación. Es un detalle pequeño con grandes implicaciones para sesiones largas — tu advisor se convierte efectivamente en una capa de conocimiento acumulativo.
Consejo 3: Puedes volver a ejecutar /advisor para cambiar modelos a mitad de sesión. No me di cuenta de esto al principio, pero puedes cambiar tu configuración de advisor a mitad de una sesión sin reiniciar. Lo usé para pasar de Opus-como-advisor a un Opus-como-advisor fresco después de un /compact para reiniciar el estado acumulado del advisor.
Consejo 4: El disparador del advisor puede ajustarse. Si bien no puedes forzar una llamada, puedes hacer que el modelo principal sea más propenso a invocar al advisor siendo explícito en tu prompt. Frases como "verifica esto con el advisor antes de confirmar" o "si te bloqueas, consulta al advisor" aumentaron mediblemente la tasa de llamadas en mis pruebas. No es una garantía — pero es una palanca útil.
Consejo 5: Presta atención al comportamiento de bucle del advisor. En una prueba, Sonnet 4.6 llamó a Opus 4.6 tres veces seguidas para el mismo problema, cada vez recibiendo un consejo ligeramente diferente y cada vez sintiéndose menos seguro sobre su dirección. Este es el modo de fallo a vigilar. Si ves que el advisor se llama repetidamente sin progreso, intervén manualmente. La capa metacognitiva es valiosa, pero no es un sustituto del juicio humano cuando el modelo está genuinamente perdido.
Sinceridad total: Por qué sigo usando subagentes por defecto para los flujos de trabajo con Opus
Aquí viene la parte honesta. Para mi flujo de trabajo diario real — donde ejecuto Opus 4.6 como modelo principal en arquitecturas de agentes complejas — sigo prefiriendo subagentes con context windows independientes sobre /advisor. Déjame explicar por qué, porque el equilibrio importa.
Cuando genero un subagente, ese agente comienza con un contexto limpio. Sin conversación acumulada. Sin encuadre sesgado de los intentos anteriores del modelo principal. Solo el prompt que le doy y las herramientas que autorizo. Esa limpieza es a menudo la diferencia entre orientación útil y consejo que simplemente refleja los puntos ciegos del modelo principal.
El comando /advisor, en cambio, proporciona el transcript completo al advisor cada vez. Si el modelo principal está bloqueado porque está encuadrando mal el problema, el advisor ve el mismo encuadre incorrecto y puede o no escapar de él. Opus es mejor escapando de las trampas de encuadre que Sonnet, razón por la cual la combinación Sonnet-principal + Opus-advisor funciona tan bien — Opus trae suficiente potencia para reencuadrar. Pero cuando Opus es tu modelo principal y el encuadre es el problema, el advisor puede ser arrastrado a la misma trampa.
Probé esto directamente. Le di a Opus 4.6 un problema de arquitectura deliberadamente mal encuadrado y configuré Opus 4.6 como advisor. El advisor estuvo de acuerdo con el encuadre. Luego generé un subagente de Opus 4.6 fresco con solo los requisitos originales (sin transcript) y le hice la misma pregunta. El subagente reencuadró el problema de inmediato y propuso una solución diferente.
El mismo modelo. El mismo problema. Resultados diferentes basados en la frescura del contexto.
Así que aquí está mi regla práctica real: usa /advisor cuando tu modelo principal sea Sonnet y quieras una red de seguridad de Opus. Usa subagentes cuando tu modelo principal sea Opus y quieras un razonamiento paralelo genuino. Usa ambos cuando estés trabajando en algo de alto riesgo.
Y sé honesto contigo mismo sobre en qué modo estás. Los valores predeterminados de la funcionalidad son inteligentes, pero no son magia.
Por qué /advisor es realmente sobre Mythos
Ahora la parte hacia la que he estado construyendo.
No creo que /advisor exista porque el equipo de Claude Code quisiera lanzar una capa metacognitiva para Sonnet y Opus. Creo que /advisor existe porque Anthropic está preparando la infraestructura para Mythos — el modelo que comenzó a filtrarse en conversaciones públicas hace unas semanas y sobre el que ya he escrito en el análisis de la filtración de Claude Mythos — y necesitaban una forma de hacer económicamente viable un modelo de alto coste y alta potencia dentro de Claude Code.
Piénsalo. Si Mythos aterriza al punto de precio que sugieren las filtraciones — significativamente por encima de Opus 4.6 — ejecutarlo como tu modelo principal para una sesión completa será prohibitivo para la mayoría de los desarrolladores. Incluso para trabajo de agencia, los márgenes no tendrán sentido en cada tarea. Entonces, ¿cómo das a los usuarios acceso al poder de Mythos sin obligarles a pagar tarifas de Mythos por cada token?
Les dejas configurarlo como advisor.
Imagina la combinación: Sonnet 4.6 como tu modelo de ejecución, funcionando rápido y barato para la mayoría de tus tokens. Mythos como tu advisor, invocado solo en los momentos críticos — antes de grandes commits, cuando los tests siguen fallando, cuando el modelo está a punto de hacer un salto interpretativo. Obtienes juicio de nivel Mythos en las decisiones que más importan, a una fracción del coste de ejecutar Mythos como modelo principal.
Este es el patrón. /advisor son los andamios. La combinación Sonnet/Opus que tenemos hoy es la prueba beta de la combinación Sonnet/Mythos que viene.
Puedo estar equivocado en esto. Es posible que /advisor sea simplemente una funcionalidad independiente y que la integración de Mythos tenga un aspecto completamente diferente. Pero las decisiones de arquitectura cuentan una historia. La lista de modelos permitidos estricta (actualmente dos modelos). El intercambio automático de contexto. El comportamiento de detección de conflictos que saca a la superficie los desacuerdos del advisor en lugar de ceder a ellos. Todas son decisiones de diseño que tienen perfecto sentido si tu objetivo final es un sistema de modelos por niveles donde el modelo de nivel más alto es lo suficientemente caro como para que solo quieras consultarlo en los problemas más difíciles.
Y si tengo razón en esto, los desarrolladores que aprendan /advisor ahora tendrán una ventaja enorme cuando llegue Mythos. Los patrones de flujo de trabajo que construyas alrededor de Sonnet-principal + Opus-advisor se transferirán casi directamente a Sonnet-principal + Mythos-advisor, con solo la configuración cambiando. Los hábitos de prompt, la conciencia de los disparadores, el marco de decisión subagente-versus-advisor — todo se traslada.
Si quieres un análisis más profundo de lo que podría traer Mythos, he escrito sobre las implicaciones en mi inmersión profunda en Mythos sobre autonomía de modelos. Pero la versión corta: sea lo que sea que resulte ser Mythos, será caro, y /advisor es cómo accederás a él sin arruinarte.
Qué te recomendaría hacer hoy
Si ya estás en Claude Code y usas Sonnet 4.6 para la mayor parte de tu trabajo, activa /advisor con Opus 4.6 como advisor ahora mismo. Úsalo en un proyecto real esta semana. Presta atención a la frecuencia con que se llama al advisor y qué tipo de problemas lo activan. Ese reconocimiento de patrones es el valor real — no las primeras veces que te salva de un bug, sino la comprensión gradual de cuándo es probable que tu modelo necesite una segunda opinión.
Si estás ejecutando Opus 4.6 como modelo principal, seguiría recomendando activar /advisor con Opus como advisor, pero en paralelo con tus flujos de trabajo de subagentes existentes. No reemplaces los subagentes. Auméntalos. Usa /advisor para las segundas opiniones ligeras e inline y los subagentes para el razonamiento paralelo más pesado.
Si aún no has actualizado a Sonnet 4.6 u Opus 4.6, haz eso primero. El comando advisor los requiere. Los modelos más antiguos no están en la lista de permitidos y no lo estarán — la funcionalidad está diseñada explícitamente para la generación actual.
Una cosa más. Si estás en mi lista de correo o sigues mi blog, voy a rastrear los patrones de uso de /advisor durante las próximas semanas y publicaré los datos. Ratios de costes, frecuencias de disparadores, resultados reales en proyectos reales. El tipo de datos que te dice si esta funcionalidad gana su lugar en tu flujo de trabajo o si es un nice-to-have que puedes ignorar. Si quieres esos datos antes de que sean públicos, la mejor manera de obtenerlos es comenzar a ejecutar tus propias pruebas ahora — porque para cuando publique mis hallazgos, Mythos probablemente estará a semanas de cambiar la ecuación por completo.
El comando /advisor no es la funcionalidad más grande que Claude Code ha lanzado este año. Puede que ni siquiera sea la más útil en cualquier día dado. Pero sí es la más estructuralmente importante, porque es la primera vez que Anthropic ha construido infraestructura explícita para la colaboración multi-modelo dentro de una sola sesión, y esa infraestructura va a importar enormemente una vez que el nivel de modelos por encima de Opus realmente exista.
¿El bug de facturación que tardé tres días en encontrar? Sonnet y Opus lo encontraron en cuatro minutos de análisis asistido por advisor. Eso no es el final de la historia. Eso es el comienzo de un patrón de flujo de trabajo que usaré durante años.
Empieza a construir el hábito ahora. Te alegrará haberlo hecho cuando llegue el siguiente modelo.
Preguntas frecuentes
¿Qué es el slash command /advisor de Claude Code?
El slash command /advisor te permite configurar un modelo Claude secundario que tu modelo principal invoca automáticamente cuando se enfrenta a decisiones complejas, errores recurrentes o puntos de control de finalización de tareas. Actualmente solo admite Sonnet 4.6 y Opus 4.6. El advisor recibe el transcript completo de la conversación y devuelve orientación que se pliega en el contexto compartido de la sesión.
¿Qué combinación de modelos debo usar con /advisor?
Para la mayoría de los desarrolladores: usa Sonnet 4.6 como modelo principal y Opus 4.6 como advisor. Esta combinación te da la velocidad y eficiencia de costes de Sonnet para el trabajo rutinario mientras reserva el razonamiento más profundo de Opus para los momentos que importan. Probé las tres combinaciones viables y esta produjo la mejor relación coste-calidad en tareas de refactorización reales.
¿Funciona /advisor con subagentes?
Sí, pero sirven propósitos diferentes. /advisor proporciona el transcript completo a un modelo secundario inline, mientras que los subagentes funcionan con context windows limpios e independientes. Usa /advisor cuando tu modelo principal sea Sonnet. Usa subagentes cuando tu modelo principal sea Opus y necesites una perspectiva fresca libre del encuadre del modelo principal.
¿Puede el advisor acceder a archivos o ejecutar comandos?
No. El advisor no tiene acceso al sistema de archivos, la shell, la web o los servidores MCP. Solo razona sobre el historial de conversación que recibe del modelo principal. Este es un límite arquitectónico duro en la implementación actual, no un permiso configurable.
¿Es /advisor más barato que ejecutar Opus 4.6 como modelo principal?
En mis pruebas, sí — una sesión de 42 rondas de Sonnet 4.6 con 6 llamadas al advisor de Opus 4.6 resultó más barata que ejecutar Opus 4.6 como modelo principal para la misma carga de trabajo. Los ahorros provienen de usar el modelo más barato para la mayoría de los tokens y pagar tarifas premium solo en las invocaciones del advisor.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (builds e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
