Esta gran actualización cambió mi forma de usar Claude Code

하이라이트

• La estrategia de Asesor combina el modelo Sonnet como ejecutor de tareas y a Opus como un consultor de alto nivel para optimizar el consumo de tokens.

• El uso de Opus como asesor en lugar de agente principal reduce significativamente los costos y evita agotar los límites de contexto de 5 horas durante periodos pico.

• En pruebas del SWE-bench, la combinación de Sonnet y Opus superó el rendimiento de Sonnet actuando de forma individual.

• La implementación de cambios en la interfaz de usuario mediante Sonnet y el asesor tomó 31 minutos, una duración mayor a la que requeriría Opus trabajando solo.

• El modelo Sonnet procesa las tareas de forma secuencial y no divide el trabajo en sub-agentes paralelos como lo hace Opus.

• El flujo de trabajo asesor-ejecutor resolvió fallos de sincronización en tiempo real que Sonnet no pudo solucionar tras múltiples intentos por su cuenta.

타임라인

1. 00:00 - 00:52

   Limitaciones de los modelos individuales y gestión de tokens

   El uso individual de modelos genera ineficiencias operativas. Opus consume una cantidad excesiva de tokens incluso en tareas triviales, mientras que Sonnet se bloquea ante problemas difíciles. La orquestación automática actual de Claude Code delega tareas, pero no soluciona el problema de los límites de contexto durante las horas de mayor demanda.

   • Opus posee una capacidad de razonamiento superior pero consume los límites de uso rápidamente.
   • Sonnet ofrece velocidad y eficiencia pero falla al enfrentar decisiones lógicas complejas.
   • Anthropic redujo recientemente los límites de uso, lo que acelera el agotamiento de la ventana de contexto de 5 horas.
2. 00:53 - 02:51

   Funcionamiento de la estrategia de Asesor

   Este enfoque se centra en la eficiencia del uso de tokens para prolongar la operatividad de Claude. A diferencia de otros frameworks centrados solo en la creación de aplicaciones, esta estructura optimiza el rendimiento en el SWE-bench. El impacto real reside en invocar la potencia de Opus solo para cerrar la brecha de rendimiento en puntos críticos de decisión.

   • El ejecutor basado en Sonnet gestiona las llamadas a herramientas y los cambios de código directamente.
   • El asesor basado en Opus interviene exclusivamente cuando el ejecutor encuentra obstáculos insuperables.
   • La combinación de ambos modelos resulta en un costo menor comparado con el uso de Opus como agente principal.
3. 02:52 - 05:18

   Resolución de problemas de sincronización en tiempo real

   Durante la depuración de una aplicación con sincronización en tiempo real, Sonnet falló repetidamente en corregir la función de borrado. Al activar a Opus como asesor, este analizó el historial de la conversación y señaló el error exacto en la lógica. La solución final permitió que los cambios se reflejaran correctamente en todos los dispositivos, incluso cuando un ítem seleccionado era borrado desde otro extremo.

   • El asesor identificó fallos específicos en la lógica de sincronización que impedían el borrado de elementos en dispositivos vinculados.
   • El ejecutor aplicó las reestructuraciones sugeridas por el asesor sin necesidad de iteraciones adicionales de prompts.
   • La lógica compleja de sincronización de estados distribuidos supera la capacidad intrínseca de Sonnet actuando en solitario.
4. 05:19 - 07:05

   Migración de interfaz y limitaciones de tiempo

   En una tarea de transformación de interfaz, el sistema utilizó Playwright MCP para entender la estructura actual. El asesor evitó errores críticos al identificar incompatibilidades de librerías al inicio del proceso. Sin embargo, la falta de capacidad de Sonnet para ejecutar sub-agentes en paralelo resultó en un proceso lento, sugiriendo que para cambios masivos en toda la aplicación es más eficiente usar Opus directamente.

   • El asesor detectó conflictos de versiones entre librerías antes de iniciar los cambios visuales en la aplicación.
   • Sonnet procesó la migración de componentes de forma secuencial, extendiendo la tarea a 31 minutos.
   • Opus es superior en la orquestación de tareas paralelas, lo que acelera cambios de gran escala en comparación con el modelo híbrido.
5. 07:06 - 08:43

   Implementación de funciones nuevas y supervisión humana

   Al intentar añadir una página nueva, Sonnet no consultó al asesor de forma automática y generó errores en el flujo de datos. Los cambios de color y título se aplicaban erróneamente fuera de la vista previa debido a una mala elección de arquitectura de componentes. Tras un empuje manual para consultar al asesor, el problema se resolvió permitiendo el streaming de cambios en tiempo real sin necesidad de ejecuciones manuales tras cada edición.

   • El ejecutor puede juzgar erróneamente la complejidad de una tarea y omitir la consulta al asesor.
   • La intervención manual mediante prompts es necesaria cuando el modelo pequeño asume tareas complejas como rutinarias.
   • La elección incorrecta de componentes por parte de Sonnet provocó filtraciones de cambios entre paneles independientes.
6. 08:44 - 10:14

   Evaluación final de la viabilidad del sistema

   Aunque el asesor ayuda a cerrar la brecha de rendimiento, no la elimina por completo. En entornos complejos, las idas y venidas entre modelos pueden consumir más tiempo y esfuerzo que el uso directo del modelo más potente. Esta configuración se recomienda específicamente cuando se trabaja bajo límites de tokens estrictos y la tarea permite una implementación mayoritariamente directa.

   • La estrategia es ideal para proyectos de escala simple a media que requieren razonamiento profundo ocasional.
   • Las aplicaciones con múltiples dependencias conectadas y puntos de fallo críticos siguen requiriendo a Opus como agente principal.
   • Sonnet carece de la profundidad necesaria para evaluar múltiples enfoques y sus consecuencias a largo plazo simultáneamente.