CritiqueCode 0.1.0 Shipped a Contract. This Is Everything After.

Changelogs lie by accumulation. A list of commands looks like a new product. It is not. CritiqueCode 0.1.0 shipped one decision: the model may write, and it may not promote its own work. Everything after that date is a surface, a route, or a way to fan out implementation without moving the ship gate.

This essay is the comparison people actually search for. What did 0.1.0 include. What 0.1.3 adds. Why each piece exists. What we refused to add so the contract would still mean something a week later.

What CritiqueCode 0.1.0 actually shipped

CritiqueCode is Critique’s author agent. You run it in the git repository you mean to edit. It uses the current working directory. The live kernel is the open-source Pi coding agent library. CritiqueCode imports that library. It does not spawn the pi CLI, and it is not a rename of the Critique CLI sidecar (@critiquedotsh/cli, binary critique).

0.1.0 already had the loop that still defines the product. The author writes through a content-addressed apply path. critique_run is the only workspace exec path, and you approve or deny each request. After a claimed unit of work, or a write-budget trip, the Author Coordinator captures a Change Capsule and runs local review with the author transcript withheld. /repair is verified repair of promoted findings, not auto-applied chatter. Slash lines never go to the model.

The TTY was already a TTY on purpose. Thinking and tools collapse to one live line, then a one-line ▸ summary. It does not stream thinking paragraphs. Interactive sessions keep stdout quiet unless you pass --json. OpenRouter Activity, when that route is used, attributes generations to critique.sh, not to the underlying kernel.

CritiqueCode 0.1.0 vs 0.1.3

Read this table as a product argument, not a feature bingo card. If a row moved, it moved because 0.1.0 made a daily-use tax we were not willing to keep. If a row did not move, it is the contract.

Why website login replaced the pasted-key ritual

0.1.0 could run if you already lived in API keys. That is a fine onboarding story for people who already have OpenRouter, Anthropic, or OpenAI in the environment. It is a terrible first run for everyone else. The failure mode is familiar: the binary prints kernel_required, the user pastes a key into a chat, and you have taught them that credentials belong in the prompt.

critique-code login is the fix. The terminal prints a URL and a short code, opens the browser when it can, and waits. You approve on critique.sh/device. CritiqueCode stores a machine key under ~/.critique/code/ (mode 0600) and sets the default route to Critique Inference. Same flow from an open session: /login. Nothing secret is written into the repository.

BYOK did not go away. /keys and environment variables still accept OpenRouter, OpenAI, Anthropic, Gemini, xAI, Groq, DeepSeek, LLM Gateway, Vercel AI Gateway, and a custom OpenAI-compatible endpoint. If Inference is connected, it stays the default until you change the route in /settings. That order is the product: get to a working author without a paste, then let specialists bring their own providers.

Why critique/auto is the default coding selector

Pinning one frontier model for every turn is how a coding agent looks serious and wastes money. Dumping the session onto a popularity router is how you get a consumer chatbot that happens to see your repo. Neither is a coding policy.

After login, the default model is `critique/auto` on the Inference API. It is a session coding selector over Critique-resold models only: an efficient specialist first, sticky while the loop is healthy, one escalate onto a frontier rung if tools keep failing. It does not search the full OpenRouter catalogue. Credits bill the routed id, not the word auto. The argument is in Stop putting Kimi on a rename.

Inference traffic bills raw USD from token rates. That spend does not consume the PR review credit pool. Voice is a different meter: $0.000003 per second of audio through qwen/qwen3-asr-0.6b. OpenRouter remains selectable. When that route is on, the default model is deepseek/deepseek-v4-flash-0731.

Why voice mode is dictation, not a spoken assistant

A long intent is easier to say than to type. A review command is easier to bark than to slash. 0.1.0 had no microphone path, so people either typed a paragraph or abandoned the TTY. Voice mode is the missing input, not a second agent.

/voice records one clip (Enter to stop). /voice on keeps listening after each reply. critique-code --voice starts already listening. Transcription uses Qwen3 ASR 0.6B. Spoken review, repair, ship, and exit still run as commands. An empty clip after /voice on returns you to the keyboard. The recorder is bundled ffmpeg-static. You do not need a system sox install.

Replies stay on screen. The agent does not read them aloud. Voice still needs an interactive TTY, which is why the local web UI does not pretend to own the microphone yet. Product notes: Talk to code.

Why CritiqueCode loads Claude Code and Codex skills

People do not start from a blank SKILL.md. They already have folders under .claude/skills, .codex/skills, .cursor/skills, .agents/skills, .opencode/skills. 0.1.0 already loaded AGENTS.md, CRITIQUE.md, and CLAUDE.md as author instructions. That was not enough. A coding agent that ignores the skills you already wrote is asking you to migrate for sport.

Current CritiqueCode ships built-in author skills for code review, when to run `/review`, and TDD. Every session also loads SKILL.md from those project and home directories. Built-in names win on collision, so a Claude Code skill named code-review cannot replace /review. Imported skills are untrusted text, same as CLAUDE.md. They cannot grant a shell or treat checks as Evidence.

critique-code skills lists the catalog. critique-code import-skills copies discovered folders into ~/.critique/code/skills so they survive after you uninstall the old harness. /skills is the same list in the TUI. Independent evidence still happens on /review / /ship, not as a Claude Code-style reviewer subagent.

Why critique_task workers cannot replace /review

0.1.0 was one author. That is slow when the next step is “find every call site” or “implement this slice while I keep talking.” Claude Code solved the latency with subagents. The failure mode is obvious if you have watched an agent review its own patch: the worker that wrote the code is happy to LGTM it.

0.1.3 adds `critique_task`. The author can fan out explore (read-only search), general, or implement slices in the same working tree. Up to three run at once. Writes still go through the CAS path. critique_run still needs your approval. Workers cannot nest critique_task. Explore workers cannot write or request a run.

The ship gate did not move. Independent evidence still happens on /review / /ship. Worker output and critique_run output are not Evidence. That is the whole point of adding workers inside this harness instead of telling people to spawn a second coding agent and hope it is honest.

Why critique-code web stays on 127.0.0.1

The TUI is a tax. You cannot select a tool card with a mouse. You cannot keep a review panel beside the chat without splitting tmux. OpenCode already shipped opencode web. Codex published the same split as an app-server. Copying their product would have been the cheap way to look current. It would also have mixed two Critique packages and thrown away the tool policy.

critique-code web is a second client of the same author loop. It binds 127.0.0.1 only. 0.0.0.0 is rejected. The kernel stays in this process: Pi createAgentSession, CAS writes, user-gated critique_run in a modal, /review / /repair / /ship with the author transcript withheld. APIs sit behind a per-process token. A foreign Origin on POST returns 403. The tab can close. The process keeps going.

It is not OpenCode’s SolidJS app. It is not Pi’s browser Agent with IndexedDB keys. It is not Critique Cloud. Voice still lives on the TTY path. Settings pickers still have a terminal UI. We did not wrap Electron, add an LSP, or ship an unrestricted terminal. Those are how a “web coding agent” quietly becomes a different product. The write-up is CritiqueCode leaves the terminal.

What did not change after CritiqueCode 0.1.0

This is the section that should survive a rewrite of the rest of the binary. If a later version moves these rows, it is a different product and should say so.

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

How to upgrade from CritiqueCode 0.1.0

There is no migrate step and no new binary name. Install the current package, cd into the repository you intend to change, and connect Inference if you have not already. Node.js 20.19 or newer is still required. pnpm critique-code from a Critique checkout uses that checkout as cwd unless you pass --cwd. That is still the wrong default when you are trying the agent on another project.

FAQ