The automation world gets to the next era with the CodeZero's no-code platform. From end-to-end automation to scalable backend endpoints in no-time.
© 2026 Code0 UG (haftungsbeschränkt)
The automation world gets to the next era with the CodeZero's no-code platform. From end-to-end automation to scalable backend endpoints in no-time.
© 2026 Code0 UG (haftungsbeschränkt)
Your tasks are not equally hard, but a single-model setup prices them as if they were. cadtopo routes each one to the cheapest agent that can actually solve it. In our benchmark that meant the same 100% pass rate as claude-opus-4.8 for $0.001376 instead of $0.28128 per task. Open source under MIT.
Almost every team building agentic AI today follows the same recipe: pick the strongest model the budget allows, send every single task to it, and then watch the monthly invoice climb faster than the product does. It is an understandable approach, because frontier models really are excellent and the integration is a single API call, but it quietly rests on an assumption that nobody ever checks, namely that all of your tasks are equally difficult. They are not, and once you stop pretending otherwise, the economics of running agents change completely.
We built a framework that takes advantage of exactly this. It is called cadtopo, it is open source under the MIT license, and on the HumanEval benchmark it matched claude-opus-4.8 precisely: the same 100% pass rate, at $0.001376 per task instead of $0.28128, which works out to 204 times cheaper for output that is indistinguishable in quality. You can find it at github.com/code0-tech/cadtopo.
Cost per task on HumanEval. Both configurations pass 164 of 164 problems, so the only thing that differs is the invoice. The bars are true to scale.
It helps to think concretely about what your agents actually spend their day doing, whether that is support ticket triage, document extraction, code review, data enrichment, classification or research summaries. Every one of those workloads has the same underlying shape: a small number of genuinely hard cases that really do need everything a frontier model can offer, followed by a very long tail of routine cases that a far cheaper open model would handle perfectly well.
Flat routing prices both categories identically, so you end up paying frontier rates for the easy ninety percent of your traffic every single day, and that is where the overwhelming majority of your AI budget quietly disappears. Classifying a ticket as a password reset is simply not the same problem as diagnosing a subtle billing bug, and pulling a date off a clean invoice is not the same problem as reconciling a scanned, handwritten one, but your model bill has no way of telling the difference. cadtopo does.
Cadtopo is a cost-aware, dynamic-topology orchestration framework for multi-agent LLM systems. You hand it a pool of agents, which can mix cheap models, expensive models, narrow specialists and tool-equipped workers however you like, and it then decides on a per-task and per-round basis which of them actually need to run. Three mechanisms do the heavy lifting.
The first is that it filters before it spends anything. Every round opens with a local embedding pass that matches the current goal against each agent's stated skill, which involves no LLM call at all and is therefore effectively free, so agents that do not fit the task at hand never get invoked in the first place. There is no phase in which everyone is polled and most of the output is subsequently discarded, and avoiding that phase matters enormously, because it is precisely where conventional multi-agent systems bleed money.
The second is that there is no fixed pipeline. The selected agents run in parallel, each working on its own view of the task, and only afterwards does cadtopo construct the communication graph from what each agent reports it can offer and what it still needs. Information therefore flows to wherever it is genuinely useful rather than travelling down a chain that you hardcoded in advance, which means the topology is an output of the round rather than a configuration file you had to reason about beforehand.
The third, and the one that makes the numbers above possible, is that cost is treated as a first-class routing signal instead of an afterthought. Every routing decision weighs three factors together: how well an agent fits the current goal, how reliable it has proven itself to be, and how much it costs to call. Expensive models are never excluded from the pool, they simply have to earn the call.
Sitting above all of this is a manager agent that scores each round's best output for completeness and then decides whether the work is finished or whether one more focused round is warranted, so easy tasks stop after a single round while hard tasks receive exactly as many as they genuinely require. The underlying protocol builds on DyTopo, while the cost-aware routing layer on top of it is our own contribution.
A cost claim without a measurement behind it is just marketing, so we deliberately chose a benchmark that nobody could reasonably accuse us of tuning. HumanEval gives you 164 Python problems evaluated at pass@1 in a sandbox, and every result is a clean pass or fail with no room for interpretation. It is worth being explicit about one thing here: HumanEval is the measuring instrument rather than the point, because nothing in cadtopo's routing logic is specific to code, and we chose code generation purely because it produces an unambiguous number.
We ran five configurations against the same problems, with the same agent roles and the same evaluation harness, so that the only variable was which models sat in the pool.
All five configurations. Pass rate on the left, cost per task on a log axis on the right, because the values span two and a half decades.
Three results are worth dwelling on.
An open 120B model running under cadtopo solved the benchmark completely, and not merely almost as well as the alternative: it achieved exactly the same score as claude-opus-4.8 at roughly half a percent of the cost. Scaled to a hundred thousand tasks, that is the difference between a bill of $137.60 and a bill of $28,128, which is no longer a line item you optimise but a decision about whether the feature is viable at all.
The same benchmark projected over volume. The green line is not flat, it rises by a fraction of a pixel per ten thousand tasks.
Note also what the first row rules out. Simply picking the cheapest model is not the answer either, because llama-3.1-8b-instruct on its own is the cheapest configuration we tested and it fails roughly half of all tasks. The saving does not come from being cheap, it comes from being selective.
This is the result we did not expect. Dropping claude-opus-4.8 into the pool alongside gpt-oss-120b did not push the per-task cost up, it pulled it down by 3.4%, from $0.001424 to $0.001376, while the pass rate stayed at 100%. The router reached for the expensive model rarely enough that its price never really surfaced, and having a genuinely strong option available meant the system converged in fewer rounds on the tasks where the cheaper model would otherwise have kept grinding.
Both pools pass 100%. The axis starts at zero and both bars share it, so the 3.4% difference is shown at its true size.
That is the whole argument compressed into a single observation. You do not have to choose between an approach that is cheap but risky and one that is safe but expensive, because you can simply put both models in the pool and let the routing decide: routine work then runs at open model prices, while the genuinely hard cases pull in the frontier model automatically. Your quality ceiling is Opus, and your bill is gpt-oss, and in our run it was slightly less than gpt-oss.
The second row is the uncomfortable one, and we are publishing it anyway. Introducing llama-3.1-8b-instruct into a pool that already contained gpt-oss-120b made the system both less accurate, at 84% rather than 100%, and simultaneously more expensive, at $0.001508 rather than $0.001424. The reason is that weak agents do not fail cleanly and quietly; they produce plausible-looking output that costs tokens to generate and then costs further tokens to review, so anyone selling you the idea that stacking more agents reliably improves results has not actually measured it.
There are two limits worth stating plainly. If your workload happens to be genuinely uniform in difficulty, then there is very little for a router to exploit and your savings will shrink accordingly, because steep difficulty curves are what pay off here and flat ones do not. Beyond that, HumanEval is what we have measured so far, and broader benchmarks covering other task types are next on our list; we will publish those numbers in exactly the same way, including any that happen to make us look bad.
Cadtopo is available on GitHub under the MIT license, which means you can clone it, read through the routing code, run the HumanEval example, fork it and ship it in a commercial product without any strings attached, no contributor license agreement and no open core bait and switch waiting for you three releases later. Issues and pull requests are very welcome at github.com/code0-tech/cadtopo.
If you would rather not write orchestration code at all, the same capability is on its way to the CodeZero Flow Builder as visual nodes, where you will be able to drag models into a pool, describe in plain language what each of them is good at, set your cost preference with a slider rather than a weight vector, and let the router take care of everything else, with no prompt chaining spaghetti and no hand-written retry fallbacks to maintain.
