What is an LLM council, and when do you need a boardroom?

An LLM council asks several AI models the same question, has them review each other's answers, and lets a chair model write one final answer. Andrej Karpathy's llm-council, a small project he published on GitHub in late November 2025, made the idea popular.

That is the whole definition. The rest of this page is about what a council is good at, where it stops, and what to use when your question is really part of a project.

How an LLM council works

Karpathy's version runs in three stages, as the project's README describes them:

1. First opinions. The question goes to every model on the council separately, and each answers on its own. You can read every response in its own tab.
2. Review. Each model is shown the others' answers, with the model names hidden so it cannot play favourites, and ranks them for accuracy and insight.
3. Final response. A designated chairman model takes all the answers and the rankings and compiles a single reply.

The models are reached through one gateway, OpenRouter, and the council and the chairman are set in a config file. Karpathy called it a Saturday hack and said he does not plan to maintain it. The pattern spread anyway, because it is easy to understand: ask several, let them check each other, get one answer back.

Commercial versions followed. Perplexity introduced Model Council on 5 February 2026, and Microsoft announced a Model Council for the Researcher agent in Microsoft 365 Copilot on 30 March 2026. We compared those approaches in A council is a query. A boardroom is a place., and side by side on Bordet vs Perplexity Model Council and Bordet vs Council AI (as of October 2026).

Why a council helps

One model's confident answer is a single point of failure. Models from different labs are trained on different data with different methods, so they tend to be wrong in different places. When three of them agree, you can move faster. When they disagree, you have found the part of the question that deserves your attention.

The review stage adds something a plain side-by-side view does not: each model has to look at the others' work and say which is better. That surfaces errors you might not have spotted yourself.

When a council is enough

A council is built around one question. You ask, the models answer and review, the chairman writes the reply, and the session is done.

For plenty of questions, that is exactly right:

• Which of two libraries is better maintained?
• What does this clause in a contract usually mean?
• Is this paragraph clear to someone outside the field?

The answer is the product. You read it, act on it, and you are unlikely to need the reasoning again next month. A council is quick for this, and we would not tell you to set anything else up.

When it is not

The trouble starts when the question is part of something that continues: a launch, a hiring round, an architecture you will keep building on, a pricing model you will defend to a co-founder.

Then the final answer is the cheapest part. What you need later is everything around it:

• The disagreements. Which model objected, to what, and whether the objection was answered or overruled.
• The decision. What you chose in the end, and why.
• The context. The background you gave, so the next question starts from it rather than from nothing.

A council's chairman merges the dissent into one reply, and when the session ends the thread ends with it. Tomorrow's follow-up starts from scratch, and you are the one carrying the history.

What a boardroom adds

A Bordet room keeps the useful part of a council, several models from different labs answering one question and reading each other, and gives it somewhere to live.

Each model holds a seat with a role: a Strategist proposes, a Maker drafts, a Critic disagrees on purpose, an Analyst checks the numbers. They answer in one conversation and reply to each other where they differ, so the disagreement is on the record rather than smoothed over. Then three things carry over:

• Shared memory. Every member sees the same project context, and it persists across sessions.
• The decisions log. An append-only record of what was decided and why. Any member, human or AI, can add an entry.
• The seats. If a lab retires a model, you change the model behind a seat in the members list. The role, the memory and the log stay put.

Your own AI can sit at the table too. Claude Code, Codex, Cursor, Claude and ChatGPT can join a room as members through the MCP connector, read the room, ask the table and log decisions. How it works walks through a room from the first question.

The short version

If you have one question, use a council. If you have a project, you want the answers, the disagreements and the decisions kept somewhere the next session can read.

FAQ

What is an LLM council?

An LLM council sends one question to several AI models, has each model review the others' answers, and lets a chair model combine them into one final answer. Andrej Karpathy's llm-council project on GitHub, published in late November 2025, made the pattern popular.

What is Karpathy's LLM council?

It is a small local web app that sends your question to several models through OpenRouter, has them rank each other's anonymised answers, and asks a chairman model to write the final reply. Karpathy described it as a Saturday hack he does not plan to maintain.

Is an LLM council better than one model?

Often, for questions where being wrong is costly. Models from different labs tend to make different mistakes, so agreement gives you confidence and disagreement shows you where to look harder. It costs several model calls instead of one.

What is the difference between an LLM council and an AI boardroom?

A council answers one question and ends. A boardroom like Bordet keeps the seats, a shared memory of the project and an append-only decisions log, so the next session starts from what the table already settled and who disagreed.

When your question is part of a project, open a boardroom, give each seat a role, and put all of them to work.