Cuánto cuesta un workflow de Claude Code y cómo controlarlo

Hola, bienvenido. En la lección anterior guardamos audit-endpoints como comando del proyecto y le enseñamos a recibir datos con args, y con esta lección cerramos la sección de dynamic workflows hablando de dinero. Vamos a ver de dónde sale el gasto de un workflow, cómo lo mide Claude Code, cómo probar un workflow en pequeño antes de soltarlo sobre todo el proyecto, qué es el aviso de workflow grande, qué modelo usa cada agente, qué pasa con ultracode y con los límites de tu plan, y cómo desactivar los workflows si no los quieres.

¿Por qué una lección entera para esto? Porque un workflow no tiene una factura propia: cuenta para el uso y los límites de tu plan como cualquier otra sesión, pero puede gastar bastante más tokens que hacer la misma tarea en la conversación, porque lanza muchos agentes y cada uno trabaja con su propio contexto. Con una suscripción, eso se traduce en llegar antes al límite de la sesión o al semanal, como vimos en la lección Planes de Claude Code: Pro, Max o pago por uso con la API, y con la API, en pagar esos tokens. Así que la decisión de gasto hay que tomarla antes de lanzar, cuando todavía puedes cambiar el tamaño del workflow.

Para seguir esta lección necesitas claude-tasks con el commit de la lección anterior, el workflow audit-endpoints guardado en .claude/workflows/ y una sesión de Claude Code en la raíz del proyecto. Todo lo que veremos es de la 2.1.283, la versión del curso, y te indico la versión mínima de cada ajuste cuando la documentación la da.

Cada agente de un workflow es un subagente, y como vimos en la lección Qué son los subagentes de Claude Code y cuándo usarlos, cada subagente hace sus propias peticiones al modelo, además de las de tu conversación. En la página de costes, la documentación pone los subagentes y los workflows en la lista de motivos por los que el uso de una sesión se dispara más de lo que parece. Para verlo en tus números tienes /usage: en Pro, Max, Team y Enterprise, su desglose de atribución reparte el uso reciente entre skills, subagentes, plugins y servidores MCP, y ahí aparece la parte que se llevan los subagentes.

La caché de prompts ayuda, pero con matices. Los agentes de una misma ejecución pueden leer la caché de otros: si 2 agentes trabajan con el mismo modelo, el mismo nivel de effort, el mismo tipo de agente, las mismas herramientas, el mismo esquema de salida y la misma carpeta de trabajo, construyen el mismo prefijo, y el que arranca después lee la caché del primero. Para aprovecharlo, cuando un reparto lanza varios agentes iguales a la vez, Claude Code retiene a todos menos al primero hasta que empieza su respuesta, y después los suelta juntos. Esa espera tiene un tope de 5 segundos por defecto, que desde la versión 2.1.229 se cambia con la variable CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS, y con 0 la desactivas.

La otra cara es la duración. En la lección Ventana de contexto y compactación en Claude Code vimos que, con una suscripción, la caché de la conversación principal dura 1 hora. La de los agentes de un workflow no entra en esa cuenta y dura 5 minutos por defecto, también con suscripción. Si quieres que dure 1 hora, desde la versión 2.1.242 tienes el ajuste subagentPromptCacheTtl con el valor "1h", que se aplica a los subagentes, a los workflows y a las peticiones auxiliares de Claude Code, como la compactación, sabiendo que la API cobra más cara la escritura en la caché de 1 hora.