kronk-cli 0.6.1 → 0.8.0

package/README.md

@@ -450,6 +450,88 @@ The profile it writes is the one documented under
 [Tip: use an `/AGENT` profile](#tip-use-an-agent-profile) — `context-window`, `nseq-max`,
 `preserve_thinking` and `max_tokens`, and deliberately no sampling parameters.
 
+### `kronk-cli rescue`
+
+Everywhere else in this document, `kronk-cli` is something *you* talk to. `rescue` is the other
+direction: a job queue so anything that can spawn a process — a script, another CLI, anything
+external that wants to hand off a token-heavy job without sitting on it — can submit a
+self-contained task to the local model, go do something else, and come back for the answer.
+
+```console
+$ kronk-cli rescue "trace how the SSE parser handles multi-line data fields" --role explore
+9k2m1x-4d2-a1b2c3
+
+$ kronk-cli rescue status 9k2m1x-4d2-a1b2c3
+running (step 4)
+
+$ kronk-cli rescue wait 9k2m1x-4d2-a1b2c3
+Multi-line `data:` fields are joined with `\n` in src/sse.js:41-53 before the
+frame is handed to the caller — see accumulateToolCalls's buffer.
+$ echo $?
+0
+```
+
+It is the same delegation `kronk-cli` already does internally — one self-contained task, its own
+context, a report that stands alone — with the caller moved outside the process instead of inside
+it. See [Sub-agents](#sub-agents) for the contract a rescue job runs under; it is the identical
+one.
+
+| Command | |
+|---|---|
+| `kronk-cli rescue "<prompt>" [--role explore\|code] [--model <id>] [-y\|-a] [--steps <n>] [--json]` | Submit. Runs detached; prints a job id and exits immediately — nothing here blocks |
+| `kronk-cli rescue status <id> [--json]` | A snapshot: `queued`, `running (step n)`, `done`, `stopped`, `interrupted` or `failed` |
+| `kronk-cli rescue wait <id> [--json]` | Block until the job reaches one of those last four states, then print its report |
+| `kronk-cli rescue result <id> [--json]` | Print the report. Refuses (exit `4`) with the current state if the job has not finished yet — use `wait` instead of polling `result` in a loop |
+
+**`--role`** is the same split `kronk-cli` gives its own sub-agents: `explore` can only read —
+`read_file`, `list_dir`, `search` — and `code` can also write files and run commands. Default is
+`explore`, the read-only one. **`--model`** is resolved exactly as `-m` resolves it everywhere
+else in this program — exact id, else the closest substring, preferring a served `/AGENT`
+profile — against what Kronk is serving *right now*; a name that matches nothing is refused at
+submit time rather than silently falling back, because a caller that asked for a specific model
+should hear about a bad name immediately, on the process it is still attached to, not from a job
+that failed twenty minutes later. Leaving `--model` out defers the choice to the job itself, the
+same default the session would otherwise use.
+
+**Without `-y`/`-a`, a tool that needs approval is refused and reported, never auto-allowed.**
+Nobody is at the prompt a rescue job would otherwise show, so there is no "ask anyway" — a refused
+tool call comes back in the transcript exactly like a human said no, and the job carries on (or
+does not) from there. This is deliberate and does not have a flag to turn it off: delegating a
+job from outside the process must not become a way past the approval prompts that delegating from
+inside it already cannot get past.
+
+**One at a time.** Kronk holds one resident copy of the model, so a second `rescue` submitted
+while one is running does not run alongside it — its `status` reports `queued` until the first
+job finishes, exactly as the module comment on delegation in `src/subagent.js` already argues for
+sub-agents. A runner that dies mid-job (killed, the machine restarting) does not wedge the queue
+behind it: the next job to check finds the lock's process gone, marks the abandoned job
+`interrupted`, and takes its turn.
+
+**`--json`** on any of the four commands prints one object instead of prose:
+
+```json
+{ "id": "9k2m1x-4d2-a1b2c3", "state": "done", "role": "explore",
+  "model": "unsloth/Qwen3.6-35B-A3B-UD-Q4_K_M/AGENT", "steps": 3, "ms": 11421,
+  "report": "Multi-line `data:` fields are joined with…", "transcript": [ /* the full run */ ] }
+```
+
+`wait`'s exit code is the one place a script gets the state without parsing anything:
+
+| State | Meaning | `wait` exit code |
+|---|---|---|
+| `done` | Finished on its own terms | `0` |
+| `stopped` | Hit its step cap before finishing | `1` |
+| `interrupted` | Killed, or recovered from a runner that died mid-job | `2` |
+| `failed` | The model call itself errored | `3` |
+
+**Records outlive the process that submitted them, on purpose.** They are not sub-agent
+transcripts (`src/tasklog.js`) and do not live in the same place or on the same clock — that
+directory is swept on this session's own schedule specifically because nothing outside the
+process is meant to still want it once the session ends, and a rescue job's whole point is that
+something outside the process still does. A rescue record is kept indefinitely until `wait` or
+`result` actually delivers it, and only then aged out, 24 hours later — `KRONK_RESCUE_DIR`
+overrides where they live, same idea as `KRONK_TASK_LOG_DIR`.
+
 ---
 
 ## Startup: the model is loaded before you type
@@ -530,6 +612,70 @@ run (`kronk-cli "prompt"`) prints no banner and prints nothing here either.
 
 ---
 
+## Checking for updates
+
+`kronk-cli --version` prints what is actually running:
+
+```console
+$ kronk-cli --version
+kronk-cli 0.7.0
+kronk    1.32.7
+```
+
+The second line is `kronk --version`, read through the same `runKronk` helper `setup` uses,
+capped at a few seconds so a stuck binary cannot hang the command. It is omitted, not guessed
+at, when `kronk` is not on `PATH` or does not answer in time — this has to work with **no server
+running**, which is the ordinary case for asking a program what it is.
+
+The startup banner adds a third line when a newer `kronk-cli` exists:
+
+```console
+  ██ kronk-cli  · local agent, no network
+  model   unsloth/Qwen3.6-35B-A3B-UD-Q4_K_M/AGENT
+  server  http://localhost:11435/v1
+  update  kronk-cli 0.7.0 → 0.8.1 · run: brew upgrade kronk-cli
+  /help for commands · Ctrl-C to interrupt · /exit to quit
+```
+
+**It asks the package manager, never the network directly.** No `fetch`, no URL literal — the
+version comes from whatever tool installed this copy, detected from the path `src/index.js`
+itself resolved to:
+
+| Route | How it's detected | What answers |
+|---|---|---|
+| Homebrew | a `Cellar/kronk-cli/` path | `brew outdated --json` |
+| npm global install | a `node_modules/kronk-cli` path | `npm view kronk-cli version` |
+| git checkout | a `.git` above the file | `git fetch --tags` + the newest tag |
+| `packaging/install.sh` | a `lib/kronk-cli` path | nothing — see below |
+
+The hint always matches the route: a Homebrew install is told `brew upgrade kronk-cli`, an npm
+one `npm install -g kronk-cli@latest`, a checkout `git pull`. Suggesting the wrong one would send
+someone to a manager that has never heard of this copy, which is worse than saying nothing.
+
+The git checkout route is the one that makes a real network call, through `git fetch --tags`
+rather than any request this program issues itself, and it honours the same off-switch as
+everything else here.
+
+**The install script has nothing to ask.** It unpacks a tarball into `$PREFIX/lib/kronk-cli` and,
+unlike the other three routes, there is no registry behind it that knows the latest release. It
+writes a small receipt (`$PREFIX/lib/kronk-cli/.install-receipt.json`, version and source) at
+install time so this route is not silent forever; when that receipt is present the banner shows
+a plain nudge —  `update  kronk-cli 0.7.0 · re-run the install script` — with no version
+comparison, because there is genuinely nothing to compare against. A copy installed before the
+receipt existed, or one someone assembled by hand, shows no update line at all, which is the
+honest answer for a route with no manager behind it.
+
+**Never on the path that slows startup down.** The check result is cached to disk with a
+timestamp and reused for up to a day; a stale or missing cache still renders instantly (from
+whatever was cached last, or nothing) while a fresh check for the *next* session runs
+unawaited in the background. Nothing about this can delay, block, or fail the REPL — a package
+manager that hangs, errors, or prints garbage simply produces no line.
+
+`KRONK_UPDATE_CHECK=false` (or `"updateCheck": false` in the config file) turns all of this off:
+no cache read, no subprocess, ever.
+
+---
+
 ## Performance
 
 The transcripts above are real sessions, kept to show what the UI looks like — not a benchmark
@@ -598,6 +744,7 @@ same way this run did.
 | `--no-subagents` | off | Remove the `task` tool, so the model cannot delegate — see [Sub-agents](#sub-agents) |
 | `--steps <n>` | unlimited | Cap tool calls per task. `0`, `off`, `none`, `inf`, `unlimited` all mean no cap |
 | `-h`, `--help` | — | Print all options and exit |
+| `-v`, `--version` | — | Print the kronk-cli version, and Kronk's if it can be had without a network call, then exit |
 | `--` | — | End option parsing; everything after it is prompt text, dashes and all |
 
 Anything not consumed as an option becomes the prompt, except a token that looks like an
@@ -680,7 +827,7 @@ Two consequences worth knowing:
 | `/steps [n\|off]` | show or set the tool-call cap |
 | `/thinking` | show or hide the model's reasoning |
 | `/think` | turn reasoning off entirely — much faster |
-| `/agents` | the sub-agents `task` can delegate to, and what each may touch |
+| `/agents` | the sub-agents `task` can delegate to, what each may touch, and the default model |
 | `/tasks [n]` | sub-agent runs this session; with `n`, that one in full |
 | `/mcp` | list attached MCP servers and their tools |
 | `/context` | how much of the context window is used |
@@ -713,14 +860,16 @@ Two consequences worth knowing:
 | `KRONK_DISTILL` | `true` | `false` disables tool-output distillation |
 | `KRONK_DISTILL_AT` | `8000` | Characters of output that trigger distillation |
 | `KRONK_SUBAGENTS` | `true` | `false` removes the `task` tool |
-| `KRONK_SUBAGENT_MODEL` | the main model | Model sub-agents run on — substring match, same as `KRONK_MODEL` |
+| `KRONK_SUBAGENT_MODEL` | the main model | Default model for a task that names none itself — substring match, same as `KRONK_MODEL`. A task can pick its own from what Kronk is serving, see [Picking a model per task](#picking-a-model-per-task) |
 | `KRONK_SUBAGENT_STEPS` | `40` | Tool-call cap for one delegated task |
 | `KRONK_TASK_LOG` | `true` | `false` stops writing sub-agent transcripts, and `/tasks` says so |
 | `KRONK_TASK_LOG_DIR` | the temp dir | Where transcripts are written |
+| `KRONK_RESCUE_DIR` | the temp dir | Where `kronk-cli rescue` keeps its job records — see [`kronk-cli rescue`](#kronk-cli-rescue) |
 | `KRONK_WARM` | `true` | `false` skips the boot-time model preload |
 | `KRONK_AUTO_COMPACT` | `true` | `false` disables automatic compaction |
 | `KRONK_COMPACT_AT` | `0.85` | Fraction of the window that triggers compaction |
 | `KRONK_THEME` | `auto` | `dark` or `light` pins the palette; `auto` reads the terminal's background |
+| `KRONK_UPDATE_CHECK` | `true` | `false` never asks the package manager whether a newer kronk-cli exists — no subprocess, ever |
 | `NO_COLOR` | — | Any value disables colour |
 | `FORCE_COLOR` | — | `0` disables colour; any other value keeps it on through a pipe |
 
@@ -908,9 +1057,10 @@ Kronk reports the **effective** window for whichever model id you selected — t
 Every limit is read from the selected model's profile, and re-read when the selection changes:
 the window, the output cap (`sampling-parameters.max_tokens`), whether the chat template
 understands `preserve_thinking`, and the model's native maximum. `/model` mid-session moves all
-of them, and a sub-agent running on `KRONK_SUBAGENT_MODEL` compacts against *its* window rather
-than the main model's. The one number that is not taken from the profile is a `KRONK_MAX_TOKENS`
-you set yourself — yours always wins.
+of them, and a sub-agent — whether it is running on `KRONK_SUBAGENT_MODEL` or on a model a task
+named for itself, see [Picking a model per task](#picking-a-model-per-task) — compacts against
+*its own* window rather than the main model's. The one number that is not taken from the profile
+is a `KRONK_MAX_TOKENS` you set yourself — yours always wins.
 
 Three places surface it:
 
@@ -1238,30 +1388,53 @@ The model can hand one job to a **sub-agent**: a fresh agent with its own contex
 own tool loop, and no memory of your conversation. It runs the task, and the only thing that
 ever comes back is its report.
 
+While it runs, it draws in a box below the prompt that redraws in place:
+
 ```console
 › which tools in this repo need approval, and where is that decided?
 
   1 ⚙ task explore: list every tool definition in src/, say which are gated and where
-   ┌ explore · list every tool definition in src/, say which are gated…
-   │   1/40 ⚙ search /def\(/ in src
-   │   ✓ 9 lines
-   │   2/40 ⚙ read src/tools.js
-   │   ✓ 587 lines
-   │   3/40 ⚙ read src/subagent.js
-   │   ✓ 211 lines
-   │   2104→380 tok · 58.1 tok/s · 1980 cached
+  ┌─ explore ──────────────────────────────────────── 6/40 · 48s ─┐
+  │ 4/40 ⚙ read src/tools.js                                      │
+  │ ✓ 587 lines                                                   │
+  │ 5/40 ⚙ search /NEEDS_APPROVAL/ in src                         │
+  │ ✓ 3 lines                                                     │
+  │ 6/40 ⚙ read src/subagent.js                                   │
+  └─ esc to collapse · ctrl-c to stop ────────────────────────────┘
+```
+
+When it finishes the box is erased, and what is left in the scrollback is the answer and one
+line saying what the run cost:
+
+```console
+  1 ⚙ task explore: list every tool definition in src/, say which are gated and where
    Six built-in tools. write_file and bash are gated, by NEEDS_APPROVAL at
    src/tools.js:261. MCP tools are gated by name, mcpNeedsApproval at :270.
    read_file, list_dir, search, set_plan and task are not gated.
-   └ 3 steps · 11.4s · /tmp/kronk-cli/mfa1k2-8817/task-001.json
+   └ 3 steps · 11.4s · /tasks 1 for the transcript
   ✓ 3 lines
 
   `write_file` and `bash`, from the `NEEDS_APPROVAL` set in src/tools.js:246…
 ```
 
-`│` marks the sub-agent's own loop; the unprefixed lines are its report, which is what the main
-agent receives as the tool result. `┌` and `└` fence one run, so two in a row are told apart in
-scrollback, and the closing line says what it cost and where the rest of it went.
+The box is the run's only appearance on screen, and that is deliberate. A nine-step survey
+printed into the conversation leaves forty lines of someone else's work between the question
+you asked and the answer you got; scroll back ten minutes later and the conversation is mostly
+sub-agent. While the run is going a live view is the only sign the thing is alive, and it is
+where you notice one thrashing — but once it has ended, almost none of it is worth keeping.
+
+Nothing is lost by erasing it. Everything the box shows is written to the run's transcript as
+it happens, so the box is a view of a file that outlives it, and `/tasks 1` below is how you
+read it back. Three keys and one fallback are worth knowing:
+
+- **`esc` collapses the box immediately** and the run carries on. For when you have seen enough
+  and want your screen back.
+- **`ctrl-c`** stops the run, as it stops anything else.
+- **An approval prompt wipes the box first.** A `code` sub-agent's `write_file` and `bash` stop
+  for the same question the main agent's do, and that question gets the terminal to itself.
+- **On a pipe or a dumb terminal there is no box at all.** `kronk-cli "…" | grep`, a CI job and
+  an `--auto` run nobody is watching each get the plain nested lines instead, in order, with no
+  cursor control in them.
 
 Three files were read. None of them is in your conversation: the 800-odd lines they cost were
 spent in a context that no longer exists, and all that is left in your window is the four-line
@@ -1273,10 +1446,10 @@ already leaving it.
 
 ### Reading a run back
 
-The report on screen is dimmed and capped at fourteen lines. That used to be the end of it: what
-the sub-agent read, what it ran, and any line fifteen of its report went out of scope with its
-context. Delegating is supposed to cost the *conversation* nothing — it was never supposed to
-cost you the ability to check.
+The report on screen is dimmed and capped at fourteen lines, and the box it ran in is gone. That
+used to be the end of it: what the sub-agent read, what it ran, and any line fifteen of its
+report went out of scope with its context. Delegating is supposed to cost the *conversation*
+nothing — it was never supposed to cost you the ability to check.
 
 So each run is written to a file as it goes, and `/tasks` reads them back.
 
@@ -1402,6 +1575,38 @@ the delegation *and* the work.
 > works — *"use a sub-agent to survey the test suite first"* — and is usually how you will
 > drive this.
 
+### Picking a model per task
+
+`KRONK_SUBAGENT_MODEL` is a session-wide setting — every delegated task ran on it, or on the main
+model, and changing your mind meant leaving the session. But which model suits a task is a
+property of the *task*, not of the session: a survey that reads thirty files and answers one
+question wants the small fast model; reproducing a build failure and fixing it wants the big one.
+
+So the `task` tool takes an optional `model`, and the delegating model picks it from what Kronk is
+actually serving — every chat model it has, with a bare id dropped when its own `/AGENT` profile
+is served beside it, offered as a fixed list rather than free
+text, so it can never ask for a model that does not exist. Leaving it out is unchanged:
+`KRONK_SUBAGENT_MODEL` if one is set, otherwise the main model.
+
+```console
+  1 ⚙ task explore: survey every call site of parseLimits · Qwen3.6-4B/AGENT
+  ┌─ explore · Qwen3.6-4B/AGENT ──────────────────────────────── 3/40 · 9s ─┐
+```
+
+The model actually used is named on the opening line and in the box, because naming one that is
+not already resident is not free. Kronk holds one large model at a time, so a task that asks for
+a different one pays a real cold load — the same 10–30s spinner `kronk-cli` itself waits through
+at startup — and may evict the model the rest of the session is running on. `/tasks` records which
+model each run was on, so a delegation that took a minute longer than the others is explained by
+the list, not a mystery.
+
+A task's own model gets *its* window and output cap, not the session's, read from that model's own
+limits the first time anything runs on it and kept for the rest of the session — the same
+argument [Context window](#context-window) already makes for `KRONK_SUBAGENT_MODEL`: a 32k
+sub-agent must not compact against the main model's 131k window. A model named that Kronk turns
+out not to be serving any more — unloaded mid-session, say — is not a failed delegation: the task
+still runs, on the same fallback as no `model` at all, with a note saying so in its report.
+
 ## Autonomous mode
 
 `--auto`, or `/auto` in the REPL, swaps in a system prompt that tells the model to finish the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kronk-cli",
-  "version": "0.6.1",
+  "version": "0.8.0",
   "description": "A Claude-Code-style terminal agent for local models served by Kronk.",
   "license": "Apache-2.0",
   "type": "module",

package/src/agent.js

@@ -12,7 +12,7 @@ import { maybeDistill } from './distill.js';
 import {
   carryChecklist, clearPlan, openItems, outstandingLines, planLines, pushNudge,
 } from './plan.js';
-import { runTask, taskTools, TASK_TOOL } from './subagent.js';
+import { runTask, taskTools } from './subagent.js';
 
 export const SYSTEM = `You are kronk-cli, a terse coding assistant running fully offline on the user's machine.
 
@@ -75,6 +75,9 @@ function endTurn(messages, { out = console.log, plan = true } = {}) {
   return messages;
 }
 
+/** Stands in for `liveLine()` under a pane, which is drawing the same seconds itself. */
+const QUIET_LIVE = { update() {}, done() {} };
+
 /**
  * Run one user turn to completion, looping while the model requests tools.
  *
@@ -89,6 +92,10 @@ function endTurn(messages, { out = console.log, plan = true } = {}) {
 export async function runTurn({
   messages, model, signal, approve, grant, mcp, auto = false, maxSteps = config.maxSteps,
   tools: toolset = TOOLS, plan: usePlan = true, out = console.log, stream = true, depth = 0,
+  // Print nothing that redraws the current line — the spinner and the live
+  // command line. Set by src/subagent.js when a pane is drawing the run, and
+  // the pane owns the bottom of the screen for as long as it is up.
+  quiet = false,
   // Called with the transcript so far after every round. Only src/subagent.js
   // passes one: a delegated run is the transcript nobody would otherwise keep,
   // and the round that ends it may be a throw or a step cap rather than a
@@ -125,7 +132,7 @@ export async function runTurn({
           : '(stopped: step cap reached)' });
       return endTurn(messages, { out, plan: usePlan });
     }
-    let sp = spinner(depth ? 'sub-agent' : 'thinking');
+    let sp = quiet ? null : spinner(depth ? 'sub-agent' : 'thinking');
     let text = '';
     let reasoning = '';
     let calls = [];
@@ -278,7 +285,12 @@ export async function runTurn({
       // The same list the model was offered, not just the name it used: with
       // delegation off, or below the top level, a `task` call is a call to a
       // tool that does not exist and falls through to runTool saying so.
-      const isTask = !isMcp && call.name === 'task' && tools.includes(TASK_TOOL);
+      //
+      // By name, not by identity — src/subagent.js rebuilds the task tool's
+      // definition object whenever the served-model list changes, so an
+      // object captured in `tools` at the top of this turn need not be the
+      // same reference `taskTools` would hand back if asked again now.
+      const isTask = !isMcp && call.name === 'task' && tools.some((t) => t.function.name === 'task');
       const label = isMcp
         ? `${c.magenta('⚙')} ${call.name} ${c.grey(JSON.stringify(args).slice(0, 120))}`
         : `${c.blue(`⚙ ${describe(call.name, args)}`)}`;
@@ -342,7 +354,7 @@ export async function runTurn({
           result = `error: the sub-agent failed — ${e.message}`;
         }
       } else {
-        const live = liveLine();
+        const live = quiet ? QUIET_LIVE : liveLine();
         try {
           result = isMcp
             ? await mcp.call(call.name, args)

package/src/argv.js

@@ -18,6 +18,7 @@
  */
 const SPECS = [
   { names: ['-h', '--help'], kind: 'flag', key: 'help' },
+  { names: ['-v', '--version'], kind: 'flag', key: 'version' },
   { names: ['-l', '--models', '--list'], kind: 'flag', key: 'models' },
   { names: ['--mcp-list'], kind: 'flag', key: 'mcpList' },
   { names: ['--no-context'], kind: 'flag', key: 'noContext' },
@@ -32,6 +33,12 @@ const SPECS = [
   { names: ['--steps'], kind: 'value', key: 'steps' },
   { names: ['--context'], kind: 'value', key: 'context' },
   { names: ['--mcp'], kind: 'optional', key: 'mcp' },
+  { names: ['--role'], kind: 'value', key: 'role' },
+  { names: ['--json'], kind: 'flag', key: 'json' },
+  // Internal: how `kronk-cli rescue` re-invokes itself as the detached
+  // worker for one job id (src/rescue.js). Not documented in --help — it is
+  // not a thing anyone types, only a thing the CLI passes to itself.
+  { names: ['--rescue-worker'], kind: 'value', key: 'rescueWorker' },
 ];
 
 const BY_NAME = new Map(SPECS.flatMap((s) => s.names.map((n) => [n, s])));
@@ -101,7 +108,7 @@ const unknown = (token) => {
 export function parseArgv(argv) {
   const out = {
     error: null,
-    help: false, models: false, mcpList: false,
+    help: false, version: false, models: false, mcpList: false,
     noContext: false, noCompact: false, noWarm: false, noThink: false,
     noSubagents: false,
     auto: false, yes: false, dryRun: false,
@@ -109,6 +116,9 @@ export function parseArgv(argv) {
     context: null,
     steps: null,
     mcp: false, mcpNames: null,
+    role: null,
+    json: false,
+    rescueWorker: null,
     words: [],
   };
   const fail = (message) => ({ ...out, error: message });

package/src/boot.js

@@ -2,10 +2,43 @@ import { config, DEFAULT_MODEL } from './config.js';
 import { listLoaded, warm } from './client.js';
 import { c, spinner } from './ui.js';
 
-/** Last resort when neither the flag nor DEFAULT_MODEL is being served. */
+const PROFILE = '/AGENT';
+
+/**
+ * Every model Kronk is serving that a delegated task may be offered: the chat
+ * models, minus the embedding and reranking ones, and minus a bare id whose
+ * own /AGENT profile is also being served — Kronk holds each profile as a
+ * separate resident copy of the same weights, so offering both would let a
+ * task load a second copy of a model that is already in the pool.
+ *
+ * Deliberately *not* `pickDefault`'s rule. That one collapses to "the /AGENT
+ * profiles, if there are any", which is right when choosing a single default
+ * — a tuned profile beats an untuned model — and wrong for building a menu,
+ * because it throws away every model that has no profile of its own. The
+ * small fast model a survey wants is exactly the one least likely to have had
+ * a profile written for it, so applying the default-picking rule here would
+ * drop the most useful entry in the list and leave a menu of nothing but
+ * large models — on a pool that holds one large model at a time, a menu where
+ * every choice costs an eviction.
+ */
+export function chatModels(ids) {
+  const chat = ids.filter((id) => !/embedding|rerank/i.test(id));
+  const profiled = new Set(chat
+    .filter((id) => id.endsWith(PROFILE))
+    .map((id) => id.slice(0, -PROFILE.length)));
+  return chat.filter((id) => !profiled.has(id));
+}
+
+/**
+ * Last resort when neither the flag nor DEFAULT_MODEL is being served.
+ *
+ * Its own filter, unchanged: one model is being chosen on the user's behalf
+ * with nothing to go on, and there a tuned /AGENT profile wins over an
+ * untuned model outright rather than merely being listed beside it.
+ */
 export function pickDefault(ids) {
   const chat = ids.filter((id) => !/embedding|rerank/i.test(id));
-  const agent = chat.filter((id) => id.endsWith('/AGENT'));
+  const agent = chat.filter((id) => id.endsWith(PROFILE));
   const pool = agent.length ? agent : chat;
   return pool.sort((a, b) => b.length - a.length)[0] ?? null;
 }

package/src/config.js

@@ -77,6 +77,12 @@ export const config = {
   // one is not: nobody is watching a sub-agent, and its report is worth less
   // than the window it would spend earning it.
   subagents: (process.env.KRONK_SUBAGENTS ?? String(file.subagents ?? 'true')) !== 'false',
+  // The default model for a task that names none. A task's own `model`
+  // argument, when it has one, wins over this — see the `task` tool in
+  // src/subagent.js. Either way, the chosen model's window and output cap
+  // are resolved per model, not stored here: src/subagent.js keeps its own
+  // cache, because which limits apply now depends on the task, not the
+  // session.
   subagentModel: process.env.KRONK_SUBAGENT_MODEL ?? file.subagentModel ?? null,
   subagentSteps: Number(process.env.KRONK_SUBAGENT_STEPS ?? file.subagentSteps ?? 40),
   // Each sub-agent run is written to a file as it goes, so `/tasks` can show
@@ -86,9 +92,24 @@ export const config = {
   taskLog: (process.env.KRONK_TASK_LOG ?? String(file.taskLog ?? 'true')) !== 'false',
   // Same reason as modelConfigPath: so tests never go near the real one.
   taskLogDir: process.env.KRONK_TASK_LOG_DIR ?? file.taskLogDir ?? null,
+  // Where `kronk-cli rescue` keeps its job records — src/rescueStore.js.
+  // Deliberately not taskLogDir: that directory's lifetime is owned by
+  // src/tasklog.js's sweep() and cleanup(), and a rescue record has to
+  // survive both, so it lives somewhere neither of them has ever heard of.
+  rescueDir: process.env.KRONK_RESCUE_DIR ?? file.rescueDir ?? null,
   // Kronk's per-model runtime settings. `setup` is the only thing that writes
   // it; the override exists so tests never go near the real one.
   modelConfigPath: process.env.KRONK_MODEL_CONFIG ?? file.modelConfigPath ?? MODEL_CONFIG,
+  // The startup banner's "a newer kronk-cli exists" line asks the package
+  // manager that installed this copy, never the network directly — see
+  // src/update.js. Off entirely for anyone who wants a program that runs no
+  // subprocess it was not asked to run.
+  updateCheck: (process.env.KRONK_UPDATE_CHECK ?? String(file.updateCheck ?? 'true')) !== 'false',
+  // Same reason as modelConfigPath and taskLogDir: so tests never touch the
+  // real one, and a cold machine's first run does not have to guess where to
+  // put it.
+  updateCacheFile: process.env.KRONK_UPDATE_CACHE ?? file.updateCacheFile
+    ?? join(homedir(), '.kronk-cli-update-cache.json'),
   // Paths a previous session granted read-only to the sandbox, via `always` at
   // the credential prompt. Read-only is the whole point: KRONK_SANDBOX_ALLOW
   // grants writes as well, and these are credential stores.
@@ -101,9 +122,6 @@ export const config = {
   projectPrimer: null,
   contextWindow: null,   // filled in at boot from the chosen model's profile
   nativeContext: null,
-  // The sub-agent model's own limits, when one is configured. A sub-agent on
-  // a 32k model must not compact against the main model's 131k window.
-  subagentLimits: null,
   templatePreservesThinking: false,   // filled in at boot from the model's template
   samplingOverride: null,   // filled in at boot: params where the profile overrides the model's own
   rcPath: RC,