Multi-agentオーケストレーション：5つのパターンと、単一agentが勝つとき

ポルトガルの会社が請求書FT-2026-0918について問い合わせてきます。メールにはVATが間違っているようだと書かれており、請求書が添付されています。net EUR 248.00、VATは21%でEUR 52.08、total EUR 300.08です。

回答に必要な事実は3か所にあり、そのうちメールに含まれているのは1つだけです。

3つを合わせると、請求書は誤りです。reverse chargeが適用され、VATはゼロであるべきで、EUR 52.08のcredit noteが必要です。請求書だけを見ると算術的には完璧です — 248.00に52.08を足すと300.08です — そしてあなたはそう答えてしまいます。

メールには「私たちはポルトガルの会社です」とは書かれています。それは主張であって、recordではありません。billing systemは主張だけでcredit noteを発行しません。この罠はひっかけではありません。意思決定に、誰も取得しようと思わなかった事実が必要になるという、ビジネス業務の普通の形です。

上記はすべて、Chapter 23のものと同じスタイルのscripted providerに対して実行されます。ルールは1つだけです。

An answer may only use a fact that is in its prompt.

「model」は、自分が持つ各ツールをcatalogue順に1回ずつ要求し、その後、見えているテキストに固定ルールを適用します。構成ごとにscriptを書き分けてはいないため、冒頭の表の差はmodelの知能についての主張ではありません。測定されたinformation routingです。実際のmodelは、その上に固有の失敗を追加します。それらを取り除くわけではありません。

以下の5つの名前はAnthropicのBuilding effective agentsから来ています。この語彙が定着した場所です。¹ 5つの考え方のどれも新しくはありません。どの陣営が何に名前を付けたのか、そしてどのアイデアがより古いのかを言えることが、それらを知る価値の半分です。

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

これがツールキット全体です。5つの関数、frameworkなし。そしてparallelなものは1行です — 図で描くのではなく書き出す意味はそこにあります。では、それぞれを順に、来歴、価格、そして間違うケースとともに見ていきます。

Prompt chainingは「タスクを一連のstepに分解し、各LLM callが前のcallのoutputを処理する」ものです。¹ このアイデアはlanguage modelより古く、pipelineです。pipelineの取引は、データが到着する前に固定されたcontrol flowと引き換えに得られる明快さです。

私たちのタスクでは4stepです。請求書のfieldを抽出し、算術を確認し、何が支払われるべきかを決め、返信を書く。ここでは2つの異なる形で失敗します。1回だけ失敗するより多くを教えてくれます。

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

relay chainの費用は$0.001940で、step 2とstep 3の間で請求書fieldを失いました。step 3に渡されたのが算術についての文だけで、他には何もなかったからです。それは保留メッセージを生成しました。役に立たず、見た目にも役に立たないものです。

accumulating chain — 冒頭の表の行 — の費用は$0.003780でした。4つの同一callに対して95%増です。なぜなら各stepが、それ以前のすべてを持つようになったからです。それは危険なoutputを生成しました。流暢で、自分の算術を引用し、言及するすべての数字について正しく、そしてEUR 52.08が支払われるべきなのに、何も支払われないと顧客に伝えるものです。

この2つの違いは1つのternaryです。持ち運ぶ情報が少ないchainは、明らかに不完全な回答を生成します。すべてを持ち運ぶchainは、自信に満ちて間違った回答を生成します — そして送信されるのは後者だけです。

どちらも本当の失敗ではありません。本当の失敗は、このpipelineが何かを読む前に、このタスクはメールの内容に対する4stepだと決めてしまったことです。その構造のどこにも「登録国はこのメールにない。取りに行け」と言う場所がありません。Chainingが正しいのは、分解が事前に分かっていて安定しているときです。ここではそれは推測で、その推測が出荷されました。

Routingは「inputを分類し、専門化されたfollowup taskへ向ける」ものです。¹ 名前は新しいですが、仕組みはdispatcherで、この本のほとんどすべてより古いものです。新しいのはclassifierがmodelになり得ることです — だからこそ、switchでは起こらなかった形で失敗します。

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

最後のargumentについて2点あります。これはerror handlingではありません。patternそのものです。model-based routerにはdispatcherにないfailure modeがあります。存在しないlabelを返す、time outする、あるいは — 高くつくものですが — それが間違っているというsignalなしに、もっともらしい誤labelを返すことです。3つともどこかに着地させる必要があり、そのどこかを別のmodel callにすることはできません。すでにmodel callが失敗したbranchにいるからです。

