CLI Reference

The Critique CLI is the canonical Critique interface for developers and coding agents.

Command map

Pick the pass that fits the change

Start with critique check for the normal, read-only working-tree validation. It uses Critique's pinned reviewer runtime in a disposable workspace, gives the reviewer the complete repository, and can run focused checks. critique quick is the deliberately lighter option: it inspects the exact change capsule without repository tools, so it can surface a concrete concern quickly but does not claim executable validation. Use critique finish when you need a specific task intent, a repair package, or a verified repair.

# Fast, read-only check before a push
critique quick

# Full, tool-enabled read-only Critique check
critique check

# Normal task-aware finish pass
critique finish \
  --intent "Prevent duplicate charges when an invoice retry races" \
  --repair pack \
  --env auto \
  --json

# Threat-model the current change and safely repair a proven defect
critique cyber --intent "Probe the new account-recovery flow"

# Attack sequencing, retries, and interruption behavior
critique break --intent "Break the changed background job flow"

cyber is a short alias for the focused security pass. break combines stress and reliability lenses. Both default to --repair apply, so a source change occurs only if Critique proves the defect and a separate fresh verifier approves the repair. Use --repair none with critique finish --focus ... when you want evidence without a possible repair.

Work with your coding agent

Run critique integrate --agent all once in a repository to install managed, version-controlled collaboration instructions for Codex, Claude Code, OpenCode, Cursor, and GitHub Copilot. Each caller receives instructions in its native project format.

The coding agent stays in the lead: it implements the user's task, can ask Critique for a second opinion while work is in motion, then asks for an independent finish review when the claim needs proof. It consumes the structured result and explains what Critique found and what changed in the same user conversation. Critique does not take over the task or authorize a broader change.

Keep author context separate from reviewer judgment

Use the task spine when the main agent is making a multi-step change:

critique task start "Prevent duplicate charges when an invoice retry races" \
  --agent claude-code \
  --accept "A retry cannot create a second charge"
critique checkpoint "Implemented the idempotency guard" --agent claude-code
critique review "Recheck the retry behavior against all callers" --json

The ledger preserves the request, acceptance criteria, constraints, and explicit checkpoints. The reviewer receives that contract and the current repository, but not the author's transcript, plan, worklog, claims, confidence, or conclusions. Checkpoints are continuity for the collaboration; they are not proof.

Ask for a second opinion before the finish line

Use critique ask when an independent perspective could change the next implementation decision: competing designs, an uncertain diagnosis, a risky migration, a hard-to-see edge case, or a challenge to the current plan. It is a read-only advisory mode, not a formal review or repair command.

# Ask about the live working tree.
critique ask "What assumption are we making about retry ownership?"

# Keep bounded follow-up context for the same repository.
critique ask "Which failure should we test first?" --session checkout

# Start that named session fresh.
critique ask "Re-evaluate the design after the refactor" --session checkout --new

# Use an interactive prompt when a person is driving the terminal.
critique chat --session checkout

Named sessions are stored locally, scoped to the repository root, and retain bounded continuity across calls. The second brain runs in Critique's pinned runtime. It can inspect the repository, run bounded diagnostics through critique_check, and delegate read-only exploration, but cannot edit the author's tree. Treat its response as advice; use critique review or critique finish when you need an independent finding or executable proof.

Use the native evidence operations

For a durable, state-bound investigation, keep related operations in one ses_* session:

critique observe --session ses_checkout --handoff .critique/handoff.json --from codex --json
critique challenge "Retries cannot charge twice" --session ses_checkout --json --events
critique investigate "duplicate delivery and interruption" --session ses_checkout --json
critique prove f_abc123 --approach reproduction --session ses_checkout --json
critique repair f_abc123 --mode propose --session ses_checkout --json
critique verify --session ses_checkout --finding f_abc123 --criterion "Charges exactly once" --json
critique complete --session ses_checkout --handoff .critique/handoff.json --json

observe treats handoff claims as untrusted author context. challenge and investigate can produce provisional findings, while prove requires independent executable evidence before promotion. complete fails closed when acceptance criteria or regression checks lack current Critique evidence. See Independent verification protocol.

For a normal read-only validation without an explicit repair request, run critique check (or critique check "your question"). It uses the full Critique-owned runtime in a disposable workspace, with complete repository access and focused evidence capture. critique quick is intentionally different: it is a capsule-only glance with no repository tools.

When Critique returns a scoped, unambiguous repair and the agent already has authority under the user's request to edit the working tree, it may resolve that repair and run critique recheck <run-id> --json. It asks the user only when Critique identifies an actual product decision or the repair would exceed the agreed scope.

