Introducing Workspace: one place for review, chat, build, and repair
Critique is merging PR review, Chat, Builder, and Remedy into a single operating surface — one rail, one ledger, one always-on engineer.

One surface. Four jobs.
May 2026 · Workspace
critique.sh
Review
Was a separate surface
Chat
Was a separate surface
Builder
Was a separate surface
Remedy
Was a separate surface
Now one place
Workspace
One left rail. One credit ledger. One repo context that follows you from question to verdict to patch to build.
What is Critique Workspace?
Critique Workspace is Critique’s unified operating environment for software teams. It replaces the old pattern of opening Chat in one tab, Builder in another, and the dashboard for review runs in a third. You pick a repository once, work in one left rail, and move between explanation (Chat), enforcement (PR review), repair (Remedy), and execution (Builder) as modes — not separate products.
For the last year, Critique grew the way most serious products do — one sharp wedge at a time. Review landed on the pull request. Chat gave you repo-grounded answers between PRs. Remedy closed the gap between finding and fix. Builder exposed the same sandbox fabric for open-ended execution. Each surface worked. Together, they still felt like four rooms in the same house with four different door locks.
That fragmentation had a cost you probably felt even if you never named it. You explained the same bug twice — once in Chat, again when a review run started. You lost thread context when you jumped from a verdict to a Remedy attempt. Builder history lived in one rail while chat lived in another. The product rhymed architecturally; the interface did not.
Why did Critique merge four products into Workspace?
The trigger was not aesthetic. It was behavioral. Teams using Critique heavily were already treating the product as a loop: ask in Chat, review on the PR, fix with Remedy, extend with Builder. The value compounded when context traveled with them. When it did not, the loop broke — and the break always happened at a tab boundary.
Workspace removes the mode tax. Not by hiding Review, Chat, Builder, or Remedy — but by making them modes inside one session instead of destinations you navigate between. Same dark, quiet shell. Same left rail for recent chats and builder runs. Same composer when you need to say what should happen next.
What Workspace is — and what it is not
The signed-in working surface at /workspace. One rail for history, one context bundle for the active repo, and mode-aware actions that hand off between conversation, execution, and review without a hard reset.
/workspacePR review still posts to GitHub. Remedy still runs in isolated sandboxes. Builder still executes cloud jobs. Workspace is the control room — not a rewrite of the pipelines underneath.
GitHub checks unchangedIf you have used Critique Chat or Builder before, Workspace will feel familiar immediately. The difference is continuity. Open a thread, escalate to build mode with ?mode=build, return to the same rail, and pick up the review run that thread referenced. The surfaces were always related. Now the UI admits it.
Four jobs, one ledger
Each mode still does a distinct job. Workspace does not blur them into a generic “AI assistant.” It keeps the boundaries sharp while sharing the infrastructure that was duplicated before: repo indexing, model routing, credit accounting, and session memory.
- Repo-grounded Chat
- Architecture questions
- PR summaries
- Memory across sessions
- One credit ledger
- One history rail
- One repo context
- Handoffs without re-briefing
- Multi-agent PR review
- Remedy patch runs
- Builder cloud jobs
- GitHub check runs
How does Critique Workspace work?
Open /workspace, select a GitHub repository, and start in Chat or switch to build mode with ?mode=build. Recent chats and Builder runs appear in one left rail. When a PR review completes, open the run from the same surface. Start Remedy from the thread when a finding is bounded. Credits, usage, and model routing draw from the same ledger you see under Dashboard → Usage — there is no second billing story for Workspace.
What shipped in Workspace (May 2026)
- /workspace as the shared operating surface for Chat and Builder history
- One left rail for recent chats and builder runs
- Builder styling aligned with the signed-in workspace instead of a separate console
- Mode-aware actions — Build, Plan, and review handoffs from the same composer
- Searchable repository and model selectors
- Activity rendered as a timeline, not raw log spam
- Prompt-derived branch publish and draft PR reuse after a run
- Microphone capture in the composer — dictate a build prompt from the workspace
- Stalled OpenCode turns bounded with liveness checks
- Per-call OpenRouter-style usage persisted for review and Builder paths
- Credit reconciliation closer to source-of-truth accounting
- Review run detail tuned for triage — verdict first, usage expandable
A day inside Workspace
You land in /workspace, select the repo, and ask why the auth middleware behaves differently on staging. Chat pulls indexed context. No review credits burn for a question.
A teammate opens a PR. The GitHub App queues Critique review. You open the run from Workspace — the same rail that held your morning chat — and read the verdict alongside the evidence pack.
Two findings are narrow: missing null guard, stale import. You start Remedy from the thread. The sandbox clones the head branch, patches, validates, and pushes — visible live without leaving Workspace.
You need a broader refactor — extract a shared module, update three callers. You switch to build mode, pick the model, and let the cloud job run. The activity timeline streams back. When it finishes, the branch and draft PR are ready.
That loop — explain, enforce, repair, extend — is the job Critique was always built for. Workspace is the first interface that treats it as one continuous shift instead of four product tabs.
What stays separate (on purpose)
| Surface | Role | Where it lives | |
|---|---|---|---|
| Checkpoint | Pre-review trust gate | Deterministic intake before credits burn | /checkpoint · Dashboard → Checkpoint |
| PR Review | Merge-gate verdict on GitHub | Scout, specialists, lead synthesis | GitHub checks + Dashboard runs |
| Workspace | Signed-in control room | Chat, Builder, context, handoffs | /workspace |
| Dashboard | Operator hub | Installations, policy, usage, help | /dashboard |
Checkpoint and automated review still run on the GitHub webhook path. Workspace is where humans stay oriented while those pipelines execute.
Who should use Workspace first
- 1You already bounce between Chat and Builder?Workspace is the default. Bookmark /workspace instead of juggling /chat and /builder.
- 2You want review context while you fix?Open the review run from the same rail, start Remedy, and keep the thread that explains why the patch exists.
- 3You only use the GitHub App today?Install stays the same. Add Workspace when you want repo Q&A and execution between PRs — the App and Workspace share installations and credits.
- 4You need enterprise policy controls first?Dashboard → Automation still owns review policy, Checkpoint rules, and model tiers. Workspace respects those settings; it does not replace them.
Frequently asked
Open Workspace
Sign in, pick a repo, and stay in one place from question to verdict to patch. Five hundred free credits still apply — no card required.
Go to Workspace