CritiqueCode Cloud: Code From Anywhere
A hosted Pi author session with its own sandbox, branch, history, and reviewable path back to GitHub.
Code from anywhere
Keep the session. Keep the branch.
critique.sh
CritiqueCode Cloud is the hosted form of the Pi-based CritiqueCode author agent. Sign in, choose a GitHub repository, open a session, and keep coding from a phone, laptop, or desktop. Every session gets its own E2B sandbox, Git branch, durable event history, and path to a pull request. The browser is a control surface—not a tunnel into your personal computer.
A local coding agent is powerful because it lives beside the repository. It is also stuck beside the repository. Close the laptop and the session is gone from view. Move to your phone and the terminal is suddenly a poor interface. Ask a teammate to inspect the work and you are back to copying screenshots or waiting for a pull request.
CritiqueCode Cloud keeps the useful part of the local harness—the interactive Pi author—while moving the execution boundary into a managed sandbox. The session becomes the unit you can reopen, inspect, and continue. It has a branch you can recover, not just a tab you hope stays alive.
One session, one branch, one sandbox
When you create a session, CritiqueCode resolves the selected base branch to a commit, creates a session branch, and starts an isolated E2B sandbox from the pinned author template. A long-lived Pi SDK worker runs inside that sandbox. It owns the author context and writes to the checked-out session branch. The control plane owns the durable record, event stream, command queue, and GitHub operations.
That split is the core design decision. E2B provides warm execution state; GitHub provides the durable code boundary; Critique’s session record lets the browser reconnect to both. The browser never receives E2B API keys, GitHub installation tokens, provider secrets, or an unauthenticated sandbox URL.
The interface is an operator workspace
The new /code surface is designed for doing the work, not decorating a chat transcript. The session rail shows active, paused, expired, failed, merged, and pull-request sessions. The main pane keeps the conversation and tool activity together. Diff, files, terminal output, checkpoints, model selection, and pull-request actions stay one tap away on a smaller screen.
| You do | CritiqueCode keeps | |
|---|---|---|
| Prompt | Send a change request, follow-up, image, or steering message | Pi JSONL session state and ordered activity events |
| Inspect | Open the diff, files, reasoning, or terminal output | A replayable event cursor and the latest source-control snapshot |
| Leave | Close the tab or switch devices | The branch, checkpoint, pull-request metadata, and session history |
| Ship | Checkpoint, create a PR, or merge when the head is current | Expected-head protection so an old view cannot silently merge stale code |
Warm for three days, clear about expiry
A sandbox should be convenient without becoming an invisible bill. The default warm window is 72 hours from meaningful activity. Prompts, steering, review, repair, checkpoints, and source-control actions extend the window. A reaper runs on a schedule, attempts a final checkpoint, and then stops the sandbox when the session expires.
Expiry does not erase the work. The session becomes read-only, with its history, branch, last checkpoint, and pull-request metadata still visible. If you need to continue, start a new session from the preserved branch. That is a much better failure mode than a loading spinner that never tells you whether your changes survived.
The author still has to face review
Hosted execution does not change CritiqueCode’s central contract: the author can implement, but it does not get to turn its own confidence into proof. The workspace makes review, repair, checkpoint, PR, and merge visible in the same session so the path from “make this change” to “open the PR” is short without pretending those steps are the same thing.
Start with a repository, not a new account model
The entry point uses the existing Critique sign-in and GitHub connection. There is no second workspace to configure and no local relay to keep running. Once the hosted deployment has its E2B template and model credentials configured, the first-session flow is deliberately small:
Flow
1. Sign in to Critique
2. Open /code
3. Choose a GitHub repository and base branch
4. Describe the changeChoose the branch and let the session create its isolated workspace.
What comes next
The next work is making the boundary boring under pressure: a real PTY that reconnects cleanly, attachments that leave the database for private object storage, brokered provider capabilities, durable worker replay, usage limits, and the native review/verified-repair adapter. The product gets better when the infrastructure disappears and the session tells the truth about what happened.