2点目は、router自身のpromptも無料ではないということです。modelを選ぶためには、routerは選択肢となるmodelのcatalogueを必要とします。そしてその中のすべてのentryは、routerがuserの質問を読む前に支払うinputです。このコースが価格計算に使うinput rateでは、約3,800 tokensのcatalogueだけで、冒頭の表にある5回のcallからなるagent run全体と同じコストになります。実際には、routing callは安いmodelで実行されます。それこそがroutingが元を取れる理由のすべてです。しかし、そう仮定するのではなく、その方向で算術をしてみる価値があります。routingが間違っているのは、まさにroutingされるtaskがrouting decisionより安いときです。

Anthropicはこれを2つに分けています。sectioning — 「タスクを独立したsubtaskに分解してparallelに実行する」 — と、voting — 「多様なoutputを得るために同じタスクを複数回実行する」です。¹ 2つは同じ図を共有していますが、それ以外はほとんど共有していません。

Sectioningは安価な勝ち筋であり、patterns.tsからの1行です。billing、tax、policyの3人のspecialistが、それぞれ自分のwindowとツールを持ち、同じメールを処理し、最後に1回だけsynthesis callを行います。同一の作業を2通りの順序で並べます。

token単位で同じで、1.8倍速い。だからこのpatternには独自の名前が与えられます。5つのうち、何の追加コストもなく何かを改善する唯一のものだからです。落とし穴は、sectionが本当に独立していなければならないことです。section Bにsection Aが生成する事実を与えると、Promise.allは存在しないstateに対して両方を実行します。for loopはそのbugを隠しました。1行版はそれを露出させます。

Votingは、同じ絵をまとった別の生き物です。同じ質問をk回実行して多数派を取ることはself-consistencyです。Wangらが2022年3月にdecoding strategyとして発表しており、誰かがそれをorchestration patternと呼ぶほぼ3年前のことです。abstractは仕組みについて正確です — 「greedyなものだけを取るのではなく、多様なreasoning pathの集合をまずsampleし、その後sampleされたreasoning pathを周辺化して最も一貫したanswerを選ぶ」 — そしてgainについても正確です。GSM8Kで+17.9 points。²

この図が隠していることが2つ続きます。第一に、votingにはChapter 17のsamplingが必要です。temperature zeroではk個のsampleはすべて同じsampleであり、多数派とはk回分の料金を払った1つのanswerです。第二に、これは多数派に意味がある場所でしか機能しません。上の請求書返信では数えるものがありません。5つのdraftは5つの異なる文だからです。Votingは短く比較可能なanswerを持つタスクのためのものです。それはまさにWangのbenchmarkであり、customer-facing agentが行うことのほとんどではありません。

ここでは、判断ではなく計算されるanswerを持つ20個の3step word problemに対して測定しました。Chapter 23のlocal modelにstep by stepでreasoningさせています。

callは5倍、tokenは5倍、請求額は正確に5倍、そして正答は1つも増えませんでした。 Votingは改善ではなく賭けであり、このrunは負けました。

それをWangへの反証として引用される前に、2つの注意があります。20試行では45%と60%を区別できません — intervalは主張の幅そのものであり、これはChapter 4の規律を自分の結果に向けたものです。そして発表されたgainは桁違いに大きなmodelから来ています。そこではvotingが周辺化する多様なreasoning pathが実際に多様です。移転するのは数値ではありません。multiplierは正確で事前に分かる一方、gainはそうではないということです。

orchestrator-workers workflowでは「中央のLLMがタスクを動的に分解し、worker LLMに委任し、その結果を統合する」もので、sectioningとの違いは「subtaskが事前定義されておらず、orchestratorによって決められる」ことです。¹ ここでの来歴はlanguage modelからではまったくありません。これはmaster-workerであり、workerがfindingを共有スペースに書き込み、それをcontrollerが読む版は、1970年代のspeech understanding研究に由来するblackboard architectureです。2026年に新しいのはcontrollerがmodelであること、したがって分解をinputごとに決められることです — 柔軟性とコストが1文に入っています。

単一agentの5callに対し、12model callがかかりました。そして同じ結論に到達しました。その後、詳しく見る価値のあることをしました。

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

