CritiqueCode vs Cursor
Cursor is the IDE-native coding agent. CritiqueCode is Critique’s terminal author with forced review. Keep Cursor if you live in the editor. Switch only when you want Critique to author, then survive independent review.
CritiqueCode vs Cursor
IDE agent vs forced review.
critique.sh
Pick Cursor when you live in the editor and want Agent (Composer and other models) to search, edit, run the terminal, and checkpoint next to the file tree. 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 Cursor, do not install CritiqueCode as a plugin. Install @critiquedotsh/cli (binary critique) and keep Cursor as the author. CritiqueCode is @critiquedotsh/harness (binary critique-code).
CritiqueCode vs Cursor is usually two questions smashed together. One is “where should the agent sit while it writes?” The other is “who is allowed to treat that write as finished?” Cursor wins the first question for people who want an IDE. CritiqueCode is built for the second.
Cursor documents Agent as the assistant that completes coding tasks, runs terminal commands, and edits files from the side pane (Cmd+I / Ctrl+I). Agent is instructions plus tools plus the model you pick. Tools include search, file read/edit, shell, web, rules fetch, browser control, and image generation. There is no published cap on tool calls per task. Composer 2.5 is Cursor’s own agentic model, tuned for long-horizon coding, tool use, file edits, and terminal work inside Cursor.
CritiqueCode is a terminal author, not an IDE. You run critique-code in the repo cwd. After a claimed unit of work, or a write-budget trip, the Author Coordinator forces runLocalCritiqueCodeReview. Author transcripts never become Evidence. /review and /ship own promotion. Read the product intro in Introducing CritiqueCode. For the three-way split (IDE vs OpenAI CLI vs CritiqueCode), see Cursor vs Codex vs CritiqueCode. More comparisons live on the comparisons hub.
CritiqueCode vs Cursor at a glance
| Dimension | Cursor | CritiqueCode |
|---|---|---|
| Job | IDE-native Agent: search, edit, run terminal, checkpoint, and iterate next to the file tree. | Critique author agent: implement in session, then forced review and verified repair before promotion. |
| Runtime | Cursor desktop (Agent side pane). Also Agents Window, Cursor CLI, web, and mobile as Cursor documents them. Composer 2.5 is Cursor-only. | 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 review diffs, checkpoints, and editor UX. Agent can keep calling tools until the task ends. Ask / Plan / Debug modes change how aggressive the write loop is. Review is 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. |
| Evidence | Diffs, local checkpoints, tests Agent ran, and Git 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. |
| Repair / rollback | Local checkpoints before significant edits. Restore from the chat timeline. Cursor’s docs say checkpoints are for undoing Agent turns. Use Git for durable history. | Verified repair may apply only if the coordinator allows it. Promotion stays on /review and /ship. |
| Install | Install the Cursor app. Open a folder. Open Agent with Cmd+I / Ctrl+I. Pick a model (Composer 2.5 or another Cursor-supported model). | npm install --global @critiquedotsh/harness, then cd into the repo you want to edit and run critique-code. Keys live in ~/.critique/code/. |
| Package / binary | Cursor app (Agent + Composer). Not an npm author agent. | @critiquedotsh/harness; binary critique-code. Sidecar for Cursor is @critiquedotsh/cli / critique. |
What Cursor Agent and Composer actually are
Cursor’s Agent overview is explicit: Agent is instructions (system prompt plus project rules), tools, and the model you pick. Cursor tunes instructions and tools per frontier model. You stay in the editor. Agent searches files, reads (including images for vision-capable models), edits, runs shell against your default terminal profile, searches the web, fetches rules, can drive a browser for screenshots and UI checks, and can generate images into assets/ by default.
Queued messages wait until the current turn finishes unless you send immediately (Cmd+Enter in Cursor’s docs). Checkpoints snapshot modified files before significant Agent edits. They live locally, separate from Git. That is a strong undo story for exploratory refactors. It is not independent review.
Composer 2.5 is Cursor’s agentic model. Cursor’s model docs describe it as stronger on long agentic tasks, effort calibration, tool selection, and reliability than Composer 2. The Composer product page states it is available in the desktop app, web, CLI, and mobile, and that you can build agents on it with the Cursor SDK. Standard list price on that page is $0.50 per million input tokens and $2.50 per million output tokens, with a faster variant at $3 / $15 per million. Fast is the default in product. Those are Cursor’s published token rates, not a quality score.
Cursor also documents Agent, Ask, Plan, and Debug modes. Agent writes. Ask is read-only. Plan wants you to approve the approach first. Debug is for bugs that need runtime evidence. Helpful. Still the same product family grading work it can also write.
What CritiqueCode actually does
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.
/review and /ship, not because the author said the tests were green.If you already use Cursor, 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. Cursor stays the author. The sidecar is the independent finish pass.
| You already have | Install | Binary | Job | |
|---|---|---|---|---|
| Cursor (keep it) | Cursor Agent / Composer 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 Cursor in the editor, or CritiqueCode in the repo on disk. If you keep Cursor, the sidecar is critique. If you want Critique to write the change, the binary is critique-code. That split is documented in the CritiqueCode docs and in Introducing CritiqueCode.
- 1Do you already use Cursor and like Agent next to the file tree?Keep Cursor. Install
@critiquedotsh/cliand usecritiqueas the independent sidecar. Do not replace Cursor with CritiqueCode unless you want Critique to author. - 2Do 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. - 3Were you told to “just use CritiqueCode” inside Cursor as a plugin?Wrong product. Sidecar for an existing agent is
@critiquedotsh/cli(critique). CritiqueCode is the author binarycritique-code. - 4Do you need Tab, VS Code extensions, and inline diffs more than a terminal author?Stay on Cursor. CritiqueCode is not an IDE. Pair it only if you want Critique to author in the terminal, or keep Cursor and add the sidecar.
FAQ
critique as the sidecar. Switch to critique-code only when you want Critique to implement, then survive forced review.