v1.11.0

Fixed

• The context watchdog no longer wedges a session into an unrecoverable "Nothing to compact" loop after a mid-run compaction (#68 by @charly1r, reproduced by @Qm-jmz). Symptom: after a mid-run compaction the resumed run started re-reading project files, context climbed back over the threshold, and a second compaction fired — but the only summarizable slice left was the tiny post-compaction tail, so pi threw Compaction failed: Nothing to compact and, because pi's compact() aborts and disconnects the agent before that check, the session was left dead (nothing the user typed recovered it). The deep fix (detect the incompressible tail and elide-rescue before giving up) belongs in the pi runtime little-coder wraps and has been flagged upstream; this release adds a wrapper-side guard that breaks the loop before the session can wedge. The context-watchdog extension now measures each compaction's actual effect: if usage is still within MIN_PROGRESS (5 points) of the threshold afterward — i.e. compaction freed too little — it pauses automatic compaction and tells the user (context still at N% after compaction — automatic compaction paused to avoid a loop) instead of firing a doomed second compact(), and it re-arms automatically once usage drops back below the threshold band (a manual /clear, /compact, or a smaller turn). A compaction that errors (onError, e.g. a "Nothing to compact" that still slips through) pauses the same way rather than silently retrying. Separately, the mid-run resume message now explicitly tells the model not to re-read files it has already read — the re-scan is what re-inflated context into that second compaction in the first place. Behaviour is unchanged when the watchdog is disabled (LITTLE_CODER_NO_COMPACT_WATCHDOG=1 / LITTLE_CODER_COMPACT_AT_PERCENT out of band). The deep incompressible-tail recovery has been flagged for pi upstream.

Added

• A configurable default model, so bare little-coder "just works" (#65 by @cndjonno). models.json now takes a top-level "default": "provider/id" (shipped default: llamacpp/qwen3.6-35b-a3b). On launch, if you didn't pass your own --model and pi has no persisted model selection yet, little-coder injects that default and prints the model's friendly name — ▸ default model: Qwen3.6-35B-A3B (MoE, local llama.cpp) (llamacpp/qwen3.6-35b-a3b) — so a first run no longer needs the verbose --model provider/id. It's first-run-only by design: the moment you pick a model in-session (pi persists defaultProvider/defaultModel), that choice wins on every later launch and the default never overrides it; passing --model, or a headless/sub-coder run, also skips injection. A user override file's own top-level default takes precedence over the shipped one. The friendly name is surfaced at launch rather than swapped into pi's width-constrained footer, which keeps the compact model id there and avoids the terminal-width overflow class from #51.
• Auto-relaunch after an in-place update (#66 by @cndjonno). Answering Y to the launcher's Update now? [Y/n] prompt used to install the new version and then drop you back to the shell with "re-run little-coder to use it." The launcher now re-execs the freshly-installed version in place with your original arguments (adding --no-update-check so the child doesn't re-poll and can't loop), landing you straight in the new build — it prints Relaunching little-coder… and, if the re-exec somehow can't start, falls back to the old manual-relaunch hint. The in-app /update command still shuts the session down for a clean manual restart, since it runs inside the pi child where an in-place re-exec isn't safe.