Progress during longer reviews

An interactive review begins with a branded dithered frame and keeps one terminal line active with the current phase and live elapsed time:

╭──────────────────────── .:*  CRITIQUE REVIEW  *:. ────────────────────────╮
│ Independent proof · current working tree · fresh evidence                  │
╰───────────────────────────────────────────────────────────────────────────╯
⠹ Reviewing the change in an isolated workspace  1m 05s · still working

Critique resolves completed phases into a compact checkmarked timeline and renders a terminal-width-aware result card with the verdict, execution location, exact model, input/output tokens, model cost, Critique fee, runtime, changed paths, proof, and real limitations. If a review runs longer than 90 seconds, the status explains that deeper checks can take longer and shows the Ctrl+C escape hatch. Non-interactive output receives a heartbeat every 30 seconds.

The card links any finding to critique findings <run-id>, which prints the full impact, reproduction, root cause, allowed paths, and validation commands. Coding agents should use critique findings <run-id> --json before acting on a result so their handoff includes the complete evidence rather than only the compact card.

Progress goes to stderr, so an interactive --json run remains visible while stdout stays one valid finish.v1 result. Redirected and CI JSON runs suppress the terminal progress line automatically. The final runtime includes real elapsed time for both successful runs and infrastructure failures.

For a machine-readable progress stream, add --events. Compatibility Finish commands keep writing finish.event.v1 phase records and heartbeats. Native operations write content-bearing critique.event.v1 records such as evidence, claims, findings, decisions, tests, repairs, and the terminal review.complete event. In both cases stderr carries events while stdout remains one terminal JSON document:

critique finish \
  --intent "Verify checkout retries" \
  --repair pack \
  --env auto \
  --json --events

Platform API v1 sessions also expose durable replay and SSE, including Last-Event-ID reconnect. CLI --events remains local process output.

Read repair outcomes literally

Per-issue state reflects real artifacts and work. Only the issue backed by repair_package_artifact is package_ready; a proven issue without its own verified repair or package is unresolved. A compatibility finish.v1 run applies at most one independently verified repair. Native repair sessions can process multiple findings only in their explicit dependency order.

Working-tree contract

critique finish compares the working tree with HEAD by default. It captures staged and unstaged tracked changes together, including deletions, plus bounded safe untracked text files. The capsule is content-addressed, redacts recognized secrets, records exclusions, and never mutates the source repository during review.

Each critic and verifier operates in a temporary clone at the capsule base commit. The patch and safe untracked files are materialized there. Repairs are prepared in another isolated workspace and verified in a fresh workspace before --repair apply may update the source tree.

Why use a fresh workspace?

Critique gives the reviewer the complete repository in an isolated workspace. The diff locates the change, but does not limit review scope. Deep reconnaissance follows callers, tests, schemas, configuration, deployment, and operational paths before the reviewer decides whether a hypothesis is real. The main coding agent's transcript, claims, plan, worklog, confidence, and conclusions are intentionally withheld.

The disposable workspace is what makes the result independent and safe: validation can reproduce the exact candidate change without touching the caller's working tree, relying on leftover local state, or mixing a repair into unfinished work. It is not another coding agent taking over the repository.

Cloud execution uploads a protected snapshot of the full working tree, including uncommitted changes. The cloud critic can inspect the complete repository and run focused commands. When cloud snapshot pooling is enabled, Critique reuses only a credential-free repository base keyed by tenant, repository, code state, and sandbox template; every critic, repairer, and verifier still receives a fresh fork. The verifier never inherits repairer conversation state, provider credentials, or hidden workspace mutations.

Resource and isolation limits

Each local stage runs one disposable workspace at a time and removes it when the stage exits, including on failure. Critique does not keep a second checkout alive while a later stage runs. The default capsule limits are 2 MiB of patch data, 2 MiB of safe untracked files, 256 KiB per untracked file, and 100 untracked files. Local environment hydration is limited to four root .env* files at 256 KiB each and is disabled with --env none.

Cloud snapshots are compressed and capped at 24 MiB. Oversized archives fail before upload with a clear limit message. Archive digests are calculated from a streaming file read, so the CLI does not retain a full archive buffer alongside the encoded capsule. Cloud uploads may be chunked for transport, but the snapshot is still bounded and authenticated. Critique can fan out read-only specialist lanes, but repair and verifier stages remain ordered.

