little-coder

You will be happy here only if your goal is a model on your own machine. The deciding trait in daily use is patience management: this is built for weak models, so it keeps them on task instead of assuming competence, and the result feels less like a brilliant colleague and more like a careful intern who never sends your code anywhere. That trade is the whole product.

Pick it if privacy or cost means the model has to be local. Pick Cline when you would rather point a strong hosted model at your editor, or a terminal agent if you want speed over independence.

Count the layers before trusting the result. Guards constrain what may be read and written, malformed output is repaired after the fact, thinking is capped by budget, and behaviour is tuned per model profile. Every one of those exists because the target model would otherwise fail, and a repair layer that silently fixes bad output also silently hides how often the model produced it. The failure you never see is the one you cannot budget for.

What it does right: only read-only git commands sit on the safe-prefix list, so an unsupervised run cannot commit, branch or push its way into your history.

Three observations. 1. Shipping the measurement apparatus alongside the agent lets a reader reproduce a comparison on their own hardware, which is what a benchmark claim is supposed to permit and almost never does. 2. Per-model profiles make the comparison controlled rather than anecdotal, since the scaffold varies deliberately instead of accidentally. 3. Roughly thirty skill files sit beside thirty extensions, so behaviour is data rather than code in most cases.

Nothing is asserted about performance anywhere. A project that measures and declines to advertise is the rarer discipline.

There is no company here, no funding and nothing being sold, so pricing power is not a question that applies. The dependency worth naming is technical rather than commercial: the substrate underneath belongs to another project, which means this one inherits its direction and its abandonment risk without any say in either.

Two and a half thousand stars is a hiring signal for the author and not an asset anyone acquires. The realistic outcomes are steady personal maintenance or a quiet stop when the author's interests move. Position: adopt for what it does today, and expect no roadmap you can hold anyone to.

The licence is free and the compute is not. Running capable models locally means capable machines, and specifying accelerators for sixty engineers is a capital conversation, not a software one. Automation is out too: a single-shot prompt exists, but nothing documents exit codes or a machine-readable result, so I cannot make it a gate in a pipeline. No SSO, no audit log, nothing that reports upward.

In its favour, nothing leaves the building, which answers a data question cleanly. Not yet. Revisit if a hardware refresh gives me an excuse.

This is built for my setup rather than tolerating it. Model endpoints are declared per model in a JSON file and the documented list covers llama.cpp, Ollama, LM Studio, MLX and any base URL on my network, with a locally served Qwen as the shipped default, so the first run needs no account anywhere. Apache-2.0 means the fork is mine outright.

Around thirty TypeScript extensions define the tool surface, which is the right level to intervene at: I add a tool by writing one, not by convincing a maintainer. MCP is absent, and here I mind that less than usual.