Swival

The deciding trait is who it was built for: people running a model that is not very good. Most agents assume a frontier model and fall apart when you point them at something small, and this one treats that as the design target rather than an edge case. If your budget for tokens is zero, that is the entire difference between useful and unusable.

Give it a frontier model and you have a competent, unremarkable CLI agent. Pick it if you work offline or on a laptop with a small model loaded. Pick Aider if you have an API key and no constraint to respect.

An autonomous loop that runs until it produces an answer, driven by a weak model, is the combination most likely to spin. The row describes no iteration cap and no cost guard, and a small model that cannot solve the task will keep trying tools rather than saying so. On a local model that costs time; on a metered one it costs money.

There is no git integration to fall back on when a loop edits the wrong file. What it does right is refuse the framework. Pure Python with no dependency stack means the loop you are debugging is the loop in front of you.

1. The central claim is comparative: that this remains reliable on small models where other agents do not. That is an unusually testable proposition, since the comparison set is public and the models are downloadable, and no measurement of it is published. 2. The design response to tight context is asserted rather than described; the row names the constraint the tool is built around but not the mechanism it uses to respect it.

2. Absent both, what remains is a plausible hypothesis and a working implementation. Those are worth something. They are not evidence.

The target user is the one who will not pay. A tool optimised for people running free local models has selected the segment with the lowest willingness to spend, deliberately, and 330 stars is what that segment produces in a year. There is nothing wrong with the choice; it simply forecloses every revenue path except patronage.

Moat: none, and none sought. Likely path: a hobby project maintained as long as it is interesting, which is the honest end state for most of this category. Likely acquirer: nobody, because the users are not a market. Position: adopt without commercial concern, since there is no commerce to be concerned about.

It takes the task as a command-line argument and runs to completion, which makes it scriptable, and scriptable is the only property I need before a tool can live on a build agent. Windows is supported too, so unlike most of this category it covers my whole estate.

What it does not have is anything else procurement asks for: no console, no audit, no identity, no vendor. The interesting use is not sixty desktops but one runner doing a repetitive job cheaply against a model we host. Approved with conditions: pipeline use for narrow, well-specified tasks, and a human on every diff it produces.

This is the provider list I have been waiting for. LM Studio and llama.cpp need no auth and no flags, and it discovers the loaded model itself, so pointing it at whatever I have running is genuinely nothing to configure. vLLM and mlx_lm.server work through the same compatible interface, and it will even shell out to an external command like codex exec if that is what I want driving it.

MIT on top, and a source tree small enough to read in an evening. No MCP client, which is the only line missing from an otherwise complete answer to the ownership question.