For those of you who asked what the research paper was about, here is my simple view.
As I kept building small AI projects, one thing kept bothering me: We treat AI models like magic boxes. We send a prompt in, something comes out, and if it sounds good, we move on. But when we start using multiple models together — which is where most serious systems are heading — it becomes unclear who did what, when we overspent compute, and whether we escalated to a bigger model because we had to or because we didn't measure properly.
I kept asking myself why the ChatGPTs and Claudes don't show that information. I wondered how much enterprises know when they sign up for these LLM providers.
That question became ACAR: Adaptive Complexity & Attribution Routing.
The Core Problem
What I built is simple in spirit. I didn't want AI systems to default to maximum complexity. I wanted them to measure uncertainty first, escalate intentionally, and leave behind a decision trace that anyone could inspect. This mattered to me, because I could not afford the $100 and $200 unlimited plans. If I spent $20, I want to know I spent only what was needed.
The League of Legends Analogy
Using the online game League of Legends as an analogy — you don't have five players doing the same thing. You have distinct roles. Some farm gold. Some support. And then there's the jungler who moves across the map, watching for imbalance, showing up at the right time to tilt a fight. And then there's your Ult — your ultimate ability — which you don't use constantly, but only when it matters. It's expensive and impactful.
I wanted to treat multi-model systems the same way. Instead of using them like five carriers in the same lane, what if I gave them each a role?
- Smaller models handle routine work
- Retrieval (the Jungler) injects context only when uncertainty rises
- The largest, most expensive model (the Ult) is invoked only when the situation genuinely requires escalation
And more importantly — I had to prove these escalations were justified.
Building the Interface
So I built a frontend to see the system's thinking and rank the LLMs based on usage, accuracy, and cost. There were services like LLM Arena and Routerbench, but I wanted to start with simple tests.
When I open ACAR's interface, it feels like instrumentation. I type a prompt. I choose how I want it executed. Then I watch:
- Which model steps first
- How much text it processes
- How much it costs
- How long it takes
- Whether the system is confident
If it's unsure, I can see it escalate to the bigger, more powerful Ult model. If it needs outside knowledge, I can see the Jungler retrieval component quietly step in and help. And when everything is done, I don't just get an answer — I get a clear, replayable record of why the system made the decisions it did. This way, I can see it, and therefore I can improve it.
What the Experiments Showed
I ran thousands of test executions. I compared single-model baselines against multi-model arenas. I tested adaptive routing with and without retrieval. I removed components deliberately to see if performance degraded in ways that made sense. I ran leave-one-out validation to check whether attribution signals actually matched real marginal contribution.
Some of my early assumptions didn't hold up. That was humbling. Attribution is harder than it looks. It's easy to think a model "helped" just because it produced output. It's much harder to measure whether it truly improved the final result. So I redesigned parts of the evaluation pipeline until the results were falsifiable and reproducible.
What I observed:
Single models were efficient but fragile on harder tasks. Static ensembles improved quality but wasted cost. Adaptive routing found better cost-quality tradeoffs. Asynchronous retrieval (the Jungler) improved quality without unnecessarily slowing everything down. Escalation gating (the Ult logic) reduced unnecessary compute while preserving quality thresholds.
But more than the metrics, what mattered to me was this: the system behaved like a coordinated team instead of a pile of APIs.
What ACAR Is Really About
At its core, ACAR is about building measured, auditable, and intentional AI systems that understand uncertainty, escalate intentionally, and leave behind auditable decision traces. It's an attempt at treating AI systems like engineered platforms rather than prompt experiments.
Hope this helps anyone reading it come up with more interesting ideas. I'm very curious about applying different game strategies to Multi-LLM Orchestration experiments, or even historical military strategies. Hopefully soon!
A special thanks to my lifetime mentors, Michele Telgen and Atishe Chordia, who instilled in me that anything worth building should be scalable with observability, and that decisions matter enough to be recorded — and to my dear professor Dr. Okenwa Okoli, PhD CEng CSci FIMMM who taught me the scientific rigor of publishing a paper. That mindset is what led me to dig into this research effort.
Resources