MonkeyCode

The deciding trait is that nothing is installed. Every task builds, tests and previews on a server, so the setup that usually eats a new engineer's first week does not exist, and the machine in front of you stops mattering to the work in any way at all.

That is either liberating or claustrophobic depending on how attached you are to your own tooling, and there is no middle setting on offer. Pick it if onboarding time is the pain you are solving. Pick a local agent if your environment is something you have spent years shaping.

The failure mode is parity. An agent that only ever compiles and tests inside one curated environment optimises for that environment, and the difference between it and production is a class of bug the agent is structurally unable to find, because it never sees the machine where the bug lives.

Nothing documented describes reproducing that environment locally or matching it to a deployment target. What it does right is running the build at all: a review that compiles is worth more than a review that reads, and most of this category never compiles anything.

1. Per-task selection is a defensible design: tasks differ in difficulty and in cost tolerance, and binding the model to the task rather than to the installation lets that variation be expressed. 2. It also creates an obligation the documentation does not meet, which is telling the user which one to pick.

2. Without published per-model results on comparable tasks, the selector is a preference control rather than an informed one, and the decision is delegated to a user with less evidence than the vendor has. The mechanism is sound. The guidance is absent, and guidance is the harder half.

The licence choice is the interesting business decision here. Strong copyleft on a platform means competitors cannot quietly absorb it into something proprietary, while customers who want to embed it come to the vendor for different terms. That is not idealism, it is a pricing mechanism written in legal text.

Moat: the licence plus an existing enterprise sales motion, which is a better combination than most rows here can claim. Likely path is the hosted tier growing while the free deployment does the distribution. Position: viable, and read the terms carefully if anything you sell would touch it.

This one was built for the person who signs the invoice, which is rare enough to say plainly. Environments, model access and task assignment are administered centrally rather than configured sixty times over, and the deployment sits inside our perimeter, so the data question answers itself before legal asks.

What is still missing is identity: no directory integration is documented, so those central controls run against accounts I create by hand. There is no published figure for a hosted seat either, which makes the budget conversation a phone call. Approved with conditions: self-hosted only, single sign-on before the second team.

This is the opposite of the machine I want. The environment is managed, the execution is remote, and the model list is somebody else's selection, so the only thing I genuinely control is which entry on it I picked. I can bring a key, which is the single concession here, and a key is not ownership.

Nothing runs on my hardware and there is no protocol for attaching the servers I already operate, so this is a system I visit rather than one I own. Grudging respect for building it in the open at all, and none whatever for the shape of it.