How this calculator works
Each of the four architectures is priced from the same shared tokens per loop figure, so the only thing that changes cost between them is the SHAPE of the workflow, not the per-step price. ReAct is the single-agent baseline: reactLoops × tokensPerLoop — one agent, one loop, done when it's done. Tree-of-thought multiplies that same per-loop cost by both branching factor and depth — branching × depth × tokensPerLoop — because exploring 3 branches at 3 levels of depth means running roughly 9 loops' worth of reasoning instead of one. Multi-agent debate runs every debating agent for its own rounds — agents × rounds × tokensPerLoop — then adds the tokens the judge has to read: every agent's final answer plus the judge's own reasoning, agents × answerTokens + judgeTokens.
Planner/orchestrator is the most involved: the orchestrator spends its own planning tokens up front, then spawns a number of subagents, each of which runs its OWN full internal loop in isolation — subagents × subagentLoops × tokensPerLoop — and each of which reports back only a compressed summary that the orchestrator reads, subagents × summaryTokens. The orchestrator's own context stays small because it only ever sees the summaries, not the subagents' full traces — but the total SYSTEM-WIDE token spend, which is what actually gets billed across every model call in the pipeline, still includes every token each subagent generated internally. A lean orchestrator does not mean a cheap system: it means the expensive part moved out of the orchestrator's context window and into a set of parallel subagent loops that are billed just the same. Every architecture's cost is totalTokens / 1,000,000 × pricePerMillion, and each non-ReAct pattern's multiplier is simply its total tokens divided by the ReAct baseline's total tokens.
Frequently asked questions
Why does the "smart" planner/orchestrator pattern end up costing more than a single ReAct agent in this calculator?
Because the orchestrator being lean and the system being cheap are two different things. In the planner/worker pattern, the central orchestrator only reads back a compressed summary from each subagent — a few hundred tokens — which makes the orchestrator's OWN context small and keeps it far below any context-window ceiling. But every one of those subagents still runs its own full internal loop of think-act-observe steps to actually get its piece of the task done, and every one of those loop tokens gets generated and billed somewhere, even though the orchestrator never sees them directly. With 3 subagents each running 4 loops at 3,000 tokens per loop, that is 36,000 tokens of subagent work happening off to the side, plus the orchestrator's own planning tokens and the summaries coming back — system-wide spend that a single ReAct agent doing 5 loops of the same task never has to pay, because there is only one loop running, not one orchestrator loop plus three parallel subagent loops.
Is tree-of-thought or multi-agent debate ever worth the extra cost?
Yes, but the case for paying the multiplier has to rest on something other than raw token cost, because on tokens alone both patterns lose to a single ReAct loop every time. Tree-of-thought earns its 1.8x (or worse, at higher branching or depth) when a task has a genuinely large solution space where premature commitment to one reasoning path is likely to produce a wrong answer that then has to be redone from scratch — the extra branches are insurance against a much more expensive retry, not a free upgrade. Multi-agent debate earns its cost when a single model's own self-consistency is the actual risk, such as high-stakes classification or adversarial review, where having independent agents reach answers separately and then be judged catches errors a solo pass would miss. If the task is well within a single agent's reliable range, neither pattern is worth its multiplier — you are paying for insurance you don't need.
Does prompt caching change which architecture is cheapest?
It shrinks all four costs by roughly the same proportion without reordering them, because caching discounts repeated input-token prefixes (system prompts, tool schemas, shared context) and every one of these four patterns still needs those prefixes resent on every loop, branch, agent turn or subagent step. ReAct's 5 loops each partly benefit from caching the repeated prefix, and so do tree-of-thought's branches, debate's per-agent rounds, and each planner subagent's internal loops — the discount applies roughly evenly across the board rather than favoring one pattern's shape over another. What caching does not do is change the underlying loop-count arithmetic: a planner spawning 3 subagents that each run 4 loops is still generating far more total generated (output) tokens than a single 5-loop ReAct agent, and output tokens are typically not eligible for the cached-input discount at all, so the architecture-pattern ranking in this calculator holds regardless of your caching setup.
How is this different from the agent loop budget calculator and the AI agent framework cost calculator already on this site?
All three price agent token spend but at different layers of the same stack. The agent loop budget calculator prices a SINGLE agent's own loop-iteration budget — given a per-loop token cost and a spending ceiling, how many think-act-observe turns can that one agent afford before you have to cut it off — it never compares across architectures, only across how many turns one agent gets. The AI agent framework cost calculator compares the tooling and infrastructure overhead of running a given agent workload on different frameworks, such as CrewAI versus LangGraph versus a custom loop — the same architecture pattern, priced under different plumbing. This calculator sits one layer up from both: it holds the framework and the per-loop cost constant and instead compares four different ARCHITECTURAL PATTERNS for solving the same task — single-agent ReAct, tree-of-thought branching, multi-agent debate, and planner/orchestrator with isolated subagents — to show that the pattern you pick multiplies your token spend before framework choice or loop budgeting ever enters the picture.