Waltuh: The one who orchestrates

I got access to Claude Code for the first time since Opus 4.8 came out, but it came with one problem: insane token usage.

I couldn't help but wonder how I could make it better, both in terms of speed and tokens used. It felt wasteful watching Sonnet and Haiku just sit there in the /models directory while Opus 4.8 did all the heavy lifting, even for tasks that clearly didn't need the most capable model.

Naturally, I looked around to see if someone had already solved this problem. But at the time I got access to Claude Code, I couldn't find a tool that did what I had in mind: intelligently breaking down a coding problem, routing each task to the most appropriate model, executing those tasks based on their dependencies, and bringing everything back together as one coherent result.

Then all those System Design and DSA classes finally hit me with an idea. What if I treated models like compute resources and routed work based on the complexity of the task?

That's what led me to build Waltuh, a multi-agent orchestrator designed to divide work intelligently instead of throwing the most powerful and expensive model at everything. Opus 4.8 acts as the orchestrator. Given a problem statement, it reasons about the implementation, creates a structured execution plan, and breaks the problem down into smaller tasks. Haiku then examines those tasks and decides which model is best suited for each one. Opus handles the problems that genuinely require deeper reasoning, Sonnet takes on moderately complex implementation work, and Haiku handles simpler, more mechanical tasks.

The orchestrator then creates the necessary subagents, gives each one the context it actually needs, and coordinates their execution based on dependencies between tasks. Independent tasks can run in parallel, while dependent tasks wait for the outputs they need. But routing tasks to the right model was only part of the token problem. There was another major source of waste: context.

Giving every subagent the entire codebase would defeat the purpose of making the system token-efficient. So Waltuh indexes the codebase and retrieves only the context relevant to each individual task. A subagent working on authentication doesn't need to read unrelated UI components, just as one fixing a database query doesn't need the entire frontend in its context window.

Each worker receives a carefully packed subset of the codebase based on its assigned task, along with outputs from any tasks it depends on. This keeps the context focused, reduces unnecessary token consumption, and gives each model less irrelevant information to reason through. The idea was simple: why make Opus do everything when a team of models can divide the work more efficiently? And that's how Waltuh started. But building Waltuh is only half the experiment. The next step is to find out whether it actually works.

I plan to run rigorous benchmarks comparing Waltuh directly against vanilla Claude Code across real-world coding tasks of varying complexity. The goal is to measure what actually matters: total token usage, execution time, cost, implementation quality, correctness, and success rate. Can Waltuh use fewer tokens without sacrificing quality? Can parallel execution make it meaningfully faster? Does intelligent model routing actually outperform simply letting Opus handle everything? And at what level of task complexity does orchestration become worth the overhead?

PS - I'd love to run these tests if you could sponser me with tokens, thank you for reading!!