どちらも正しいです。なぜそうなのかを知っているのは片方だけです。tax workerは自分のwindowに請求書、order、tax tableを持ち、結論に到達し、さらに — 誰も頼んでいないのに — 請求書のpurchase order numberがorderのものと一致しないことにも気づきました。そしてsummaryを返しました。orchestratorはその両方のstatementを繰り返すことはできますが、どちらも確認できません。evidenceはorchestratorが見たことのないwindowに残ったからです。これがChapter 24の最後の問いへの答えです。親が見られるのは、子が書き留めることを選んだものだけです。

修正はflagであり、価格があります。

input tokensは12%増、費用は8.3%増。そしてsource=worker_unverifiedというphraseがanswerから消えます。これはあらゆるmulti-agent systemにある取引で、ほとんど明示されません。子のclean windowには価値があり、親がそれをauditできる能力にも支払う価値があります。そしてその両方を無料で持つことはできません。

では、orchestrator-workersが間違うのはいつでしょうか。このタスクでは、ここです。同じ4つのツールを持つ1つのagentも到達したcorrect answerを、1.66倍のcostと2.3倍のwall clockで買い、さらにそのanswerをdefendしにくくしました。Anthropic自身のguidanceもpatternに入る前に同じことを言っています。「可能な限り最も単純なsolutionを見つけ、必要なときだけcomplexityを増す」べきであり、「agentic systems often trade latency and cost for better task performance」だからです。¹ 上の表は、その文に数字を付けたものです。

1つのcallが生成し、別のcallが評価し、evaluationがpassするまでloopが繰り返されます。¹ 公開された先祖はSelf-Refine — 同じmodelを「generator, refiner, and feedback provider」として使い、7つのタスク平均で絶対値約20 pointsの改善を報告しています³ — とReflexionです。Reflexionはcritiqueを試行間のepisodic bufferに保存し、baselineが80%だったHumanEvalで91% pass@1を報告しています。⁴

cost modelは5つのうち最も単純です。roundあたり2callで、round数はあなたのものではありません。 1callで済むタスクに3roundのrefinementをかけると6callです。したがってpatternのfloorは6×で、ceilingはあなたが設定したcap次第です。だからChapter 23のbudget exitは、きれいごとではなく必須になります。

ceilingはもう少し微妙で、測定できます。同じ20問でlocal modelは9問正解しました。その後、それぞれのanswerを見せ、それが正しいかを尋ねました — そのanswerが自分自身のものだとは伝えません。これによりお世辞のconfoundを取り除き、capabilityだけを残します。

これはsection titleが示すより良いjudgeです。そしてそれを言うことが、断定ではなく測定する意味です。正しいものを1つも止めず、11個のmistakeのうち8個を捕まえました。filterとしてはcallに値します。

しかしstopping ruleとしては — evaluator-optimiser loopが実際にそれを使う用途ですが — その3つの承認がすべてです。それらはwrong answerを手にした状態でloopを終わらせ、追加roundをいくら増やしてもそこには届きません。refinement loopはjudgeより正しくなることはできません。 roundをさらに買うことは、judgeが見えるerrorへのattemptをfull priceで買うことであり、judgeが見えないerrorには何も買っていません。

したがってruleはこれです。evaluatorがcallを稼ぐのは、generatorが持っていない何かを持つときだけです。 compiler、test suite、schema validator、別のmodel、人間。Self-Refine自身の結果はhuman preferenceとtask metricsに対して測定されており、model自身の意見に対してではありません。evaluatorの唯一の優位性が別のpromptであるなら、あなたは同意に倍額を払っています。Chapter 29では、本当に優位性のある版を作ります。答えが事前に書かれたgolden setです。

上の5つはあなたのcodeの形です。その下に、しばしば並べて列挙されるものの、本来はそうすべきでない第2のfamilyがあります。ReAct、Reflexion、plan-and-execute、tree of thoughtsはreasoning loopsであり、そのcostはrequestにあります。

Chapter 12はmodel内部のreasoningについてでした。あなたはそれに1callのoutput tokensとして支払います。こちらは別種です。請求が来るとき、この違いは重要です。長いchain of thoughtは1callを高くし、reasoning loopは1つのタスクを多くのcallに変えます。各callはそれ以前のすべてを再送します — Chapter 23がrunaway tableで測定したquadraticです。

tree-of-thoughtsのpaperは自分自身のcost tableを公開しています。これはもっと一般的であるべきですが、珍しいことです。GPT-4を使ったGame of 24では、input/output prompting best-of-100がcaseあたり$0.13で33%を解き、chain of thought best-of-100が$0.47で49%、tree of thoughtsが$0.74で74%を解きました。著者は、それが「CoTより5-100倍多いgenerated tokensを必要とする可能性がある」とも述べています。⁷

