LangChain’s coding-agent spend was climbing because every thread, however small, went to GPT-6 Astra. So they built a router into the agent’s harness: read the thread’s first human message, pick one of three tiers — GLM-5.3-Flash in the cheap lane, GPT-5.6 Sol in the middle, Astra only when the request looks heavy. Across 973 live threads split in half (every number below is from their writeup; I didn’t rerun any of it), routed threads merged PRs at 29.2% against 27.3% for always-Astra, p=0.49: no quality difference their metric could find. Median cost fell from $2.61 to $0.94, and the router sent only a tenth of threads to the frontier tier.
The part worth more than the headline is the experiment the post spends three sentences on. They also ran the router against the opposite control — every thread on the cheap model — and ended that arm within a day, because the engineers using it flagged the output quality almost immediately. Neither fact needs a router to learn, though LangChain learned them with one already built. The frontier baseline wastes in a way the quality metric never mentions: an arm paying a $2.61 median per thread and an arm paying $0.94 merged at the same rate, so the overspend surfaces only when a person reads a trace — which is where feedback like “pretty expensive for this query” came from. The cheap baseline fails in the work itself, and the people doing the work say so within a day. The 973-thread A/B bought the hard half of the knowledge: that on this task mix, stepping off the frontier tier cost nothing measurable. The other half was available from some annoyed engineers at any time.
What a router harvests is the spread between tiers on your own traffic. Theirs was a 30× range in median cost per thread — $0.097 on fast, $1.50 on balanced, $2.88 on performance — and the routed arm’s outcomes held level with always-Astra in aggregate. The post doesn’t break merge rates out per tier, so whether each tier individually holds the line is an inference from that aggregate, not a reported number. The flatness, such as it is, is a property of the task mix rather than the models, which is why their first step was a week of reading traces and classifying threads before picking the tiers. It’s the same variance probe the harness-economics argument runs one layer down: measure what models actually do on your tasks before building machinery on top, whether the machinery is a harness or a tier picker.
Their placement claim — routing belongs in the harness because the harness has task context a gateway lacks — mostly reduces to something less architectural: the tier criteria are written from your traces, and the middleware they released takes those criteria as input. The routing intelligence ships empty, and it gets written by whoever knows the tasks, wherever the selection runs. A gateway would work fine the moment you hand it the same local analysis; the work is the analysis, not the address of the decision.
The naive design held up anyway. The router picks once, from the first message, and their own example of a question that turns into a bug fix is the known hole in that. A one-shot pick still cut the median bill by 64%, though the aggregate can’t say how much of that is the classifier reading requests well and how much is most threads being cheap however you label them. What the numbers do establish is the usable part: nine of ten routed threads ran on the mid or cheap tiers, and the routed arm as a whole merged at the control’s rate.