This also keeps pricing legible. Local execution stages are included ($0 Critique fee). When you are signed in, local reviewer model calls route through the Critique Inference API and draw from your Critique credit balance (model_billing: critique_managed). The pinned runtime still belongs to Critique in both signed-in and local-provider configurations. Critique Cloud charges 15¢ per executed stage plus separately reported managed model usage. A normal review usually runs one critic stage. A repair that is applied and independently verified can run three: critic, repair, and verifier.

Re-login required for managed local billing: browser sign-in now issues write:inference on the machine key. If an older key lacks that scope, run critique login again.

Focused review and repair

Normal critique finish selects language and framework skills from the actual change. Add a focused pass when the risk calls for deeper adversarial work:

Focused commands default to --repair apply: a repair is made only after a defect is proven and is published only after a fresh verifier passes. To inspect without changing the source tree, use critique finish --focus security --repair none --intent "...". Repeat --focus to combine lenses.

Security-focused passes run through the same Critique-owned runtime as every other local review. The review is not a separate agent product and does not inherit the main agent's conversation.

Models

The default managed provider alias is deepseek/deepseek-v4-flash-latest. Signed-in users can choose another catalog model in Account, where every option includes its Lobe provider icon and current credit floor. The preference applies to Critique Cloud runs that use auto and new CLI device approvals.

Account and critique models separate temporary provider-sponsored free routes from the managed catalog. They have 0 model-credit cost while available, can rotate or disappear as providers change capacity, and do not carry a Critique zero-data-retention guarantee. Do not send sensitive or regulated code through those routes.

critique model deepseek/deepseek-v4-flash-latest
critique finish --model deepseek/deepseek-v4-flash-latest --intent "Verify the change"

Provider IDs work with Critique Cloud and the pinned reviewer runtime. Use --model provider/model for one run or critique model provider/model to persist the local default. The reviewer model and independent verifier model are separate settings; .critique/profile.json can select the verifier family explicitly.

Terminal result cards and finish.v1 JSON include the exact model identifier reported by the runtime. They also include runtime-reported input/output tokens and provider cost. The runtime version is pinned by the CLI and recorded in its local receipt; unavailable model telemetry is labelled as unreported rather than guessed.

Local or cloud?

Local is the default. Use it for the everyday “check this before I push” job. Critique works in a temporary copy on your machine, then removes that copy.

When you are signed in with critique login, local Critique reviewer runs bill model usage to your Critique credit balance through the Inference API, and sync a usage summary to Account. Source, patches, and capsules never leave the machine for that sync. Run critique sync to backfill local history. Local Critique stage fees stay $0.

If your machine key was issued before Inference scopes were added, run critique login again so the key includes write:inference.

Use cloud when the point is a separate, clean machine: your laptop cannot run the project, you need another environment, or the calling agent is not on the machine with the runtime.

Cloud test environments

1. Run a cloud review:

critique cloud "Run the real tests against this uncommitted change"

2. If the tests need secrets, open [Account](/account), import a **test-only** `.env` as a named cloud environment, and add it to the command:

```bash
critique cloud --cloud-env test "Run the real tests against this uncommitted change"

Critique compresses the current working tree—including staged, unstaged, deleted, renamed, and safe untracked files—and uploads that snapshot for this run. A fresh cloud critic unpacks it, explores relevant repository context, and runs focused checks. When repair is requested, another fresh agent produces a bounded patch and a third fresh agent verifies it.

critique cloud waits for that terminal result. If the local process is interrupted or the wait window ends, run critique wait <run-id> to reconnect; the remote job continues independently. Large working-tree snapshots upload in authenticated chunks and are digest-verified before the remote job is queued.

The sandbox receives selected environment values as process variables, but agents are instructed not to inspect or print them. Values are encrypted at rest, are not included in the uploaded source snapshot, are redacted from output, and are never placed in prompts, patches, or proof artifacts. Use a separate test database and test API keys. Do not import production credentials.

--cloud-env is intentionally explicit. It never uploads your local .env automatically.

Policy

critique init creates .critique/finish.json for durable constraints, time/cost budgets, and the optional security scan. max_seconds and max_cost_cents apply to the whole finish run, across critic, repairer, and verifier—not independently to every stage. If budget runs out before a repair can be freshly verified, Critique reports an unverified budget limitation and does not apply the repair. Repository instructions remain part of the review context, but cannot widen Critique's permissions.

CI

Use critique ci --intent "..." --base <ref> --json with CRITIQUE_API_KEY for non-interactive runs. Cloud execution receives the protected working-tree snapshot, never local environment files.