Workflow multiagente
- Modelo
- Opus 5 (main + 36 subagentes) · 1 Haiku
- Requests
- 914
- Tokens leídos de caché
- 80,9 M
56 min
duración
~78 %
de la ventana de 5 h
$89
coste API equivalente
01
El problema
Sentry es el servicio que recoge los fallos de una aplicación en producción. En el equipo de una app móvil, cada semana rotan dos personas al mantenimiento, y parte de su trabajo es revisar los errores nuevos que llegan ahí.
Mantener Sentry limpio es un horror. Los falsos positivos son enormes, hay mucho ruido y los errores se repiten con cada subida. Nadie quiere estar pendiente, así que muchos errores se ignoran sin saber la causa. Un ejemplo: un fallo que solo pasaba en móviles con poca RAM disponible y temperatura alta. A mano nunca lo habrían encontrado.
La idea fue que cada mañana un workflow coja los errores nuevos, decida cuáles merecen la pena y deje el análisis hecho para que alguien lo desarrolle. La primera versión, sobre Opus 4.8, consumía el 30 % de la ventana de cinco horas en cada ejecución y casi todo acababa en "verificación humana". Se paró por coste, y dos semanas después se midió esto.
02
Las dos vías
Vía A · Workflow multiagente con Opus 5
Una skill lanza el triaje. Por debajo, un workflow con tres piezas:
- Analizador. Recoge los errores nuevos. Es un agente Haiku que solo ejecuta un script determinista (el workflow necesita un agente para lanzar el script, así que se usa el más barato).
- Buscador de causa raíz. Analiza cada error y busca por qué pasa, siguiendo las migas de pan del fallo por el código.
- Verificador adversario. No se cree nada de lo que dice el anterior, va en contra y le obliga a repensar. Hacen bucle hasta tres veces. Si no llegan a conclusión, marca el error como "needs-human".
La ejecución tiene un límite de maxIssues=15. En la medición: agente principal en Opus 5, 36 subagentes y un Haiku.
Vía B · Una sesión inline con Fable 5
Sin workflow. Una sola sesión de Claude Code con Fable 5 en effort medium, sin subagentes. El modelo va fichero a fichero y se guarda lo que lee en su propio contexto, en vez de delegar en subagentes.
03
Cómo se midió
Mismo lote de issues de Sentry: los últimos 14 días, con nivel error y fatal. Misma mañana, una ejecución de cada vía, primero el workflow y después la sesión inline.
Cuota. Sale de quota-snapshots.jsonl, el registro de la ventana de cinco horas del plan de Claude Code, antes y después de cada ejecución.
Coste. Es el equivalente a precio de API (cache write ×1,25, cache read ×0,1), no lo facturado en el plan por asiento. Sirve para comparar las dos vías, no para saber lo que se pagó.
Una muestra es una muestra. Queda pendiente repetir la medida más de una mañana antes de darlo por definitivo.
04
Consumo
Sesión inline
- Modelo
- Fable 5, effort medium
- Requests
- 26
- Tokens leídos de caché
- 1,97 M
20 min
trabajo efectivo (31 de sesión)
~5 %
de la ventana de 5 h
$5
coste API equivalente
Barras a la misma escala dentro de cada fila.
05
Cobertura y resultado
Cuántas issues se triaron, en qué acabó cada una y cuánto coinciden las dos vías.
Workflow · Opus 515/20issues triadas · 4 recortadas por maxIssues=15, 1 no entró en el lote del workflow
- Accionable2
- Resuelto en release previa0
- No accionable1
- Needs-human12
- Sin triar5
Inline · Fable 520/20issues triadas · sin recorte
- Accionable4
- Resuelto en release previa6
- No accionable9
- Needs-human1
- Sin triar0
3/15
issues triadas con el mismo veredicto en ambas sesiones
6
issues resueltas en una release previa que Fable detectó y el workflow no (~1.640 eventos)
06
Conclusión
Veredicto del experimento
Para triaje, la sesión inline con Fable produjo un resultado más completo (20/20 frente a 15/20), más accionable (3 tareas concretas más 6 "no hacer nada" con evidencia de release) y con menos falsos positivos, en un tercio del tiempo y una quinceava parte de la cuota.
Lo que cambia la lectura
El coste por token engaña. La cuenta real es tokens totales hasta llegar a la conclusión. 36 subagentes releyendo contexto (80,9 M de caché) valen más que un modelo que va fichero a fichero y se lo guarda.
La arquitectura también es coste. El workflow multiagente se diseñó para compensar las limitaciones del modelo (verificador adversario, bucles de tres intentos). Con un modelo que razona encadenado, ese andamiaje sobra y encima lo empeora: 12 de 15 acabaron en "needs-human".
Muchas rondas baratas salen más caras que una cara. La regla de "cuándo compensa el modelo potente" ya no es hipótesis, tiene dato. Sigue pendiente repetir la medida más de una mañana.
07
Términos
| Accionable | El triaje encontró la causa y deja una tarea concreta para desarrollar. |
|---|---|
| No accionable | Ruido, repetición o fallo sin arreglo posible desde el código. Se archiva. |
| Needs-human | El agente no llegó a conclusión y pide que una persona lo revise. |
| Resuelto en release previa | El fallo dejó de aparecer a partir de una release ya publicada. No hay nada que hacer. |
| Ventana de 5 horas | Cuota de uso del plan de Claude Code. Se rellena cada cinco horas y se mide en porcentaje consumido. |
| Coste equivalente API | Lo que habrían costado los mismos tokens a precio de API, con caché incluida. No es lo facturado en el plan. |