WhipCode is a coding agent with a shared daemon and three front ends

One daemon, three ways to look at the same session

WhipCode is described as an open source coding agent built for work that does not fit in one context window, and it comes with a Desktop app, a terminal UI and a web client.

The architecture underneath is the interesting part. A shared daemon owns the work, so closing a window does not end the session. The three front ends are views onto the same daemon, and the session state is independent of whichever interface you happen to be looking at. The documentation states this twice in different forms, that the daemon keeps session state independent of the UI and that a window can be closed and reconnected to later.

That is a design decision with consequences for how you use an agent. A long job, one that takes minutes of tool calls and several rounds of reasoning, does not have to live inside one terminal window that you must not close. You can watch it in the Desktop app, drop to the terminal, and come back to the web client on another machine, and the work continues.

The audience is a developer who wants an agent they can inspect rather than a chat box. The project description lists what that means in practice: follow conversations, inspect the execution tree and timeline, and track model usage and cost.

The implementation is Go, with the terminal interface built on the bubbletea, bubbles, lipgloss and glamour libraries, and the module also carries the Model Context Protocol SDK, an agent client protocol SDK, a WebAssembly runtime through wazero, Starlark, a SQLite driver, and browser automation libraries.

The agent loop is short programs, not a growing transcript

The mechanism that distinguishes WhipCode from a plain chat loop is described as a recursive language model loop, or RLM, that uses short Starlark or JavaScript programs to inspect context, call tools and delegate. The project is explicit that this is not just a growing chat transcript.

The difference is one of control. Instead of appending every observation to a conversation and letting the model re-read it, the agent runs small programs against a bounded view of the state. A program can look something up, decide what to do next, call a tool, and return a compact result. The Starlark and JavaScript options matter because they are both sandboxable, so the code the agent writes executes in a constrained environment rather than with the full privileges of the harness.

Delegation is recursive. Agents split work into focused tasks, launch their own agents and coordinate through messages, which is what makes the bounded context design work at a scale beyond a single agent. A parent can hand a well-scoped piece of work to a child, and the child's result comes back as a summary rather than as a transcript of everything it read.

The environment list in the module confirms the shape of the system. wazero is there to run WebAssembly, Starlark is a first class dependency for the scripting layer, and the browser automation libraries suggest that browser control is one of the tools available to the agent.

The documentation on the runtime lives in `docs/rlm-runtime.md`, and the architecture is described separately in `docs/architecture.md`.

Context is fetched in slices rather than crammed into a prompt

The stated aim of the project is to keep context within reach, and the mechanism is bounded reading. Search and read history, files and large tool outputs in bounded slices, instead of stuffing everything into a prompt.

This is the problem that the RLM loop exists to solve. Tool output is the usual culprit. A single file read, a test run or a directory listing can be larger than the window you have, and the usual responses are to truncate it, which loses the part that matters, or to summarise it, which is a guess. Reading in slices means the agent can go back for the part it needs, and the program it runs is what decides what part that is.

The rest of the control surface follows the same logic of making the agent's work legible and adjustable. You can choose models, set tool permissions, and connect local or remote execution hosts, so the agent can run somewhere other than your laptop. The agent can be extended with skills and with MCP servers, which is how external tools get into the loop.

The module backs this up with the Model Context Protocol SDK at version 1.7.0 and an agent client protocol SDK, so MCP integration is a first class feature rather than a script someone added. There is also a themes generator, `go run ./cmd/themegen`, with a check mode in the package scripts, which is a small thing that says the project treats the interface as a product.

Two install paths, and the Desktop one is a beta

The Desktop build is the polished path and it is labelled a beta. The quickstart asks you to download `whipcode-desktop-darwin-arm64.dmg`, open it and drag Whip Beta into Applications, then launch it and choose Set up this Mac if prompted. The app includes its matching backend, so no separate CLI installation is needed. It is Apple Silicon only, and it requires macOS 14 or newer.

There is an important warning attached to it. The documentation says to use a release built after the clean project reset, and that old Desktop releases are not an upgrade path.

The terminal path is a shell installer:

curl -fsSL https://raw.githubusercontent.com/context-labs/whip/main/install.sh | sh
whipcode

