little-coder: a pi-based coding agent tuned for small local models

The scaffold-model fit problem little-coder targets

Most coding agents are tuned against frontier models with large context budgets. little-coder starts from the opposite premise: the scaffold, meaning the system prompt, the tool set, the skill cards and the extension set, has to fit the model, not the other way round. The README describes the project as a coding agent tuned for small local models, built on top of pi, and the package description in package.json says it reproduces the whitepaper's scaffold-model-fit adaptations as pi extensions. The intended user is someone running a local server on their own laptop, with a model in the 9.7B to 35B range, who wants an agent loop that does not assume a frontier API. The README points at a Substack write-up titled Honey, I Shrunk the Coding Agent for the reasoning, and cites a 9.7B Qwen beating frontier entries on Aider Polyglot under this scaffold. That claim is the project's own, taken from its README, and the benchmark harness lives in the benchmarks/ directory if you want to reproduce it yourself.

How little-coder layers on top of pi without forking it

little-coder is not a fork. pi is a plain dependency in package.json, pinned as @earendil-works/pi-coding-agent, and the repository keeps everything little-coder-specific under .pi/extensions/, skills/ and benchmarks/. The README puts the count at about 30 extensions plus 30 skill markdown files plus a Python benchmark harness, on top of pi's four built-in tools (read, write, edit, bash) and a roughly 1000-token system prompt. The launcher is bin/little-coder.mjs, a Node script with a node shebang. It runs pi with --no-extensions and wires in exactly the bundled set. That single flag explains most of the project's behaviour: cold-start context stays around 7k tokens, and the set of extensions that loads is the set that ships. The direct consequence, stated in the README, is that a package installed globally with pi install will not load inside little-coder, because pi install registers into pi's settings and --no-extensions skips those. There are three opt-in routes around it: drop extensions in ~/.config/little-coder/extensions/, point LITTLE_CODER_EXTRA_EXTENSIONS at files anywhere, or relaunch with --with-pi-extensions. None of them change the default. Run /extensions to see what is loaded. Themes are unaffected, since pi themes have always loaded.

Installing little-coder and running a first task

Node.js 22.19 or newer is required. The README gives a one-line installer, an npm route and a bun route, and states there is no clone step and no npm install in a workspace.

curl -fsSL https://raw.githubusercontent.com/itayinbarr/little-coder/main/install.sh | bash

Alternatively install globally with npm. The package declares a bin entry named little-coder pointing at bin/little-coder.mjs, so the command lands on your PATH and works from any directory.

npm install -g little-coder

If you install with bun instead, the README notes a caveat: the launcher is a Node script, so Node 22.19 or newer still has to be on your PATH for the binary to start. bun is fine for installing and updating, but the runtime is Node. To go fully node-less you would replace the shebang in $(bun pm bin -g)/little-coder with #!/usr/bin/env bun.

bun add -g little-coder

Now cd into your own project and launch. The agent uses the directory you launched it from as its working directory, so Read, Write, Edit and Bash operate on your project rather than on little-coder's install path.

cd ~/your-project
little-coder

Bare little-coder launches the default model declared in models.json, which ships as "default": "llamacpp/qwen3.6-35b-a3b", and prints its friendly name at startup. That default only applies on a first run: once you pick a model in-session, the choice sticks and the default never overrides it. To name a model explicitly, or to point at a different provider, pass --model. The README shows cloud and local providers side by side.

little-coder --model llamacpp/qwen3.6-35b-a3b
little-coder --model ollama/qwen3.5
little-coder --model lmstudio/local-model
little-coder --list-models

The canonical setup the project is tuned for is a local llama.cpp server hosting Qwen3.6-35B-A3B. The README marks local model setup as optional and points to its own section for how to serve it. Two interactive features are worth knowing on day one: ctrl+q toggles Plan Mode, which researches a request with sub-coders, asks one to three clarifying questions and writes a plan instead of editing anything, with /implement switching to the action model in a fresh session seeded with the plan; and f2 starts Deep Research, which fans out read-only sub-coders into an ephemeral scratch directory. The README is explicit that f2 is for external and online research, not for exploring the code you are sitting in, and suggests a normal session or dispatch for that instead.

What the closed extension set costs you

The --no-extensions default is the project's central design decision and also its sharpest limitation. It buys predictability: nothing in your working directory changes the loaded set mid-task, and cold-start context stays small enough for a local model. It costs you the ecosystem. If your workflow depends on a pi extension you installed globally, it will be silently absent until you use one of the three opt-in paths, and the failure mode is quiet rather than loud: the agent simply behaves as if the extension were never there. The README's answer is to run /extensions and check. That is a reasonable habit, but it puts the burden on you to notice an absence, which is harder than noticing an error. The same trade-off shows up in the tool skill cards. little-coder injects a short usage card for the tools a turn is likely to need, selected by error-recovery, then recency, then intent. When the selector keeps choosing the wrong card, /skills <tool> pins one and /skills off returns to automatic selection. A selector that needs manual overrides is a selector that will occasionally guess wrong, and the README treats that as expected rather than as a bug. Plan Mode has a related boundary: approving a plan saves it to .pi/approved-plan.md and stops there. /implement is a separate step that opens a fresh session seeded with the plan. If you expect approval to start the work, you will be waiting.

little-coder versus opencode and plain pi

The comparison people search for is little-coder vs opencode, and the honest difference is scope. opencode is a general coding agent; little-coder is a scaffold tuned for small local models, and its whole extension set exists to compensate for what a 9.7B to 35B model does badly. If you are running a frontier model through an API, that compensation is overhead you are paying for nothing. The more interesting comparison is little-coder vs pi, because little-coder is pi plus about 30 extensions, 30 skill files and a benchmark harness. Using pi directly gives you four built-in tools, a roughly 1000-token system prompt, and full freedom over which extensions load. Using little-coder gives you a fixed, tested set and a launcher that enforces it. That is the actual choice: control versus a known configuration. The README frames little-coder as pi plus additions rather than a replacement, and says it does not fork pi or shadow its CLI. If you have never used pi, the README suggests skimming pi.dev first, since the rest of the documentation assumes familiarity with --agent-import-path, --mode rpc and .pi/extensions/ auto-discovery.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-08-29. Releases have been frequent and versioned: v1.17.0 on 2026-08-15, v1.18.0 on 2026-08-22 and v1.19.0 on 2026-08-29, matching the version field in package.json. That cadence matters for upgrade cost, because the launcher wires in a bundled extension set rather than discovering one. Upgrading the package changes the set that loads, and the README's guidance to run /extensions after a change is the cheapest way to see the difference. little-coder ships no npm install scripts; the README states the launcher does everything at launch time. That is a smaller supply-chain surface than a package with postinstall hooks, though it does not remove the dependency on pi itself, which is pinned as ^0.83.0 and can move under you on a minor bump. The project is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file, which is what Apache-2.0 expects when a project bundles third-party code. There is also a vendor/ directory and an override remapping node-domexception to file:./vendor/node-domexception, so some vendored code is present. If you redistribute little-coder or a product built on it, read LICENSE and NOTICE yourself; the Apache-2.0 terms include patent and attribution provisions that a summary here cannot cover.

Editorial conclusion

little-coder is for engineers who already run a local model such as Qwen3.6-35B-A3B through llama.cpp, Ollama or LM Studio and want a terminal agent whose scaffold was adapted to that model size rather than to a frontier API. It is not the right tool if you depend on globally installed pi extensions loading automatically, since the launcher passes --no-extensions and your working directory cannot change the loaded set mid-task. Before adopting, run little-coder --list-models to confirm your provider is reachable, run /extensions to see exactly what loaded, and read docs/extensions.md if you need the LITTLE_CODER_EXTRA_EXTENSIONS or --with-pi-extensions escape hatches.

Frequently asked questions

Official sources

1. itayinbarr/little-coder on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases