Skip to content
Skip to content
Comparisons11 min read

CritiqueCode vs Claude Code: When to Keep, Switch, or Combine

Claude Code is Anthropic’s terminal coding agent. CritiqueCode is Critique’s author agent with forced review. Most teams that already like Claude Code should keep it and add a sidecar, not replace it.

Repath Khan

CritiqueCode vs Claude Code

Keep, switch, or combine.

critique.sh

Direct answer

Pick Claude Code when you want Anthropic’s agentic coding tool in the terminal (and its other surfaces) and you already trust that workflow. Pick CritiqueCode when you want Critique to author the change in an interactive Pi session, then force independent review before “done” means anything. If you already use Claude Code, do not install CritiqueCode as a sidecar. Install @critiquedotsh/cli (binary critique) and keep Claude Code as the author. CritiqueCode is @critiquedotsh/harness (binary critique-code).

CritiqueCode vs Claude Code is a search that usually hides two different questions. One is “which terminal agent should write the patch?” The other is “who is allowed to treat that patch as finished?” Those are not the same product decision.

Claude Code is good at the first question. Official Anthropic docs describe it as an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. It ships in the terminal, IDE extensions, a desktop app, and the browser. Teams should keep it when that is the author they already pay for and know how to steer.

CritiqueCode is built for the second question. It is an interactive author session that implements, then the Author Coordinator forces runLocalCritiqueCodeReview. Author transcripts never become Evidence. /review and /ship own promotion. Read the product intro in CritiqueCode and the install contract in the CritiqueCode docs. For the wider verification argument, see best coding agent 2026.

Fair comparison, different jobs
This is not a scoreboard. Claude Code wins if your bottleneck is implementation velocity on Anthropic’s agent. CritiqueCode wins if your bottleneck is an author that cannot grade its own homework.
Claude Code rows follow Anthropic’s published overview at code.claude.com/docs. CritiqueCode rows follow the current CritiqueCode docs. Features Anthropic has not documented are omitted.
DimensionClaude CodeCritiqueCode
JobAnthropic’s agentic coding tool: implement, edit, run commands, manage local git workflows.Critique author agent: implement in session, then forced review and verified repair before promotion.
RuntimeTerminal CLI (claude), plus IDE, desktop, and web surfaces documented by Anthropic.Interactive Pi author session in the target repo. Process uses cwd. Slash commands stay in the TUI and are never sent to the model.
ReviewYou can ask it to review, add hooks, skills, or CI jobs. Review is not a separate controller that 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.
EvidenceSession output, tests it ran, and git history you keep. 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.
InstallOfficial native installer (curl -fsSL https://claude.ai/install.sh | bash on macOS/Linux/WSL), Homebrew cask, WinGet, or Linux packages. Then cd into a project and run claude.npm install --global @critiquedotsh/harness, then cd into the repo you want to edit and run critique-code. Keys live in ~/.critique/code/.
Model flexibilityClaude models via Claude subscription or Anthropic Console. Terminal CLI and VS Code also support third-party providers, per Anthropic’s overview.OpenRouter default when OPENROUTER_API_KEY is set, else Critique Inference critique/auto, then Anthropic, OpenAI, LLM Gateway, Vercel AI Gateway, or a custom OpenAI-compatible endpoint.

You run critique-code in the repository you want to change. You talk to it like other terminal coding agents: 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. The model cannot run a process, pick a working directory, or request network on its own.

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.

Claude Code (typical author loop)
Start `claude` in the repoEdit files and run commandsOptional self-checks, hooks, or CICommit or open a PR when you are satisfied
CritiqueCode (author, then forced review)
Interactive Pi author sessionYou approve each `critique_run`Coordinator captures a Change CapsuleForced `runLocalCritiqueCodeReview``/review` and `/ship` own promotion

Claude Code is Anthropic’s agentic coding tool. The official overview says it reads your codebase, edits files, runs commands, and integrates with development tools. The terminal CLI is the full-featured local surface: edit files, run commands, manage the project from the command line. First-run login uses a Claude subscription or Anthropic Console account. If ANTHROPIC_API_KEY is set, the CLI skips the login prompt and asks you to approve the key instead.

Anthropic documents more than a single CLI. There is a VS Code extension (also listed for Cursor), a JetBrains plugin that still requires the CLI, a desktop app, and Claude Code on the web. The same docs describe CLAUDE.md project instructions, auto memory, skills, hooks, subagents, background agents, git workflows, and composable -p prompts you can pipe into. Terminal CLI and VS Code support third-party providers. That is a strong, documented product. This post does not invent extra capabilities, and it does not argue that you should throw it away.

Many teams should keep Claude Code. If the agent already matches how you write software, the expensive mistake is ripping it out because a comparison table exists. The cheaper move is to put an independent finish pass next to it.

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.

Two Critique packages. Do not swap them.
Do not call `critique finish` as a substitute for CritiqueCode. Do not install CritiqueCode by changing the sidecar package.
You already haveInstallBinaryJob
Claude Code (keep it)Claude Code as the author@critiquedotsh/clicritiqueSidecar reviewer. Independent finish pass. Not CritiqueCode.
Want Critique to authorNo existing author, or you want Critique’s loop@critiquedotsh/harnesscritique-codeAuthor agent with forced local review and verified repair.

The local path is the whole recommendation. Run Claude Code (or CritiqueCode) in the repo on disk. If you keep Claude Code, the sidecar is critique. If you want Critique to write the change, the binary is critique-code. That is the split. It is documented in CritiqueCode and in the introducing CritiqueCode post.

Keep, switch, or combine
  1. 1
    Do you already use Claude Code and like the author loop?
    Keep Claude Code. Install @critiquedotsh/cli and use critique as the independent sidecar. Do not replace Claude Code with CritiqueCode unless you want Critique to author.
  2. 2
    Do you want the author itself to be forced through Critique review?
    Install @critiquedotsh/harness, cd into the target repo, and run critique-code. You approve critique_run. The coordinator forces runLocalCritiqueCodeReview. /review and /ship own promotion.
  3. 3
    Were you told to “just use CritiqueCode” on top of Claude Code as a plugin?
    Wrong product. Sidecar for an existing agent is @critiquedotsh/cli (critique). CritiqueCode is the author binary critique-code.
  4. 4
    Is the goal a remote platform, GitHub App, MCP server, or cloud execution host?
    That is not this comparison. CritiqueCode vs Claude Code is a local author-and-review contract. Stay on the CLI in the repository you mean to change.

Pick the binary that matches the job
Keep Claude Code if it already authors well. Add critique as the sidecar. Switch to critique-code only when you want Critique to implement, then survive forced review.