AIDive

Pack de vídeo

El kit de límites de ultracode: cinco ajustes, checklist de fan-out y pares medidos

11 min de lectura

TL;DR y veredicto

  • Ultracode no hace más listo a Claude Code. Cambia lo que se le dice al modelo y retira tres protecciones, así que una ejecución gasta más y para más tarde.
  • 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, ejecútalo normal en high.
  • Cinco ajustes limitan una ejecución: la guía de tamaño de workflow en small, un techo de 4 agentes concurrentes, un modelo más barato para todos los agentes del workflow, la palabra clave en vez del interruptor y auto-continue en el límite de uso desactivado.
  • Los dos archivos que llevan los límites son settings.json y ultracode-caps.sh. La checklist es when-to-fan-out.md. Los pares medidos están en paired-runs.csv.
  • La guía de tamaño es un consejo, no un tope. En nuestra propia ejecución decía menos de 5 agentes y la ejecución usó 9.

Qué dicen las fuentes

Palabra clave frente a interruptor. Escribir ultracode en un prompt hace que esa tarea use un workflow. Pedirlo con tus propias palabras, como "use a workflow", funciona como la misma activación s1. La palabra clave no hace nada en un prompt pasado con -p, en una entrada del Agent SDK sin sellar ni en una tarea programada s1. El interruptor es distinto. Con ultracode activado, Claude planifica un workflow para cada tarea sustancial, y una petición puede convertirse en varios workflows seguidos s1. La documentación añade que una sesión con ultracode activado llega antes a un límite de sesión o semanal que el mismo trabajo con él desactivado s1.

La frase inyectada. Con ultracode activado, la referencia de autoría de workflows dice: "author and run a workflow for every substantive task by default. The goal is the most exhaustive, correct answer you can produce" y que "token cost is not a constraint." El mismo texto se cita en un issue público titulado "Ultracode overrides the workflow size guideline" s8. Cada workflow de una secuencia recibe su propio presupuesto de agentes, así que cuatro fases de 15 agentes suman 60 agentes sin que ningún workflow rompa la guía s8.

Las tres protecciones. Ultracode apaga tres comprobaciones. El aviso Large workflow no aparece. El límite de subagentes concurrentes de la sesión no se aplica a los subagentes que Claude lanza con la herramienta Agent. En modo de permisos auto no se te pide aprobar el primer lanzamiento de workflow s1.

La guía de tamaño. Small significa menos de 5 agentes, medium menos de 10, large menos de 50. El valor por defecto es medium, o small en un plan Pro con v2.1.271 o posterior. Claude Code la envía al modelo como consejo, no como tope, así que un prompt que pida otra escala la sigue anulando s1. Los límites duros son 16 agentes concurrentes por defecto y 1.000 agentes por ejecución. El aviso de workflow grande salta por encima de 25 agentes o 1,5 millones de tokens proyectados, y solo avisa s1.

Nuestra propia ejecución. Escribimos la palabra clave en un sandbox de dos archivos y 16 líneas de código, con la guía de tamaño en small, y pedimos una revisión de solo lectura. La ejecución usó 9 agentes: 2 buscadores y 7 verificadores. Cada buscador leyó unos 45,2k tokens. No hicimos una ejecución normal del mismo prompt, así que no tenemos una cifra pareada propia.

La prueba pareada. En un plan de 200 $, un desarrollador dio la misma especificación a una ejecución normal y a una con ultracode. Las dos pasaron 136/136 pruebas ocultas. La normal terminó en 25 min con el 8 % del límite de 5 horas. La de ultracode se cortó a los 76 min con el 18 % gastado, y usó 12 agentes en dos equipos (9 y 3), no 1.000. Por minuto el consumo fue casi igual: simplemente no paró s3.

Tres pares más en un plan Pro. Un solo agente contra workflow, mismos hallazgos: 115k contra 972k tokens, 52k contra 936k y 102k contra 683k. El medidor /usage se movió 4 contra 12, 7 contra 12 y 4 contra 8 puntos, lo que el autor resume como aproximadamente el doble de cuota, hasta el triple. El tiempo de reloj en el script del plan de Opus fue 173 s contra 178 s. En cuatro trabajos de investigación independientes, lo paralelo fue 1,6x más rápido por 2,3x los tokens s4.

El par de 30x. Un agente en xhigh tardó 1 h 13 m por unos 18 $ a precios de API. Max con ultracode tardó 9 h 14 m, con 40 subagentes, por unos 554 $. Una ejecución cada uno, precios de lista de API, no facturado en una suscripción s11.