That works on macOS or Linux. For an exact version you use the install.sh command from the release notes, and the companion `latest.sh` always selects stable v1+ and never an alpha. The new CLI track starts at `v1.0.0-alpha.N`, and the documentation is explicit that prerelease installation is deliberate and that default stable installation arrives with `v1.0.0`.

Desktop-managed installations update through the Desktop app, and standalone CLI installations use `whipcode update`. Provider access is separate from installation: you bring an API key or use a supported subscription login, and the providers and authentication page covers the details.

The web client is a gateway on top of the daemon

The web access is not a separate mode of operation, it is a view onto the daemon, and the documentation is careful about how it starts.

The sequence is `whipcode daemon start` and then `whipcode web`, which opens a browser and stays running as a separate gateway. Ctrl+C stops the web access, not the daemon work, which is the point of the design. An ordinary daemon start and an ordinary Desktop start open no web listener at all, so the network surface only appears when you ask for it.

That matters for a tool that has filesystem and execution access. The web documentation has sections for `--no-open`, managed startup and trusted network configuration, which are exactly the settings you would want to think about before exposing an agent with tool permissions over a network.

The rest of the repository structure follows the same separation. `apps/` holds the desktop and web applications, `packages/` holds the client SDK, protocol and UI packages, `cmd/` holds the Go entry points, `driver/` and `internal/` hold the runtime, `evals/` holds the evaluations, and `examples/` holds example agents and a client. The npm workspace list in `package.json` covers `packages/*`, `examples/*` and `apps/*`, and the Node requirement is pinned to 24.x.

The benchmark number comes with its own caveats

The project publishes a benchmark result, and it is worth reading how, because the caveats are part of the claim.

WhipCode solved 20 of 30 tasks, or 66.7 percent, in what the documentation calls a retained Frontier evaluation, made up of 21 Terminal-Bench tasks and nine code repository tasks.

The caveat is unusually explicit. The project states that providers and execution environments differ, that the $2.60 WhipCode point in the supplied chart and the definition of the cost axis are not yet reconciled with the retained reports, and that this is not a matched cost comparison and not an official leaderboard ranking. The chart compares against other harnesses including Codex and Claude Code, and the documentation asks the reader to take the result with that in mind.

So the honest reading is that a specific task set was solved two thirds of the time under some conditions, and that the cost side of the comparison is not settled. The evaluation material is in `evals/` and the detailed write-up, including sources and limitations, is in `docs/benchmarks.md`.

For a project at alpha stage, publishing the number together with the reconciliation problem is more useful than a clean leaderboard position would have been.

Alpha releases mean resets, not upgrades

The version line is the thing to understand before you rely on this tool. The most recent releases are v1.0.1-alpha.18 on 2026-09-27, v1.0.1-alpha.17 on 2026-09-26 and v1.0.1-alpha.15 on 2026-09-26, so three alphas of the same version in two days, with a stable 1.0.0 still ahead rather than behind.

The documentation spells out the consequences. Existing internal installs must follow the manual reset checklist in `docs/team-reset.md` rather than upgrade in place, and old Desktop releases are not an upgrade path either. There is a two script split in the installer for some releases, and the note about version environment variables says no version variable is needed for those releases, which is the kind of detail that only matters if you have been pinning versions by hand.

For development, the requirements are Go 1.27 or newer, Node.js 24 and Task, and the build is four commands:

git clone --branch main https://github.com/context-labs/whip.git
cd whip
npm ci
task build

The documentation notes that this builds locally without replacing an installed app or restarting the daemon, which is a considerate touch for a tool that owns a long running background process.

The licence is Apache-2.0, which permits use and modification in commercial products with attribution and preservation of the licence and notices, and the repository carries an AGENTS.md file, a CONTRIBUTING.md and a `.agents/` directory, which is the shape of a project that expects agent-driven contributions.

Editorial conclusion

WhipCode suits a developer who wants a coding agent with a durable session, a terminal interface and a desktop app over the same work, and who is willing to work with alpha software and to wire up a model provider and credentials. It is the wrong tool for a team that needs a stable versioned release, and the wrong tool for a machine that is not running macOS 14 or newer for the Desktop path. Check first which release line you are on, because the documentation says the new CLI track starts at v1.0.0-alpha.N and that existing installs must follow the manual reset checklist rather than upgrade in place.

Frequently asked questions

Official sources

1. context-labs/whip on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases