Sua carga de trabalho
—Total de thread único
—Fan-out total
—poupança
Custo total por contagem de tarefas (N)
Todo o resto mantido em suas entradas acima foi varrido por N. Observe onde o espalhamento ultrapassa o thread único.
| Tarefas (N) | Thread único | Fan-out | Mais barato |
|---|
Como funciona esta calculadora
UM única conversa acumulada lidar com N tarefas reenvia seu histórico completo a cada turno: a entrada da tarefa i é contexto base + (i-1) × tokens de saída anteriores. Somado em N tarefas, esse termo histórico cresce como N × (N-1) / 2 — quadrático em N — mesmo que o trabalho de cada tarefa seja idêntico em tamanho. Distribuição para subagentes isolados fornece a cada tarefa um novo contexto: contexto base + tarefa, além de um prompt fixo de despacho do orquestrador para iniciá-la e a saída do subagente lida como entrada do orquestrador. Essa sobrecarga é por tarefa, não cumulativa, portanto, as escalas totais da distribuição linearmente em N, mais uma etapa final de síntese.
Nos padrões (20 tarefas, 4.000 tokens de contexto base, 1.200 tokens de saída/tarefa, envio de 300 tokens, preços de classe Sonnet), o termo histórico de thread único sozinho adiciona aproximadamente 19 × 20/2 = 190 blocos extras de "saída anterior" de 1.200 tokens para entrada de tarefas posteriores - um custo que o thread único paga que a distribuição simplesmente nunca acumula. N pequeno favorece o thread único, pois evita a sobrecarga de envio/ingestão; a tabela de varredura mostra exatamente onde está o cruzamento da sua carga de trabalho.
Perguntas frequentes
Por que uma única conversa longa fica mais cara por tarefa?
Como a maioria das APIs de conclusão de bate-papo não tem estado, cada turno reenvia o histórico completo da conversa como tokens de entrada. A tarefa 1 envia apenas o contexto base. A tarefa 20 envia o contexto base mais a saída das tarefas 1 a 19. Esse termo histórico cresce com cada tarefa, portanto, o total de tokens de entrada em N tarefas é dimensionado como N*(N-1)/2 — quadrático em N — mesmo que o trabalho de cada tarefa individual seja do mesmo tamanho.
Por que a distribuição para subagentes isolados evita esse crescimento?
Cada subagente obtém uma nova janela de contexto — seu próprio contexto base mais sua tarefa, nada das outras tarefas N-1. O orquestrador paga apenas por um breve prompt de despacho para iniciar cada subagente e um breve resumo para ler cada resultado. Essa sobrecarga é fixa por tarefa, portanto, o custo total é dimensionado linearmente com N em vez de quadraticamente. A desvantagem é a própria sobrecarga de envio/ingestão do orquestrador, e é por isso que a distribuição não é automaticamente mais barata em N muito pequenos.
Em que contagem de tarefas o fan-out começa a vencer?
Depende de quão grande é a sua saída por tarefa em relação à sobrecarga de despacho/ingestão do orquestrador - saídas maiores tornam o termo do histórico de thread único mais rápido, puxando o ponto de cruzamento para um N menor. Use a tabela de varredura abaixo com seu próprio contexto base, tamanho de saída e sobrecarga do orquestrador para encontrar seu cruzamento exato em vez de confiar em uma regra prática.
Isso se aplica aos subagentes do Claude Code, LangGraph ou CrewAI da mesma maneira?
A matemática subjacente é a mesma para qualquer estrutura em que um orquestrador despacha trabalhadores de contexto isolado e coleta resultados curtos de volta – subagentes do Código Claude, subgráficos LangGraph, equipes CrewAI ou um loop de distribuição manual. O que difere entre as estruturas é a sobrecarga exata de envio e ingestão por subagente, e é por isso que essas entradas são separadas aqui, em vez de codificadas.