157 agent runs, 18 configurations, and the one variable nobody actually tested

The arithmetic worth doing first is the denominator. Three architectures, three planning depths and two execution models make eighteen configurations ^[3], so 157 runs spread across them averages about nine runs per configuration ^[12]. Split again by the four task domains and you are at roughly two runs per cell ^[13]. That is enough to notice a pattern. It is not enough to rank causes, which matters here because the headline finding leans on a variable that was never under test: the post names model size as the loser ^[2], while the three dimensions it says it varied were architecture, planning depth and execution model ^[3]. Two things that were varied get credited to a third thing that was not.

What the numbers do support is narrower and still useful. According to the author, configurations that spent three to five times more tokens before acting completed tasks 4.2 times more often and went through 3.8 times fewer rollback cycles than setups tuned for fast execution ^[4], and the direction held in every domain ^[5]. The rollback figure is the more interesting half, because a rollback is a discrete countable event, while a completion rate depends entirely on how you score partial work.

The mechanism described is not mysterious. The planner decomposes a goal into subtasks with explicit success criteria, executors return structured evidence of completion, and the planner validates before descending another level ^[9]; a lightweight controller triggers replanning when validation fails ^[6]; routing is done by matching subtasks against executor "skill cards" that state capabilities, constraints and preferred input and output formats, rather than guessing ^[8]. What the extra planning tokens buy is a cheap place to fail. A validation gate stops a wrong tool sequence at subtask two instead of surfacing it after integration testing.

The budget case is where the post runs out. It asserts the economic principle that planning is cheap relative to costly mistakes ^[10], then introduces token economics and supplies no figures in the text ^[11]. So the number that would settle the spending question, cost per completed task, is left for the reader to construct, and 4.2x arrives without the baseline completion rate that would turn it into a percentage ^[15].

Even so, the ordering argument survives on structure rather than on the multipliers. A planner tier is a change inside your own orchestration: one strong model holding global context and decomposition, cheaper specialist models doing the tactical work, a shared memory layer keeping state across the fleet ^[6]. The claimed payoff is running premium reasoning without paying premium rates on every action ^[7], plus retry logic aimed at the failed subtask instead of the whole workflow, and planning failures observable separately from execution failures ^[7]. A model upgrade, by contrast, raises the unit price of every call and tells you nothing about where your agents actually go wrong. This is one team's self-published account, originally posted on the author's own site ^[16], so treat the architecture as the transferable part and the multipliers as their local result.