whip

The deciding trait is speed, and it is the only thing this was built for. Tool calls run in parallel, everything streams, and the whole thing is one binary that starts before you have finished letting go of the return key. If your complaint about agent tooling is that you spend the day waiting, this is aimed directly at you.

What you give up is everything else: no version control help, nothing that runs while you are away, and a very small project behind it. Pick it if latency is what annoys you most. Pick a bigger tool if you want features more than milliseconds.

There is a capability here that nobody has written down. The documentation index lists browser and computer use, and the README does not describe the feature, so the row records something the project has not explained: no permissions model, no scope, no statement about what it can reach. A browser tool you cannot read about is a browser tool you cannot reason about.

Beyond that it writes files and runs bash with no version control integration behind it, which for a tool this fast means mistakes arrive quickly. What it does right is stay small enough that reading the loop is an afternoon rather than a project.

1. The concurrency primitives are chosen rather than improvised: per-path file locks and background subagents built on channels rather than hand-rolled promises. Locking at path granularity is the correct unit for this problem, because it permits parallelism exactly where two agents are not in conflict and serialises them precisely where they are.

2. That is a stronger guarantee than most parallel agent tools offer, and it is stated as a property rather than a hope. 3. Nothing is measured. A harness whose single stated goal is speed invites a latency figure, and none is published, which is a missed opportunity rather than a flaw.

The default is the business model. A harness that ships pointing at one inference provider is a distribution channel for that provider, and the interesting question is what Context Labs gets for being the front door. Two hundred and fourteen stars is small, and a default costs nothing to change if it grows.

Moat: none in the software; the position is the routing. Likely path: either the provider relationship becomes explicit and this becomes a client for it, or the project stays a fast toy with a curious default. Likely acquirer: the provider it defaults to. Position: change the default on day one and use it happily.

One small vendor and no support organisation is the whole story here, and that decides it for sixty engineers. When it breaks, we fix it or we stop using it; there is nobody to escalate to and no contract to point at. That is acceptable for a personal tool and not for anything on a critical path.

It does not run unattended, so there is no pipeline use to justify the exception, and there is no console, no audit and no identity integration. Each developer would hold their own provider credentials. Not yet: revisit if it grows a maintainer team and something that runs on a server.

Apache-2.0, and two details tell me somebody thought about ownership. Dropping a .mcp.json into the repository is all it takes for servers to appear, which means my tool configuration is versioned with the project instead of hidden in a home directory. And model discovery is live from each provider's catalog, so a new model shows up in the picker without me editing a list somebody else has to update.

Any OpenAI-compatible endpoint works, which puts my own served model in the same picker as everything else, and that is the whole ownership question answered.