[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-83101":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":15,"stars30d":15,"stars90d":13,"forks30d":13,"starsTrendScore":16,"compositeScore":17,"rankGlobal":10,"rankLanguage":10,"license":18,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":19,"hasPages":19,"topics":21,"createdAt":10,"pushedAt":10,"updatedAt":41,"readmeContent":42,"aiSummary":43,"trendingCount":13,"starSnapshotCount":13,"syncStatus":44,"lastSyncTime":45,"discoverSource":46},83101,"deliberation","antonbabenko\u002Fdeliberation","antonbabenko","Ask Codex, Gemini, Grok, and 400+ OpenRouter models (Qwen, Kimi, DeepSeek) for second opinions or arbiter-mediated consensus. One MCP server for Claude Code, Codex, Cursor, Kiro, OpenCode. Measures which models earn their seat.","",null,"JavaScript",69,0,1,11,3,46.6,"MIT License",false,"master",[22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"ai-agents","ai-coding","claude","claude-code","claude-code-plugin","code-review","codex","consensus","developer-tools","gemini","grok","llm","mcp","mcp-server","multi-agent","openai","plan-review","security-review","xai","2026-06-12 04:01:40","# Deliberation\n\nGet a second opinion in Claude Code from GPT, Gemini, and Grok - plus 400+ more models through OpenRouter, including Qwen, Kimi, and DeepSeek. Seven domain experts (Architect, Code Reviewer, Security Analyst, and four more) review your plans, find bugs, and debate edge cases until they agree.\n\n[![Four chairs at the table: Claude, GPT, Gemini, Grok - one verdict you can ship](assets\u002Fagents.png)\u003Cbr>One model is a guess. Three that agree is a plan. → read the blog post](https:\u002F\u002Fbuilder.aws.com\u002Fcontent\u002F3DtBiR4ua0qy7ybZMPzPmQ2SDMj\u002Fone-model-is-a-guess-three-that-agree-is-a-plan)\n\n\u003Cdetails>\n\u003Csummary>📸 See a full \u003Ccode>\u002Fconsensus\u003C\u002Fcode> run: round 1 disagreement to round 5 convergence\u003C\u002Fsummary>\n\n![Round 1: reviewers disagree](assets\u002Fround1.png)\n\n\u003Cdetails>\n\u003Csummary>... a few moments later ...\u003C\u002Fsummary>\n\n![A Few Moments Later](assets\u002Fafewmomentslater.png)\n\n\u003C\u002Fdetails>\n\n![Round 5: convergence reached](assets\u002Fround5.png)\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>📸 See \u003Ccode>\u002Fask-all\u003C\u002Fcode> stage a 2-round architect debate: three models, three verdicts, then each critiques the others - disagreement matrix included\u003C\u002Fsummary>\n\n![\u002Fask-all: three architects walk into a repo, two ship bugs walk out](assets\u002Fask-all.png)\n\nWhen three models argue, the real bug reveals itself. Round 1 = independent top findings. Round 2 = each model dunks on the others' picks. The disagreement matrix shows where they diverge; the conclusion shows what to actually fix first.\n\n\u003C\u002Fdetails>\n\n## What is Deliberation?\n\nClaude can ask GPT, Gemini, Grok, or any OpenAI-compatible model (via OpenRouter) for help\nthrough MCP. The plugin handles the wiring for each provider so you just write the prompt.\nEach expert has a distinct specialty and can advise or implement.\n\nYou can use any subset of the providers. The plugin detects which are configured and routes\naccordingly. OpenRouter is advisory-only and config-driven: models are declared in\n`~\u002F.config\u002Fdeliberation\u002Fconfig.json` (Windows: `%APPDATA%\\deliberation\\config.json`; override\nwith `DELIBERATION_CONFIG`) and hot-reload without restarting Claude Code.\n\n| What you get | Why it matters |\n|--------------|----------------|\n| 7 domain experts | The right specialist for each problem type |\n| GPT, Gemini, Grok, or OpenRouter models | Use your preferred provider(s) |\n| Dual mode | Experts analyze (read-only) or implement (write) |\n| Auto-routing | Claude detects when to delegate from your request |\n| Synthesized responses | Claude interprets expert output, never raw passthrough |\n\n## Install\n\n### Claude Code plugin (recommended):\n\n**1. Add the marketplace - [antonbabenko\u002Fagent-plugins](https:\u002F\u002Fgithub.com\u002Fantonbabenko\u002Fagent-plugins)**\n```\n\u002Fplugin marketplace add antonbabenko\u002Fagent-plugins\n```\n\n**2. Install the plugin**\n```\n\u002Fplugin install deliberation@antonbabenko\n```\n\n**3. Run setup**\n```\n\u002Fdeliberation:setup\n```\n\nClaude now routes complex tasks to your GPT, Gemini, Grok, and OpenRouter experts (Grok and OpenRouter advise; GPT and Gemini can also implement).\n\n> **Setup is a one-time step.** The MCP servers are registered by the plugin manifest, so they load\n> automatically and stay current across updates.\n\n### Updating (Claude Code)\n\n```\n\u002Fplugin marketplace update antonbabenko  # pull the new version from the marketplace\n\u002Freload-plugins                          # reconnect the MCP servers (or just restart Claude Code)\n```\n\n**Updating on non-Claude hosts:** hosts that run the standalone server via `npx -y\n@antonbabenko\u002Fdeliberation-mcp` get the latest published version on each fresh resolve. `npx`\ncaches resolved packages, so if a host serves an old build, clear the npx cache\n(`rm -rf ~\u002F.npm\u002F_npx`) or pin\u002Frefresh the version.\n\n### Alternative: Use `deliberation` MCP server (standalone, works with any agents)\n\nThe orchestration server is also published on its own - npm [`@antonbabenko\u002Fdeliberation-mcp`](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@antonbabenko\u002Fdeliberation-mcp), Official MCP Registry name `io.github.antonbabenko\u002Fdeliberation`.\n\n**One-click install:**\n\n[![Install in Cursor](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FInstall-Cursor-blue?style=flat-square&logo=cursor)](https:\u002F\u002Fcursor.com\u002Fen-US\u002Finstall-mcp?name=deliberation&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBhbnRvbmJhYmVua28vZGVsaWJlcmF0aW9uLW1jcCJdfQ==) [![Install in VS Code](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FInstall-VS_Code-FF9900?style=flat-square&logo=visualstudiocode&logoColor=white)](https:\u002F\u002Finsiders.vscode.dev\u002Fredirect\u002Fmcp\u002Finstall?name=deliberation&config=%7B%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40antonbabenko%2Fdeliberation-mcp%22%5D%7D) [![Install in Kiro](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FInstall-Kiro-9046FF?style=flat-square&logo=kiro)](https:\u002F\u002Fkiro.dev\u002Flaunch\u002Fmcp\u002Fadd?name=deliberation&config=%7B%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40antonbabenko%2Fdeliberation-mcp%22%5D%7D)\n\n\u003Cdetails>\n\u003Csummary>Manual config for any MCP clients\u003C\u002Fsummary>\n\nAdd this to your host's MCP config (most hosts use the `mcpServers` key):\n\n```json\n{\n  \"mcpServers\": {\n    \"deliberation\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@antonbabenko\u002Fdeliberation-mcp\"],\n      \"env\": {\n        \"XAI_API_KEY\": \"xai-...\",\n        \"OPENROUTER_API_KEY\": \"sk-or-v1-...\"\n      }\n    }\n  }\n}\n```\n\nThe `env` block is how you set provider keys outside Claude Code. GPT and Gemini do not read keys here - they use the `codex` and `agy` CLIs (logged in separately), so drop those lines if you only use GPT\u002FGemini. `XAI_API_KEY` enables Grok; `OPENROUTER_API_KEY` enables OpenRouter (which also needs models declared in `~\u002F.config\u002Fdeliberation\u002Fconfig.json` - the canonical XDG path, Windows `%APPDATA%\\deliberation\\config.json` - or point elsewhere with `DELIBERATION_CONFIG`). The one-click buttons above cannot carry secrets - add the `env` block by hand after installing.\n\nPer-host config location and the key it expects:\n\n| Host | Config | Key |\n|------|--------|-----|\n| Claude Code | `claude mcp add deliberation -- npx -y @antonbabenko\u002Fdeliberation-mcp` (or project `.mcp.json`) | `mcpServers` |\n| Claude Desktop | `~\u002FLibrary\u002FApplication Support\u002FClaude\u002Fclaude_desktop_config.json` (macOS), `%APPDATA%\\Claude\\claude_desktop_config.json` (Windows) | `mcpServers` |\n| Cursor | `~\u002F.cursor\u002Fmcp.json` (global) or `.cursor\u002Fmcp.json` (project) | `mcpServers` |\n| VS Code | `.vscode\u002Fmcp.json` - note: each entry needs `\"type\": \"stdio\"` | `servers` |\n| Codex CLI | `~\u002F.codex\u002Fconfig.toml` - TOML, e.g. `[mcp_servers.deliberation]` | `mcp_servers` |\n| Gemini CLI | `~\u002F.gemini\u002Fsettings.json` | `mcpServers` |\n| Windsurf | `~\u002F.codeium\u002Fwindsurf\u002Fmcp_config.json` | `mcpServers` |\n| Zed | `settings.json` | `context_servers` |\n| Cline | the extension's MCP settings (Cline panel -> MCP Servers) | `mcpServers` |\n\nProvider prerequisites are the same as the plugin (see [Requirements](#requirements)): the Codex CLI for GPT, `agy` for Gemini, `XAI_API_KEY` for Grok, and `OPENROUTER_API_KEY` plus `~\u002F.config\u002Fdeliberation\u002Fconfig.json` for OpenRouter (Windows: `%APPDATA%\\deliberation\\config.json`; override the config path with `DELIBERATION_CONFIG`).\n\nTools exposed: `ask-all`, `consensus` (the full convergence loop in one call, or a single synthesis pass with `synthesizeAlways:true`), `consensus-step` (drive the loop yourself, one action per call), `ask-gpt` \u002F `ask-gemini` \u002F `ask-grok` \u002F `ask-openrouter`, `panel` + `ask-one` (discover the active provider set, then call providers individually - issue them in parallel for visible per-provider progress), `analyze` (read-only run analytics over the debug log + sessions: per-model latency \u002F tokens + verdict agreement, with advisory tuning suggestions), the seven experts (`architect`, `plan-reviewer`, `scope-analyst`, `code-reviewer`, `security-analyst`, `researcher`, `debugger`), and the session tools (`session-get` \u002F `session-revisit` \u002F `session-annotate`). Every result carries `ms` + the effective `reasoningEffort` (HTTP providers add token `usage`). An optional debug log (`\"debug\": { \"enabled\": true }`) records latency \u002F tokens \u002F votes - never prompts or responses. These are server-side, so they work on every MCP host, not just Claude Code (see [AGENTS.md](AGENTS.md)).\n\nThe package also ships a `deliberation-setup` bin. Run it once with `npx -y --package @antonbabenko\u002Fdeliberation-mcp deliberation-setup` to write a starter `~\u002F.config\u002Fdeliberation\u002Fconfig.json` (it never overwrites an existing one). The plain `npx -y @antonbabenko\u002Fdeliberation-mcp` form runs the default bin (the server), which is what your MCP host launches. For host rule wiring, see [`AGENTS.md`](AGENTS.md) and the per-host snippets in [`examples\u002F`](examples\u002F).\n\n\u003C\u002Fdetails>\n\n### Native plugins per host (Cursor \u002F Codex \u002F Kiro \u002F OpenCode)\n\nBeyond the raw MCP config above, deliberation ships **native plugin artifacts** for four hosts so the experience matches the Claude Code plugin (persona-bearing experts + when-to-delegate guidance, not just bare tools). All of these are **generated from the canonical sources** by `node scripts\u002Fsync-hosts.js` and committed, so they never drift (a CI drift test enforces it). Each host scans the repo for its own files:\n\n| Host | Native artifacts (in this repo) | Install |\n|------|----------------------------------|---------|\n| **Cursor** | `.cursor\u002Frules\u002Fdeliberation.mdc` | Use the one-click MCP button above, then copy the `.mdc` into your project's `.cursor\u002Frules\u002F`. |\n| **Codex CLI** | `plugins\u002Fdeliberation\u002F` (`.codex-plugin\u002Fplugin.json` + `.mcp.json` + `skills\u002F`) and a repo-scoped `.agents\u002Fplugins\u002Fmarketplace.json` | `codex plugin marketplace add antonbabenko\u002Fdeliberation`, then install **deliberation** from `\u002Fplugins`. |\n| **Kiro** | `POWER.md` + `mcp.json` + `steering\u002F` (a \"Kiro Power\") | In Kiro, \"Add power from GitHub\" -> this repo URL. Submit to the registry at [kiro.dev\u002Fpowers\u002Fsubmit](https:\u002F\u002Fkiro.dev\u002Fpowers\u002Fsubmit\u002F). |\n| **OpenCode** | `.opencode\u002Fcommands\u002F*.md` + `.opencode\u002Fagents\u002F*.md` | Add the MCP server to `opencode.json` (`mcp` key, `type: \"local\"`, `command: [\"npx\",\"-y\",\"@antonbabenko\u002Fdeliberation-mcp\"]`), then copy `.opencode\u002Fcommands\u002F` and `.opencode\u002Fagents\u002F` into your project. |\n\nProvider credentials work the same as the standalone server (GPT via the Codex CLI, Gemini via `agy`, `XAI_API_KEY` for Grok, `OPENROUTER_API_KEY` for OpenRouter) - set only the providers you use. The MCP server already injects each expert persona server-side, so these native files add the host's command\u002Fsteering surface, not duplicated logic.\n\n**Full per-host install guides:** [`public-docs\u002Fhosts\u002F`](public-docs\u002Fhosts\u002F) - [Cursor](public-docs\u002Fhosts\u002Fcursor.md), [Codex CLI](public-docs\u002Fhosts\u002Fcodex.md), [Kiro](public-docs\u002Fhosts\u002Fkiro.md), [OpenCode](public-docs\u002Fhosts\u002Fopencode.md).\n\n## Requirements\n\nYou need at least one provider:\n\n- **Codex CLI** (GPT): `npm install -g @openai\u002Fcodex`, then `codex login`.\n- **Antigravity CLI**: [Getting Started with Antigravity CLI](https:\u002F\u002Fantigravity.google\u002Fdocs\u002Fcli-getting-started) and [Migrating from Gemini CLI](https:\u002F\u002Fantigravity.google\u002Fdocs\u002Fgcli-migration), then run `agy` and login.\n- **Grok (xAI)**: no CLI to install; the bridge ships with the plugin (needs Node 18+). Set `XAI_API_KEY` (get a key at https:\u002F\u002Fconsole.x.ai).\n- **OpenRouter**: no CLI; the bridge ships with the plugin (needs Node 18+). Set `OPENROUTER_API_KEY` (get a key at https:\u002F\u002Fopenrouter.ai\u002Fkeys), then declare models in `~\u002F.config\u002Fdeliberation\u002Fconfig.json` (Windows: `%APPDATA%\\deliberation\\config.json`; override with `DELIBERATION_CONFIG`). Works with any OpenAI-compatible endpoint (Ollama, vLLM, LM Studio, HuggingFace Inference) - auth is skipped automatically when the key env var is empty.\n\n## Commands\n\nBundled with the plugin (available once installed):\n\n| Command | Purpose |\n|---------|---------|\n| `\u002Fdeliberation:setup` | Configure Codex\u002FGemini\u002FGrok\u002FOpenRouter MCP servers + orchestration rules |\n| `\u002Fdeliberation:consensus` | 🔥🔥🔥 Arbiter-mediated GPT + Gemini + Grok + Claude convergence loop |\n| `\u002Fdeliberation:ask-all` | 🔥 GPT + Gemini + Grok (+ configured OpenRouter models) in parallel, synthesized |\n| `\u002Fdeliberation:ask-gpt` | One-shot GPT (Codex) second opinion |\n| `\u002Fdeliberation:ask-gemini` | One-shot Gemini second opinion |\n| `\u002Fdeliberation:ask-grok` | One-shot Grok (xAI) second opinion (advisory-only) |\n| `\u002Fdeliberation:ask-openrouter` | One-shot OpenRouter model second opinion (advisory-only) |\n| `\u002Fdeliberation:analyze` | Analyze recent runs (latency, tokens, verdict agreement) and suggest model\u002Freasoning\u002Ffanout tuning (advisory) |\n| `\u002Fdeliberation:uninstall` | Remove MCP config, rules, and aliases |\n| `\u002Fdeliberation:grok-files` | List, prune, or gc Grok-uploaded files (storage + local cache cleanup) |\n\n`\u002Fsetup` can also install short aliases (`\u002Fask-gpt`, `\u002Fask-gemini`, `\u002Fask-grok`, `\u002Fask-all`, `\u002Fconsensus`, `\u002Fanalyze`) into `~\u002F.claude\u002Fcommands\u002F`. This is opt-in. Existing same-named commands are kept by default; setup asks before overwriting any of them. `\u002Fdeliberation:uninstall` removes an alias only if it is byte-identical to the bundled copy.\n\n## The Experts\n\n| Expert | What they do | Example triggers |\n|--------|--------------|------------------|\n| **Architect** | System design, tradeoffs, complex debugging | \"How should I structure this?\" \u002F \"What are the tradeoffs?\" |\n| **Plan Reviewer** | Validate plans before you start | \"Review this migration plan\" \u002F \"Is this approach sound?\" |\n| **Scope Analyst** | Catch ambiguities early | \"What am I missing?\" \u002F \"Clarify the scope\" |\n| **Code Reviewer** | Find bugs, improve quality | \"Review this PR\" \u002F \"What's wrong with this?\" |\n| **Security Analyst** | Vulnerabilities, threat modeling | \"Is this secure?\" \u002F \"Harden this endpoint\" |\n| **Researcher** | External libraries, docs, best practices | \"How do I use X?\" \u002F \"Find examples of Y\" |\n| **Debugger** | Root-cause analysis, minimal fixes | \"Why does this crash?\" \u002F \"Debug this failing test\" |\n\n### When experts help most\n\n- **Architecture decisions** - \"Should I use Redis or in-memory caching?\"\n- **Stuck debugging** - after two or more failed attempts, get a fresh perspective\n- **Pre-implementation** - validate a plan before writing code\n- **Security concerns** - \"Is this auth flow safe?\"\n- **Code quality** - a second opinion on your implementation\n\n### When not to use experts\n\n- Simple file operations (Claude handles these directly)\n- First attempt at any fix (try yourself first)\n- Trivial questions (no need to delegate)\n\n## How to Use\n\nDescribe your task. Claude detects when an expert helps and delegates automatically:\n\n```\nYou: \"Is this authentication flow secure?\"\nClaude: routes to the Security Analyst, then synthesizes the findings.\n```\n\nYou can also ask explicitly: \"Ask GPT to review this architecture\", \"Ask Gemini to...\", or \"Ask Grok to...\". Each expert runs read-only for analysis or with write access to apply fixes, and Claude picks the mode from your request.\n\nOr invoke the slash commands directly - see Commands above.\n\n## How \u002Fconsensus and \u002Fask-* keep models honest\n\n`\u002Fask-gpt`, `\u002Fask-gemini`, `\u002Fask-grok`, and `\u002Fask-all` are the quick commands: each dispatches one or three external models, Claude reads the output, and you get one synthesized answer. Single shot, no loop, no peer round.\n\n`\u002Fconsensus` is the heavy one. Same parallel dispatch, but with a peer-review round and a multi-round loop that stops only when the models agree. The cost: the orchestrator (Claude) writes the review prompt, casts a vote, decides which objections are real, and runs the loop. Left alone, that setup can quietly rubber-stamp its own plan. Four guards stop that.\n\n![\u002Fconsensus 3-stage flow](assets\u002Fconsensus-flow-simple.png)\n\n[See the detailed diagram with bias guards and per-model flow](assets\u002Fconsensus-flow.png)\n\nThe four guards:\n\n- **Blind verdict.** Claude posts its own verdict (APPROVE \u002F REQUEST CHANGES \u002F REJECT) in a message sent *before* the one that calls the panel. The pre-commitment sits in the transcript, so Claude cannot reshape its opinion after seeing the others. The engine enforces this: the panel is not revealed until the blind verdict is recorded.\n- **Peer review.** Each external model reviews the plan independently and returns a verdict plus categorized critical issues; Claude weighs them as the arbiter. The models vote, Claude adjudicates.\n- **No self-approval.** A round converges only when every responding external approves and at least one external actually answered. Claude's own approval never carries a round by itself. A provider that errors (an unconfigured Grok returning `missing-auth`, for example) drops out of the count instead of jamming the loop.\n- **No silent dismissal.** Every critical issue that gets dismissed or deferred ships with a one-line reason in the final report, including the times Claude walks back one of its own blind objections. The engine rejects an adjudication that dismisses an issue without a reason.\n\nThe `\u002Fask-*` commands carry a lighter version of the same rule. The external model only advises: Claude reads the output, applies its own judgment, and owns the synthesized answer. When the models agree, that is input, not a verdict.\n\n\u003Cdetails>\n\u003Csummary>Deep dive: how a single \u002Fconsensus round actually runs\u003C\u002Fsummary>\n\n`\u002Fconsensus` is a thin driver over the core convergence engine (`core\u002Fconsensus-loop.js`); the loop mechanics - round counting, the convergence rule, the configurable max-rounds cap, history, and the confidence label - live in the engine, not the command. Each round:\n\n1. **Blind verdict.** Claude commits its own verdict (transcript-visible) BEFORE the panel is revealed; the engine gates the reveal on it.\n2. **Panel review.** GPT, Gemini, Grok (and any configured OpenRouter delegates) review the plan in parallel and emit APPROVE \u002F REQUEST CHANGES \u002F REJECT plus categorized critical issues. The server parses each verdict.\n3. **Arbiter adjudication + revision.** Claude reconciles the panel verdicts and its own blind verdict; for each critical issue it picks accept, dismiss (reason required), or defer, then revises the plan for the next round.\n\nThe loop converges when at least one responding external approves, none reject, zero critical issues remain accepted, and Claude adjudicates APPROVE - so Claude cannot self-approve. It otherwise stops at `consensus.maxRounds` (default 5, configurable) as `unresolved`. The confidence label reflects how fast it settled (round 1 = high, 2-3 = medium, 4-5 = low).\n\nThe same engine backs the entry points other hosts use: the `consensus` tool (runs the whole loop server-side in one call with a provider arbiter, or a single synthesis pass with `synthesizeAlways:true`) and `consensus-step` (drive it yourself, one action per call). See [TECHNICAL.md](TECHNICAL.md#consensus-flow-details) for the taxonomy and the engine contract.\n\n> An earlier revision ran an extra \"Stage 2\" anonymized peer cross-review (each model scoring the others' answers blind, adapted from [karpathy\u002Fllm-council](https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fllm-council)). The engine-driven rewrite removed it to keep one source of truth; it may return as an engine feature.\n\n\u003C\u002Fdetails>\n\n## Configuration\n\nFull setup and configuration reference lives in **[SETUP.md](SETUP.md)**. It covers:\n\n- **Expert modes** - advisory (`read-only`) vs implementation (`workspace-write`), chosen automatically from your request\n- **Config file** - location (`~\u002F.config\u002Fdeliberation\u002Fconfig.json`), the `DELIBERATION_CONFIG` override, and hot-reload\n- **The six config sections** - `providers`, `models`, `routing`, `consensus`, `sessions`, `debug` - with a minimal example\n- **OpenRouter models** - declaring records, `askAll` \u002F `consensus` eligibility, fan-out, `reasoningEffort`, and arbiter selection\n- **Debug log** - opt-in latency \u002F token \u002F voting trace\n- **Session persistence** - opt-in on-disk run history and the `session-*` tools\n\nFor provider internals, environment variables, and manual MCP setup, see **[TECHNICAL.md](TECHNICAL.md)**.\n\n## Author\n\nMaintained by Anton Babenko - [LinkedIn](https:\u002F\u002Flinkedin.com\u002Fin\u002Fantonbabenko), [X\u002FTwitter](https:\u002F\u002Fx.com\u002Fantonbabenko).\n\n## Contributing\n\nContributions welcome. See [CONTRIBUTING.md](CONTRIBUTING.md) for the workflow, commit conventions, and the automated release process. \n\n## License\n\n[MIT](LICENSE)\n","Deliberation 是一个用于获取多个AI模型对代码或计划的第二意见和共识的工具。它支持Codex、Gemini、Grok以及通过OpenRouter接入的400多个模型（如Qwen、Kimi、DeepSeek）之间的协作评审。项目的核心功能包括多模型间的自动路由、专家角色定义（如架构师、代码审查员等），并通过多轮讨论达成一致意见，特别适用于需要高质量代码审查、安全分析及复杂问题解决的场景。此外，Deliberation还提供了双模式操作，既可进行只读分析也可直接实施修改，并且能够根据配置自动选择合适的模型参与讨论。",2,"2026-06-11 04:10:06","CREATED_QUERY"]