Claude Code Workflows: 41 agentes, 5M tokens, probados
Cuarenta y un agentes. Esa es la cantidad de instancias de Haiku que uno de mis workflows de Claude Code lanzó la semana pasada, todas a la vez, para auditar y puntuar cada skill que tenía instalada. Vi el contador subir en la terminal — 12, 28, 41 — cada uno una llamada completa e independiente a Claude evaluando una receta diferente contra criterios que le había dado al orquestador. Todo el proceso consumió aproximadamente 5 millones de tokens de entrada antes de terminar.
Ese número me detuvo. Cinco millones. En la mayoría de los cálculos de precios, suena como una factura que induce pánico. Pero aquí está el giro que reenmarcó toda la función para mí: la salida fue diminuta. Un informe clasificado, unas pocas cientos de líneas. Todo ese gasto de tokens fue en lectura — rastreo, análisis, puntuación — no en generación. Computacionalmente pesado, sí. ¿Excesivamente caro? No realmente. Los tokens de entrada de Haiku son baratos, y 41 de ellos leyendo en paralelo terminaron en una fracción del tiempo real que un solo agente habría necesitado para procesar secuencialmente la misma pila.
Ese es el momento en que los workflows de Claude Code me hicieron clic. No como un término de moda del lanzamiento de Opus 4.8. Como una herramienta específica con una forma específica — una que es genuinamente diferente de skills, subagentes y equipos de agentes, y una que es tremendamente fácil de usar mal si no entiendes esa forma.
Así que eso es este artículo. No un anuncio de funciones. Una guía de campo. Al final sabrás exactamente cuál de los cinco primitivos de orquestación elegir — skill, subagente, equipo de agentes, workflow o el bucle /goal — y aproximadamente cuánto te cuesta cada uno en tokens y complejidad. Aprendí la mayoría de esto de la manera un poco cara. Tú no tienes por qué.
Lo que Anthropic realmente lanzó con Workflows el 28 de mayo
Los workflows dinámicos llegaron el 28 de mayo de 2026, incluidos en el lanzamiento de Claude Opus 4.8 como research preview. Si ya leíste mi análisis de los niveles de esfuerzo de Opus 4.8, piensa en los workflows como la otra mitad de ese lanzamiento — el modelo obtuvo un dial de pensamiento, y Claude Code obtuvo una forma de distribuir ese pensamiento entre cientos de agentes a la vez.
Necesitas Claude Code v2.1.154 o posterior para ejecutarlos. Funcionan en la CLI, la app de escritorio y la extensión de VS Code. Y la forma en que disparas uno es casi sospechosamente casual: simplemente pones la palabra workflow en algún lugar de tu prompt. Di "ejecuta un workflow para auditar cada ruta API en busca de verificaciones de auth faltantes" y Claude hace algo que nunca antes había hecho — escribe un script de orquestación en JavaScript al vuelo, se lo pasa a un runtime en segundo plano, y ese runtime lanza los agentes.
Dos límites duros que vale la pena grabar en tu memoria: el runtime ejecuta hasta 16 agentes simultáneamente, y limita un solo workflow a 1.000 agentes en total. Mi auditoría de 41 agentes de skills no se acercó al techo. Pero es muy fácil escribir un prompt que lo haga — "analiza cada archivo en este monorepo" contra unos miles de archivos saturará ese límite rápidamente y mantendrá la cola procesando. Volveremos a esto, porque es la principal manera en que la gente quema dinero con esta función.
Aquí está el detalle arquitectónico que realmente importa. El que hace que los workflows sean diferentes y no simplemente "subagentes pero más." Déjame mostrarte.
Lo que hace diferentes a los workflows: el plan vive fuera de la cabeza de Claude
Todas las demás herramientas de orquestación en Claude Code mantienen su plan dentro de la ventana de contexto del modelo. La sesión principal recuerda lo que delegó, rastrea lo que regresó, mantiene el estado en su propia memoria de trabajo. Eso está bien para un puñado de tareas. Se desmorona a escala, porque las ventanas de contexto son finitas y cada resultado delegado que metes de vuelta consume espacio que necesitas para el razonamiento real.
Los workflows rompen esa regla completamente. El plan y el estado de ejecución viven en un archivo JavaScript externo, no en el contexto de Claude.
Lee eso otra vez, porque es todo el juego. Cuando inicias un workflow, Claude no solo decide lanzar agentes — escribe un script real: bucles, lógica de ramificación, cuántos agentes lanzar, qué recibe cada uno, cómo combinar los resultados, qué rondas de verificación ejecutar. Ese script se guarda en una carpeta que especificas. Un runtime separado lo ejecuta en un entorno aislado, completamente aparte de tu sesión de chat. Los resultados intermedios — cada salida cruda de cada agente, cada cálculo auxiliar — permanecen en las variables del script. Nunca tocan tu conversación.
Lo que regresa a tu sesión es solo la respuesta final combinada.
Imagina la diferencia físicamente. Con subagentes, tu sesión principal es un gerente sosteniendo un portapapeles, rastreando personalmente cada informe conforme llega. Con un workflow, tu sesión principal escribe un programa, se lo entrega a un servidor de construcción, se va, y regresa a un único artefacto terminado. El portapapeles nunca se llena. Por eso mi auditoría de 41 agentes no reventó la ventana de contexto aunque procesó 5 millones de tokens de entrada — el 99% de esos tokens vivieron y murieron dentro de las variables del script. Mi sesión solo vio el informe clasificado al final.
Esto tiene dos consecuencias que no aprecié hasta haber ejecutado algunos. Primero, porque la orquestación es un archivo guardado, los workflows son re-ejecutables y controlables por versiones. Puedes hacer commit del script, hacer diff, pasárselo a un compañero. Guarda uno útil y se convierte en un comando slash — tu workflow de revisión de branch se convierte en /my-review, repetible para siempre. Segundo, y esto es crítico para el modelo mental: los agentes lanzados no hablan entre sí. Cada uno es una llamada completamente independiente a Claude con su propio contexto aislado. Se despliegan, hacen su única tarea, devuelven un resumen, y eso es todo. Sin conversación cruzada. Sin debate. La combinación ocurre en la lógica del script, no en una conversación entre agentes.
Retén ese detalle de "los agentes no hablan." Es la línea exacta que separa un workflow de un equipo de agentes — y trazar esa línea mal es cómo la gente elige la herramienta equivocada y paga por ello.
Skill vs subagente vs equipo de agentes vs workflow vs /goal: el modelo mental
Bien. Aquí está la parte por la que viniste. Cinco primitivos, y la verdad honesta es que la mayoría de la gente solo necesitaba dos y por entusiasmo fue a por los caros. Yo también. Déjame recorrer cada uno como los uso realmente ahora, del más barato al más caro, porque costo y complejidad suben juntos en una escalera limpia: skills → subagentes → equipos de agentes → workflows. El bucle /goal está a un lado como un eje completamente diferente, y explicaré por qué.
¿Qué es una skill en Claude Code?
Una skill es una receta reutilizable que se ejecuta dentro de tu sesión personal de Claude Code. Es una automatización de un solo agente — un conjunto guardado de instrucciones que Claude puede invocar bajo demanda, por ti o por otras herramientas, sin lanzar nada en paralelo.
Ese es el peldaño más bajo, y debería ser tu opción por defecto. Una skill no se despliega. No obtiene su propio contexto separado. Se ejecuta ahí mismo en tu sesión, como una función que puedes llamar por nombre. Mi rutina de verificación SEO, mi formateador de mensajes de commit, mi receta de "audita este archivo para N+1 queries" — todo skills. Baratas de ejecutar, triviales de mantener y reutilizables en todo. Escribí un argumento completo para construir skills antes de recurrir a agentes, y lo respaldo ahora más que cuando lo publiqué. La gran mayoría de los instintos de "necesito un agente para esto" son en realidad "necesito una skill para esto."
Usa una skill cuando la tarea es pequeña, repetible y autocontenida. Si puedes describirla como una receta, es una skill. Listo.
¿Qué es un subagente?
Un subagente se ejecuta en paralelo a tu sesión principal pero no comparte su ventana de contexto, no puede hablar con otros subagentes, y reporta su resultado solo a la sesión principal.
Este es el siguiente peldaño, y la palabra clave es descargar. Un subagente es para cuando quieres que una tarea secundaria se maneje sin que sature la memoria de tu hilo principal. Digamos que estoy profundo en un refactoring y quiero que la explicación del suite de tests se resuma sin descarrilar mi contexto — se lo paso a un subagente. Va, hace la cosa, regresa con una respuesta, y la memoria de trabajo de mi sesión principal se mantiene limpia. El compromiso que elimina es overhead de comunicación. Un subagente no coordina, no negocia, no notifica a nadie más. Es un encargo de ida. Eso es una característica, no una limitación — hace que los subagentes sean baratos y predecibles.
Usa un subagente cuando tienes una tarea secundaria simple e independiente y la quieres fuera de tu contexto principal. Sin colaboración necesaria. Solo "ve a manejar esto y reporta."
¿Qué es un equipo de agentes?
Un equipo de agentes es un grupo pequeño de agentes que se comunican, comparten tareas y colaboran hacia un objetivo, dentro de su propia ventana de contexto compartida — los agentes debaten, coordinan y construyen sobre el trabajo del otro.
Ahora estamos en el peldaño caro, y la palabra que lo distingue es hablar. A diferencia de los subagentes, los miembros de un equipo de agentes pueden verse e intercambiar información. Comparten contexto. El hallazgo de un agente informa al del otro. Debaten, transfieren, convergen. Profundicé en exactamente cómo y cuándo los agentes deberían hablar entre sí en un artículo dedicado, y la versión corta es: esa conversación es todo el punto, y también es por qué los equipos cuestan dinero real. Contexto compartido más ida y vuelta significa más tokens, más rondas, más cómputo.
Usa un equipo de agentes cuando la tarea es genuinamente colaborativa — cuando la discusión entre agentes produce algo que ningún agente solo podría, y cuando compartir contexto entre ellos es vital. Debates de arquitectura. Revisiones de múltiples perspectivas donde la crítica de un agente afina la propuesta de otro. No para throughput. Para deliberación.
¿Qué es un workflow?
Un workflow es un sistema orquestado por JavaScript que lanza muchos agentes independientes — posiblemente cientos — ejecutándose en paralelo sobre diferentes piezas de una tarea, luego combina sus resultados en lógica de script. Los agentes no se comunican; el plan vive en un archivo externo, no en el contexto de Claude.
Peldaño más alto. Más poderoso, más complejo, más caro. Todo lo que describí dos secciones atrás. El rasgo definidor, lo que lo separa de un equipo de agentes: amplitud sin conversación. Un equipo son pocos agentes hablando. Un workflow son muchos agentes sin hablar — cada uno procesando su propia porción, resultados combinados por código. Mis 41 evaluadores Haiku fueron un workflow de libro: 41 trabajos independientes, cero conversación cruzada, una clasificación combinada al final.
Usa un workflow cuando una tarea naturalmente se fragmenta en muchas piezas independientes y paralelizables. Rastrear una codebase completa. Puntuar un dataset grande. Investigación amplia a través de docenas de ángulos. El tipo de trabajo donde las piezas no necesitan saber unas de otras — solo necesitan hacerse todas, rápido, y enrollarse.
¿Qué hace el comando /goal?
/goal ejecuta un proceso en bucle donde un agente sigue iterando sobre el mismo problema hasta que se cumple una condición de finalización — puede ejecutar muchos ciclos y tomar mucho tiempo.
Aquí es por qué dije que /goal está en un eje diferente. Todo lo anterior trata de cuántos agentes y si hablan. /goal trata de cuántas veces un esfuerzo itera. Es un bucle. Le das un objetivo y una definición de terminado, y muele — intenta, evalúa, refina, intenta otra vez — hasta que la condición se satisface. Puede ejecutar una docena de ciclos. Puede tomar bastante tiempo. Eso es esperado.
Usa /goal cuando la tarea necesita profundidad — refinamiento iterativo hacia un objetivo difícil — en lugar de amplitud.
Y esa palabra, profundidad, es la clave de todo el mapa. Déjame hacerlo concreto.
Amplitud vs profundidad: el marco que finalmente hizo que esto encajara
Aquí está la frase que reorganizó cómo pienso sobre todo esto:
Los workflows son amplitud. /goal es profundidad.
Un workflow se expande — muchos agentes, cada uno manejando una porción diferente, todos a la vez. Amplitud. Lo usas cuando el trabajo es amplio: cien archivos que escanear, cincuenta afirmaciones que verificar, una gran pila plana de tareas independientes. La ganancia es paralelismo. Intercambias tokens por tiempo real y consigues que un trabajo amplio se haga rápido.
El bucle /goal se profundiza — un esfuerzo, refinado una y otra vez, hasta que esté bien. Profundidad. Lo usas cuando el trabajo es profundo: un solo problema complicado que necesita ser martillado ciclo tras ciclo hasta que pase un listón. La ganancia es persistencia. Intercambias tiempo por calidad en una cosa difícil.
Una vez que tuve ese marco, elegir la herramienta dejó de ser adivinanza. ¿Amplio y superficial? Workflow. ¿Estrecho y profundo? /goal. ¿Necesitas ambos — un trabajo amplio donde cada pieza también necesita refinamiento iterativo? Ahí es donde los combinas cuidadosamente, y seré honesto sobre cómo resulta en un momento, porque es poderoso y es una gran manera de quemar una fortuna.
Esta lente de amplitud versus profundidad también explica las dos funciones estrella que Anthropic envió encima de los workflows. Ambas son workflows bajo el capó, apuntando a los dos extremos de ese espectro.
Ultra Code y /deep-research: workflows sin guantes
Dos cosas se sientan encima del motor crudo de workflows, y deberías saber que existen antes de decidir si las necesitas.
Ultra Code (/effort ultracode) es la configuración máxima: mayor esfuerzo de razonamiento más orquestación automática de workflows. Actívalo y Claude decide, para cada tarea sustancial en la sesión, si planificar un workflow. Una sola solicitud puede desplegarse en varios workflows consecutivos — uno para entender el código, uno para hacer el cambio, uno para verificarlo. Es el modo más capaz que tiene Claude Code. También es, sin sorpresa, lo más caro que puedes ejecutar. El mayor esfuerzo quema la mayoría de tokens de pensamiento, y envolver eso en orquestación automática multiplica la cantidad de agentes. Recurro a ultracode cuando estoy haciendo algo genuinamente difícil y genuinamente valioso. No lo dejo activado por defecto. Así es como consigues una factura sorpresa.
/deep-research es el workflow integrado apuntado a la forma de investigación. Haz una pregunta y despliega búsquedas web a través de múltiples ángulos, obtiene y verifica cruzadamente las fuentes, hace que agentes voten sobre afirmaciones competidoras, y sintetiza un único informe citado. Es un workflow construido específicamente para amplitud de investigación — amplitud aplicada al conocimiento en lugar de al código. Si has usado las diversas herramientas de deep-research que hay por ahí, esto es ese patrón, nativo en Claude Code, corriendo sobre el mismo motor de orquestación que mi auditoría de 41 agentes.
Lo gestionas todo con un comando: /workflows. Ejecútalo en cualquier momento para ver qué está corriendo, qué terminó, y para abrir una vista de progreso — o para detener un workflow que claramente se está desviando. He presionado ese botón de parada. Más de una vez. Lo que me lleva a la parte de este artículo que más quiero que leas.
Lo que hice mal: los errores de tokens sobre los que nadie te advierte
Seré directo contigo — mi primer instinto con los workflows fue lanzarlos a todo, y eso fue un error que me costó tokens y me enseñó las reglas reales.
Error uno: usé un workflow para un trabajo que no era amplio. Al principio lancé un workflow para una tarea que realmente eran solo tres pasos secuenciales en un archivo. Montar la orquestación, escribir el script, lanzar agentes — todo ese overhead, para algo que una sola skill habría manejado en un cuarto de los tokens. Los workflows son excesivos para trabajos pequeños o simples, punto. La orquestación cuesta algo incluso antes de que los agentes se ejecuten. Si la tarea genuinamente no se fragmenta en muchas piezas independientes, estás pagando el impuesto de configuración por nada.
Error dos: fui vago, y un workflow me tomó literalmente. Le pedí a uno que "revisara la codebase en busca de problemas." Sin alcance, sin entregable, sin límites. Felizmente se desplegó sobre muchos más archivos de los que me importaban, cada agente una llamada completa a Claude, el medidor de tokens de entrada girando como una máquina tragamonedas. Este es el modo de fallo. Los workflows pueden quemar tokens de entrada absurdamente rápido en trabajos amplios precisamente porque están diseñados para rastrear amplio. Un workflow hace exactamente lo que dijiste — y a la escala de cientos de agentes paralelos, "exactamente lo que dijiste" incluye cada interpretación suelta de un prompt descuidado.
La solución para ambos es la misma, y es aburrida, y funciona: sé explícito y específico. Define el entregable. Acota el alcance. "Audita los 14 archivos en app/Http/Controllers para middleware de autorización faltante y devuelve una tabla de archivo, ruta y la verificación faltante" le da al orquestador una pared donde detenerse. "Revisa el código" le da un continente.
Aquí está la regla por la que ahora realmente vivo. Un workflow es la herramienta correcta solo cuando todo lo siguiente es verdad: la tarea es grande, las piezas son independientes, y esas piezas son paralelizables. Falla en cualquiera y elegiste el primitivo equivocado. ¿Grande pero secuencial? Usa /goal. ¿Pequeño pero repetido? Usa una skill. ¿Colaborativo y basado en discusión? Usa en cambio un equipo de agentes. Las elecciones de orquestación siguen la misma lógica adaptada a la tarea que trabajé en mi análisis de arquitectura de enjambres de agentes — adapta la estructura al trabajo, no a tu entusiasmo.
Si prefieres no aprender este cálculo quemando tokens en un repo de cliente en vivo, este es exactamente el tipo de configuración de orquestación que construyo y afino para equipos — puedes ver lo que acepto en mi Fiverr. Acertar la selección de primitivos a la primera es la mayor parte del valor.
El truco que cambia la economía: anidar skills dentro de workflows
Aquí está el movimiento que hizo que los workflows se sintieran menos como un pozo de dinero y más como palanca. Puedes anidar skills dentro de un workflow. Cada uno de los muchos agentes que un workflow lanza puede invocar tus recetas reutilizables existentes.
Piensa en lo que eso hace. Inviertes el esfuerzo una vez en escribir una skill precisa y bien probada — digamos, una receta precisa de "puntúa este archivo de skill contra estos diez criterios." Luego un workflow lanza 41 agentes y cada uno ejecuta esa misma skill contra un objetivo diferente. Obtienes el paralelismo de un workflow con la consistencia y mantenibilidad de una skill. La capa cara y compleja se apoya en la capa barata y simple. Esa es la arquitectura a la que llegué para la auditoría que abrió este artículo, y es por qué la salida fue tan limpia — cada uno de esos 41 agentes evaluaba con la misma rúbrica, porque todos ejecutaban la misma skill.
Esta es la parte de la escalera costo-complejidad que la gente pasa por alto. Los peldaños no son mutuamente excluyentes. El patrón inteligente es la herramienta más barata haciendo el trabajo real, envuelta en la herramienta cara solo donde genuinamente necesitas la escala. Workflows arriba, skills abajo. No estás eligiendo entre ellos — los estás apilando.
Puedes ir más lejos y combinar un workflow con /goal — amplitud y profundidad juntas, muchos agentes paralelos cada uno iterando hacia un objetivo. Es la orquestación más poderosa que he ejecutado. También es lo más caro en todo este artículo, por un margen amplio, y lo trato como una herramienta eléctrica sin protección. Vale la pena para un trabajo genuinamente grande y genuinamente difícil. Una gran manera de evaporar tokens en cualquier cosa menos.
Un breve paréntesis que no tiene nada que ver con workflows: si todo esto suena como más orquestación de la que tu problema real necesita — digamos que solo quieres construir una app o sitio web de IA con algunas conexiones MCP, no coordinar 41 agentes — Lovable es una rampa de acceso mucho más simple. Conecta servidores MCP y te da una experiencia de construcción que no requiere nada de esto. Es una herramienta diferente para una altitud diferente. Todo el punto de este artículo es hacer coincidir la herramienta con la tarea, así que sería un hipócrita si no lo mencionara. Ahora de vuelta a los agentes.
Lo que esto realmente te cuesta — y cómo saber que funciona
Déjame fundamentar la economía, porque "5 millones de tokens" sin contexto es aterrador o sin sentido dependiendo de lo que asumas.
El número que importa no es el total de tokens — es cuáles tokens. Mi auditoría de 41 agentes fue casi completamente tokens de entrada, y ejecuté los evaluadores en Haiku. Con los precios publicados de Anthropic, la entrada de Haiku cuesta una fracción de centavo por mil tokens, así que 5 millones de tokens de entrada de modelo barato leyendo es una factura fundamentalmente diferente a 5 millones de tokens de salida de generación de Opus. La lección se generaliza: el costo de un workflow está dominado por cuánto leen sus agentes, por el precio del modelo con el que leen. Elige el modelo deliberadamente. Modelos baratos para rastreo amplio y superficial. Modelos caros solo para las piezas que necesitan razonamiento real.
¿Cómo sabes si un workflow es la decisión correcta antes de ejecutarlo? Haz esta prueba de instinto. Cuenta las piezas independientes. Si la tarea se divide en aproximadamente diez o más fragmentos que genuinamente no dependen unos de otros, el paralelismo pagará el overhead de orquestación — esa es tu luz verde. Menos que eso, o las piezas dependen entre sí, y un primitivo más simple casi seguro gana en costo.
Y una vez que esté ejecutándose, observa dos cosas en /workflows: la cantidad de agentes y el tiempo real. Si la cantidad de agentes está subiendo hacia territorio que no pretendías — ese despliegue a escala de monorepo — detenlo y acota tu alcance. Si un workflow está tardando mucho más que el trabajo secuencial equivalente, la tarea probablemente no era paralelizable y elegiste mal. Toda la promesa de amplitud es tiempo real más rápido a través del paralelismo. Si no estás obteniendo eso, la forma estaba equivocada.
La recompensa realista, cuando la forma sí es correcta: trabajos que habrían tomado a un solo agente una hora de procesamiento secuencial terminan en minutos, porque el trabajo era amplio y lo dejaste expandirse. Esa es toda la propuesta de valor. No es magia. Solo paralelismo, correctamente aplicado, con el plan mantenido seguramente fuera de la cabeza del modelo.
La decisión que hace todo esto fácil
Regresa a ese contador de terminal subiendo más allá de 41. La razón por la que esa ejecución se sintió bien en lugar de imprudente no fue la tecnología. Fue que había hecho coincidir la herramienta con la forma del trabajo: una pila amplia y plana de trabajos de puntuación independientes, cada uno ejecutando una skill idéntica, resultados combinados en código, salida pequeña. Primitivo correcto, modelo correcto, alcance acotado. Todo downstream de esa decisión fue fácil.
Esa es toda la habilidad aquí, y realmente no se trata de Claude Code en absoluto. Se trata de mirar una tarea y hacer una pregunta antes de tocar un solo comando: ¿esto es amplio o profundo, colaborativo o independiente, grande o pequeño? Responde eso honestamente y la herramienta se elige sola. Skill para lo pequeño y repetido. Subagente para el encargo secundario simple. Equipo de agentes para el debate genuino. Workflow para el rastreo amplio e independiente. /goal para la iteración profunda. Las herramientas caras envolviendo a las baratas, nunca al revés.
Así que antes de tu próximo gran trabajo — la auditoría de codebase, la investigación amplia, el dataset que has estado postergando — para y nombra su forma en voz alta. ¿Amplio o profundo? Esa sola palabra te ahorrará más tokens que cualquier configuración en la app. ¿Cuál es la tarea más amplia en tu plato que estás haciendo un archivo a la vez?
Preguntas frecuentes
¿Qué son los workflows dinámicos de Claude Code?
Los workflows dinámicos de Claude Code son una función, lanzada el 28 de mayo de 2026, que permite a Claude escribir un script de orquestación en JavaScript y ejecutar muchos agentes independientes en paralelo sobre diferentes piezas de una tarea. El plan vive en un archivo externo, no en la ventana de contexto de Claude, y los agentes no se comunican — los resultados se combinan en lógica de script. Disparas uno incluyendo la palabra "workflow" en tu prompt (requiere Claude Code v2.1.154+).
¿Cómo son diferentes los workflows de los subagentes y equipos de agentes?
Los workflows lanzan muchos agentes no comunicantes en paralelo con el plan en un script externo, mientras que los subagentes ejecutan tareas secundarias aisladas que solo reportan a la sesión principal, y los equipos de agentes son un grupo pequeño que sí habla y comparte contexto para colaborar. La regla limpia: los subagentes descargan, los equipos deliberan, los workflows se despliegan amplio. Para la distinción más profunda sobre cuándo los agentes deberían comunicarse, ve mi guía de equipos de agentes.
¿Cuándo debería usar un workflow versus el comando /goal?
Usa un workflow para amplitud — muchas piezas independientes y paralelizables como rastrear una codebase o puntuar un dataset — y usa /goal para profundidad, donde un esfuerzo itera en bucle hasta alcanzar un objetivo. Los workflows se expanden; /goal se profundiza. Si la tarea es amplia y superficial, workflow. Si es estrecha y profunda, /goal.
¿Cuánto cuestan los workflows de Claude Code en tokens?
El costo de un workflow está dominado por cuánto leen sus agentes multiplicado por el precio del modelo que usan, así que la misma ejecución de 5 millones de tokens es barata en entrada de Haiku y cara en salida de Opus. Los costos se disparan cuando los prompts son vagos o el alcance no está acotado, porque cada uno de los hasta 1.000 agentes es una llamada completa a Claude. Acota el alcance y elige modelos baratos para rastreo amplio y superficial. Para el lado del modelo, ve mi revisión de los niveles de esfuerzo de Opus 4.8.
¿Qué es el modo Ultra Code en Claude Code?
Ultra Code (/effort ultracode) combina el mayor esfuerzo de razonamiento con orquestación automática de workflows, permitiendo que Claude decida cuándo cada tarea sustancial justifica lanzar un workflow. Es el modo más capaz de Claude Code y el más caro — una sola solicitud puede desplegarse en varios workflows consecutivos. Úsalo para trabajo genuinamente difícil y de alto valor, no como configuración por defecto.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (desarrollo personalizado e integraciones): 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