Cómo es un par. Un repositorio de pruebas público contiene un par de un solo agente contra workflow en la misma tarea. El agente único usó 181.646 tokens, el workflow 1.326.703. El coste a precio de API fue 0,2678 $ contra 1,3744 $. El tiempo de reloj fue 43 s contra 80 s, y el medidor de sesión se movió +0 contra +12 puntos s22. Es un solo par, así que léelo como una forma y no como una ley. La documentación lista los subagentes y workflows como un motor de tokens: cada agente que lanza un workflow envía sus propias peticiones además de las de la conversación principal s5. El equipo de investigación de Anthropic midió unas 4x más tokens para un agente que para un chat, y unas 15x para un sistema multiagente s20.

Dónde compensa: Bun. Bun se reescribió de Zig a Rust con unos 50 workflows dinámicos ejecutados de forma continua durante 11 días. El código fuente era de 535.496 líneas de Zig, y el port fue desde el inicio hasta el 100 % de la suite de tests pasando en todas las plataformas en 11 días s19. El juez fue una suite de tests ya existente.

Dónde compensa: la caza de bugs. Anthropic plantó 70 bugs en un código base de 116k líneas. En 3 ejecuciones, un solo agente encontró 14, 15 y 27. Un workflow encontró 66 en cada una de sus 3 ejecuciones s24. Esa prueba se hizo en Managed Agents, el producto de API, no en Claude Code. Anthropic no dio ningún coste y aconseja empezar con una tarea acotada s24. El blog de lanzamiento dice que la mayoría de las tareas de programación tradicionales no necesitan un panel de 5 revisores s2.

La ejecución descontrolada. Un script escrito por el modelo en un plan Max 20x arrancó 221 agentes en 51 minutos. Tras el primer error de límite de sesión se arrancaron 189 agentes más. La tabla de quien reporta cuenta 47.465.299 tokens incluyendo caché s7. Dos matices de quien reporta: los 189 agentes posteriores no tenían respuestas de modelo registradas, y el fallback del script siguió despachando cuando un merge no devolvió nada. Esa ejecución era en v2.1.266, antes de la pausa en el límite de uso s7. Un segundo reporte público describe dos workflows de 56 y 104 agentes, 1.472.855 y 1.752.360 tokens, donde 92 de 160 agentes fallaron por el límite de sesión s21. Quien reporta dice que se informó de ultracode activado sin que el usuario lo activara.

Las palancas. CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS toma un valor de 1 a 256 y requiere v2.1.269 s10. CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL ejecuta todos los agentes del workflow en un modelo mientras los demás subagentes conservan el suyo, desde v2.1.296 s18. Con autoContinueAtUsageLimit activado, una ejecución que llega al límite se pausa y se reanuda en el reinicio, hasta dos esperas, y a la tercera el agente falla. Con él desactivado, los agentes afectados fallan en el muro s1. El blog de lanzamiento dice que un presupuesto en el prompt, como "use 10k tokens", fija el tope s2. La vista /workflows muestra el uso de tokens de cada agente, y x detiene la ejecución s1. /usage señala los comportamientos que suponen el 10 % o más del uso reciente, y v2.1.299 añadió avisos para workflows s5 s18.

El kit de límites

El bloque de ajustes. El límite 1 es la guía de tamaño, el límite 4 es ultracode en false para que la palabra clave sea la única entrada, y el límite 5 es auto-continue desactivado. Ponlo en .claude/settings.json o en cualquier archivo de ajustes. La clave workflowSizeGuideline funciona en cualquier archivo de ajustes desde v2.1.219 s1.

settings.json

{
  "workflowSizeGuideline": "small",
  "ultracode": false,
  "autoContinueAtUsageLimit": false
}

settings.json on GitHub

Las líneas de entorno. Límites 2 y 3. Sustituye el marcador por el id completo del modelo en el que quieras ejecutar tus agentes de workflow.

ultracode-caps.sh

#!/usr/bin/env bash
# Source this file before you launch Claude Code: `source ultracode-caps.sh && claude`.
# These two lines are caps 2 and 3 of the five. Caps 1, 4 and 5 live in settings.json.

# Cap 2: at most 4 workflow agents run at once. The default is 16 (fewer on a machine
# with few CPUs). Accepted values are 1 to 256. Needs Claude Code v2.1.269 or later.
export CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS=4

# Cap 3: run every workflow agent on one cheaper model, while your other subagents
# keep theirs. Replace the placeholder with the full model id you want to pay for.
# Needs Claude Code v2.1.296 or later.
export CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL="<your-cheaper-model-id>"

# Optional kill switch for a shared machine: no workflows at all.
# export CLAUDE_CODE_DISABLE_WORKFLOWS=1

ultracode-caps.sh on GitHub

La checklist que recorres antes de escribir la palabra clave.

when-to-fan-out.md

# When to fan out: the two-condition checklist

Fan out (use the ultracode keyword in one prompt) only if both answers are yes.

