CritiqueCode vs OpenCode
OpenCode is an open-source, model-agnostic coding agent for the terminal (plus desktop and IDE). CritiqueCode is Critique’s author agent with forced independent review. They are not the same project.
CritiqueCode vs OpenCode
Open-source author vs forced review.
critique.sh
Pick OpenCode when you want an MIT-licensed, model-agnostic coding agent you can run in a TUI, desktop app, or IDE extension, with 75+ providers via Models.dev and optional OpenCode Zen. Pick CritiqueCode when you want Critique to author in an interactive Pi session, then force independent review before promotion. OpenCode is published at opencode.ai by the anomalyco project. It is not owned, operated, or rebranded by Critique. If you already like OpenCode as the author, keep it and install @critiquedotsh/cli (binary critique). Do not install CritiqueCode as a sidecar. CritiqueCode is @critiquedotsh/harness (binary critique-code).
CritiqueCode vs OpenCode is usually two questions jammed into one query. The first is “which open terminal harness should write the patch?” The second is “who is allowed to treat that patch as finished?” OpenCode is built for the first. CritiqueCode is built for the second.
OpenCode’s own intro calls it an open source AI coding agent, available as a terminal interface, desktop app, or IDE extension. You cd into a project, run opencode, optionally /init to write AGENTS.md, then Plan or Build. That is a real, documented product with a large community. This post does not steal its stars, and it does not pretend Critique ships it.
CritiqueCode is the author agent in @critiquedotsh/harness. You talk to it in the repo, approve critique_run, then the Author Coordinator forces runLocalCritiqueCodeReview. Author transcripts never become Evidence. /review and /ship own promotion. Product intro: Introducing CritiqueCode. Install contract: CritiqueCode docs. For the wider open-source field, see best open source coding agents 2026 and the comparisons hub.
CritiqueCode vs OpenCode at a glance
| Dimension | OpenCode | CritiqueCode |
|---|---|---|
| Job | Open-source AI coding agent: implement, plan, edit, run tools, share sessions. | Critique author agent: implement in session, then forced review and verified repair before promotion. |
| Publisher | anomalyco / OpenCode at opencode.ai. MIT-licensed source at github.com/anomalyco/opencode. Independent of Critique. | Critique.sh. Package @critiquedotsh/harness, binary critique-code. Not a fork of OpenCode. |
| Runtime | TUI in the current directory (opencode), plus documented desktop app and IDE extension. Plan and Build as primary agents. Subagents: General, Explore, Scout. | Interactive Pi author session in the target repo. Process uses cwd. Slash commands stay in the TUI and are never sent to the model. |
| Review | You can add a custom review subagent, Plan mode (edits and bash default to ask), and permission rules. Review is optional configuration, not a separate controller the author cannot skip. | After a claimed unit of work, or a write-budget trip, the Author Coordinator forces runLocalCritiqueCodeReview as the only review entry. |
| Permissions | Documented permission config: allow, ask, or deny per tool. Official defaults are permissive: most tools allow. doom_loop and external_directory default to ask. .env reads are denied by default. --auto auto-approves requests that are not denied. | The model can call critique_run. You approve or deny each request. It cannot run a process, pick a working directory, or request network on its own. |
| Evidence | Session output, tests it ran, /undo and /redo, shared conversation links. The same agent that wrote the change can also narrate why it is done. | Author check output and author transcripts are never Evidence and never leak into specialist or adjudicator prompts. Promotion stays on /review and /ship. |
| Install | curl -fsSL https://opencode.ai/install | bash, or npm install -g opencode-ai, Homebrew tap anomalyco/tap/opencode, plus Arch, Chocolatey, Scoop, Mise, Docker, and GitHub releases as documented. | npm install --global @critiquedotsh/harness, then cd into the repo you want to edit and run critique-code. Keys live in ~/.critique/code/. |
| Models | Any LLM provider via /connect. Official providers docs: 75+ providers through the AI SDK and Models.dev, including local models. OpenCode Zen is a curated catalog the OpenCode team tests for coding agents. Keys stored in ~/.local/share/opencode/auth.json. | Critique Inference critique/auto after critique-code login. OpenRouter, OpenAI, Anthropic, and other BYOK keys remain in /keys and /settings. |
What OpenCode is, from its own docs
OpenCode is the open source AI coding agent at opencode.ai. The docs tell you to install, /connect a provider, cd into a project, run opencode, then /init so it can analyze the repo and write AGENTS.md. Plan mode (Tab) disables edits so the model can propose an implementation. Build mode makes the changes. /undo and /redo revert or restore the last agent edits. /share creates a link to the current conversation.
The agents page documents two built-in primary agents (Build and Plan) and three built-in subagents (General, Explore, Scout). You can add your own in opencode.json or markdown under ~/.config/opencode/agents/ and .opencode/agents/. A review-style subagent with edit: deny is a documented pattern. That is useful. It is still the same harness configuring a specialist. It is not an independent controller that fires after every claimed unit of work whether the author wants it or not.
Providers docs say OpenCode uses the AI SDK and Models.dev for 75+ LLM providers and local models. /connect stores keys in ~/.local/share/opencode/auth.json. Zen is optional: a handpicked set of models OpenCode has tested for coding agents, billed through opencode.ai/auth if you choose that path. You can also bring Anthropic, OpenAI, Google, Copilot login, ChatGPT Plus/Pro login, or a custom OpenAI-compatible endpoint. That model-agnostic story is the product’s honest strength.
Permissions default to allow for most tools. The docs are explicit about this. doom_loop (same tool call three times with identical input) and external_directory default to ask. .env files are denied on read unless you override. You can tighten everything to ask, deny git push, or run --auto so non-denied prompts auto-approve. Configure that if you care. Do not assume a fresh install behaves like a locked-down review gate.
What CritiqueCode actually does
You run critique-code in the repository you want to change. You describe the work, approve tool use, watch files get written. The model can call critique_run. You approve or deny each request in the TUI.
That is the author half. The controller half is the point of the product. When the author claims a unit of work complete, the Author Coordinator captures a Change Capsule and runs local CritiqueCode review. Specialists never author the product. none_promoted is not a correctness proof. Quiet review is still not a guarantee.
/review and /ship, not because the author said the tests were green.If you already use OpenCode, install the sidecar
This is the mix-up that will waste a Saturday. Critique ships two packages in the same npm org. They are not aliases. They are not a rename of OpenCode either.
| You already have | Install | Binary | Job | |
|---|---|---|---|---|
| OpenCode (keep it) | OpenCode as the author | @critiquedotsh/cli | critique | Sidecar reviewer. Independent finish pass. Not CritiqueCode. |
| Want Critique to author | No existing author, or you want Critique’s loop | @critiquedotsh/harness | critique-code | Author agent with forced local review and verified repair. |
The local path is the whole recommendation. Run OpenCode or CritiqueCode in the repo on disk. If you keep OpenCode, the sidecar is critique. If you want Critique to write the change, the binary is critique-code. That split is documented in CritiqueCode and in Introducing CritiqueCode.
- 1Do you already use OpenCode and like the author loop?Keep OpenCode. Install
@critiquedotsh/cliand usecritiqueas the independent sidecar. Do not replace OpenCode with CritiqueCode unless you want Critique to author. - 2Do you need MIT source, 75+ providers, Plan/Build, and a forkable TUI?Stay on OpenCode. That is what opencode.ai documents. CritiqueCode is not a drop-in OpenCode fork.
- 3Do you want the author itself to be forced through Critique review?Install
@critiquedotsh/harness,cdinto the target repo, and runcritique-code. You approvecritique_run. The coordinator forcesrunLocalCritiqueCodeReview./reviewand/shipown promotion. - 4Were you told Critique owns OpenCode, or that CritiqueCode is “OpenCode with a skin”?Wrong. OpenCode is the anomalyco project. CritiqueCode is
@critiquedotsh/harness. They compete as terminal authors. They are not the same codebase.
FAQ
critique as the sidecar. Switch to critique-code only when you want Critique to implement, then survive forced review.