安い方法のほぼ6倍の価格で、success rateは2倍強です。それが得かどうかは、failed caseがあなたにいくらかかるかによります。この4つのどれかを採用する前に問うべき質問です。

このコースではそれらを再実装しません。4つすべてに、著者自身によるPythonのreference implementationがあります。そしてその価値は、translationではなくsourceであることです。ysymyth/ReAct、noahshinn/reflexion、princeton-nlp/tree-of-thought-llm、AGI-Edgerunners/Plan-and-Solve-Prompting。それらのrepositoryのpromptsを読んでください。promptsこそがpaperです。

ここからがmulti-agent properで、混乱の大半がここにあります。1つのagentが別のagentを関与させる方法は2つあります。それらはvariantではなく、違いはその後、誰が主導権を持つかです。

Agent as a tool. 親がそれを呼び出し、answerを受け取り、続行します。これはChapter 18のツールinterfaceで、その後ろにagent全体がいるものです。親はcontrolを失いません。上のorchestratorが行っているのはこれです。

Handoff. 親がconversationをtransferし、戻ってきません。OpenAIのguideが最も明確な公開statementです。handoffは「agentが別のagentへ委任できるone way transferである... agentがhandoff functionを呼び出した場合、最新のconversation stateもtransferしつつ、handoff先の新しいagentで直ちにexecutionを開始する」ものです。⁸

語彙に関する警告です。これは頻繁に人をつまずかせます。「handoff」は1つのSDKの言葉であり、standardではありません。 OpenAI Agents SDKとそのguideのterminologyです。そのguideは2つの構成を「manager」と「decentralized」と呼び、manager patternでは「edgeはtool callを表し、decentralized patternではedgeはhandoffを表す」とも述べています。⁸ この領域にはopen standardも存在します — A2Aです。version 1.0.0で、Linux Foundationのcopyrightの下にあり、versioned release historyとbreaking changesのdocumented listを持ちます。その掲げるprincipleはopaque executionです。agentsは「internal thoughts、plans、tool implementationsを共有する必要なく、declared capabilitiesとexchanged informationに基づいてcollaborateする」。⁹ これはhandoffではありません。この比較はChapter 26で扱うべきものです。ここで重要なのは、2つの言葉の一方はlibraryのAPIであり、もう一方はgovernanceを持つspecificationだということです。

違いはdiagramではなくdata structureです。

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

20行で、さもなければproductionで見つけることになる2つのbugです。reachableは誰も到達できないagentを見つけます — configuredで、paid forで、しかし決して呼ばれません。conflictsは、同時に両方の種類であるedgeを拒否します。口に出して読むまではpedanticに聞こえます。親はcontrolを保ち、同時にそれを手放す、ということになるからです。1つのorphanと1つのdouble edgeを持つ5-agent systemで実行します。

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

ここからが、このsectionが存在する理由である測定です。そしてこの章で唯一、scripted modelではなくreal modelに対して行ったものです。

顧客が最初のmessageでconstraintを述べます — 私たちのaccountはスペインではなくポルトガルで登録されている。tax関連はすべてポルトガルを使う必要がある — その後、別の話題でchatし、billingが答えるべき質問をします。caseはtransferされます。24試行、毎回異なる国と会社、4種類のtransfer payload。そして受信側のagentに1つだけ質問します。この顧客のaccountはどの国で登録されていますか。

3行目はcontrolであり、その通りに振る舞います。事実がそこにないので、recallできません。他の3つがfindingです。

full transcriptは173 tokensで、83%の確率で機能します。その4つのfailureはこの章ではなくChapter 24の主題です。typed recordは69 tokens — summaryより7つ多いだけ — で、毎回機能します。constraintが文ではなくnamed fieldに置かれているからです。

そして凝視すべきはsummaryの行です。24回中24回失敗しました。その理由はreaderが見落としたからではありません。constraintは24個のsummaryのうち1個にしかそもそも現れませんでした。 受信側agentは不注意ではありませんでした。答えを含まないテキストを渡されていたのです。summaryとは、あなたが書いていないcompactionであり、あなたには見えないwindowを持つmodelによって作られ、summaryらしく読めるようにoptimisedされたものです。そして「顧客は、当社のrecordが間違った国を持っていると言っている」は、summariserがprocedural noiseとして落とすまさにその種のclauseです。