1. Does a test suite or a rule set judge the output?
   - [ ] A suite that already exists and says pass or fail without anyone's opinion.
   - [ ] Or a written rule file the output is reviewed against.
2. Does the job split into independent pieces?
   - [ ] No piece waits on the result of another piece.
   - [ ] Each piece can be checked on its own.

If either answer is no, run plain at high effort. A plain run costs one bill. A
workflow costs one bill per agent.

Jobs that usually pass both tests:
- A port or migration across many files with a test suite as the judge.
- A review of a whole codebase against a rule file.
- A translation of many files with the same prompt.
- A cleanup pass over a pile of similar documents.

Jobs that usually fail one of them:
- A small feature, a bug fix, a refactor of one module.
- Anything where "good" is a matter of taste.
- A chain of steps where each one needs the previous result.

Before you start:
- [ ] Run a slice first (one folder, ten files) and read the token total.
- [ ] Put a budget in the prompt, for example "use 10k tokens".
- [ ] Open /workflows and watch per-agent tokens. Press x to stop.
- [ ] After the run, open /usage and read the share that went to workflows.

when-to-fan-out.md on GitHub

Los pares y casos medidos de las fuentes, una fila cada uno, con el id de la fuente.

paired-runs.csv

source_id,run,measure,baseline,workflow_or_fanout,note
s22,rebuild-your-claude-md pair (rep 2),tokens,181646,1326703,"all four usage fields summed, 14 agent transcripts on the workflow side"
s22,rebuild-your-claude-md pair (rep 2),API cost in USD,0.2678,1.3744,single agent vs workflow
s22,rebuild-your-claude-md pair (rep 2),wall time in seconds,43,80,single agent vs workflow
s22,rebuild-your-claude-md pair (rep 2),session meter points,+0,+12,"/usage before to after: 17% to 17% vs 19% to 31%"
s24,70 planted bugs in 116k lines,bugs found,"14, 15 and 27 (3 runs)","66 in each of 3 runs","Managed Agents, not Claude Code; no cost given"
s19,Bun port from Zig to Rust,test suite passing,,100%,"about 50 dynamic workflows, 11 days, 535,496 lines of Zig"
s6,fixed worker and gate files,tokens for workflow execution and monitoring,100%,about 20%,"self-reported, no plan stated; runs 5 to 6 hours down to 20 to 40 minutes"
s7,runaway run on Max 20x,agents started,,221,"51 minutes; 189 started after the first session-limit error; 47,465,299 tokens including cache"
s21,ultracode reported on without the user enabling it,agents started,,"56 and 104","1,472,855 and 1,752,360 tokens; 92 of 160 agents failed with the session limit"
s20,multi-agent research system,tokens vs a chat,about 4x for an agent,about 15x for multi-agent,Anthropic's own data
s3,same spec on a $200 plan,hidden checks passed,136/136,136/136,"both runs perfect"
s3,same spec on a $200 plan,time and 5-hour limit used,"25 min, 8%","76 min (cut off), 18%","12 agents in two teams (9 and 3)"
s4,Opus plan script,tokens,115k,972k,"Pro plan; /usage 4 vs 12 points; 173 s vs 178 s"
s4,compact script,tokens,52k,936k,"Pro plan; /usage 7 vs 12 points"
s4,Claude.md script,tokens,102k,683k,"Pro plan; /usage 4 vs 8 points"
s4,four independent research jobs,time and tokens,"102 s, about 33k","about 64 s, 76k","parallel 1.6x faster for 2.3x tokens"
s11,Cybercity,time and API cost,"1 h 13 m, about $18 (1 agent)","9 h 14 m, about $554 (40 subagents)","xhigh vs max with ultracode; one run each; API list prices"

paired-runs.csv on GitHub

Dos notas sobre el kit. La clave ultracode solo importa si de otro modo empezarías las sesiones con el interruptor activado, y mantenerla en false significa que cada fan-out es una decisión que tomas en un prompt. Desactivar los workflows por completo elimina la palabra clave y el interruptor: pon "disableWorkflows": true en ~/.claude/settings.json s1.

Haz esto el lunes

  • Copia settings.json en los ajustes de tu proyecto y comprueba que /config muestra la guía de tamaño como small.
  • Carga ultracode-caps.sh con source en el shell desde el que lanzas Claude Code, con un id de modelo real en lugar del marcador.
  • Comprueba que el interruptor de ultracode está apagado en /effort, y usa la palabra clave en un solo prompt cuando quieras un fan-out.
  • Antes de cualquier fan-out, responde las dos preguntas de when-to-fan-out.md. Si una respuesta es no, ejecuta normal en high.
  • Ejecuta primero una porción y lee el total de tokens en /workflows antes de ampliar el trabajo.
  • Añade un presupuesto al prompt, por ejemplo "use 10k tokens".
  • Mantén /workflows abierto en la primera ejecución y pulsa x si el número de agentes sube más de lo que esperabas.
  • Después de la ejecución, abre /usage y anota la parte que fue a workflows.

