AIDiveIntro: mismas pruebas, el doble del medidor, cinco límites
Ultracode es la palabra clave, o el interruptor, que convierte una petición que escribes en Claude Code en un equipo entero de agentes. En una prueba pareada con la misma especificación, las dos ejecuciones pasaron las mismas pruebas ocultas, y la de ultracode consumió más del doble del medidor de sesión. La razón no es un modelo más listo: es una frase que el harness inyecta y tres protecciones que apaga.
Este artículo cubre cuatro cosas:
- la prueba pareada, leída en el medidor del plan;
- el multiplicador de tokens en varios pares más;
- el único tipo de trabajo en el que un equipo encontró 66 bugs plantados mientras un solo agente encontraba 14;
- los cinco ajustes que limitan una ejecución antes de que se coma tu semana, uno de los cuales la detiene en el propio límite de uso.
Qué activa ultracode: la palabra clave, el interruptor, un workflow de agentes
Ultracode son dos interruptores. Escribir ultracode dentro de un prompt ejecuta esa única tarea como un workflow sin tocar el nivel de esfuerzo de la sesión. Activar el interruptor con el comando /effort hace que Claude planifique un workflow para cada tarea sustancial, así que una petición puede convertirse en varios workflows seguidos.
Un workflow es un script que Claude escribe para sí mismo; ese script ejecuta un equipo de agentes por fases. En un sandbox minúsculo (un par de archivos con un manejo de promesas descuidado, revisión de solo lectura), Claude exploró los archivos, lanzó un workflow que llamó "unhandled promise audit", y bajo la caja del prompt apareció una fila de tarea con una barra de progreso, el número de agentes, el tiempo transcurrido y un total de tokens que no dejaba de subir. El comando /workflows lista una fila por agente con su propio contador de tokens, además de teclas para pausar, detener o reiniciar.
En esa ejecución, cada buscador había leído unos 45.000 tokens antes incluso de que empezaran los verificadores, para un puñado de líneas de código.
Cada sesión lleva además una guía de tamaño, el número de agentes por debajo del cual se aconseja a Claude quedarse:
| Guía de tamaño | Agentes aconsejados |
|---|---|
| small (por defecto en Pro) | menos de 5 |
| medium | menos de 10 |
Cada agente envía sus propias peticiones además de tu conversación. Un workflow nunca es una sola factura; es una factura por agente, y el medidor las cuenta todas.
La prueba pareada: las mismas 136 pruebas, 8 por ciento contra 18, y nunca para
Un desarrollador midió el coste en el plan de suscripción más alto con una configuración limpia: la misma especificación para una pequeña hoja de cálculo, el mismo modelo con el mismo esfuerzo, una ejecución normal y una con ultracode. Las dos se puntuaron con pruebas ocultas, tests que el modelo nunca ve. Las dos pasaron las 136.
| Ejecución | Final | Límite de sesión usado | Pruebas pasadas |
|---|---|---|---|
| Normal | terminó sola, 25 min | 8 % | 136 / 136 |
| Ultracode | cortada por el reloj a los 76 min, aún comprobando | 18 % | 136 / 136 |
Dentro de la ejecución con ultracode, Claude escribió un script cuyo único trabajo era ejecutar un equipo: 12 agentes contados, testers, algunos jueces y, más tarde, unos "breakers" cuyo trabajo era romper la página. Uno de ellos sí encontró un bug real en la barra de fórmulas, que seguía mostrando el texto antiguo después de hacer clic en otra celda.
Por minuto, la ejecución con ultracode gastó el límite casi igual de rápido que la normal, de media algo más despacio. No quemó más rápido; no paró. Ultracode no hace a Claude más listo, hace que Claude compruebe, y pagas cada comprobación. Es un solo par con una especificación pequeña, y la segunda ejecución la cortó un reloj, pero la forma está clara: misma respuesta, más del doble de ventana de sesión, y el tiempo extra fue todo comprobación.
Por qué cuesta: una frase y tres protecciones apagadas
El modelo es el mismo. Lo que cambia es el texto que el harness le entrega; el harness es el propio Claude Code, sus herramientas y las instrucciones que rodean al modelo.
Con ultracode activado, Claude Code carga una referencia antes de escribir cualquier workflow. Ese texto le dice al modelo que ejecute un workflow para cada tarea sustancial por defecto, y contiene la frase que explica la factura: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." Es el texto del propio harness, y un issue público de GitHub cita las mismas líneas.
Tres protecciones se apagan a la vez:
- El aviso de workflow grande, que normalmente salta cuando una ejecución programa demasiados agentes, no aparece.
- El límite de la sesión sobre cuántos agentes pueden ejecutarse a la vez no se aplica a los agentes que Claude lanza.
- En modo auto, el primer lanzamiento nunca se envía a aprobación.
La guía de tamaño es un consejo, no un tope: con small (menos de 5 agentes) en el sandbox, la ejecución con ultracode lanzó igualmente 9. Para ser justos, la frase es un valor por defecto que el modelo aún puede sopesar, y las protecciones se retiran a propósito para trabajos muy grandes. La respuesta cabe en una línea: ultracode no cambia el modelo, cambia las instrucciones a "un equipo para todo, y el coste no es una restricción".
El multiplicador: tres pares, la escalera de esfuerzo, el par de 30x
Un segundo desarrollador ejecutó varios pares de un solo agente contra workflow en el plan Pro, con scripts de tipo revisión, leyendo el medidor de uso antes y después de cada uno.
| Medida | Un solo agente | Workflow |
|---|---|---|
| Tokens en un script de revisión | unos 115.000 | 972.000 |
| Multiplicador de tokens entre los pares | 1x | hasta 18x, para aproximadamente los mismos hallazgos |
| Movimiento del medidor | 1x | hasta 3x |
| Tiempo de reloj | casi idéntico | casi idéntico |
El workflow no terminó antes; gastó más mientras tú esperabas lo mismo. El único sitio donde lo paralelo compensó fue un lote de trabajos de investigación independientes, donde los agentes terminaron antes, aun así por más del doble de tokens.
Una tercera prueba construyó unas cuantas apps pequeñas en cada nivel de esfuerzo a precios de API. Cada escalón de la escalera duplicaba más o menos la factura, y ultracode quedó en varias veces lo que costó max sin llegar nunca a ganar. La mayoría de esos tokens fueron lecturas de caché, las baratas; la minúscula porción de tokens de salida suponía casi la mitad del coste.
Un par más, una escena de ciudad: un solo agente tardó cerca de una hora por unos pocos dólares de precio de API. La ejecución con ultracode tardó casi un día entero, docenas de subagentes y unas 30 veces el coste.
Son lecturas del medidor en números enteros, apps desde cero a precios de API y una escena de ciudad, así que ninguna es un marcador por sí sola. Juntas, el patrón es el mismo siempre: el fan-out compra comprobación y cobertura, no una mejor respuesta, salvo que el trabajo se divida en piezas independientes.
Dónde compensa el fan-out: una suite de tests como juez, y la regla en una línea
Algunos trabajos tienen de verdad esta forma: una migración, una auditoría, un barrido por un código base.
Bun se reescribió de Zig a Rust con unos 50 workflows dinámicos en Claude Code, ejecutándose sin parar durante 11 días. Son más de medio millón de líneas de Zig, desde el inicio hasta que toda la suite de tests pasó en todas las plataformas en esos mismos días. Lo que lo hizo funcionar no fue el número de agentes sino el juez: una enorme suite de tests ya existente decía pasa o falla sin la opinión de nadie.
La caza de bugs de Anthropic muestra lo mismo. Se plantaron setenta bugs en un código base grande y un solo agente se ejecutó varias veces.
| Agente | Bugs encontrados de 70 |
|---|---|
| Un solo agente (3 ejecuciones) | 14, 15, 27 |
| Workflow (3 ejecuciones) | 66 en cada ejecución |
Una salvedad: esa prueba se hizo en Claude Managed Agents, el producto de API, no en Claude Code, y no se dio ningún coste.
El hilo de lanzamiento añade las otras victorias reportadas, y todas se parecen: revisión contra un archivo de reglas, traducir un código base entero, limpiar un montón de páginas escaneadas. El blog de lanzamiento lo dice claro: la mayoría de las tareas de programación tradicionales no necesitan un panel de cinco revisores.
La regla: haz fan-out solo cuando una suite de tests o un conjunto de reglas juzgue la salida y el trabajo se divida en piezas independientes. Todo lo demás se ejecuta normal, en high. El tester de la prueba pareada dijo lo mismo con sus palabras: guárdalo para trabajos donde comprobar es el trabajo, como una migración por cientos de archivos.
Cinco ajustes que limitan una ejecución
Cada límite está en un sitio que ya conoces.
| # | Ajuste | Dónde | Efecto |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config en Dynamic workflow size, o settings.json |
consejo (menos de 5 agentes), y también baja el umbral del aviso de workflow grande |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
variable de entorno, exportada antes de lanzar | por defecto hasta 16 agentes a la vez; con 4 el resto hace cola, frena el gasto sin matar la ejecución |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
variable de entorno | ejecuta todos los agentes del workflow en un modelo que eliges mientras los demás subagentes conservan el suyo; un modelo más barato abarata la comprobación |
| 4 | la palabra clave ultracode, nunca el interruptor |
en el prompt; nunca la clave ultracode en los ajustes |
la palabra clave ejecuta una tarea como workflow y se detiene; el interruptor lo deja fijo hasta que lo apagues |
| 5 | autoContinueAtUsageLimit |
ajustes | activado: una ejecución que llega al límite se pausa, espera al reinicio y sigue, más de una vez; desactivado: los agentes fallan en el muro y la ejecución termina ahí |
Tres hábitos acompañan a los ajustes. El blog de lanzamiento dice que un presupuesto escrito en el prompt, como "use 10k tokens", fija el tope. Después de cualquier ejecución, /usage muestra qué parte del uso reciente fue a subagentes y workflows, con un aviso cuando dominan. Si una ejecución va mal mientras corre, el panel /workflows y la tecla x la detienen, y el trabajo ya hecho suele conservarse.
Nada de esto abarata un agente. Limita cuántos agentes puede gastar una ejecución y cuánto tiempo puede seguir gastando.
La ejecución descontrolada, los límites y el veredicto
Un reporte público muestra cómo desaparece una semana. Un script escrito por el modelo, en el plan más grande, arrancó 221 agentes en menos de una hora. Tras el primer error de límite de sesión el script siguió despachando, y otros 189 agentes arrancaron en los minutos siguientes. La tabla del propio autor del reporte cuenta decenas de millones de tokens entre las fases antes del muro.
| Fase | Tokens, caché incluida |
|---|---|
| Ground | 11.063.801 |
| Find | 35.885.272 |
| Merge | 516.226 |
| Total | 47.465.299 |
El culpable fue una línea del script generado, un fallback que decía: si el agente no devolvió nada, usa la lista en bruto y sigue. El merge falló y la ejecución continuó. Esa versión es anterior a la pausa en el límite de uso, y quien reporta dice que esos tokens no venían de los agentes fallidos. Un techo de concurrencia habría adelgazado esa ejecución, y auto-continue desactivado la habría terminado en el muro.
El veredicto: en la misma tarea, con las mismas pruebas pasadas, ultracode consumió más del doble del medidor de una ejecución normal. No porque sea más listo, sino por la frase inyectada y las protecciones que retira. Compensa cuando una suite de tests o un conjunto de reglas juzga la salida y las piezas no se esperan entre sí. En todo lo demás, lo escribes y pagas por comprobar. Cinco ajustes limitan lo que una ejecución puede gastar: la guía de tamaño, el techo de concurrencia, el modelo del workflow, la palabra clave en vez del interruptor y la parada en el límite.
