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

Hola, bienvenido. En esta lección cerramos la sección de dynamic workflows hablando de dinero, después de guardar en la lección anterior audit-endpoints como comando del proyecto y enseñarle a recibir datos con args. 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.

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 de planes, 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 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. De cada ajuste te indico la versión mínima cuando la documentación la da.

Cada agente de un workflow es un subagente, y como vimos en la lección de subagentes, 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 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 de ventana de contexto y compactación 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.