consult-llm is a tool for getting a "second opinion" from another AI model within an existing agent workflow. It was developed by raine and is hosted on GitHub. Its core idea is: a model reviewing its own work is not an independent check, and even in a new context it still shares the same training, priors, and many of the same failure modes; whereas different models are trained differently and make different mistakes, and are more likely to offer counterarguments, challenge weak reasoning, or expose blind spots. Model strengths vary by task and are hard to predict, quick cross-checking is low-cost, and sometimes another model can find a way forward.
Main capabilities include: getting a second opinion from another model from the agent along with relevant file context (/consult); having models debate the best approach and synthesize a consensus (/debate); using an existing subscription via a CLI backend without an API key (supporting Gemini CLI, Codex CLI, Pi, Cursor CLI, Claude CLI, OpenCode); continuing a conversation across requests using thread_id; copying prompts to the clipboard for use with browser-based LLMs (--web); monitoring activity and historical runs in a live TUI.
How to use: first install the binary, then configure the backend. The CLI backend is simplest when you already have a subscription and requires no API key; you can also set an API key. After that, run the verification command to check the setup, then install the skill so the agent can call consult-llm. It is triggered in Claude Code, OpenCode, or Codex via /consult, /debate, /collab; in Pi, use /skill:consult, /skill:debate, /skill:collab. The skill pipes the prompt into consult-llm, which calls the backend and streams the response back inline.
In terms of configuration, consult-llm separates model families from backends. Model families include gemini, openai, deepseek, minimax, anthropic, grok, zai, openrouter. Backends include api (direct HTTP calls using an API key) and CLI backends (calling locally installed and logged-in CLI tools). The API backend is the default backend, and the endpoint can be overridden via base_url or environment variables. A key advantage of the CLI backend is that the CLI Agents can browse the codebase, run commands, and research on their own before responding, whereas the API backend only receives the prompt and explicitly included files.
Multi-turn conversation: The CLI backend supports multi-turn conversation. The first response includes a [thread_id:xxx] prefix; pass that ID back via --thread-id to continue the conversation and retain the full context of previous turns. Applies to Gemini CLI, Codex CLI, Cursor CLI, OpenCode, and Claude CLI.
Configuration is read from layered YAML files, in descending priority: environment variables, .consult-llm.local.yaml (project-local override, not committed to git), .consult-llm.yaml (committed project configuration), ~/.config/consult-llm/config.yaml (user configuration, supports $XDG_CONFIG_HOME; the legacy path ~/.consult-llm/config.yaml is still read for backward compatibility). Project files are discovered by searching upward from the current directory to the nearest .git root or $HOME.
Model selection has three layers: allowed_models is the allowlist, restricting which exact model IDs are enabled and which selectors can resolve; default_model controls single-response CLI invocations when -m is omitted and default_models is empty or unset; default_models controls multi-model invocations when -m is omitted, preserving order and duplicates. Selectors such as anthropic resolve to the best enabled model of that family according to the built-in priority order, and a specific model can be specified via <provider>.selector_model.
API keys can be set in the user configuration, project-local configuration, or environment variables, with environment variables taking highest priority. API keys are not allowed in .consult-llm.yaml (the committed project configuration).
Use cases: planning architecture, reviewing changes, debating approaches, solving tricky bugs, using free browser LLM services instead of API credits, preferring a specific LLM's web interface, reviewing the full prompt before committing.
Limitations: Some features depend on specific CLI tools and login status; API keys cannot be written into the committed project configuration; base_url is not allowed to be set in the committed project configuration because it controls where API credentials are sent; the shared project configuration rejects literal provider env values and cli_profiles.*.env to prevent secrets and machine-local paths from leaking.
