Multi-agent-orkestrering: fem mönster och när ett vinner

Ett portugisiskt företag skriver in om faktura FT-2026-0918. Mejlet säger att momsen ser fel ut och bifogar fakturan: netto EUR 248.00, moms debiterad med 21 %, EUR 52.08, total EUR 300.08.

Fakta som behövs för att svara finns på tre platser, och bara en av dem finns i mejlet:

Lägg ihop de tre och fakturan är fel: reverse charge gäller, momsen borde ha varit noll, och en kreditnota på EUR 52.08 ska utfärdas. Titta bara på fakturan och den är matematiskt perfekt — 248.00 plus 52.08 är 300.08 — och du kommer att säga det.

Mejlet säger faktiskt ”vi är ett portugisiskt företag”. Det är ett påstående, inte en post, och inget faktureringssystem utfärdar en kreditnota på ett påstående. Fällan är inget trick: det är den vanliga formen på affärsarbete, där beslutet behöver ett faktum ingen tänkte på att hämta.

Allt ovan körs mot en scriptad provider i stil med Kapitel 23:s, med exakt en regel:

Ett svar får bara använda ett faktum som finns i dess prompt.

”Modellen” ber om varje verktyg den har, en gång, i katalogordning, och tillämpar sedan en fast regel på texten den kan se. Inget är scriptat per upplägg, så skillnaderna i öppningstabellen är inte påståenden om model intelligence: de är information routing, mätt. En riktig modell lägger sina egna fel ovanpå; den tar inte bort dessa.

De fem namnen nedan är Anthropics, från Building effective agents, vilket är där vokabulären landade.¹ Ingen av de fem idéerna är ny, och att säga vilket hus som namngav vad — och vilken idé som är äldre — är halva värdet av att känna till dem.