Ir más lejos

Fija el worker y la puerta en vez de dejar que el modelo los escriba. Un post de Hacker News cuenta que bajó el gasto de tokens en la ejecución y supervisión de workflows a cerca del 20 % de lo que era, con workflows que tardaban de 5 a 6 horas y ahora tardan de 20 a 40 minutos. Es autorreportado y no indica el plan s6. El método tiene dos partes. Un archivo de agente workflow-worker recibe una pieza del plan y permisos ajustados para escribir y ejecutar tests solo de su parte. Un archivo de agente workflow-gate toma los resultados de los agentes paralelos, y las comprobaciones en serie pasan a un Makefile con dos objetivos: make workflow-serial-gate revisa el árbol de git y ejecuta los tests de lo que cambió, y make workflow-final-gate ejecuta tests limpios sobre todo s6. La comprobación de la puerta que antes tardaba 10 minutos en planes complejos ahora tarda un segundo, según el mismo post. El 20 % cubre ejecución y supervisión, no la creación del plan ni la implementación. Para probarlo, escribe los dos archivos de agente una vez, guárdalos en el repo y apunta tu prompt de workflow a ellos.

Lee el reporte de la ejecución descontrolada antes de fiarte de un script generado. El issue muestra una tabla por fase y el único patrón detrás de los 189 agentes extra: cuando un agente de merge no devuelve nada, el script recurre a la lista en bruto y sigue s7. Pide al modelo scripts que se detengan ante un agente fallido. Mantén auto-continue desactivado en cualquier ejecución que no vigiles.

Entiende por qué pierde la guía. El issue 92631 muestra el texto de la guía junto a la frase de ultracode, y por qué gana la segunda cuando no coinciden s8. Si quieres un techo duro, la variable de concurrencia limita cuántos agentes corren a la vez, y el presupuesto en el prompt limita lo que gastan.

Usa el hilo de lanzamiento para los trabajos amplios. La réplica más afilada del primer día está en el hilo de lanzamiento, con comentarios como "an exciting new way to burn up as many tokens as possible" y "Quantity of output is not the issue right now. Quality is." s9. Las victorias que la gente reporta ahí comparten una forma: revisión contra un archivo de reglas, traducción de un código base, limpieza de páginas escaneadas.

Managed Agents es otro producto. La prueba de los 70 bugs usó workflows dinámicos de Managed Agents, que son solo de API. Si construyes sobre la API, empieza con una tarea acotada, como aconseja Anthropic s24. Los ajustes de Claude Code no se trasladan.

De qué no fiarse. Las anécdotas de cuota sin plan ni cifra son de segunda mano. Un comentarista cuenta que 6 agentes se comieron una cuota de 4 horas, y otro cuenta un port de casi 2.000 millones de tokens que costó 20 $ en el modelo barato de otro proveedor a través de su propio clon s23 s9. Ninguno es una medición de Claude Code en un plan. Una cifra solo merece entrar en tus notas cuando viene con el plan, el modelo, la versión y la tarea.

FAQ

¿Cuesta lo mismo la palabra clave que el interruptor? No. La palabra clave ejecuta una tarea como workflow. El interruptor planifica un workflow para cada tarea sustancial, así que una petición puede convertirse en varios s1. Los dos gastan además de tu conversación, porque cada agente envía sus propias peticiones s5.

¿Poner la guía de tamaño en small limita una ejecución a 4 agentes? No. Es un consejo enviado al modelo, y un prompt o la frase de ultracode pueden anularlo s1 s8. En nuestra ejecución decía menos de 5 y la ejecución usó 9. Los límites duros son la variable de concurrencia y tu propia parada.

¿Qué pasa cuando una ejecución llega a mi límite de uso? Con autoContinueAtUsageLimit activado, una sesión interactiva de claude.ai pausa la ejecución y continúa en el reinicio, hasta dos esperas, desde v2.1.271. Las versiones anteriores hacen fallar a los agentes afectados s1. Con él desactivado, los agentes fallan en el límite y la ejecución termina ahí.

¿Por qué un modelo más barato para los agentes del workflow? La mayor parte de un workflow es comprobar, y cada agente envía sus propias peticiones. CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL pone todos los agentes del workflow en un modelo y deja en paz a tus otros subagentes s18. Comprueba el resultado en una porción antes de fiarte.

¿Puedo seguir usando ultracode? Sí, para trabajos que pasen las dos preguntas de la checklist. El port de Bun tenía una suite de tests completa como juez s19. Para una función pequeña o un arreglo de bug, una ejecución normal en high es lo predeterminado.

Archivos