{"slug": "show-hn-have-your-agent-consult-other-models", "title": "Show HN: Have your agent consult other models", "summary": "Developer Raine released consult-llm, an open-source tool that lets AI agents query other models for second opinions during coding tasks. The tool supports multiple providers including GPT-5.5, Gemini 3.1 Pro, and Claude Opus 4.7, and can be integrated via slash commands in agents like Claude Code and Codex to catch blind spots in reasoning.", "body_md": "[Quick start](#quick-start) ·\n[Usage](#usage) ·\n[Providers & Configuration](#providers--configuration) ·\n[Skills](#skills) ·\n[Logging](#logging) ·\n[Monitor](#monitor) ·\n[Changelog](/raine/consult-llm/blob/main/CHANGELOG.md)\n\n`consult-llm`\n\nis a tool for getting a second opinion from another AI model,\nright inside your existing agent workflow. Use it to plan architecture,\nreview changes, debate approaches, or get unstuck on tricky bugs. It supports GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7,\nDeepSeek V4 Pro, MiniMax M2.7, and Grok 4.3, along with any `openrouter/*`\n\nmodel, with API and local CLI backends,\nmulti-turn threads, git diff context, web-mode clipboard export, and a live monitor TUI.\n\nA model reviewing its own work isn't an independent check. Even in a fresh context, it shares the same training, priors, and many of the same failure modes. A different model was trained differently and makes different mistakes, so it's more likely to push back, challenge weak reasoning, or expose a blind spot.\n\nModel strengths are uneven and hard to predict per task. A quick cross-check is cheap, and sometimes the other model is the one that finds the path forward.\n\n- Install skills into your agent (Claude Code, Codex, OpenCode)\n- Trigger with a slash command:\n`/consult`\n\n,`/debate`\n\n,`/collab`\n\n- The skill pipes your prompt into\n`consult-llm`\n\n, which calls the backend and streams the response back inline\n\nFor the more detailed flow, [continue below](#how-it-really-works).\n\n```\n> The hint unlocking is still broken after your fix. Ask gemini\n\n⏺ Skill(consult-llm)\n  ⎿  Successfully loaded skill · 1 tool allowed\n\n⏺ Let me consult Gemini to understand this segmentation mismatch:\n\n⏺ Bash(cat issue.md | consult-llm -m gemini -f HintsText.tsx -f hints.ts)\n  ⎿ [model:gemini-3.1-pro-preview]\n\n     The root cause is a race condition in `handleConfirmGenerateHints`.\n     After `await generateHints()`, the component state updates in the\n     background, but the function continues with a stale `activeSegment`\n     variable, requesting a hint for \"isn't\" instead of \"isn't it\".\n\n⏺ Gemini identified the real issue: a race condition with stale state\n  after async operations. I was looking at the wrong thing entirely.\n```\n\nNote\n\nThis project previously used MCP as its transport layer. If you were using that version, see the [migration guide](#migrating-from-mcp) below.\n\n**Get a second opinion from another model** from your agent with relevant file context (`/consult`\n\n)**Have models debate the best approach** and synthesize a consensus (`/debate`\n\n)**Use existing subscriptions** via CLI backends without API keys ([Gemini CLI](#gemini-cli),[Codex CLI](#codex-cli),[Cursor CLI](#cursor-cli),[Claude CLI](#profile-backend),[OpenCode](#opencode))**Continue conversations across requests** with`thread_id`\n\n**Copy prompts to clipboard** for browser-based LLMs (`--web`\n\n)in a real-time TUI[Monitor](#monitor)active and past runs\n\n- Install the binaries:\n\n```\n# Homebrew\nbrew install raine/consult-llm/consult-llm\n\n# Shell script (macOS/Linux)\ncurl -fsSL https://raw.githubusercontent.com/raine/consult-llm/main/scripts/install.sh | bash\n```\n\n- Configure a backend. CLI backends are the easiest if you have an existing subscription (no API key needed):\n\n```\nconsult-llm config set gemini.backend gemini-cli   # requires: gemini login\nconsult-llm config set openai.backend codex-cli    # requires: codex login\n```\n\nOr set API keys:\n\n```\nconsult-llm config set openai.api_key your_openai_key\nconsult-llm config set gemini.api_key your_gemini_key\nconsult-llm config set grok.api_key your_xai_key\n# or via environment variables: OPENAI_API_KEY, GEMINI_API_KEY, XAI_API_KEY, etc.\n```\n\n- Verify your setup:\n\n```\nconsult-llm models                    # see available models and resolved selectors\necho \"hello\" | consult-llm -m gemini  # quick smoke test\n```\n\n- Install the skills so your agent can call\n`consult-llm`\n\nfor you:\n\n```\nconsult-llm install-skills\n```\n\nThen invoke skills from inside your agent (see [Usage](#usage) right below).\n\nSome real-world examples. Click to expand.\n\n## Explain the problem, and tell CC to consult a smarter LLM\n\n```\n  <Some long explanation of the issue here>\n\n  Consult LLM for assistance, use gemini\n\n⏺ I see the issue! The problem is that the frontend is trying to use the hint\n  for \"isn't\" but the server generated a hint for \"isn't it\" (the full phrase).\n  This is a mismatch between how the frontend segments text and how the server\n  generates hints.\n\n  Let me consult the LLM to get assistance on this segmentation mismatch issue.\n\n⏺ Write(hint-segmentation-issue.md)\n  ⎿  Wrote 53 lines to hint-segmentation-issue.md\n     # Hint Segmentation Mismatch Issue\n     ## Problem Description\n     There's a mismatch between how the frontend segments text for clickable\n     words and how the backend generates hints. This causes hint unlocking to\n     fail when the segments don't match exactly.\n     ## Example Case\n     **Original Text**: \"Hello! Nice weather, isn't it?\"\n     … +43 lines (ctrl+r to expand)\n\n⏺ Bash(cat hint-segmentation-issue.md | consult-llm -m gemini -f hint-segmentation-issue.md -f web/src/components/HintsText.tsx -f web/src/utils/hints.ts -f server/src/routes/public/hints.ts -f server/src/llm/hints.ts)\n  ⎿  [model:gemini-3.1-pro-preview] [thread_id:a3f7c...]\n\n     An excellent analysis of the problem. The root cause has been correctly\n     identified: a race condition within the `handleConfirmGenerateHints`\n     function in `HintsText.tsx`. The component state updates in the background\n     after `await generateHints()`, but the function continues executing with a\n     stale `activeSegment` variable, causing it to request a hint for a smaller\n     text segment ( e.g., \"isn't\") instead of the full, newly-available hint\n     phrase (e.g., \"isn't it\").\n     … +607 lines (ctrl+r to expand)\n\n⏺ Perfect! The LLM identified the core issue - there's a race condition in\n  handleConfirmGenerateHints where the function uses stale state after async\n  operations. The solution is to re-target the hint key after generation to\n  find the correct matching hint.\n\n  Let me implement this solution:\n\n⏺ Update Todos\n  ⎿  ☐ Fix hint segmentation mismatch by implementing smarter hint key\n       targeting in handleConfirmGenerateHints\n```\n\n## Using web mode to copy prompts to clipboard for browser-based LLMs\n\n```\n> I need help implementing a -b/--background flag for my Rust CLI. Use consult LLM with web mode\n\n⏺ I'll use web mode to copy the formatted prompt to your clipboard so you can\n  paste it into any browser-based LLM service.\n\n⏺ Bash(cat <<'EOF' | consult-llm -m gemini --web -f src/cli.rs -f src/workflow.rs -f src/tmux.rs\n  What is the best approach to implement a -b/--background flag for the\n  \"workmux add\" command that creates a tmux window in the background without\n  switching to it?\n\n  The current implementation automatically switches to the newly created window\n  via `tmux::select_window()` in the `setup_environment()` function. I need to\n  make this behavior conditional based on a flag passed from the CLI.\n\n  Consider:\n  1. Where should the background flag be threaded through the call chain?\n  2. Should I modify the existing SetupOptions struct or add a parameter?\n  3. What's the most maintainable approach given the codebase structure?\n  4. Are there any edge cases to consider (e.g., should select_pane also be\n     conditional)?\n  EOF)\n  ⎿  ✓ Prompt copied to clipboard!\n\n     Please paste it into your browser-based LLM service and share the response\n     here before I proceed with any implementation.\n\n     Note: File paths were included:\n       - src/cli.rs\n       - src/workflow.rs\n       - src/tmux.rs\n\n> [User pastes the response from the external LLM]\n\n⏺ Thank you! Based on the recommendations, I'll now implement the solution...\n```\n\nThis is useful when:\n\n- You want to use a free browser-based LLM service instead of API credits\n- You prefer a specific LLM's web interface\n- You want to review the full prompt before submitting it\n\n## Debugging Neovim plugin treesitter API breakage\n\n```\n⏺ Fixed! Added nil checks for both node and child and updated the iter_matches call to handle the newer API properly.\n\n> Still not working:\n\n  E5108: Error executing lua /Users/raine/code/testonly.nvim/lua/testonly.lua:92: attempt to call method 'child' (a nil value)\n  stack traceback:\n          /Users/raine/code/testonly.nvim/lua/testonly.lua:92: in function 'reset_all_exclusive'\n          /Users/raine/code/testonly.nvim/lua/testonly.lua:110: in function 'reset_all_exclusive'\n          [string \":lua\"]:1: in main chunk\n\n  Ask gemini\n\n⏺ Let me consult with a more powerful AI to understand the current Neovim treesitter API changes:\n\n⏺ Bash(cat <<'EOF' | consult-llm -m gemini -f lua/testonly.lua\n  I'm debugging a Neovim plugin that's broken due to treesitter API changes.\n  The error is \"attempt to call method 'child' (a nil value)\" on line 92. The\n  code is trying to access child nodes from treesitter matches but the API\n  seems to have changed in newer Neovim versions.\n\n  Here's the problematic code:\n  ``` lua\n  for _, match, _ in parsed_query:iter_matches(root, bufnr, start_row, end_row) do\n      for id, node in pairs(match) do\n          local name = parsed_query.captures[id]\n          if name == \"call\" and node then\n              local child = node:child(0)  -- ERROR HERE\n              if child then\n                  local text = vim.treesitter.get_node_text(child, bufnr)\n                  -- ... rest of logic\n              end\n          end\n      end\n  end\n  ```\n\n  What's the correct way to iterate over treesitter query matches and access\n  child nodes in current Neovim versions? What API changes should I be aware of?\n  EOF)\n  ⎿  [model:gemini-3.1-pro-preview] [thread_id:b9e2a...]\n\n     Problem\n     -------\n\n     … +93 lines (ctrl+r to expand)\n\n⏺ Perfect! The issue is that iter_matches() can return nil nodes in the match table. Let me fix this by switching to the recommended iter_captures() approach:\n\n⏺ Update(lua/testonly.lua)\n  ⎿  Updated lua/testonly.lua with 7 additions and 10 removals\n       85      local root = parser:parse()[1]:root()\n       86      local start_row, _, end_row, _ = root:range()\n       87\n       88 -    for _, match, _ in parsed_query:iter_matches(root, bufnr, start_row, end_row) do\n       89 -      for id, node in pairs(match) do\n       90 -        local name = parsed_query.captures[id]\n       91 -        if name == \"call\" and node then\n       92 -          local child = node:child(0)\n       93 -          if child then\n       94 -            local text = vim.treesitter.get_node_text(child, bufnr)\n       88 +    for id, node, _ in parsed_query:iter_captures(root, bufnr, start_row, end_row) do\n       89 +      if parsed_query.captures[id] == \"call\" then\n       90 +        local first_child = node:named_child(0)\n       91 +        if first_child then\n       92 +          local text = vim.treesitter.get_node_text(first_child, bufnr)\n       93\n       94 -            if text == \"it.only\" or text == \"describe.only\" then\n       95 -              toggle_test_exclusive(child)\n       96 -            end\n       94 +          if text == \"it.only\" or text == \"describe.only\" then\n       95 +            toggle_test_exclusive(first_child)\n       96            end\n       97          end\n       98        end\n```\n\n## Using slash command to consult multiple LLMs for comparison\n\n```\n> /consult The branch completions should dynamic. Git should be called only when\nusing tab to autocomplete. Ask gemini and codex\n\n⏺ I'll consult both Gemini and Codex about making the branch completions dynamic\n  (only calling git when tab-completing). Let me gather the relevant context first.\n\n⏺ Bash(cat <<'EOF' | consult-llm -m gemini -f src/cli.rs -f src/git.rs\n  I have a Rust CLI tool using clap that needs dynamic shell completions.\n  Currently, the branch completions are generated at completion script generation\n  time via `possible_values()`. Instead, I need the git operations to only run\n  when the user presses TAB to autocomplete.\n\n  Current setup:\n  1. `WorktreeBranchParser` implements `TypedValueParser` with `possible_values()`\n     that calls git\n  2. Shell completions are generated via clap_complete's `generate()` function\n  3. The completions are sourced at shell startup: `source <(workmux completions zsh)`\n\n  The problem: Running `workmux completions zsh` takes ~210ms because it runs git\n  operations during completion generation, not during actual tab completion.\n\n  How can I implement truly dynamic completions where git is only called when the\n  user presses TAB? What's the best approach with clap and clap_complete for zsh?\n  EOF)\n  ⎿  [model:gemini-3.1-pro-preview] [thread_id:c1d4e...]\n\n     The root cause of the slow startup (~210ms) is that `clap_complete::generate()`\n     executes your `possible_values()` logic (git operations) *while generating the\n     script*. This bakes the *current* branches into the static script, which is both\n     slow (happens every time you `source` it) and incorrect (branches become stale).\n     … +116 lines (ctrl+o to expand)\n\n⏺ Bash(cat <<'EOF' | consult-llm -m codex -f src/cli.rs -f src/git.rs\n  I have a Rust CLI tool using clap that needs dynamic shell completions.\n  Currently, the branch completions are generated at completion script generation\n  time via `possible_values()`. Instead, I need the git operations to only run\n  when the user presses TAB to autocomplete.\n\n  Current setup:\n  1. `WorktreeBranchParser` implements `TypedValueParser` with `possible_values()`\n     that calls git\n  2. Shell completions are generated via clap_complete's `generate()` function\n  3. The completions are sourced at shell startup: `source <(workmux completions zsh)`\n\n  The problem: Running `workmux completions zsh` takes ~210ms because it runs git\n  operations during completion generation, not during actual tab completion.\n\n  How can I implement truly dynamic completions where git is only called when the\n  user presses TAB? What's the best approach with clap and clap_complete for zsh?\n  EOF)\n  ⎿  [model:gpt-5.1-codex-max] [thread_id:d2f5b...]\n\n     **Findings**\n     - `WorktreeBranchParser::possible_values` (`cli.rs:41-72`) runs git during script\n       generation, so `workmux completions zsh` always pays the git cost (~210ms) even\n       though the result is only needed at tab time.\n     … +77 lines (ctrl+o to expand)\n\n⏺ Summary from Gemini and Codex\n\n  Both agree on the same solution:\n\n  Root Cause\n\n  clap_complete::generate() calls possible_values() during script generation, not\n  at tab-completion time. This means git runs every shell startup.\n\n...\n```\n\nThis example shows using the `/consult`\n\nslash command to ask multiple LLMs\n(Gemini and Codex) about the same problem **in parallel** and compare their\nresponses. Both LLMs independently arrived at the same solution, providing\nconfidence in the approach.\n\nThe CLI is invoked by your agent via the installed skills; you don't call it directly. From inside Claude Code, OpenCode, or Codex:\n\n```\n/consult what's the best way to model this state machine?\n/consult --gemini review this design for edge cases\n/debate should this be a separate service or stay in the monolith?\nconsult-llm models                    # list available models and resolved selectors\nconsult-llm doctor                    # diagnose backend auth and config\nconsult-llm config set <key> <value>  # set a config value (user config by default)\nconsult-llm init-config               # scaffold ~/.config/consult-llm/config.yaml\nconsult-llm init-prompt               # scaffold ~/.config/consult-llm/SYSTEM_PROMPT.md\nconsult-llm install-skills            # install bundled skills to platform skill dirs\nconsult-llm update                    # self-update the binary\n```\n\n`consult-llm models`\n\nshows which models are active based on the configuration loaded for the current directory and prints `Default models:`\n\n, the ordered list used when `-m`\n\nis omitted. The `Default -m args:`\n\nline is a convenience for same-prompt calls; `--run`\n\nworkflows use the model list to build one `--run model=...`\n\nentry per prompt.\n\n`consult-llm doctor`\n\nchecks that each provider's backend dependency (API key or CLI binary) is satisfied, shows which config files were loaded, and validates session storage. Pass `--verbose`\n\nto see all config keys including unset defaults.\n\n`consult-llm`\n\nseparates **model families** from **backends**.\n\nA **model family** is what you ask for: `gemini`\n\n, `openai`\n\n, `deepseek`\n\n, `minimax`\n\n, `anthropic`\n\n, `grok`\n\n, or `openrouter`\n\n.\n\nA **backend** is how `consult-llm`\n\nreaches that model family:\n\n: direct HTTP calls using an API key`api`\n\n**CLI backends**: shell out to a local CLI tool already installed and logged in\n\n| Model family | `api` backend |\nCLI backends available | API key env var |\n|---|---|---|---|\n| Gemini | yes | `gemini-cli` , `cursor-cli` , `opencode` , `profile` |\n`GEMINI_API_KEY` |\n| OpenAI | yes | `codex-cli` , `cursor-cli` , `opencode` , `profile` |\n`OPENAI_API_KEY` |\n| DeepSeek | yes | `opencode` , `profile` |\n`DEEPSEEK_API_KEY` |\n| MiniMax | yes | `opencode` , `profile` |\n`MINIMAX_API_KEY` |\n| Anthropic | yes | `profile` , `claude-cli` , `cursor-cli` |\n`ANTHROPIC_API_KEY` |\n| Grok | yes | `cursor-cli` , `profile` |\n`XAI_API_KEY` |\n| OpenRouter | yes | `opencode` , `profile` |\n`OPENROUTER_API_KEY` |\n\nDirect HTTP calls to the provider. Requires an API key. Set it in your user config or as an environment variable:\n\n```\n# User config (recommended, persists across sessions)\nconsult-llm config set openai.api_key your_openai_key\nconsult-llm config set gemini.api_key your_gemini_key\nconsult-llm config set grok.api_key your_xai_key\n\n# Or as environment variables\nexport OPENAI_API_KEY=your_openai_key\nexport GEMINI_API_KEY=your_gemini_key\nexport XAI_API_KEY=your_xai_key\n```\n\nThe `api`\n\nbackend is the default. To set it explicitly:\n\n```\nconsult-llm config set gemini.backend api\nconsult-llm config set openai.backend api\nconsult-llm config set grok.backend api\n```\n\nShell out to an already-installed local CLI. No API keys needed in `consult-llm`\n\n; authentication is handled by the CLI tool.\n\nA key advantage over the API backend: CLI agents can browse your codebase, run commands, and do their own research before responding. The API backend receives only the prompt and files you explicitly include.\n\nRequires the [Gemini CLI](https://github.com/google-gemini/gemini-cli) and `gemini login`\n\n:\n\n```\nconsult-llm config set gemini.backend gemini-cli\n```\n\nRequires Codex CLI and `codex login`\n\n:\n\n```\nconsult-llm config set openai.backend codex-cli\nconsult-llm config set openai.reasoning_effort high  # none | minimal | low | medium | high | xhigh\n\n# Optional: append extra args to every `codex exec` invocation. Shell-quoted.\n# Useful e.g. to skip the sandbox in environments that already isolate Codex:\nconsult-llm config set openai.extra_args '--dangerously-bypass-approvals-and-sandbox'\n```\n\nThe same `extra_args`\n\nfield is supported on `gemini:`\n\nfor the Gemini CLI backend.\n\nRoutes through `cursor-agent`\n\n:\n\n```\nconsult-llm config set openai.backend cursor-cli\nconsult-llm config set gemini.backend cursor-cli\n```\n\nIf your prompts need shell commands in Cursor CLI ask mode, allow them in `~/.cursor/cli-config.json`\n\n.\n\nRoutes Anthropic models through the stock `claude`\n\nexecutable on `PATH`\n\n:\n\n```\nconsult-llm config set anthropic.backend claude-cli\n```\n\nThe native backend defaults to `claude`\n\n, stream-json output, stdin prompt delivery, and the non-interactive flags needed by consult-llm. Optional native settings:\n\n```\nconsult-llm config set anthropic.reasoning_effort high  # low | medium | high | xhigh | max\nconsult-llm config set anthropic.extra_args '--permission-mode acceptEdits'\n```\n\nUse the `profile`\n\nbackend instead when you need a custom Claude command, env, model env var, or wrapper.\n\nRoutes any model family through a named CLI profile. This is useful when a Claude Code CLI process proxies another provider, for example routing Gemini models through a local [claude-code-proxy](https://github.com/raine/claude-code-proxy):\n\n```\ncli_profiles:\n  claude-gemini-proxy:\n    command: /Users/you/.local/bin/claude\n    env:\n      ANTHROPIC_BASE_URL: http://localhost:18765\n      ANTHROPIC_AUTH_TOKEN: anything\n      ANTHROPIC_SMALL_FAST_MODEL: gemini-3.1-pro-preview\n    model_env: ANTHROPIC_MODEL\n\ngemini:\n  backend: profile\n  cli_profile: claude-gemini-proxy\n```\n\n`model_env`\n\nsets the named environment variable to the requested model ID before launching the profile command. For Anthropic models, use `anthropic.backend: profile`\n\nwhen selecting a named CLI profile. Existing configs that combine `anthropic.backend: claude-cli`\n\nwith `anthropic.cli_profile`\n\nare treated as profile-backed for backward compatibility, but new configs should use `profile`\n\nexplicitly.\n\nFields like\n\n`type: claude-cli`\n\n,`command: claude`\n\n,`interface: stream-json`\n\n,`prompt: stdin`\n\nand flags like`-p`\n\n,`--output-format stream-json`\n\n,`--verbose`\n\n,`--bare`\n\nare defaulted or auto-injected for`claude-cli`\n\nprofiles. Only non-default choices need to be written. See[CLI backend profiles]below.\n\nThe example passes literal environment values and arguments to the CLI process. Prefer a user or project-local config for profiles with `env`\n\nvalues; committed project config rejects `cli_profiles.*.env`\n\nso secrets and machine-local paths do not leak.\n\nRun `consult-llm doctor`\n\nafter configuring it. The provider row should show `via profile`\n\nand the selected profile command, for example `profile 'claude-gemini-proxy' command claude (...)`\n\n.\n\nRoutes through `opencode`\n\nto Copilot, OpenRouter, or other providers:\n\n```\nconsult-llm config set openai.backend opencode\nconsult-llm config set gemini.backend opencode\nconsult-llm config set deepseek.backend opencode\nconsult-llm config set minimax.backend opencode\n\n# Optional: configure OpenCode provider routing\nconsult-llm config set opencode.default_provider copilot\nconsult-llm config set openai.opencode_provider openai\n```\n\nRoutes `openrouter/*`\n\nmodels through OpenCode:\n\n```\nconsult-llm config set openrouter.backend opencode\n```\n\nNo API key needed -- authentication is handled by your OpenCode installation.\nAny `openrouter/*`\n\nmodel ID available in OpenCode works automatically. Add it\nto your config:\n\n```\nopenrouter:\n  backend: opencode\n\nextra_models:\n  - openrouter/xiaomi/mimo-v2.5-pro\n\nallowed_models:\n  - gpt-5.5\n  - gemini-3.1-pro-preview\n  - openrouter/xiaomi/mimo-v2.5-pro\n```\n\nThe `extra_models`\n\nentry adds the model to the catalog; `allowed_models`\n\nmust\nalso list it since it acts as an allowlist. Any `openrouter/*`\n\nmodel ID from\nOpenCode works -- add them to both lists.\n\nThe `openrouter`\n\nselector resolves to the first available enabled model (e.g.\n`openrouter/auto`\n\nwhen no specific model is configured directly).\n\nThe `profile`\n\nbackend selects a named entry from the top-level `cli_profiles`\n\nmap. Each profile defines how consult-llm launches the CLI process:\n\n`type`\n\n: profile executor type (defaults to`claude-cli`\n\n, the only supported value today)`command`\n\n: executable name or path (defaults to`claude`\n\n)`args`\n\n: literal argv entries before the prompt`env`\n\n: literal environment variables passed to the CLI process`effort`\n\n: optional effort level (`low`\n\n,`medium`\n\n,`high`\n\n,`xhigh`\n\n,`max`\n\n); passed as`--effort <level>`\n\nto the CLI`model_env`\n\n: optional env var name set to the requested model ID at launch time`interface`\n\n: output parsing strategy (`text`\n\n,`json`\n\n, or`stream-json`\n\n; defaults to`stream-json`\n\n)`prompt`\n\n: how the prompt is delivered (`stdin`\n\nor`argument`\n\n; defaults to`stdin`\n\n)\n\nFor `claude-cli`\n\nprofiles, the executor auto-injects `-p`\n\n, `--output-format <interface>`\n\n, `--verbose`\n\n, `--bare`\n\nand the env vars `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1`\n\n, `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1`\n\n, `CLAUDE_CODE_DISABLE_UPDATE_CHECK=1`\n\n, and `NO_COLOR=1`\n\n.\n\nProvider blocks reference a profile by name. For example, `gemini.backend: profile`\n\nwith `gemini.cli_profile: claude-gemini-proxy`\n\nuses the profile shown above. For Anthropic, prefer `anthropic.backend: claude-cli`\n\nfor the stock native backend and `anthropic.backend: profile`\n\nwhen selecting a named profile.\n\nCLI backends support multi-turn conversations. The first response includes a\n`[thread_id:xxx]`\n\nprefix; pass that ID back with `--thread-id`\n\nto continue\nthe conversation with full context from prior turns.\n\n```\n> Ask codex what's the best caching strategy for our read-heavy API\n\n⏺ Bash(cat <<'EOF' | consult-llm -m codex\n  What's the best caching strategy for a read-heavy API?\n  EOF)\n  ⎿  [model:gpt-5.5] [thread_id:thread_b1ff711...]\n\n     Redis with TTL-based invalidation. Set short TTLs for volatile data ...\n\n⏺ Codex recommends Redis with TTL-based invalidation, but our payment\n  endpoints need strong consistency. Let me push back on that.\n\n⏺ Bash(cat <<'EOF' | consult-llm -m codex --thread-id thread_b1ff711...\n  What if we need strong consistency guarantees? Does that change your\n  recommendation?\n  EOF)\n  ⎿  [model:gpt-5.5] [thread_id:thread_b1ff711...]\n\n     Yes. With strong consistency, the TTL approach breaks down. Consider\n     write-through caching or cache invalidation on writes instead ...\n\n⏺ Codex revised its recommendation based on the consistency constraint. I'll\n  use write-through caching for the payment endpoints.\n```\n\nThis works with Gemini CLI, Codex CLI, Cursor CLI, OpenCode, and Claude CLI. See the [debate skills](#skills) for multi-LLM workflows that use thread IDs to maintain context across debate rounds.\n\nconsult-llm reads layered YAML config files. Resolution order (highest to lowest precedence):\n\n-\nEnvironment variables\n\n-\n`.consult-llm.local.yaml`\n\n(project-local overrides, not committed to git) -\n`.consult-llm.yaml`\n\n(committed project config) -\n`~/.config/consult-llm/config.yaml`\n\n(user config)Supports\n\n`$XDG_CONFIG_HOME`\n\n. The legacy path`~/.consult-llm/config.yaml`\n\nis still read for backward compatibility.\n\nProject files are discovered by walking up from the current directory to the nearest `.git`\n\nroot or `$HOME`\n\n.\n\n`.consult-llm.local.yaml`\n\nis useful for personal backend or model preferences that you don't want committed. Add it to your [global gitignore](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer) so it's excluded from all projects:\n\n```\necho '.consult-llm.local.yaml' >> ~/.gitignore_global\n```\n\nIf you use [workmux](https://github.com/raine/workmux) worktrees, symlink it into new worktrees automatically by adding it to your `.workmux.yaml`\n\n:\n\n```\nfiles:\n  symlink:\n    - .consult-llm.local.yaml\n```\n\nScaffold the user config and set values:\n\n```\nconsult-llm init-config\nconsult-llm config set default_model gemini\nconsult-llm config set default_models '[gemini, openai, openai]'\nconsult-llm config set gemini.backend gemini-cli\n# Write to project config instead of user config:\nconsult-llm config set --project default_model openai\n# Write to local project overrides (not committed):\nconsult-llm config set --local openai.backend codex-cli\n```\n\nValues are parsed as YAML, so booleans and lists work naturally:\n\n```\nconsult-llm config set no_update_check true\nconsult-llm config set allowed_models '[gemini, openai]'\n```\n\nModel selection has three layers:\n\n`allowed_models`\n\nis the allowlist: it restricts which exact model IDs are enabled and which selectors can resolve. It also validates`default_model`\n\n,`default_models`\n\n, and explicit`--<selector>`\n\nskill flags.`default_model`\n\ncontrols single-response CLI calls where`-m`\n\nis omitted and`default_models`\n\nis empty or unset.`default_models`\n\ncontrols multi-model calls where`-m`\n\nis omitted; it preserves order and duplicates, so`[openai, openai]`\n\nintentionally samples OpenAI twice. When`default_models`\n\nis empty or unset, the CLI falls back to`default_model`\n\n, then the built-in fallback model.\n\nIf `default_models`\n\nnames a model excluded by `allowed_models`\n\n, config loading fails instead of silently using it.\n\nExample `~/.config/consult-llm/config.yaml`\n\n:\n\n```\nallowed_models: [gemini-3.1-pro-preview, gpt-5.5, grok-4.3]\ndefault_model: gpt-5.5\ndefault_models: [gpt-5.5, gpt-5.5]\n\ngemini:\n  backend: gemini-cli\n\nopenai:\n  backend: codex-cli\n  reasoning_effort: high\n\nanthropic:\n  backend: claude-cli\n  reasoning_effort: high\n\ngrok:\n  api_key: your_xai_key\n\nopencode:\n  default_provider: copilot\n```\n\nAPI keys can be set in your user config, a project-local config file, or as environment variables. Environment variables take highest precedence.\n\n**User config** (`~/.config/consult-llm/config.yaml`\n\n), applies everywhere:\n\n```\nopenai:\n  api_key: your_openai_key\ngemini:\n  api_key: your_gemini_key\ngrok:\n  api_key: your_xai_key\n```\n\n**Project-local config** (`.consult-llm.local.yaml`\n\nin the repo root, gitignored), overrides the user config for that project:\n\n```\nopenai:\n  api_key: your_project_specific_key\n```\n\nAPI keys are **not** allowed in `.consult-llm.yaml`\n\n(the committed project config). The tool will refuse to load it and tell you to move the key to `.consult-llm.local.yaml`\n\n.\n\n**Environment variables** (highest precedence, useful for CI):\n\n`OPENAI_API_KEY`\n\n`GEMINI_API_KEY`\n\n`ANTHROPIC_API_KEY`\n\n`DEEPSEEK_API_KEY`\n\n`MINIMAX_API_KEY`\n\n`XAI_API_KEY`\n\n** direnv** is an alternative to\n\n`.consult-llm.local.yaml`\n\nfor project-specific keys via environment variables. Add a `.envrc`\n\nin the repo root and `direnv allow`\n\nit, then put keys in a `.env`\n\nfile (both gitignored):\n\n```\n# .envrc\ndotenv\n# .env\nOPENAI_API_KEY=your_project_specific_key\n```\n\ndirenv loads the variables automatically when you enter the directory and unloads them when you leave.\n\nCost estimates are displayed for known models. Any model name is accepted; cost estimates show as zero for models without pricing data.\n\n## Pricing table\n\n| Model | Input | Output |\n|---|---|---|\nOpenAI models |\n||\n`gpt-5.5` |\n$5.00/M | $30.00/M |\n`gpt-5.4` |\n$2.50/M | $15.00/M |\n`gpt-5.3-codex` |\n$2.50/M | $10.00/M |\n`gpt-5.2` |\n$1.75/M | $14.00/M |\n`gpt-5.2-codex` |\n$1.75/M | $7.00/M |\nGoogle Gemini models |\n||\n`gemini-2.5-pro` |\n$1.25/M | $10.00/M |\n`gemini-3-pro-preview` |\n$2.00/M | $12.00/M |\n`gemini-3.1-pro-preview` |\n$2.00/M | $12.00/M |\nDeepSeek models |\n||\n`deepseek-v4-pro` |\n$0.55/M | $2.19/M |\nMiniMax models |\n||\n`MiniMax-M2.7` |\n$0.30/M | $1.20/M |\nAnthropic models |\n||\n`claude-opus-4-7` |\n$5.00/M | $25.00/M |\nGrok models |\n||\n`grok-4.3` |\n$1.25/M | $2.50/M |\n\nPricing is per million tokens (M). Check the provider's current pricing page before relying on estimates for billing decisions.\n\n```\nconsult-llm init-prompt   # scaffold ~/.config/consult-llm/SYSTEM_PROMPT.md\n```\n\nOverride the path in config:\n\n```\nsystem_prompt_path: /path/to/project/.consult-llm/SYSTEM_PROMPT.md\n```\n\n## All environment variables\n\nEnvironment variables override config file values.\n\n| Variable | Description | Allowed values | Default |\n|---|---|---|---|\n`OPENAI_API_KEY` |\nOpenAI API key | ||\n`GEMINI_API_KEY` |\nGemini API key | ||\n`ANTHROPIC_API_KEY` |\nAnthropic API key | ||\n`DEEPSEEK_API_KEY` |\nDeepSeek API key | ||\n`MINIMAX_API_KEY` |\nMiniMax API key | ||\n`OPENROUTER_API_KEY` |\nOpenRouter API key | ||\n`XAI_API_KEY` |\nxAI API key for Grok models | ||\n`CONSULT_LLM_DEFAULT_MODEL` |\nModel or selector to use for single-response calls when `-m` is omitted |\nselector or exact model ID | first available |\n`CONSULT_LLM_DEFAULT_MODELS` |\nComma-separated ordered multi-model defaults when `-m` is omitted; duplicates preserved |\nselectors or exact model IDs | empty (falls through to default_model then fallback) |\n`CONSULT_LLM_GEMINI_BACKEND` |\nBackend for Gemini models | `api` `gemini-cli` `cursor-cli` `opencode` `profile` |\n`api` |\n`CONSULT_LLM_OPENAI_BACKEND` |\nBackend for OpenAI models | `api` `codex-cli` `cursor-cli` `opencode` `profile` |\n`api` |\n`CONSULT_LLM_DEEPSEEK_BACKEND` |\nBackend for DeepSeek models | `api` `opencode` `profile` |\n`api` |\n`CONSULT_LLM_MINIMAX_BACKEND` |\nBackend for MiniMax models | `api` `opencode` `profile` |\n`api` |\n`CONSULT_LLM_ANTHROPIC_BACKEND` |\nBackend for Anthropic models | `api` `profile` `claude-cli` `cursor-cli` |\n`api` |\n`CONSULT_LLM_GROK_BACKEND` |\nBackend for Grok models | `api` `cursor-cli` `profile` |\n`api` |\n`CONSULT_LLM_OPENROUTER_BACKEND` |\nBackend for OpenRouter models | `api` `opencode` `profile` |\n`api` |\n`CONSULT_LLM_ALLOWED_MODELS` |\nComma-separated allowlist; restricts which models are enabled | model IDs | all |\n`CONSULT_LLM_EXTRA_MODELS` |\nComma-separated extra model IDs to add to the catalog | model IDs | |\n`CONSULT_LLM_CODEX_REASONING_EFFORT` |\nReasoning effort for Codex CLI backend | `none` `minimal` `low` `medium` `high` `xhigh` |\n`high` |\n`CONSULT_LLM_CODEX_EXTRA_ARGS` |\nExtra CLI args appended to `codex exec` (shell-quoted) |\ne.g. `--dangerously-bypass-approvals-and-sandbox` |\n|\n`CONSULT_LLM_GEMINI_EXTRA_ARGS` |\nExtra CLI args appended to `gemini` (shell-quoted) |\nshell-quoted args | |\n`CONSULT_LLM_CLAUDE_REASONING_EFFORT` |\nReasoning effort for native Claude CLI backend | `low` `medium` `high` `xhigh` `max` |\nunset |\n`CONSULT_LLM_CLAUDE_EXTRA_ARGS` |\nExtra CLI args appended to `claude` (shell-quoted) |\nshell-quoted args | |\n`CONSULT_LLM_OPENCODE_PROVIDER` |\nDefault OpenCode provider prefix for all models | provider name | per-model default |\n`CONSULT_LLM_ANTHROPIC_CLI_PROFILE` |\nCLI profile name when `anthropic.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_GEMINI_CLI_PROFILE` |\nCLI profile name when `gemini.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_OPENAI_CLI_PROFILE` |\nCLI profile name when `openai.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_DEEPSEEK_CLI_PROFILE` |\nCLI profile name when `deepseek.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_MINIMAX_CLI_PROFILE` |\nCLI profile name when `minimax.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_GROK_CLI_PROFILE` |\nCLI profile name when `grok.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_OPENROUTER_CLI_PROFILE` |\nCLI profile name when `openrouter.backend` is `profile` |\nprofile name | |\n`CONSULT_LLM_OPENCODE_OPENAI_PROVIDER` |\nOpenCode provider for OpenAI models | provider name | `openai` |\n`CONSULT_LLM_OPENCODE_GEMINI_PROVIDER` |\nOpenCode provider for Gemini models | provider name | `google` |\n`CONSULT_LLM_OPENCODE_DEEPSEEK_PROVIDER` |\nOpenCode provider for DeepSeek models | provider name | `deepseek` |\n`CONSULT_LLM_OPENCODE_MINIMAX_PROVIDER` |\nOpenCode provider for MiniMax models | provider name | `minimax` |\n`CONSULT_LLM_OPENCODE_OPENROUTER_PROVIDER` |\nOpenCode provider for OpenRouter models | provider name | `openrouter` |\n`CONSULT_LLM_SYSTEM_PROMPT_PATH` |\nPath to a custom system prompt file | file path | `~/.config/consult-llm/SYSTEM_PROMPT.md` |\n`CONSULT_LLM_NO_UPDATE_CHECK` |\nDisable background update checks | `1` `true` `yes` |\n\nAll prompts and responses are logged to:\n\n```\n$XDG_STATE_HOME/consult-llm/consult-llm.log\n```\n\nDefault: `~/.local/state/consult-llm/consult-llm.log`\n\nEach entry includes tool call arguments, the full prompt, the full response, and token usage with cost estimates.\n\n## Example log entry\n\n```\n[2025-06-22T20:16:04.675Z] PROMPT (model: deepseek-v4-pro):\n## Relevant Files\n\n### File: src/main.ts\n\n...\n\nPlease provide specific suggestions for refactoring with example code structure\nwhere helpful.\n================================================================================\n[2025-06-22T20:19:20.632Z] RESPONSE (model: deepseek-v4-pro):\nBased on the analysis, here are the key refactoring suggestions to improve\nseparation of concerns and maintainability:\n\n...\n\nThis refactoring maintains all existing functionality while significantly\nimproving maintainability and separation of concerns.\n\nTokens: 3440 input, 5880 output | Cost: $0.014769 (input: $0.001892, output: $0.012877)\n================================================================================\n```\n\n`consult-llm-monitor`\n\nis a real-time TUI for active runs and history.\n\n```\nconsult-llm-monitor\n```\n\nIt reads the per-run spool written by `consult-llm`\n\n, including active snapshots,\nrun metadata, event streams, and shared history.\n\n`consult-llm`\n\nkeeps orchestration in the host agent and uses the CLI as a\nsmall transport boundary. Instead of manually copying context into a browser LLM\nor juggling another agent TUI, your current agent can hand off a focused prompt,\nstream the answer back inline, and continue the conversation from there.\n\nThat boundary also lets the host agent and external model talk to each other in\nmulti-turn workflows. `/consult`\n\ncan ask for a second opinion, `/debate`\n\ncan\nhave models critique each other, and threaded CLI backends can continue the same\nconversation without leaving the agent session.\n\nThe installed skills are reusable workflow definitions; the backend is just\nconfiguration. You can use Codex CLI for personal projects, Cursor CLI at work,\ndirect APIs in CI, or different default model lists per repo while keeping the\nsame `/consult`\n\n, `/debate`\n\n, and `/review-panel`\n\nhabits.\n\nAt runtime, the installed skill decides what context to include, formats the\nprompt, and invokes `consult-llm`\n\nwith stdin plus `-f`\n\nfile attachments. API\nbackends receive only that explicit prompt and file context. CLI-agent backends\nsuch as Gemini CLI, Codex CLI etc. can also inspect the working tree themselves,\ndepending on their own tools and permissions. The CLI resolves layered\nconfiguration, selects the requested backend, streams the model response to\nstdout, and records run metadata for logging and monitoring.\n\nIf you like sequence diagrams, here's one for you:\n\n```\nsequenceDiagram\n    participant User\n    participant Agent as Host agent<br/>(Claude Code, Codex, OpenCode)\n    participant Skill as Workflow skill<br/>(/consult, /debate, /collab)\n    participant CLI as consult-llm CLI\n    participant Config as Config resolver\n    participant Backend as Backend adapter<br/>(API or local CLI)\n    participant Model as External model\n    participant Logs as Logs / monitor spool\n\n    User->>Agent: Ask for a second opinion\n    Agent->>Skill: Load matching workflow skill\n    Skill->>Skill: Gather prompt and file context\n    Skill->>CLI: Pipe prompt via stdin<br/>pass files with -f\n    CLI->>Config: Resolve layered config and model selectors\n    Config-->>CLI: Backend, model, prompt settings\n    CLI->>Backend: Dispatch normalized request\n    Backend->>Model: API request or local CLI invocation\n    Model-->>Backend: Streaming response\n    Backend-->>CLI: Normalized stream and metadata\n    CLI-->>Logs: Write prompt, response, usage, run state\n    CLI-->>Agent: Stream response on stdout\n    Agent-->>User: Summarize and apply next steps\n```\n\nThe skill system has two layers:\n\n** consult-llm (base CLI)** handles the mechanics: reading stdin, attaching file context, calling the right backend, streaming the response, and managing thread IDs for multi-turn conversations. A dedicated\n\n`consult-llm`\n\nreference skill documents this contract and is loaded by other skills before they invoke the CLI.**Workflow skills** compose on top. They gather context from the codebase, decide which models to call and how, and synthesize the results for you. When you run `/consult`\n\nor `/debate`\n\n, the agent reads a skill file that tells it how to orchestrate one or more `consult-llm`\n\ncalls and what to do with the responses.\n\nWhen a workflow skill runs, the agent pipes the prompt via stdin and passes file context with `-f`\n\n:\n\n```\ncat <<'__CONSULT_LLM_END__' | consult-llm -m gemini -f src/main.rs -f src/config.rs\nYour question here.\n__CONSULT_LLM_END__\n```\n\nThe response streams back to stdout and the agent sees it inline. If the response exceeds the shell tool's output limit (30k chars in Claude Code by default), the full output is saved to a file and the agent is notified where to find it; it can use `Read`\n\nto retrieve the rest. In practice this is rare; the large majority of responses are well under that limit.\n\n```\nconsult-llm install-skills\n```\n\nInstalls to all detected platforms. Target a specific one with `--platform`\n\n:\n\n```\nconsult-llm install-skills --platform claude\nconsult-llm install-skills --platform opencode\nconsult-llm install-skills --platform codex\n```\n\nPlatforms supported:\n\n- Claude Code:\n`~/.claude/skills/`\n\n- OpenCode:\n`~/.config/opencode/skills/`\n\n- Codex:\n`~/.codex/skills/`\n\nAll workflow skills accept `--<selector>`\n\nflags matching the selectors reported by `consult-llm models`\n\n(e.g. `--gemini`\n\n, `--openai`\n\n, `--deepseek`\n\n). With no selector flag, multi-model skills use the ordered `Default models`\n\nlist printed by `consult-llm models`\n\n, which comes from `default_models`\n\n; duplicate entries are intentional and preserved.\n\n: ask one or more external LLMs; any number of`consult`\n\n`--<selector>`\n\nflags, plus`--browser`\n\nfor clipboard/web mode: multiple LLMs brainstorm together, building on each other's ideas`collab`\n\n: the agent brainstorms with one partner LLM (`collab-vs`\n\n`--<selector>`\n\nrequired) in alternating turns: multiple LLMs propose and critique competing approaches`debate`\n\n: the agent debates one opponent LLM (`debate-vs`\n\n`--<selector>`\n\nrequired), then synthesizes the best answer: role-asymmetric advisory panel; each model speaks from one expert lens, agent synthesizes a trade-off resolution. The agent picks roles to fit the task (with a`panel`\n\n`--roles`\n\noverride). Modes:`--mode design`\n\n(default) or`--mode review`\n\nfor diff critique: standalone multi-model code review of a diff with identical prompts; agent dedupes findings by severity/confidence. Read-only by default;`review-panel`\n\n`--fix`\n\nopt-in for localized must-fix items: autonomous spec → plan → review → implement → red-team workflow. Evidence-gated reviewers, written feedback ledger, triggered debug loop, opt-in commits. Rigor knob:`implement`\n\n`--rigor lite|standard|deep`\n\n: coordinator that breaks a large task into a DAG of phases, each running`phased-implement`\n\n`/implement`\n\nin its own[workmux](https://github.com/raine/workmux)worktree. Supports sequential, parallel, and mixed dependencies; per-phase merge with`/merge --keep`\n\nand ancestry verification; failure halts dependents. Requires`workmux`\n\n: interactive design session - agent clarifies the idea with the user, fans out to multiple LLMs in parallel for divergent approach generation, user picks one, then co-design with optional multi-LLM critique. Saves a design doc; hand it to`workshop`\n\n`/implement`\n\nto build\n\nSee `skills/*/SKILL.md`\n\nfor the exact prompts and invocation patterns.\n\n```\nconsult-llm update\n```\n\nThis downloads the latest GitHub release, verifies its SHA-256 checksum, updates\n`consult-llm`\n\n, and updates `consult-llm-monitor`\n\nif it lives alongside it.\n\nIf you previously used the MCP server version (`consult-llm-mcp`\n\nnpm package):\n\n-\n**Install the CLI binary**(see[Quick Start](#quick-start)). -\n**Install skills** so your agent can call`consult-llm`\n\nfor you:\n\n```\nconsult-llm install-skills\n```\n\n-\n**Migrate your config.** Any env vars you set in the MCP`\"env\"`\n\nblock can move to`~/.config/consult-llm/config.yaml`\n\n, including API keys.For example, this MCP config in\n\n`~/.claude.json`\n\n:\n\n```\n\"mcpServers\": {\n  \"consult-llm\": {\n    \"command\": \"npx\",\n    \"args\": [\"-y\", \"consult-llm-mcp\"],\n    \"env\": {\n      \"CONSULT_LLM_GEMINI_BACKEND\": \"api\",\n      \"CONSULT_LLM_OPENAI_BACKEND\": \"codex-cli\",\n      \"CONSULT_LLM_CODEX_REASONING_EFFORT\": \"xhigh\",\n      \"CONSULT_LLM_ALLOWED_MODELS\": \"gpt-5.4,gemini-3.1-pro-preview,MiniMax-M2.7\",\n      \"CONSULT_LLM_MINIMAX_BACKEND\": \"opencode\",\n      \"CONSULT_LLM_OPENCODE_MINIMAX_PROVIDER\": \"minimax\"\n    }\n  }\n}\n```\n\nbecomes:\n\n```\nallowed_models: [gpt-5.4, gemini-3.1-pro-preview, MiniMax-M2.7]\n\ngemini:\n  backend: api\n\nopenai:\n  backend: codex-cli\n  reasoning_effort: xhigh\n\nminimax:\n  backend: opencode\n  opencode_provider: minimax\n```\n\nPut this in\n\n`~/.config/consult-llm/config.yaml`\n\nfor user-wide settings, or in`.consult-llm.yaml`\n\nat the project root if the settings were specific to that project. -\n**Remove the MCP server registration** from your Claude Code config (`~/.claude.json`\n\n):\n\n```\n\"mcpServers\": {\n  // remove this entry:\n  \"consult-llm\": { ... }\n}\n```\n\n-\n**Uninstall the npm package** if you installed it globally:\n\n```\nnpm uninstall -g consult-llm-mcp\ngit clone https://github.com/raine/consult-llm.git\ncd consult-llm\njust check\n```\n\n`just check`\n\nruns the standard local validation, including build and tests. Use `cargo build`\n\nor `cargo test`\n\ndirectly only when iterating on one step.\n\nTry the local binary directly:\n\n```\ncat <<'EOF' | cargo run -- -m gemini\nSanity-check the local build and explain what this CLI does well.\nEOF\n```\n\nSee [RELEASE.md](/raine/consult-llm/blob/main/RELEASE.md).", "url": "https://wpnews.pro/news/show-hn-have-your-agent-consult-other-models", "canonical_source": "https://github.com/raine/consult-llm", "published_at": "2026-06-14 07:34:40+00:00", "updated_at": "2026-06-14 08:01:00.392035+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "large-language-models"], "entities": ["Raine", "OpenAI", "Google", "Anthropic", "DeepSeek", "MiniMax", "xAI", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/show-hn-have-your-agent-consult-other-models", "markdown": "https://wpnews.pro/news/show-hn-have-your-agent-consult-other-models.md", "text": "https://wpnews.pro/news/show-hn-have-your-agent-consult-other-models.txt", "jsonld": "https://wpnews.pro/news/show-hn-have-your-agent-consult-other-models.jsonld"}}