1. Conduid
  2. Developer Tools
  3. elhamid/llm-council
MCP server · Developer Tools

elhamid/llm-council

LLM Council fork with persistence, decision traces, stability fixes, repeatable checks, and MCP integration.

Unclaimed last commit 8 months ago devtools
46Fair

Scored 14 days ago · breakdown

About elhamid/llm-council

elhamid/llm-council is an MCP server published by elhamid in the Developer Tools category: lLM Council fork with persistence, decision traces, stability fixes, repeatable checks, and MCP integration.

The repository has 8 stars and 3 forks, with the last commit 8 months ago. Six months or more without a commit doesn't mean the server is broken, but check the open issues before depending on it in production.

Install

From source
git clone https://github.com/elhamid/llm-council

This server has no ConduID identity, so agent calls to it are not receipted. Pin the version you install and review the source before granting it credentials.

Ask AI

✦

Ask AI about elhamid/llm-council

Powered by Claude · Grounded in docs

I know everything about elhamid/llm-council. Ask me about installation, configuration, usage, or troubleshooting.

Security checks

Static checks derived from the repository 7 days ago. Heuristics on the source, not an audit.

  • ✓README presentThe repository ships documentation.
  • !License declaredNo license file. Legally you have no right to use it in a product.
  • ✓Tests presentA test suite exists in the repository.
  • ✓Dependencies pinnedA lockfile pins dependency versions.
  • ✓No dynamic code executionSource scan found no eval, dynamic Function, or shell execution.
  • !Scoped permissionsDoesn't declare a permission scope. Assume it can do anything its process can.

Releases

v0.1.0v0.1.0

README

LLM Council

llmcouncil

Fork notes (elhamid)

This is a fork of karpathy/llm-council.

Update — 2025-12-19 (Stability + auditability pass)

New in this fork since the previously published state:

  • Conversation history is complete again: storage loads older runs from backend/data/conversations.json and supports the legacy data/ layout (including data/conversations/ per-conversation JSON files when present), so older runs show up in the UI.
  • Sidebar no longer truncates early: the frontend now requests /api/conversations?limit=500 so the conversation list reliably shows full history.
  • Stage 2 judge duplication fixed: Stage 2 now dedupes judge models so evaluation does not silently double-count the same judge.
  • Titles persist correctly: after Stage 3 completes, a title is derived and saved to the conversation record, so it sticks across refreshes and appears in history.
  • Tooling + reproducibility: added Stage 2 smoke/quality scripts and supporting evaluation artifacts to make regressions repeatable.
  • Roles updated + clarified: earlier fork notes described roles as Analyst / Researcher / Critic / Provocateur; the implemented role set is now Builder / Reviewer / Synthesizer / Contrarian (with a provider-default mapping in backend/roles.py). This keeps the “multi-perspective” intent, but with clearer, more actionable role behavior.

Value added — 2025-12-14 (decision-quality focused)

  • Decision-auditable runs: every council response is saved with a compact decision trace (Stage 1 answers, Stage 2 rankings, and the Stage 2→model mapping), so you can inspect why the Chairman concluded what it did — not just the final text.
  • Reduced “model-brand” bias in judging: Stage 2 rankings operate on anonymized responses (Response A/B/C/…), and the label→model mapping is preserved for post-hoc review. This keeps peer review focused on content quality rather than model identity.
  • Role-separated council behavior: explicit role specs (Analyst / Researcher / Critic / Provocateur + Chairman) make the council behave more like a real review board: one pushes rigor, one hunts missing facts, one stress-tests, one challenges assumptions — then the Chairman synthesizes.
  • Repeatable scoring across runs: aggregated ranks (average rank + count) are persisted so you can compare council behavior over time and across prompts, instead of treating each run as a one-off chat.

Implementation notes (supporting the above)

  • Real SSE endpoint (text/event-stream) for /api/conversations/{id}/message/stream with incremental stage*_start/complete events.
  • Persist meta/metadata (label_to_model, aggregate_rankings, model_roles) so Stage2 renders correctly and the run is reviewable later.
  • Frontend Stage2 reads msg.meta || msg.metadata so fork/upstream payload shapes both render.

The idea of this repo is that instead of asking a question to your favorite LLM provider (e.g. OpenAI GPT 5.1, Google Gemini 3.0 Pro, Anthropic Claude Sonnet 4.5, xAI Grok 4, eg.c), you can group them into your "LLM Council". This repo is a simple, local web app that essentially looks like ChatGPT except it uses OpenRouter to send your query to multiple LLMs, it then asks them to review and rank each other's work, and finally a Chairman LLM produces the final response.

In a bit more detail, here is what happens when you submit a query:

  1. Stage 1: First opinions. The user query is given to all LLMs individually, and the responses are collected. The individual responses are shown in a "tab view", so that the user can inspect them all one by one.
  2. Stage 2: Review. Each individual LLM is given the responses of the other LLMs. Under the hood, the LLM identities are anonymized so that the LLM can't play favorites when judging their outputs. The LLM is asked to rank them in accuracy and insight.
  3. Stage 3: Final response. The designated Chairman of the LLM Council takes all of the model's responses and compiles them into a single final answer that is presented to the user.

Vibe Code Alert

This project was 99% vibe coded as a fun Saturday hack because I wanted to explore and evaluate a number of LLMs side by side in the process of reading books together with LLMs. It's nice and useful to see multiple responses side by side, and also the cross-opinions of all LLMs on each other's outputs. I'm not going to support it in any way, it's provided here as is for other people's inspiration and I don't intend to improve it. Code is ephemeral now and libraries are over, ask your LLM to change it in whatever way you like.

Setup

1. Install Dependencies

The project uses uv for project management.

Backend:

uv sync

Frontend:

cd frontend
npm install
cd ..

2. Configure API Key

Create a .env file in the project root:

OPENROUTER_API_KEY=sk-or-v1-...

Get your API key at openrouter.ai. Make sure to purchase the credits you need, or sign up for automatic top up.

3. Configure Models (Optional)

Edit backend/config.py to customize the council:

COUNCIL_MODELS = [
    "openai/gpt-5.1",
    "google/gemini-3-pro-preview",
    "anthropic/claude-sonnet-4.5",
    "x-ai/grok-4",
]

CHAIRMAN_MODEL = "google/gemini-3-pro-preview"

Running the Application

Option 1: Use the start script

./start.sh

Option 2: Run manually

Terminal 1 (Backend):

uv run python -m backend.main

Terminal 2 (Frontend):

cd frontend
npm run dev

Then open http://localhost:5173 in your browser.

Tech Stack

  • Backend: FastAPI (Python 3.10+), async httpx, OpenRouter API
  • Frontend: React + Vite, react-markdown for rendering
  • Storage: JSON files in data/conversations/
  • Package Management: uv for Python, npm for JavaScript

README fetched from the repository 7 days ago. The original is authoritative.

Questions

About elhamid/llm-council

How do I install elhamid/llm-council?

No package has been published for this server, so install it from source: clone the repository and follow its README.

Is elhamid/llm-council safe to use with an AI agent?

Its trust score is 46 out of 100 (fair). It passes 4 of the 6 static security checks run so far; the failures are listed above. It has no ConduID identity yet, so agent calls to it are not receipted.

Is elhamid/llm-council still maintained?

The last commit was 8 months ago. That's long enough that you should check whether the maintainer is responding to issues before depending on it.