How I Built Multi-Model Council Inside Claude Code With OpenRouter
What happened when GPT, Grok, Kimi, and DeepSeek examined the same business decision.
A few months ago, I built an AI board of advisors inside Claude Code.
The board had a CEO, CFO, CTO, operator, and critic. Each advisor received the same business question, but each one had a different job.
The CEO looked at direction. The CFO looked at money and risk. The CTO looked at feasibility. The operator looked at what I could realistically execute. The critic came in last and tried to find the assumption everyone else had missed.
When I asked the board how I could grow revenue without making the business heavier, it helped me see why running a cohort program fit better than several other options I was considering. The idea was already in my head, and I still made the final decision, but the board forced me to look at the same choice from several directions before I committed.
At the time, I thought the different advisor roles were the most important part of the setup.
Then I noticed something I had missed.
Every advisor was still running on Claude.
I had created five different job descriptions, but all five advisors inherited the judgment of one underlying model. The CEO and critic could disagree because I gave them different instructions. But, they still came from the same model family, with many of the same tendencies and blind spots.
If Claude overlooked an assumption, there was a chance the entire board would overlook it too.
The Board Was Useful, but It Had One Missing Layer
I still believe the original board got two things right.
First, it forced me to examine the same decision through multiple perspectives.
Second, every advisor needs the same real evidence. A CFO cannot judge a business with no numbers. An operator cannot recommend a sequence without knowing your capacity. A critic with no source material can only produce generic warnings.
Roles and evidence made the board useful.
But after running them for a while, I realized that one thing the board couldn’t give me was a genuinely different model perspective. Five advisors could inspect five parts of the decision and still repeat the same blind spot because the same underlying model powered all of them.
So, the obvious next step was to bring in models from other AI labs. But that would only help if those models were capable enough to handle the same difficult work that demands a huge amount of reasoning.
Until recently, I was not convinced they were.
Why This Became Worth Building Now
I would not have gone through this setup just to collect more AI opinions.
For a long time, the practical choice was simple. Use the strongest frontier model for work that required deeper reasoning and judgment. Once the direction was clear, hand the repetitive and easier-to-verify execution to a faster, cheaper model.
As a heavy Claude user, that usually meant splitting the work between Opus and Sonnet. I used Opus for brainstorming, difficult decisions, and planning. Then I handed the execution work to Sonnet once the plan was defined.
That combination worked because the difference between the two jobs was easy to see. One model helped me decide what to do. The other helped me carry it out.
Recently, that split has become less obvious.
The gap between the models I trusted to think and the models I trusted to execute has started to narrow.
That is why recent releases such as Kimi K3 and DeepSeek V4 caught my attention. Both model families now support long-context, agent-style work that I previously would have reserved for a stronger frontier model.
Moonshot describes Kimi K3 as a 2.8-trillion-parameter open-weight model with native vision and a one-million-token context window. DeepSeek V4 Pro and V4 Flash also support a one-million-token context window, thinking modes, tool calls, and an Anthropic-compatible API.
So these recent advancements in open-weight models are really hard to ignore.
In Artificial Analysis’s July 17 evaluation, Kimi K3 scored 57 on its Intelligence Index, 13 points above Kimi K2.6. In its July 31 evaluation, DeepSeek V4 Flash 0731 scored 10 points above the previous V4 Flash.
To be clear, these scores do not prove that either model will suit your work style. But it’s important to acknowledge why these models are now worth testing on work that used to belong almost entirely to the largest proprietary models such as Anthropic and OpenAI.
Ultimately, these benchmarks just give us more reasons to test them in the first place.
But, the real result I care the most is whether Kimi catches a gap Claude missed, whether DeepSeek challenges an assumption GPT accepts, or whether one model handles a tool call that another model quietly fumbles.
That requires running them on the same real task.
From Switching Models to Running Them Together
In my previous post, I showed how to use DeepSeek as the model behind Claude Code.
Dheeraj Sharma kept the same Claude Code project, research agent, commands, files, and MCP setup. He changed the model handling the requests. The experiment showed that you could keep the system you had already built and route the work you do to another model.
Near the end of that session, we talked about taking the idea further through OpenRouter.
That led me to Claude Code’s four model aliases: Fable, Opus, Sonnet, and Haiku.
Those names normally point to Anthropic models. But things get more interesting when Claude Code connects through OpenRouter, because each alias can point to a different model ID from a different provider.
So Opus could point to GPT. Sonnet could point to Grok. Haiku could point to Kimi. Fable could point to DeepSeek.
Then a Claude Code subagent assigned to each alias runs on the model behind that alias.
That is the discovery behind this post.
You can run several models at the same time inside one Claude Code project, give each one a separate responsibility, and bring their reviews back into one decision process.
You no longer have to open four websites, paste the same background into four chats, collect four answers, and manually remember which model said what. The decision brief, source material, reviewer jobs, and saved output can stay together.
What We Are Building: Multi-Model AI Council
I think of this build as a Model Council—three council members and one judge.
Here’s how it works: the three council members review your decision brief at the same time. Every model receives the same facts, constraints, unknowns, and success criteria. They also receive the same review task and return their findings in the same format.
Each council member reviews the full decision. It looks for weak assumptions, checks the evidence, considers the customer or reader’s perspective, identifies possible failure modes, and recommends what should happen next.
The complete build has six parts:
A secure OpenRouter connection that keeps the API key outside the project files.
A routing template that maps four Claude Code aliases to council members as well as the judge.
One shared review prompt and output format for every council member.
A decision brief that prevents each model from inventing its own version of the situation.
A
/model-councilskill that runs the reviews, saves each result, and sends them to the judge.A verification process for confirming which model ran, what evidence it used, and how much the council cost.
We will run the finished council on one real decision and answer three questions:
Where did the models agree, and where did their reasoning split?
Did another model surface something that could change or sharpen the decision?
Was the additional time, cost, and complexity justified by what it found?
By the end, you will have the routing setup, the /model-council skill, the shared decision brief and review format, the judge instructions, and the checks needed to see whether every model did the work it claimed to do.
We will begin with the routing layer, verify every model, and only then give the council a decision to review.
Let’s dive in.
🚨 Before continuing, note that these model council tools can only be run using Claude Code in the terminal, not in the Claude Code desktop app. If you’ve never done this before, read my post here to get started:
Connect OpenRouter and Choose Your Four Models
OpenRouter gives you one place to access more than 400 AI models from different providers. OpenRouter charges based on usage rather than a subscription, so your model cost depends entirely on the tasks you ask it to perform.
In this section, I will connect OpenRouter to the Claude Code harness and point Claude Code’s four model slots to four models we choose. You could use DeepSeek, Grok, Kimi, Qwen, GLM, or another compatible model available through OpenRouter.
Three models will review the same decision. The fourth will judge their findings and bring the results back into one decision memo.
But first, let’s get your OpenRouter API key.
Create the OpenRouter API Key
Create a dedicated key from the OpenRouter API Keys page. I use a separate key for the council so I can recognize its requests and place a spending limit on it.
Start with a low limit ($20). Three council members and a judge can send several long requests during one run. I would raise the cap only after measuring the cost of the first complete council.
Go to Credits page to start adding a small amount of money. I added $10 of credit before testing the reasoning models. You can start with as low as $5.
You can start with the free plan too, but the number of tokens you can use for each request is very low. As a result, you can’t really test anything substantial if you want to ask the model to do harder tasks.