A builder wired forty Claude Haiku workers into one Claude Sonnet report-writer, watched the bill land on the wrong line item, and fixed it with thirty lines of Python
A post went round this week from a builder running a fan-out research pipeline: forty parallel Claude Haiku workers, each taking a narrow slice of one question, all feeding one Claude Sonnet call that writes the final report. Forty cheap calls, one strong call to close. Sounds efficient. Everyone budgets it that way.
Then he counted. Raw combined output landing on Sonnet: 41,200 tokens. Fifteen of the forty findings were near-duplicates. Six were malformed. Sonnet’s first job on every run wasn’t reasoning; it was janitorial. In his own words, he’d built a research pipeline and shipped the expensive model a data-cleaning job wearing a research pipeline’s clothes.
The fix was one deterministic function, no model in it. Same forty workers, same Sonnet: 5,300 tokens in, cost per run from $1.38 to $0.19, latency from 51 seconds to 11, and, the part he didn’t expect, 23 contradictions between workers surfaced that the raw dump had buried.
I want to give the post its due, because it’s the rare viral engineering thread with a runnable function and honest caveats. And then, in my usual manner, I want to argue with the word multi-agent, because the interesting thing here isn’t agentic at all.
Everyone budgets the workers. Nobody budgets the reader.
The insight in one line: in a fan-out pipeline, the expensive layer is not the fan. It’s the funnel. Forty Haiku calls cost pennies; the model that has to read all forty outputs is billed on input, and input is where the growth is. Add workers for coverage and you’re not scaling the cheap layer, you’re silently scaling the bill of the one call nobody put in the spreadsheet.
There’s a second cost that isn’t tokens, and the post cites the right paper for it. Liu and colleagues’ Lost in the Middle found that models retrieve information well from the start and end of a long prompt and significantly worse from the middle, even on long-context models. Dump forty unordered findings into one prompt and you haven’t just inflated the bill; you’ve filed most of the evidence in exactly the region the reader is worst at.
Which reframes the whole thing. The reducer isn’t primarily saving money. It’s moving the evidence out of the model’s blind spot and telling it, in advance, which claims agree and which collide.
The function, and why the surprising part is the important part
The reducer does four things, none needing a model: drop entries missing a claim, evidence, or source; group the rest by a normalized claim; keep the highest-confidence version of each group; and, when several workers independently landed on the same claim, say so, append “confirmed by N other workers,” because agreement is a signal the synthesis model should be handed, not something it should have to rediscover by reading forty documents back to back.
The surprise: grouping doesn’t only dedupe, it exposes disagreement. Two workers asserting contradictory values for the same fact become visible the moment you group instead of concatenate, because a contradiction on page one and page thirty-three of a wall of text is not something a model reliably catches by reading forward.
Twenty-three contradictions across the sample runs, found by a defaultdict. That’s the sentence to keep. Structured reduction isn’t a cost optimization with a correctness bonus; it’s a place to put a check that plain concatenation has no way to run. And the escalation number confirms it: runs kicked to a human for ambiguity dropped from six in fifty to one in fifty, because the ambiguity was being surfaced upstream instead of smeared across the prompt.
Where I’d argue with a word: this isn’t a multi-agent lesson
Here’s the friendly quibble. The post frames itself as advice for people “scaling a multi-agent pipeline.” But strip the model names and look at the shape: many cheap parallel workers emit key-value-ish records, a deterministic step groups by key and reduces, one expensive step consumes the result. You have reinvented MapReduce. Google published it in 2004. That’s a compliment, not a dunk: the reason MapReduce mattered was precisely that the middle box, the shuffle-and-reduce, was code, and code is where you put the things that must be exact and cheap.
Faithful readers will recognize the rule from my graph-engineering piece: nodes are model, edges are code. Judgment at the ends of the pipeline, where the workers interpret sources and Sonnet writes; plumbing in the middle, where nothing needs to be smart. What made this pipeline expensive was that a piece of plumbing had been handed to the most expensive node in the graph. The fix wasn’t a smarter model or a cheaper worker. It was taking work away from Sonnet.
The industry name-cycles I keep writing about make this easy to miss. “Multi-agent,” “orchestration,” “swarm”: the vocabulary implies every problem in the system is an agent problem, so people reach for another model call. Most of the problems in a fan-out system are the same ones a 2004 data engineer had: dedupe, validate, group, sort. Not one of them wants a language model in the loop.
The guards, and the bug he told on himself
Four guards, all code: malformed entries dropped and logged, not silently absorbed; disagreements flagged and passed to synthesis explicitly; singleton groups passed through with no false confidence added; an empty input returns empty and skips synthesis instead of running Sonnet on nothing. That last one is small and I love it, because “the expensive model ran on an empty list” is a real bill I have seen on a real invoice.
And then the honest bit, which is why I trust the rest: normalize() is a similarity match on claim text and its false-merge rate is untested. Two genuinely different claims that happen to phrase alike could be collapsed into one, a correctness bug hiding behind a cost win. He says he wants more runs before trusting it on anything he can’t spot-check. Good. I’d add one more caveat he doesn’t mention: “confirmed by three other workers” is only evidence of truth if the workers are independent. If four Haiku workers all read the same upstream blog post, you have one source wearing four hats, and the reducer has just upgraded a rumour to consensus. Group by claim, yes; but also count distinct sources behind each group, and don’t let the confirmation tag fire on a single URL.
Steal this
If more than one worker feeds one final model, put a reducer between them before you touch the prompt. Measure token count into the synthesis call before you optimize anything else; it’s usually the whole cost story. Treat agreement and disagreement between workers as data the reducer surfaces, not noise the model rediscovers. And keep the boundary clean: dedupe, drop, group, and sort are code problems; reasoning about what’s left is the model’s job. Don’t let one bleed into the other.
Forty workers were never the expensive part. The reader was. Which is a very 2026 way of learning a very 2004 lesson: the cheap machines can fan out as wide as you like, as long as something boring and exact stands between them and whoever has to make sense of it.
-Hardik
I’ve spent about two decades building data systems, a good chunk of it writing reducers before anyone called the map step an “agent.” I write about AI’s mechanics, its hype cycles, and the number of times a new vocabulary rediscovers an old pipeline. Subscribe; my synthesis step is one human, and I’d like fewer tokens landing on him.
Sources / further reading: The original breakdown, posted on X and Telegram by its author, including the reduce_findings() function, the per-run numbers (41,200 → 5,300 tokens; $1.38 → $0.19; 51 s → 11 s; 23 contradictions; 6/50 → 1/50 escalations) and the untested-normalize() caveat; all figures are his, from his sample runs. Nelson Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023; TACL 2024). Jeffrey Dean and Sanjay Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters” (OSDI 2004). My earlier piece on graph engineering for the “edges are code, nodes are model” rule. The independence caveat on the confirmation tag is mine.