Comment fonctionne cette calculatrice
UN conversation unique accumulée la gestion de N tâches renvoie son historique complet à chaque tour : l'entrée de la tâche i est contexte de base + (i-1) × jetons de sortie précédents. Résumé sur N tâches, ce terme historique grandit comme N × (N-1) / 2 — quadratique en N — même si le travail propre à chaque tâche est de taille identique. Distribution vers des sous-agents isolés donne à chaque tâche un nouveau contexte : contexte de base + tâche, plus une invite de répartition fixe de l'orchestrateur pour la lancer et la sortie du sous-agent relue en tant qu'entrée de l'orchestrateur. Cette surcharge est par tâche et non cumulative, donc la répartition totale s'étend linéairement en N, plus une étape finale de synthèse.
Aux valeurs par défaut (20 tâches, 4 000 jetons de contexte de base, 1 200 jetons de sortie/tâche, répartition de 300 jetons, tarification de classe Sonnet), le terme d'historique à thread unique ajoute à lui seul environ 19 × 20/2 = 190 blocs supplémentaires de « sortie précédente » de 1 200 jetons à l'entrée des tâches ultérieures - un coût payé par un seul thread qui ne s'accumule tout simplement jamais. Small N privilégie le thread unique car il évite la surcharge de répartition/ingestion ; le tableau de balayage montre exactement où se situe le croisement de votre charge de travail.
Questions fréquemment posées
Pourquoi une seule longue conversation devient-elle plus coûteuse par tâche au fur et à mesure ?
Étant donné que la plupart des API de discussion sont sans état, chaque tour renvoie l'historique complet de la conversation sous forme de jetons d'entrée. La tâche 1 envoie uniquement le contexte de base. La tâche 20 envoie le contexte de base ainsi que le résultat des tâches 1 à 19. Ce terme historique augmente avec chaque tâche, de sorte que le nombre total de jetons d'entrée sur N tâches évolue comme N*(N-1)/2 — quadratique en N — même si le travail de chaque tâche individuelle est de la même taille.
Pourquoi la diffusion vers des sous-agents isolés évite-t-elle cette croissance ?
Chaque sous-agent reçoit une nouvelle fenêtre de contexte : son propre contexte de base plus sa tâche, rien des autres tâches N-1. L'orchestrateur ne paie que pour une courte invite de répartition pour lancer chaque sous-agent et un bref résumé pour relire chaque résultat. Ces frais généraux sont fixes par tâche, de sorte que le coût total évolue linéairement avec N plutôt que quadratiquement. Le compromis est la surcharge de répartition/d'ingestion de l'orchestrateur elle-même, c'est pourquoi la distribution n'est pas automatiquement moins chère avec un très petit N.
À partir de quel nombre de tâches la distribution commence-t-elle à gagner ?
Cela dépend de la taille de votre sortie par tâche par rapport à la surcharge de répartition/d'ingestion de l'orchestrateur : des sorties plus grandes rendent la bulle de terme d'historique monothread plus rapide, ramenant le point de croisement vers un N plus petit. Utilisez le tableau de balayage ci-dessous avec votre propre contexte de base, taille de sortie et surcharge de l'orchestrateur pour trouver votre croisement exact au lieu de vous fier à une règle empirique.
Cela s'applique-t-il de la même manière aux sous-agents Claude Code, LangGraph ou CrewAI ?
Le calcul sous-jacent est le même pour tout framework dans lequel un orchestrateur envoie des travailleurs en contexte isolé et récupère de courts résultats : sous-agents Claude Code, sous-graphes LangGraph, équipes CrewAI ou boucle de diffusion manuelle. Ce qui diffère entre les frameworks, c'est la surcharge exacte de répartition et d'ingestion par sous-agent, c'est pourquoi il s'agit ici d'entrées distinctes plutôt que codées en dur.