meetmendapara09/llm-council

Purpose and entry points

LLM Council is a local, browser-based multi-model deliberation system. A user prompt is sent through OpenRouter to several LLMs, then through peer review/ranking, and finally to a chairman model for synthesis. Backend startup is backend/main.py (also reachable via root main.py); the React/Vite client boots at frontend/src/main.jsx and composes the app in frontend/src/App.jsx.

Backend API and orchestration

FastAPI owns the application boundary, request lifecycle, and routes in backend/main.py. Council workflow coordination belongs in backend/council.py, separating multi-stage LLM prompting from HTTP handling. Runtime model selection and chairman designation are centralized in backend/config.py, making the council membership an application-level policy rather than a frontend concern.

Three-stage council pipeline

1. First opinions: fan out the user question to configured council models and collect independent answers.

2. Review: redistribute peer outputs with model identities anonymized; each model evaluates/ranks the others.

3. Chairman synthesis: send accumulated opinions and reviews to the designated chairman model for the final response.

The core workflow boundary is backend/council.py; model settings are in backend/config.py; external completion requests are delegated to backend/openrouter.py.

External LLM integration

backend/openrouter.py is the adapter to the OpenRouter API, using async HTTP calls and the root OPENROUTER_API_KEY environment configuration. This isolates provider transport/authentication from council prompts and orchestration. The configured model IDs in backend/config.py may represent different underlying providers, but OpenRouter is the single upstream service boundary.

Conversation state and persistence

Conversation/session memory is managed separately from orchestration in backend/memory.py. Persistent conversation data is handled by backend/storage.py and stored as local JSON files under the documented data/conversations/ location. This provides local durability without a database and forms the boundary between in-process state and filesystem persistence.

Frontend interaction model

The React client calls backend endpoints through frontend/src/api.js. frontend/src/components/ChatInterface.jsx is the primary prompt/chat interaction surface; frontend/src/components/Stage1.jsx, frontend/src/components/Stage2.jsx, and frontend/src/components/Stage3.jsx render the progressively available council outputs. frontend/src/components/Sidebar.jsx supports conversation navigation/state selection. Markdown-oriented response display is part of the frontend runtime.

Deployment/runtime shape

The system is intended for local development: Python 3.10+ with FastAPI and uv-managed dependencies, plus a Vite-served React frontend using npm. start.sh coordinates the two-process development setup. The frontend runs at Vite’s localhost endpoint and communicates with the Python backend; the backend in turn accesses OpenRouter over the network and local JSON storage on disk.