この計算機の仕組み
あ 単一の蓄積された会話 N 個のタスクを処理すると、ターンごとに完全な履歴が再送信されます。タスク i の入力は次のとおりです。 基本コンテキスト + (i-1) × 以前の出力トークン。 N 個のタスクを合計すると、その歴史用語は次のようになります。 N×(N-1)/2 — N の 2 次 — 各タスク自体の作業のサイズが同じであっても。 分離されたサブエージェントへのファンアウト すべてのタスクに新しいコンテキスト (ベース コンテキスト + タスク) を与えます。さらに、それを起動するための固定オーケストレーター ディスパッチ プロンプトと、サブエージェントの出力がオーケストレーター入力として読み取られます。このオーバーヘッドは累積的ではなくタスクごとであるため、ファンアウトの合計はスケールされます。 直線的に N に、最終合成ステップが 1 つ加えられます。
デフォルト (タスク 20 個、基本コンテキスト トークン 4,000 個、タスクあたり 1,200 個の出力トークン、300 トークンのディスパッチ、Sonnet クラスの価格設定) では、シングルスレッドの履歴項だけで、後のタスクの入力におよそ 19×20/2 = 190 個の追加の 1,200 トークンの「前の出力」ブロックが追加されます。このコストはシングルスレッドが支払いますが、ファンアウトは決して蓄積されません。 N が小さいと、ディスパッチ/取り込みのオーバーヘッドが回避されるため、シングルスレッドが優先されます。スイープ テーブルは、ワークロードのクロスオーバーがどこにあるかを正確に示します。
よくある質問
1 つの長い会話が進むにつれてタスクあたりのコストが高くなるのはなぜですか?
ほとんどのチャット完了 API はステートレスであるため、すべてのターンで完全な会話履歴が入力トークンとして再送信されます。タスク 1 はベース コンテキストのみを送信します。タスク 20 は、基本コンテキストとタスク 1 ~ 19 の出力を送信します。この履歴項はタスクごとに増加するため、個々のタスク自体の作業サイズが同じであっても、N 個のタスクにわたる合計入力トークンは N*(N-1)/2 (N の 2 次) のようにスケールされます。
分離されたサブエージェントへのファンアウトによってその増加が回避されるのはなぜですか?
各サブエージェントは新しいコンテキスト ウィンドウを取得します。つまり、独自の基本コンテキストとその 1 つのタスクであり、他の N-1 個のタスクからは何も取得されません。オーケストレーターは、各サブエージェントを起動するための短いディスパッチ プロンプトと、各結果を読み戻すための短い概要に対してのみ料金を支払います。このオーバーヘッドはタスクごとに固定されるため、総コストは二次関数ではなく N に比例して増加します。トレードオフは、オーケストレーターのディスパッチ/取り込みのオーバーヘッド自体です。これが、非常に小さい N ではファンアウトが自動的に安くならない理由です。
ファンアウトはどのタスク数で勝ち始めますか?
それは、タスクごとの出力がオーケストレーターのディスパッチ/インジェスト オーバーヘッドと比較してどれだけ大きいかによって決まります。出力が大きいほど、シングル スレッドの履歴用語のバルーンが速くなり、クロスオーバー ポイントがより小さい N に引き下げられます。経験則に頼るのではなく、独自の基本コンテキスト、出力サイズ、オーケストレーター オーバーヘッドを使用して以下のスイープ テーブルを使用して、正確なクロスオーバーを見つけます。
これは、Claude Code サブエージェント、LangGraph、または CrewAI にも同じように適用されますか?
基礎となる計算は、オーケストレーターが分離コンテキスト ワーカーをディスパッチし、短い結果を収集するフレームワーク (Claude Code サブエージェント、LangGraph サブグラフ、CrewAI クルー、手動のファンアウト ループなど) で同じです。フレームワーク間で異なるのは、サブエージェントごとの正確なディスパッチと取り込みのオーバーヘッドです。そのため、ここではハードコード化されずに個別の入力となります。