/* 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 };
}

Det är hela verktygslådan: fem funktioner, inget framework, och den parallella är en enda rad — vilket är poängen med att skriva ut den i stället för att rita den. Nu en i taget, med dess ursprung, dess pris och fallet där den har fel.

Prompt chaining ”decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one”.¹ Idén är äldre än språkmodeller: det är en pipeline, med pipelinens byte — tydlighet i utbyte mot ett control flow som är fixerat innan datan kommer fram.

Fyra steg för vår uppgift: extrahera fakturafälten, kontrollera aritmetiken, besluta vad som är skyldigt, skriv svaret. Här misslyckas den på två olika sätt, vilket lär mer än att misslyckas en gång.

--- 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-kedjan kostade $0.001940 och tappade fakturafälten mellan steg två och tre, eftersom steg tre fick en mening om aritmetik och inget annat. Den producerade ett avvaktande meddelande: värdelöst, och synligt värdelöst.

Den ackumulerande kedjan — raden i öppningstabellen — kostade $0.003780, vilket är 95 % mer för fyra identiska calls, eftersom varje steg nu bär med sig allt före det. Den producerade den farliga outputen. Flytande, med hänvisning till sin aritmetik, korrekt på varje siffra den nämner, och säger till en kund att inget är skyldigt när EUR 52.08 är skyldigt.

Skillnaden mellan de två är en ternary. En kedja som bär mindre producerar svar som uppenbart är ofullständiga; en kedja som bär allt producerar svar som är säkert fel — och bara den andra sorten skickas.

Inget av dem är det verkliga felet. Det verkliga felet är att pipelinen beslutade, innan den läst något, att den här uppgiften är fyra steg över innehållet i ett mejl. Ingenstans i den strukturen finns en plats att säga ”registreringslandet finns inte i det här mejlet; gå och hämta det”. Chaining är rätt när decomposition är känd i förväg och stabil. Här var den en gissning, och gissningen skickades.

Routing ”classifies an input and directs it to a specialized followup task”.¹ Namnet är nytt; mekanismen är dispatcher, äldre än nästan allt annat i den här boken. Det nya är att klassificeraren kan vara en modell — vilket är det som får den att misslyckas på sätt en switch aldrig gjorde.

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

Två saker om det sista argumentet. Det är inte error handling; det är mönstret. En model-based router har ett failure mode som en dispatcher inte har: den kan returnera en label som inte finns, time out, eller — den dyra — returnera en rimlig men felaktig label utan signal om att den är fel. Alla tre måste landa någonstans, och detta någonstans kan inte vara ännu ett model call, eftersom du redan är i grenen där model calls misslyckades.

Den andra saken är att routerns egen prompt inte är gratis. För att välja en modell behöver en router en katalog med modeller att välja mellan, och varje post i den är input som routern betalar för innan den har läst användarens fråga. Med det input-pris som den här kursen räknar med kostar en katalog på ungefär 3 800 tokens redan lika mycket som hela agentkörningen med fem anrop i inledningstabellen. I praktiken körs routing-anropet på en billig modell, vilket är hela anledningen till att routing betalar sig; men aritmetiken är värd att göra i den riktningen i stället för att anta. Routing är fel precis när den routade uppgiften är billigare än routingbeslutet.

Anthropic delar denna i två: sectioning — ”breaking a task into independent subtasks run in parallel” — och voting — ”running the same task multiple times to get diverse outputs”.¹ De delar diagram och delar nästan inget annat.

Sectioning är den billiga vinsten, och det är raden från patterns.ts: tre specialister — billing, tax, policy — var och en med sitt eget fönster och sina verktyg, över samma mejl, ett synthesis call i slutet. Identiskt arbete, ordnat på två sätt:

Samma token för token, 1,8 gånger snabbare. Det är därför mönstret förtjänar ett eget namn: det är det enda av de fem som förbättrar något utan att kosta något. Haken är att sektionerna måste vara genuint oberoende — ge sektion B ett faktum som sektion A producerar och Promise.all kör båda mot ett state som inte finns ännu. for-loopen dolde den buggen; enradaren avslöjar den.

Voting är ett annat djur i samma bild. Att köra samma fråga k gånger och ta majoriteten är self-consistency, publicerat av Wang et al. i mars 2022 som en decoding-strategi, nästan tre år innan någon kallade det ett orchestration pattern. Dess abstract är precist om mekanismen — ”first samples a diverse set of reasoning paths instead of only taking the greedy one, and then selects the most consistent answer by marginalizing out the sampled reasoning paths” — och om vinsten: +17,9 poäng på GSM8K.²

Två saker följer som bilden döljer. För det första kräver voting sampling från Kapitel 17: vid temperature zero är alla k samples samma sample, och majoriteten är ett svar betalt k gånger. För det andra fungerar det bara där en majoritet betyder något — på fakturasvaret ovan finns inget att räkna, eftersom fem utkast är fem olika meningar. Voting är för uppgifter med ett kort, jämförbart svar, vilket är exakt Wangs benchmarks och nästan inget en customer-facing agent gör.

Mätt här på 20 trestegs ordproblem vars svar beräknas snarare än bedöms, med den lokala modellen från Kapitel 23 som resonerar steg för steg:

Fem gånger calls, fem gånger tokens, exakt fem gånger notan, och inte ett enda ytterligare korrekt svar. Voting är en satsning, inte en förbättring, och den här körningen förlorade den.

Två förbehåll, innan någon citerar det som en vederläggning av Wang. Tjugo försök kan inte skilja 45 % från 60 % — intervallet är lika brett som påståendet, vilket är Kapitel 4:s disciplin vänd mot mitt eget resultat. Och de publicerade vinsterna kommer från modeller flera storleksordningar större, där de diverse reasoning paths som voting marginaliserar över faktiskt är diverse. Det som överförs är inte siffran: det är att multiplikatorn är exakt och känd i förväg medan vinsten inte är det.

I orchestrator-workers workflow ”a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results”, och skillnaden mot sectioning är att ”subtasks aren't pre-defined, but determined by the orchestrator”.¹ Ursprunget här är inte språkmodeller alls: detta är master-worker, och versionen där workers skriver fynd i ett delat utrymme som en controller läser är blackboard architecture, från forskning om talförståelse på 1970-talet. Det nya 2026 är att controllern är en modell och därför kan decomposition beslutas per input — vilket är flexibiliteten, och kostnaden, i en mening.

Det kostade 12 model calls jämfört med den enskilda agentens 5, och det nådde samma verdict. Sedan gjorde det något värt att titta noga på:

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

Båda är rätt. Bara en vet varför. Tax worker hade fakturan, ordern och skattetabellen i sitt eget fönster, drog slutsatsen, och märkte också — utan att någon frågade — att inköpsordernumret på fakturan inte matchar orderns. Sedan returnerade den en sammanfattning. Orchestrator kan upprepa båda påståendena och kontrollera inget av dem, eftersom bevisen stannade i ett fönster den aldrig såg. Det är Kapitel 24:s avslutande fråga, besvarad: parent får se vad child valde att skriva ned.

Lösningen är en flagga, och den har ett pris:

Tolv procent fler input tokens, 8,3 % mer pengar, och frasen source=worker_unverified försvinner från svaret. Det är bytet i varje multi-agent system och det sägs nästan aldrig: childens rena fönster är värt att ha, parentens möjlighet att auditera det är värd att betala för, och du kan inte få båda gratis.

Så när är orchestrator-workers fel? Här, på den här uppgiften. Det köpte ett korrekt svar som en agent med samma fyra verktyg också nådde, för 1,66 gånger kostnaden och 2,3 gånger wall clock, och gjorde svaret svårare att försvara. Anthropics egen vägledning säger samma sak innan mönstren börjar: hitta ”the simplest solution possible, and only increasing complexity when needed”, eftersom ”agentic systems often trade latency and cost for better task performance”.¹ Tabellerna ovan är den meningen med siffror under.

Ett call genererar, ett annat utvärderar, och loopen upprepas tills utvärderingen passerar.¹ De publicerade föregångarna är Self-Refine — samma modell som ”generator, refiner, and feedback provider”, med rapporterade cirka 20 poäng absolut förbättring i genomsnitt över sju uppgifter³ — och Reflexion, som lagrar kritiken i en episodic buffer över försök och rapporterar 91 % pass@1 på HumanEval där baseline nådde 80 %.⁴

Kostnadsmodellen är den enklaste av de fem: två calls per runda, och antal rundor är inte ditt. Tre rundor refinement på en uppgift som tog ett call är sex calls, så mönstrets golv är 6× och dess tak är vilken cap du än sätter — vilket gör budget exit från Kapitel 23 obligatorisk snarare än prydlig.

Taket är subtilare, och det är mätbart. På samma 20 problem svarade den lokala modellen rätt på 9. Sedan visades den vart och ett av dessa svar och fick frågan om det var rätt — utan att få veta att svaret var dess eget, vilket tar bort flattery-confound och lämnar capability one:

Det är en bättre domare än sektionsrubriken antyder, och att säga det är poängen med att mäta i stället för att påstå: den blockerade inget korrekt och fångade 8 av 11 misstag. Som filter är den värd sina calls.

Som stopping rule, vilket är vad en evaluator-optimiser-loop faktiskt använder den för, är de tre godkännandena hela berättelsen: de avslutar loopen med ett felaktigt svar i handen, och inga extra rundor når dem någonsin. En refinement-loop kan inte bli mer korrekt än sin domare. Att köpa fler rundor köper försök på de fel domaren kan se, till fullt pris, och ingenting alls mot dem den inte kan se.

Därav regeln: en evaluator förtjänar sina calls bara när den har något generatorn inte har. En compiler, en test suite, en schema validator, en annan modell, en människa. Self-Refines egna resultat mäts mot human preference och task metrics, aldrig mot modellens åsikt om sig själv. Om din evaluators enda fördel är en annan prompt betalar du dubbelt för enighet. Kapitel 29 bygger versionen med en verklig fördel: en golden set med svaren nedskrivna i förväg.

De fem ovan är former för din kod. Under dem finns en andra familj som ofta listas bredvid dem och inte borde göra det: ReAct, Reflexion, plan-and-execute och tree of thoughts är reasoning loops, och deras kostnad ligger i requests.

Kapitel 12 handlade om reasoning inne i modellen, som du betalar för i output tokens på ett call. Detta är den andra sorten. Skillnaden spelar roll när notan kommer: en längre chain of thought gör ett call dyrare, och en reasoning loop gör en uppgift till många calls, där vart och ett skickar om allt före sig — det kvadratiska Kapitel 23 mätte i sin runaway-tabell.

Tree-of-thoughts-artikeln publicerar sin egen kostnadstabell, vilket är mer sällsynt än det borde vara. På Game of 24 med GPT-4: input/output prompting best-of-100 löste 33 % för $0.13 per case, chain of thought best-of-100 löste 49 % för $0.47, och tree of thoughts löste 74 % för $0.74, där författarna noterar att det ”could require 5-100 times more generated tokens than CoT”.⁷

Nästan sex gånger den billiga metodens pris för lite mer än dubbla framgångsgraden. Om det är ett fynd beror på vad ett misslyckat case kostar dig — frågan att ställa innan du antar någon av dessa fyra.

Den här kursen reimplementerar dem inte. Alla fyra har reference implementations av sina egna författare, i Python, och deras värde är att vara källan snarare än en översättning: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm och AGI-Edgerunners/Plan-and-Solve-Prompting. Läs prompts i de repositorierna; prompts är artiklarna.

Nu multi-agent på riktigt, där det mesta av förvirringen bor. Det finns två sätt för en agent att involvera en annan, de är inte varianter, och skillnaden är vem som bestämmer efteråt.

Agent som verktyg. Parent anropar den, får ett svar och fortsätter. Det är Kapitel 18:s verktygsgränssnitt med en hel agent bakom det, och parent tappar aldrig kontrollen. Det är vad orchestrator ovan gör.

Handoff. Parent överför konversationen och får den inte tillbaka. OpenAI:s guide är det tydligaste publicerade uttalandet: handoffs är ”a one way transfer that allow an agent to delegate to another agent... If an agent calls a handoff function, we immediately start execution on that new agent that was handed off to while also transferring the latest conversation state.”⁸

En vokabulärvarning, eftersom detta ställer till det för folk hela tiden: ”handoff” är ett SDK:s ord, inte en standard. Det är terminologi från OpenAI Agents SDK och den guiden, som också kallar de två uppläggen ”manager” och ”decentralized” och noterar att i manager pattern ”edges represent tool calls whereas in the decentralized pattern, edges represent handoffs”.⁸ Det finns en öppen standard på det här området — A2A, i version 1.0.0, under Linux Foundations copyright, med versionerad release history och en dokumenterad lista över breaking changes, vars uttalade princip är opaque execution: agents ”collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations”.⁹ Det är inte en handoff, och jämförelsen hör hemma i Kapitel 26. Det som spelar roll här är att ett av de två orden är ett biblioteks API och det andra är en specifikation med governance.

Distinktionen är en datastruktur, inte ett diagram:

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;
}

Tjugo rader, två buggar du annars skulle hitta i produktion. reachable hittar agenten ingen kan nå — konfigurerad, betald, aldrig anropad. conflicts vägrar edge som är båda sorterna på en gång, vilket låter pedantiskt tills du läser det högt: parent både behåller kontrollen och ger bort den. Kör det på ett fem-agent-system med en orphan och en dubbel edge:

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

Nu mätningen den här sektionen finns för, och den enda i kapitlet som gjorts mot en riktig modell snarare än en scriptad.

En kund anger en constraint i sitt första meddelande — vårt konto är registrerat i Portugal, inte Spanien; allt som rör skatt måste använda Portugal — chattar om något annat, och ställer sedan en fråga billing måste svara på. Ärendet överförs. Tjugofyra försök, ett annat land och företag varje gång, fyra transfer payloads, och den mottagande agenten får sedan en fråga: i vilket land är kundens konto registrerat?

Den tredje raden är en control och beter sig som en: faktumet finns inte där, så det kan inte återkallas. De andra tre är fyndet.

Hela transcriptet är 173 tokens och fungerar 83 % av gångerna, med sina fyra misslyckanden som Kapitel 24:s ämne snarare än detta kapitels. Den typade posten är 69 tokens — sju fler än sammanfattningen — och fungerar varje gång, eftersom constraint ligger i ett namngivet fält i stället för i en mening.

Och sammanfattningen är raden att stirra på. Den misslyckades 24 gånger av 24, och orsaken är inte att läsaren missade den. Constraint förekom i bara 1 av de 24 sammanfattningarna över huvud taget. Den mottagande agenten var inte slarvig; den fick en text som inte innehöll svaret. En sammanfattning är en compaction du inte skrev, producerad av en modell vars fönster du inte kan se, optimerad för att läsas som en sammanfattning — och ”kunden säger att våra poster har fel land” är exakt den sorts bisats en summariser släpper som procedurbrus.

En ärlig gräns för den siffran: summariser är en modell med en halv miljard parametrar och en större skulle behålla mer. Det som inte förbättras med storlek är riskens form — den sändande agenten beslutar, per handoff, per formulering, osynligt, vilka fakta som överlever. Den typade posten beror inte på det omdömet alls, vilket är varför den vinner genom konstruktion snarare än intelligens. Vad som än måste överleva en transfer ska vara ett fält, inte en mening.

Samma resonemang gäller åt andra hållet, för agent-as-tool-topologin, och den tidigare tabellen har redan prissatt det: det som kommer tillbaka från en worker är också en sammanfattning, och att betala 8,3 % mer för att få bevisen med den är samma lösning sedd från parentens sida.

Tre avslutande fakta, alla från tabellerna ovan.

Ett multi-agent system multiplicerar calls, och calls är kvadratiska i context. Orchestrator gjorde 12 model calls där en agent gjorde 5, och varje bär sitt eget växande transcript — 3 628 input tokens mot 2 697, ett gap som växer med uppgiftens längd.

Varje gräns är en lossy channel. Två agents betyder en sammanfattning. Fyra agents i en kedja betyder tre, sammansatta, var och en skriven av en modell som optimerar för något annat än ditt beslut.

Den enskilda agenten hittade något ingen bad om. Mismatchen i purchase order dök upp eftersom ett fönster höll fakturan och ordern samtidigt. Att dela arbetet över specialister delar också förmågan att märka att två fakta motsäger varandra.

Inget av detta argumenterar mot de publicerade multi-agent frameworks, som är värda att läsa som primary sources snarare än genom tutorials.¹⁰ Det argumenterar för att låta den andra agenten förtjäna sin plats.

Alltså ett test snarare än en preferens. Lägg till en andra agent när minst ett av detta är sant: sub-task behöver ett rent fönster parent inte får ärva (Kapitel 24); sub-tasks är genuint oberoende och wall clock spelar roll, vilket är 1,8× ovan; sub-task behöver andra behörigheter eller en annan modell, vilket Kapitel 30 gör till ett säkerhetsargument; eller sub-task ägs av någon annan, vilket är där ett riktigt protokoll börjar spela roll. Om svaret är ”så att varje agent har en tydligare prompt”, ge den enda agenten en tydligare prompt. Det är gratis.

Du kan nu namnge de fem mönstren, prissätta dem mot varandra på en uppgift, skilja en orchestrator från en sectioner och ett tool call från en handoff, och försvara en enda agent med en tabell i stället för en preferens.

Alla upplägg här delade en bekvämlighet som inte överlever kontakt med något verkligt: alla verktyg tillhörde oss. Faktura, order, skattetabell, workers bakom orchestratorn — samma repository, samma deploy, samma typer, samma människor.

Lägg nu en av dem på andra sidan en företagsgräns. Skattetabellen tillhör en redovisningsleverantör, orderposten ett lagersystem, och ingen av dem har läst ditt Tool-gränssnitt. Du behöver ett sätt för en modell du inte skrev att upptäcka, beskriva och anropa en capability som någon annan driver — med authentication (vilket är Kapitel 27:s halva), versioning, och garantin att en server inte kan läsa resten av din konversation. Det är ett protokollproblem, det har en specifikation med ett normativt schema, och nästan allt som indexerats om det beskriver en revision som inte längre finns.

Kapitel 26 läser den specifikationen i stället för att sammanfatta den, och börjar med att skriva JSON-RPC i en terminal för hand.

Varje kostnad och token count ovan kom från den scriptade provider som beskrivs i den andra sektionen, på Node 22 över ett loopback-gränssnitt, räknat med o200k_base encoding och prissatt med priserna Kapitel 16 läste den 6 september 2026 — $2.00 per miljon input tokens och $12.00 per miljon output. Wall-clock-siffror kommer från samma körningar med providerns latency satt till 400 ms per call och verktyg till 50 ms, så de mäter upplägget snarare än någon provider. De två real-model-mätningarna — handoff-tabellen och voting-and-judging-tabellen — använde Qwen/Qwen2.5-0.5B-Instruct i float32 på CPU bakom en endpoint av samma form, greedy utom där en temperature anges, med intervall beräknade med Wilsons metod från Kapitel 4. Ingen request i det här kapitlet gick till en betald endpoint, och ingen siffra i det uppskattades.