その数値についての正直な限界です。summariserは5億parameter modelであり、より大きなmodelならより多くを保持するでしょう。sizeで改善しないのはriskの形です — 送信側agentが、handoffごと、phrasingごとに、観測不能な形で、どの事実が生き残るかを決めます。typed recordはその判断にまったく依存しません。だからintelligenceではなく構成上、勝ちます。transfer後も必ず生き残るべきものは、sentenceではなくfieldであるべきです。

同じreasoningは逆方向にも、agent-as-tool topologyにも適用されます。そして先ほどの表はすでに価格を示しています。workerから返るものもsummaryであり、evidenceも一緒に受け取るために8.3%多く払うのは、親側から見た同じ修正です。

締めくくりに3つの事実を示します。すべて上の表からです。

multi-agent systemはcallを倍増させ、callはcontextに対してquadraticです。 orchestratorは、1つのagentなら5回だったmodel callを12回行いました。各callは自分自身の増え続けるtranscriptを持ちます — input tokensは2,697に対して3,628で、この差はタスクが長くなるほど広がります。

すべてのboundaryはlossy channelです。 2つのagentは1つのsummaryを意味します。chain内の4つのagentは3つのsummaryを意味し、それらは合成され、それぞれがあなたのdecisionとは別のものをoptimiseするmodelによって書かれます。

単一agentは誰も頼んでいないものを見つけました。 purchase-orderの不一致が表面化したのは、1つのwindowが請求書とorderを同時に持っていたからです。workをspecialistに分けることは、2つの事実が食い違っていると気づく能力も分けることです。

これは公開されているmulti-agent frameworkへの反論ではありません。それらはtutorial越しではなくprimary sourceとして読む価値があります。¹⁰ これは、第2のagentに自分の場所を稼がせるべきだ、という主張です。

ですから、好みではなくtestです。第2のagentを追加するのは、少なくとも次のどれかが真のときです。sub-taskが親に継承させてはならないclean windowを必要とする（Chapter 24）。sub-taskが本当にindependentでwall clockが重要である、つまり上の1.8×。sub-taskがdifferent permissionsまたはdifferent modelを必要とする。これはChapter 30でsecurity argumentになります。あるいはsub-taskがowned by someone elseである。このとき本物のprotocolが重要になります。答えが「各agentのpromptをより明確にするため」なら、1つのagentにより明確なpromptを与えてください。それは無料です。

これで、5つのpatternに名前を付け、1つのタスクで互いに価格を比較し、orchestratorとsectioner、tool callとhandoffを見分け、好みではなく表で単一agentを擁護できるようになりました。

ここにあるすべての構成は、現実のものに触れた瞬間に消える便利さを共有していました。すべてのツールが私たちのものだったことです。請求書、order、tax table、orchestratorの後ろのworkers — 同じrepository、同じdeploy、同じtypes、同じ人々。

では、そのうち1つを会社のboundaryの向こう側に置いてください。tax tableはaccounting vendorのもの、order recordはwarehouse systemのものです。そしてどちらもあなたのTool interfaceを読んでいません。あなたが書いていないmodelが、誰か別の人が運用するcapabilityをdiscoverし、describeし、callする方法が必要です — authentication（これはChapter 27の半分です）、versioning、そしてserverがあなたのconversationの残りを読めないという保証を伴って。これはprotocol problemであり、normative schemaを持つspecificationがあります。そしてそれについてindexされているほとんどすべては、もはや存在しないrevisionを説明しています。

Chapter 26はそれを要約するのではなくspecificationを読み、terminalにJSON-RPCを手で打ち込むところから始めます。

上記のすべてのcostとtoken countは、第2sectionで説明したscripted providerから得ました。Node 22をloopback interface上で使い、o200k_base encodingで数え、Chapter 16が2026年9月6日に読んだ料金 — input tokens 100万あたり$2.00、output 100万あたり$12.00 — で価格付けしています。wall-clock figuresは同じrunからで、provider latencyをcallあたり400 ms、toolsを50 msに設定しているため、providerではなく構成を測っています。2つのreal-model measurements — handoff tableとvoting-and-judging table — は、同じ形のendpointの後ろにあるCPU上のfloat32のQwen/Qwen2.5-0.5B-Instructを使い、temperatureが示されている場合を除きgreedyで、intervalはChapter 4のWilson methodで計算しました。この章のrequestはpaid endpointには送られておらず、推定した数値もありません。