CritiqueCode Is the Coding Agent That Cannot Grade Its Own Homework

Most coding agents optimize for the moment a patch appears. That is the easy moment. The expensive moment is later: when the agent says it is finished, the tests it remembered to run are green, and nobody independent has challenged the claim.

CritiqueCode is built for that later moment. The model can write. The model cannot promote its own work to Evidence. Review is not a slash-command afterthought you might forget. After the author claims a unit of work complete, or the write budget trips, the controller captures a Change Capsule and runs local CritiqueCode review as the only review entry.

What CritiqueCode is

CritiqueCode is an interactive author runtime. You run it in the repository you want to edit. It uses the current working directory. You talk to it like other terminal coding agents: describe the change, approve tool use, watch files get written. Slash commands stay in the TUI. They are never sent to the model. Voice mode (/voice, critique-code --voice) transcribes speech with Qwen3 ASR 0.6B so the same prompts and commands can be spoken.

The difference is the job split. The author session implements. Specialists never author the product. Author check output and author transcripts are never Evidence and never leak into specialist or adjudicator prompts. Promotion stays on /review and /ship. none_promoted is not a correctness proof.

How the loop actually works

The model cannot run a process, pick a working directory, or request network on its own. It can call critique_run. You approve or deny each request in the TUI. Output from those checks is still untrusted until review and refute-or-promote. That is the whole product: writes are scoped, spend is routed, and “done” is a controller decision.

Install and first session

Run CritiqueCode in the project you want to change. Keys live in ~/.critique/code/, not in the repository. Override the home directory with CRITIQUE_CODE_HOME if you need an isolated profile.

pnpm critique-code from the Critique checkout uses this repository as cwd unless you pass --cwd. That is the wrong default when you are trying the agent on another project.

Models and attribution

Defaults are boring on purpose. OpenRouter deepseek/deepseek-v4-flash-0731 when OPENROUTER_API_KEY is set. Otherwise Critique Inference critique/auto when a crt_ key or CRITIQUE_API_KEY is present. Then Anthropic, OpenAI, LLM Gateway, Vercel AI Gateway, or a custom OpenAI-compatible endpoint. critique/auto is the coding selector on Critique Inference.

OpenRouter Activity attributes CritiqueCode generations to critique.sh (HTTP-Referer https://critique.sh, title critique.sh), not to the underlying agent kernel. The TTY shows a wordmark, a compact live status (thinking / write path / read path), then a one-line summary before the reply. It does not stream thinking paragraphs. Interactive TTY sessions keep stdout quiet unless you pass --json.

Commands that matter

Depth flags on review are quick, standard, and paranoid. Focus can include general and security. The route derives risk and spend. Pi may receive the route. It cannot increase its own depth, add lanes, or bypass required prechecks. Secret scanning is the only blocking preflight check. If it is missing, unusable, or material, source does not reach Pi.

Why this exists next to Claude Code, Codex, and Cursor

Those tools are good at implementation velocity. Teams already pay for them. CritiqueCode is for people who want the author loop itself to include an independent challenge, without pretending the writer and the judge are the same process. If you already have a coding agent you like, keep it and use the Critique CLI sidecar. If you want one binary that authors and then cannot lie about review, use CritiqueCode.

FAQ