Tu carga de trabajo
—Total de un solo hilo
—Total de distribución
—ahorros
Costo total por recuento de tareas (N)
Todo lo demás retenido en sus entradas anteriores, se extendió por N. Observe dónde el despliegue supera al hilo único.
| Tareas (N) | Hilo único | Distribución en abanico | Más económico |
|---|
Cómo funciona esta calculadora
A única conversación acumulada manejar N tareas reenvía su historial completo en cada turno: la entrada de la tarea i es contexto base + (i-1) × tokens de salida anteriores. Sumado en N tareas, ese término histórico crece como norte × (norte-1) / 2 - cuadrático en N - aunque el trabajo propio de cada tarea es idéntico en tamaño. Distribución a subagentes aislados brinda a cada tarea un contexto nuevo: contexto base + tarea, además de un mensaje de envío fijo del orquestador para iniciarla y la salida del subagente leída como entrada del orquestador. Esa sobrecarga es por tarea, no acumulativa, por lo que el total de distribución aumenta linealmente en N, más un paso de síntesis final.
En los valores predeterminados (20 tareas, 4000 tokens de contexto base, 1200 tokens de salida/tarea, envío de 300 tokens, precios de clase Sonnet), el término de historial de un solo subproceso por sí solo agrega aproximadamente 19 × 20/2 = 190 bloques adicionales de "salida anterior" de 1200 tokens a la entrada de tareas posteriores: un costo que paga un solo subproceso y que la distribución simplemente nunca se acumula. La N pequeña favorece el subproceso único ya que evita la sobrecarga de envío/ingesta; la tabla de barrido muestra exactamente dónde se encuentra el cruce de su carga de trabajo.
Preguntas frecuentes
¿Por qué una sola conversación larga se vuelve más costosa por tarea a medida que avanza?
Debido a que la mayoría de las API de finalización de chat no tienen estado: cada turno reenvía el historial de conversación completo como tokens de entrada. La tarea 1 envía solo el contexto base. La tarea 20 envía el contexto base más el resultado de las tareas 1-19. Ese término histórico crece con cada tarea, por lo que los tokens de entrada totales en N tareas escalan como N*(N-1)/2 (cuadrático en N), aunque el trabajo de cada tarea individual sea del mismo tamaño.
¿Por qué la distribución hacia subagentes aislados evita ese crecimiento?
Cada subagente obtiene una nueva ventana de contexto: su propio contexto base más su tarea, nada de las otras tareas N-1. El orquestador solo paga por un breve mensaje de envío para iniciar cada subagente y un breve resumen para leer cada resultado. Esos gastos generales se fijan por tarea, por lo que el costo total aumenta linealmente con N en lugar de cuadráticamente. La compensación es la sobrecarga de envío/ingesta del orquestador en sí, razón por la cual la distribución en abanico no es automáticamente más barata con un N muy pequeño.
¿A partir de qué recuento de tareas comienza a ganar el fan-out?
Depende de qué tan grande sea su salida por tarea en relación con la sobrecarga de envío/ingesta del orquestador: las salidas más grandes hacen que el término histórico de un solo subproceso aumente más rápido, reduciendo el punto de cruce a una N más pequeña. Utilice la tabla de barrido a continuación con su propio contexto base, tamaño de salida y sobrecarga del orquestador para encontrar su cruce exacto en lugar de depender de una regla general.
¿Esto se aplica de la misma manera a los subagentes de Claude Code, LangGraph o CrewAI?
Las matemáticas subyacentes son las mismas para cualquier marco en el que un orquestador envía trabajadores de contexto aislado y recopila resultados breves: subagentes de Claude Code, subgrafos de LangGraph, equipos de CrewAI o un bucle de despliegue manual. Lo que difiere entre los marcos es la sobrecarga exacta de envío e ingesta por subagente, razón por la cual aquí se trata de entradas separadas en lugar de codificadas.