samagotchi 0.55.0 → 0.57.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f90692cf867e2bd082f40c2ae576604656d23169163ed5584f9221ccec528ac1
-  data.tar.gz: ac4852809e3ccdc332dd0d052e17671096eb167691cdde6f01fc2ef6e43b9870
+  metadata.gz: 75f7f85ba516cdddbcb52f53060ff9cad85ba2bbbb433baa0d8d4190dee29036
+  data.tar.gz: 992280b49b2b8843f85f62de8859b448ff0c4643680d7d1c5ab429ed645d35c6
 SHA512:
-  metadata.gz: 541c55286cdad591988db3b43af6c60480061f931b418c83ff44afe3fe62e677df638021f082ce42241bd1f0145ca3a88173f9046341e9d282351cdc92814a1c
-  data.tar.gz: ae24243b3978c3f8f87a655c50d9f446128618b63d6dc5b10923f09eef90d11fcd4bee714692d287157340029f83097476c7d057f27c8ddff98c86f30678758b
+  metadata.gz: 10d0cc0ee61e9eee9b0b96a03433e4bca70feb5e0f5a291eda877c5d892846cc935c94e399147b66f9df865fe432aa402512d05fbf2aafc6149adb6674cc69d0
+  data.tar.gz: 31d03c2a809991463364357bdd4f744120479b86e6f94d4b4e08026966f57d699f72025990eee0bd620887a06c3bdeb7d6d282e9983292dc5832c761691e2041

data/CHANGELOG.md

@@ -8,6 +8,68 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.57.0] - 2026-10-11
+
+### Added
+
+- Web: more refs. An edit or write approval card's path opens the current file at the first line the dry run
+  changes, and its diff lines open at theirs, so you can look at the real file before you approve. A read of a whole
+  file or a range (not the head/tail preview of a big file) gets a closed `lines 40–60` under its output: opened, it
+  shows the text as read with line numbers, and a click on a line opens the file there.
+- Web: a `path:line` in an answer or a step's text opens that file in your editor too, when it names a file the
+  session's tool rows touched (`app.js:12` names the one touched file ending in it). It links once the turn has ended
+  and after a reload; code blocks, links (a PR link stays the PR's) and files the session didn't touch stay text.
+- The `slow-commands` bundle, in the `core` profile: an `execute` that ran past its limit (or 80% of it) is remembered
+  for the project, and the next identical `execute` is denied once a turn with advice to start it with `task_create`
+  and wait with `task_wait` (with how long a finished task of it took, when there is one). `mode: notify` only warns;
+  `/slow-commands` lists a project's entries, `/slow-commands forget <n|all>` drops them. See "The slow-commands
+  bundle" in docs/plugins.md.
+- `after_tool_call` hooks get `call:` (the call that ran), `elapsed_ms:` (the tool's run, nil for a denied call) and
+  `result:` (the tool's own text, without the `[tool]` lead, the `ran as:` line or the cap).
+
+### Fixed
+
+- More of chi's internal objects (commands, bootstrap, gem update, the web token) no longer print the environment or
+  the web token when inspected, e.g. in a failing spec's output or a debugger: they show every other instance variable
+  but the ones holding the environment or token, which print `[redacted]`.
+- The host registry and a plugin's `ctx` no longer print the environment (API keys included) when inspected, e.g.
+  in a failing spec's output or a debugger: they show host names, addresses, key variable names and models.
+- `chi --resume ID --thinking X` whose `/thinking` fails (or waits for the running turn) now says `--thinking`, not
+  "could not set the --llm-context".
+- The MCP bundle no longer prints a server's env values or command arguments (e.g. a token) when inspected; a failing
+  spec or a debugger now shows only the server's state, the command's first word and the env's variable names.
+
+Update with `chi update`: it installs slow-commands (new in `core`, core 0.2.0) and updates mcp (0.6.2: no env
+values when inspected). Then restart `chi web`.
+
+## [0.56.0] - 2026-10-11
+
+### Added
+
+- `reasoning_history` (`drop`, `turn`, `all`) on a `models:` or `hosts:` entry, and `SAMAGOTCHI_REASONING_HISTORY`
+  for a whole process: which of its own reasoning a chat host's model gets back. `/model` names a configured level
+  and `chi self` shows it.
+- `/reasoning-history drop|turn|all|default` sets a session's own level (saved; continue and fork copy it); `/model`,
+  `/stats` and the web's session bar (a `reasoning` chip, on chat hosts) show it with its source.
+- `/thinking` and `/reasoning-history` ask before a change that makes the server read the conversation again (Gemma,
+  hosted APIs, a change to or from `all`); `--yes` applies at once. The terminal puts the `--yes` line in the next
+  input, the web's reply has an Apply button; `chi send`, `chi -p … --non-interactive` and piped lines apply directly.
+
+### Changed
+
+- A chat host (`api: openai`) now gets the running turn's reasoning back: each of the turn's earlier replies carries its
+  reasoning as `reasoning_content`, as Qwen's, Gemma 4's and DeepSeek's templates and the hosted APIs expect
+  (`reasoning_history: turn`, the default). A local Qwen thought ~8x less per request with it. `drop` sends none (as
+  before), `all` sends every reply's, earlier turns too. A host that refuses it (a 400 about reasoning) gets the step
+  again without it, and that model sends none from then on (a notice says so once). See "Reasoning history" in
+  docs/configuration.md.
+- `/thinking`'s cache note now tells a local chat server (only the tail; the whole prompt for a Gemma model) from a
+  hosted one (the whole conversation). The web's thinking chip sends its level with `--yes`.
+
+### Fixed
+
+- A local llama.cpp turn whose connection dropped mid-answer now restarts that step (up to twice) instead of failing.
+
 ## [0.55.0] - 2026-10-10
 
 ### Added
@@ -2461,7 +2523,9 @@ and long-lived sessions.
 - A macOS desktop helper (`chi desktop install`): a "Send to chi" Service and a
   hotkey panel that send selected text or the clipboard to your sessions.
 
-[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.55.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.57.0...HEAD
+[0.57.0]: https://github.com/dm1try/samagotchi/compare/v0.56.0...v0.57.0
+[0.56.0]: https://github.com/dm1try/samagotchi/compare/v0.55.0...v0.56.0
 [0.55.0]: https://github.com/dm1try/samagotchi/compare/v0.54.0...v0.55.0
 [0.54.0]: https://github.com/dm1try/samagotchi/compare/v0.53.0...v0.54.0
 [0.53.0]: https://github.com/dm1try/samagotchi/compare/v0.52.0...v0.53.0

data/README.md

@@ -76,7 +76,7 @@ It finds out whether the server is llama.cpp or OpenAI-compatible, picks the
 model (or asks, when there are several), sends one test request and writes
 the config. With a config already there, it adds a `hosts:` entry and keeps
 the rest of the file. Then it installs the `core` bundles (loop-guard,
-check-in, guardrails: the safety set for a small local model) and, on a
+check-in, guardrails, slow-commands: the safety set for a small local model) and, on a
 terminal, offers `dev` (known-names, mcp, btw, skills, source-links). Edit the
 file later as in [Configure](#configure); `chi bootstrap --help` has the
 options.

data/docs/architecture.md

@@ -280,7 +280,10 @@ process that already owns the `Engine`); every worker starts it, and it exposes:
   `404` for an unknown id. A POST with a body because routes match exact paths.
 - `POST /session/:id/command` — a session command (`/model`, `/models`, `!rollback`, `!cmd`,
   `/continue`) for the worker loop; `202` with a `command_id` its `:command_ran` names, `400` when
-  the line isn't one.
+  the line isn't one. A `:command_ran` carries `thinking`, `reasoning_history` and `llm_context`
+  (the summaries the next turn runs under) when the command changed them or the model, and
+  `confirm: {line, text}` when a `/thinking` or `/reasoning-history` change from a `web:` or `tui:`
+  client asks first (`CacheConfirm`; nothing changed, `line` applies it).
 - `POST /session/:id/exit` — ask the worker to exit now (`{client_id:}`). The worker checks with
   the event log held (`WorkerIdleExit#hold_for_request`): `200 {status: "exiting"}` and it leaves
   like an idle exit, or `409 {status: "held", reason:}` with `turn_running`, `input_queued`,
@@ -390,7 +393,8 @@ server's `reasoning_content`; the raw-prompt loop splits each generation's
 stream with a fresh `ThoughtStreamSplitter` (Qwen's `<think>` and Gemma's
 `<|channel>thought … <channel|>` are thinking, tool-call bodies are dropped
 from `text:`). The chat loop's model turns keep their `tool_calls` and tool results their `tool_call_id`,
-so later requests and resumed sessions pair them. It has its own system prompt
+so later requests and resumed sessions pair them, and their reasoning (`thinking:`), which goes back as
+`reasoning_content` on the running turn's replies (`reasoning_history`). It has its own system prompt
 (no raw-prompt tool declarations; the tools go as JSON schemas).
 
 `Engine#build_stream_event_handler` is the one seam both loops' streams pass

data/docs/cli.md

@@ -64,7 +64,7 @@ chi bootstrap                            # try localhost 8080, 11434, 1234, 8000
   or with anchors gets the lines printed to paste instead. `--dry-run` shows
   what it would write.
 - **The bundles.** Unless writing the config failed, it installs the system
-  bundle and the `core` profile (loop-guard, check-in, guardrails), one line
+  bundle and the `core` profile (loop-guard, check-in, guardrails, slow-commands), one line
   each; on a terminal it then asks `Also install dev (known-names, mcp, btw,
   skills, source-links)? [y/N]`. Run again, it installs nothing new: a bundle
   you uninstalled stays out ([Bundle profiles](memory.md#bundle-profiles-core-and-dev)).
@@ -489,14 +489,34 @@ from (`session`, `--thinking` / `SAMAGOTCHI_THINKING_LEVEL`, `models: <key>`,
 session's own level, which comes first; `/thinking default` unsets it. It is
 saved with the session (a `--resume`, a continue and `/model` keep it) and
 applies from the next turn's start; the reply says what the change costs the
-prompt cache: the whole prompt on native Gemma 4 (its `<|think|>` starts the
-prompt), only the tail on native Qwen, and other request fields on a chat host
-(a local llama.cpp or Splash server keeps its cache; a hosted API such as
-OpenRouter → Claude or OpenAI may restart its own). `/thinking` alone answers
+prompt cache: the whole prompt on Gemma 4 (native, or a local chat server whose
+model name says gemma: `<|think|>` starts the prompt), only the tail on Qwen
+(native, or a local llama.cpp or Splash server), and the whole conversation on a
+remote chat host (OpenRouter, a hosted API). `/thinking` alone answers
 mid-turn too; a change sent while a turn runs waits for the turn's end, and
 skips that turn's warm-up. `/stats` shows the level on its `thinking:` line.
 See "Thinking" in [configuration.md](configuration.md).
 
+`/reasoning-history` shows which of its own reasoning a chat host's model gets
+back from the next turn on, and where that came from (`session`,
+`SAMAGOTCHI_REASONING_HISTORY`, `models: <key>`, `hosts.<name>`, the default
+`turn`). `/reasoning-history drop|turn|all` sets the session's own level, which
+comes first; `/reasoning-history default` unsets it. It is saved and carried as
+`/thinking`'s is, and a native host ignores it (the reply says so). A change to
+or from `all` once an earlier reply has thinking rewrites the earlier replies;
+`drop` ↔ `turn` costs nothing. `/stats` shows it on its `reasoning history:`
+line, the web as the `reasoning` chip. See "Reasoning history" in
+[configuration.md](configuration.md).
+
+A `/thinking` or `/reasoning-history` change that restarts the prompt cache
+asks first: the reply says what it costs, changes nothing, and names the line
+that applies it (`/thinking low --yes`). `--yes` (or `-y`) applies it at once.
+The terminal puts that line in the next input (Enter applies it); the web's
+reply has an Apply button. `chi send ID "/thinking low"`,
+`chi -p "/thinking low" --non-interactive` and lines piped into the REPL apply
+without asking (a plain `chi -p` opens the REPL, which asks). See "Changes that
+restart the prompt cache" in [configuration.md](configuration.md).
+
 ### Typing during a turn
 
 The prompt stays open while a turn runs, in an attached terminal and in the plain
@@ -525,9 +545,10 @@ REPL alike:
   - At once, beside the turn: `/stats`, `/recap`, `/help`, `/context`, a
     plugin's anytime command (`/btw`), and the commands that only show
     something: `/models` (with a filter too), and `/model`, `/llm-context`,
-    `/thinking` and `/guardrails` alone.
+    `/thinking`, `/reasoning-history` and `/guardrails` alone.
   - After the turn: the ones that change something (`/model X`, `/model clear`,
-    `/llm-context strategy …`, `/thinking LEVEL`, `/guardrails revoke N`) and `!cmd`, whose output
+    `/llm-context strategy …`, `/thinking LEVEL`, `/reasoning-history LEVEL`, `/guardrails revoke N`) and
+    `!cmd`, whose output
     joins the conversation. `(queued: runs after this turn)` says so at once (the
     web draws the command's bubble dashed, with the same words, until it ran);
     when the turn ends they run in the order sent, a prompt sent before one
@@ -698,7 +719,8 @@ as you toggled them. A reloaded session shows the same block
 from the saved messages (each step's thinking, narration, tool parameters
 and output, the output capped at 2000 characters) and the timing records
 (status and duration per row). On an `api: openai` host the model's
-reasoning is saved with each step for this (never sent back to the model);
+reasoning is saved with each step for this (and sent back to the model
+within the turn: see "Reasoning history" in [Configuration](configuration.md));
 steps saved before that have none, so they show no thinking. An `edit` or
 `write` row has a closed `diff +3 −1` under it that opens to the change it
 made (up to 120 lines or 8 KB), live and after a reload (see

data/docs/configuration.md

@@ -487,15 +487,15 @@ models:
   (`chi web`'s, say) wakes it later: use `chi send --new --thinking low`.
 - A level is fixed for a turn: a change takes effect at the next turn's start. `/thinking LEVEL` sent while a turn
   runs waits for its end (as `/model X` does), and holds off that turn's warm-up. What a change costs the prompt cache,
-  which `/thinking` says:
+  which `/thinking` says (and asks before the costly ones: "Changes that restart the prompt cache"):
 
-  | Backend | A level change |
-  |---|---|
-  | native Qwen (`qwen36`) | only the prompt's tail (the empty thought after the cue) |
-  | native Gemma 4 (`gemma4`) | the whole prompt is read again: `<\|think\|>` starts the system prompt |
-  | chat host, local llama.cpp or Splash | other request fields; the server keeps its cache (a Gemma template re-reads it all) |
-  | chat host, OpenRouter → Claude | thinking params are part of the cached prefix: the cache restarts |
-  | chat host, OpenRouter → OpenAI reasoning | an effort change rewrites hidden instructions: the prefix is lost |
+  | Backend | A level change | Asks |
+  |---|---|---|
+  | native Qwen (`qwen36`) | only the prompt's tail (the empty thought after the cue) | no |
+  | native Gemma 4 (`gemma4`) | the whole prompt is read again: `<\|think\|>` starts the system prompt | yes |
+  | chat host, local (llama.cpp, Splash), a model name with `gemma` | the whole prompt: the template writes the same token | yes |
+  | chat host, local, any other model | other request fields; the server keeps its cache, only the tail changes | no |
+  | chat host, remote (OpenRouter, a hosted API) | Claude's thinking params are part of the cached prefix, an OpenAI effort change rewrites hidden instructions: the conversation is read again | yes |
 
 - `models:` levels and `thinking.level` in the file are read every turn; a host's `thinking:` reaches a worker when
   it starts, as its `sampling:` does (`chi sessions stop` to change it).
@@ -539,6 +539,81 @@ hosts:
 A different level changes a native model's system prompt (Gemma's token, Qwen's turn preamble), so the next turn
 reads the whole context again once; on a chat host only the end of the prompt changes.
 
+## Reasoning history
+
+Which of its own reasoning a chat host's model (`api: openai`) gets back. chi saves each step's reasoning; with it
+sent back, the model goes on from its own plan between tool calls instead of working it out again (in one test a local
+Qwen thought about 8x less per request and finished a small task about 40% sooner). One level, set per model or per host:
+
+```yaml
+hosts:
+  deepseek-api:
+    url: https://api.deepseek.com/v1
+    api: openai
+    api_key_env: DEEPSEEK_API_KEY
+    reasoning_history: all   # its API wants every earlier reply's reasoning when tools are sent
+models:
+  some-model:
+    reasoning_history: drop
+```
+
+- `turn` (the default) sends the running turn's reasoning: each reply since the last user message carries its
+  reasoning as `reasoning_content`, which is what Qwen's, Gemma 4's and DeepSeek's chat templates and the hosted APIs
+  (OpenRouter takes it for DeepSeek, Qwen and other text-reasoning models) expect. The running turn starts at the
+  last message you sent (a prompt, or a steer: as the chat template counts it) and never before the turn's own start,
+  so a turn that goes on by itself (a reminder, a context wake, a continue after a stop) sends nothing of the one
+  before it, an interrupted reply's partial thought included.
+- `drop` sends none (what chi did before this setting).
+- `all` sends every reply's reasoning, earlier turns too. It sends only the field: a local template that leaves out
+  earlier turns' reasoning (Qwen's) needs `sampling: {chat_template_kwargs: {preserve_thinking: true}}` as well.
+- Order, first set wins: the session's own level, `SAMAGOTCHI_REASONING_HISTORY` (the whole process; for A/B runs),
+  the `models:` entry (found the way `profile:` is), the `hosts:` entry, then `turn`. Anything else than a level warns
+  once and counts as unset. A host's level reaches a worker when it starts, as its `sampling:` does.
+- **A session's own level** (`drop`, `turn` or `all`; an explicit `turn` counts as its own) is saved in the session
+  (its file's `"reasoning_history"`), so a `--resume`, a respawned worker, a continue and `/model` keep it; a plugin's
+  fork copies it, a delegate child starts without it. Set it with `/reasoning-history LEVEL` in the session
+  (`/reasoning-history default` unsets it, `/reasoning-history` alone shows the level and where it came from) or the
+  web's `reasoning` chip in the session bar (shown on chat hosts only). There is no start flag: a fresh session runs
+  the command before its first turn at no cost. A change takes effect at the next turn's start; sent while a turn runs
+  it waits for its end.
+- What a change costs the prompt cache (`/reasoning-history` says so, and asks first when it costs: "Changes that
+  restart the prompt cache"):
+
+  | Change | Cost |
+  |---|---|
+  | `drop` ↔ `turn` | none: a turn's first request carries no reasoning under either |
+  | to or from `all`, once an earlier reply has thinking | every earlier reply gains or loses its reasoning: a server that renders it (hosted APIs, llama.cpp's default template) reads the conversation again from the first earlier thought |
+  | nothing thought yet, the same level, or a native host | none |
+
+- The native loop (`/completion`) ignores it: it always keeps the running turn's reasoning, a mid-turn steer included
+  (the chat loop starts again after a steer).
+- When a host answers a request that sent reasoning back with an HTTP 400 about reasoning, chi asks again without it,
+  sends none to that model from then on (until the worker restarts) and says so once. If the request without it is
+  refused too, the thinking fields get the same fallback ("Thinking") and the reasoning goes back on the next step.
+- `/model` names a level that isn't the default (`reasoning history: drop (models: some-model)`, `all (session)`),
+  `/stats` shows it on its `reasoning history:` line (chat hosts only), and `chi self` on its `reasoning history` row
+  (a session's own level first when run from its commands).
+- Claude via OpenRouter signs its reasoning (`reasoning_details`), which chi doesn't keep: it gets the plain text,
+  and the fallback above covers a refusal.
+
+## Changes that restart the prompt cache
+
+`/thinking` and `/reasoning-history` ask before a change that makes the server read the conversation again: Gemma's
+thinking switch, a remote chat host's thinking fields ("Thinking"), and a change to or from `all` once an earlier reply
+has thinking ("Reasoning history"). They ask only when the level the next turn runs under really changes and the
+session has a model reply.
+
+- The reply says what it costs and changes nothing yet: `Nothing changed yet: send /thinking low --yes to apply.`
+- `--yes` (or `-y`, anywhere after the command) applies it at once.
+- The terminal (the REPL and an attached TUI) puts the `--yes` line in the next input: Enter applies it.
+- The web's reply bubble has an **Apply (restarts the cache)** button. The session bar's chips are already an explicit
+  choice: their Set sends the `--yes` line, and their form says what a change costs. Command bubbles are page-only, so
+  the button is gone after a reload.
+- Only a person at a web tab or a chi TUI is asked. `chi send ID "/thinking low"`,
+  `chi -p "/thinking low" --non-interactive`, lines piped into the REPL, a delegate, a plugin and a card's action
+  apply directly, since nobody would see the question; so do the start flags (`chi --thinking` on a resumed or
+  attached session sends `/thinking LEVEL --yes`). A plain `chi -p` opens the REPL, which asks.
+
 ## Llama HTTP Timeouts
 
 Long-running llama.cpp completions can exceed Ruby's default HTTP read timeout.
@@ -1199,6 +1274,7 @@ described in their own sections.
 | `context.every_seconds` | `300` | | How often an attached context source's command runs when it has no `--every` (seconds, at least 30). See [Attached context](context.md). |
 | `context.wake` | `true` | yes | A source whose update says `wake: true` may start a turn in a live, idle session (one per source per 10 minutes, within `session.max_wakes`); `false`: updates wait as notes for the next turn. See [Waking](context.md#waking). |
 | `thinking.turn_preamble` | `true` | yes | Ask a `qwen36` model to open its thinking with a short `TURN:` line (the step label). |
+| `reasoning_history` | `turn` | | Which of its reasoning a chat host's model gets back: `drop`, `turn`, `all`; environment only (`SAMAGOTCHI_REASONING_HISTORY`), below a session's own level (`/reasoning-history`), above the `models:`/`hosts:` entries. See "Reasoning history". |
 | `thinking.level` | `default` | `--thinking` | `off`, `low`, `medium`, `high` or `default` for every model; the flag and env outrank the `models:`/`hosts:` entries, the file's value doesn't; a session's own level outranks them all, and `--thinking` sets it on a session run (on `chi web` it sets this). See "Thinking". |
 | `models.<key>.thinking`, `hosts.<name>.thinking` | none | | A model's or host's level. See "Thinking". |
 | `hosts.<name>.models` | none | | The model ids a host serves whatever its `/v1/models` lists: a map of ids, or a plain list. See "Models a host serves but doesn't list". |

data/docs/hooks.md

@@ -56,7 +56,7 @@ The plugin class must respond to `#call(event)` — duck-typed, no base class re
 | `:after_generation` | After LLM returns (both loops); not after a generation a hook cut (`stop_generation`) | `{ type: :after_generation, iteration: N, response: "...", messages: [...] (the conversation as sent) }` |
 | `:generation_progress` | While the response streams, in batches (see [Watching the stream](#watching-the-stream)) | `{ type: :generation_progress, iteration: N, thinking: "..." (new since the last fire), text: "..." (new visible text), thinking_chars: N, text_chars: N (this generation so far), elapsed_ms: N, restarted: true (only on the first fire after a dropped stream was asked again) }` |
 | `:before_tool_call` | Before tool dispatch (and before `tool_call_started`) | `{ type: :before_tool_call, iteration: N, call: {...}, params: "...", guardrail: Verdict, context: {...}, targets: {...}, blocked: false, block_reason: nil }` |
-| `:after_tool_call` | After tool execution | `{ type: :after_tool_call, iteration: N, tool: "read", output: "..." (the text the model gets: capped at max_tool_output_chars, a cut one ending in a [cut: N of M chars …] line), status: "ok" \| "error" \| "blocked" \| "stopped" }`; `stopped` is a `task_wait` the turn's Stop ended (the task runs on) or whose task was stopped |
+| `:after_tool_call` | After tool execution | `{ type: :after_tool_call, iteration: N, tool: "read", output: "..." (the text the model gets: capped at max_tool_output_chars, a cut one ending in a [cut: N of M chars …] line), status: "ok" \| "error" \| "blocked" \| "stopped", call: {...} (the call that ran, as the gate left it), elapsed_ms: N (the tool's own run, without an approval wait; nil for a denied call), result: "..." (the tool's own text: no "[read]" lead, no "ran as:" line, never cut) }`; `stopped` is a `task_wait` the turn's Stop ended (the task runs on) or whose task was stopped. Match on `result:`, not `output:`: it is what the tool said (`Error: command timed out after 120s` for an execute killed at its limit, `Samagotchi::Tools::Execute::TIMEOUT_PREFIX`) |
 | `:session_end` | After each turn `:after_turn` fires for, after it (turn-level lifecycle) | `{ type: :session_end, session_id: "..." }` |
 
 Every event also carries the hook runtime (next section): `hook:` (the label
@@ -507,7 +507,7 @@ Notes:
 - Ordering: bundle hooks fire by `(priority, bundle_name, hook_name)` (lower priority first), then plain `config.yml` hooks in registration order.
 - Settings: a hook class with `initialize(settings = {})` gets the bundle's section of `config.yml` `bundles:` (see [Settings](#settings)).
 - A bundle can also ship a `plugin.rb` whose `chi.on(event)` blocks are bundle hooks too, next to commands and tools; see [Plugins](plugins.md). There `ctx.notify`, `ctx.steer` and the other `ctx` helpers act as this page's `event[:notify]`… do for the event the block runs for.
-- Shipped bundles (each in a profile: `core` or `dev`, see [Bundle profiles](memory.md#bundle-profiles-core-and-dev)): `chi bundle install guardrails` (rules, see [Guardrails](guardrails.md#the-guardrails-bundle)) and `chi bundle install known-names` (a hook, see [Guardrails](guardrails.md#the-known-names-bundle)), `chi bundle install source-links` (a hook: announces source refs, see [The source-links bundle](#the-source-links-bundle)), `chi bundle install btw` (a plugin: `/btw`, see [Plugins](plugins.md#the-btw-bundle)), `chi bundle install mcp` (a plugin: tools from MCP servers, see [Plugins](plugins.md#the-mcp-bundle)) `chi bundle install loop-guard` (a plugin: breaks tool-call loops, see [Plugins](plugins.md#the-loop-guard-bundle)), `chi bundle install check-in` (a plugin: checks on a long turn, see [Plugins](plugins.md#the-check-in-bundle)) and `chi bundle install skills` (a plugin: `/skill`, versions of skills, see [Plugins](plugins.md#the-skills-bundle)).
+- Shipped bundles (each in a profile: `core` or `dev`, see [Bundle profiles](memory.md#bundle-profiles-core-and-dev)): `chi bundle install guardrails` (rules, see [Guardrails](guardrails.md#the-guardrails-bundle)) and `chi bundle install known-names` (a hook, see [Guardrails](guardrails.md#the-known-names-bundle)), `chi bundle install source-links` (a hook: announces source refs, see [The source-links bundle](#the-source-links-bundle)), `chi bundle install btw` (a plugin: `/btw`, see [Plugins](plugins.md#the-btw-bundle)), `chi bundle install mcp` (a plugin: tools from MCP servers, see [Plugins](plugins.md#the-mcp-bundle)) `chi bundle install loop-guard` (a plugin: breaks tool-call loops, see [Plugins](plugins.md#the-loop-guard-bundle)), `chi bundle install check-in` (a plugin: checks on a long turn, see [Plugins](plugins.md#the-check-in-bundle)), `chi bundle install slow-commands` (a plugin: commands that ran past the execute limit are run as tasks next time, see [Plugins](plugins.md#the-slow-commands-bundle)) and `chi bundle install skills` (a plugin: `/skill`, versions of skills, see [Plugins](plugins.md#the-skills-bundle)).
 - Installing a bundle executes its hook code at `Engine` startup. Only install bundles you trust, as you would a gem. Hooks are **not** executed at install time (copy-only); they are `module_eval`'d at `Engine.new` inside per-bundle `Samagotchi::Bundles::<name>` namespaces (no top-level `require` collisions). Keep hook files side-effect-free at load time; do work in `#call` — top-level side effects (require, IO, `at_exit`, global assignment) run once per `Engine.new` (class redefinition is idempotent).
 
 Lifecycle:

data/docs/internals/background-tasks.md

@@ -24,6 +24,6 @@ Behavior:
 - `task_get` returns metadata and `output_path`; use `read` for output contents.
 - `task_wait` accepts `timeout`, `tail_lines` (maximum 100), and `done_pattern` (a regular expression string).
 - `task_create` accepts `env` as a JSON object string for deterministic overrides such as `PATH`; use an absolute interpreter path when that is simpler. Ruby/Bundler isolation variables remain protected.
-- `execute` and `task_create` export chi's own markers into the command, set over the model's `env` (which can't set them: `Error: env key is reserved`): `SAMAGOTCHI_PARENT_SESSION` (the session's id, `chi` without one; a chi started there answers as a parent agent), `SAMAGOTCHI_SESSION_MODEL` (the resolved ref the session runs on, read at each call so it follows `/model`; unset when unknown) and `SAMAGOTCHI_SESSION_THINKING` (the session's own thinking level; unset when it has none). `chi self` reads the last two for its model and thinking level. The three are `TaskRuntime::MARKER_ENV_KEYS` (and `SessionManager::SESSION_MARKER_ENV`, which a spawned worker unsets). A session's worker never inherits them from whoever started it (a `chi send` run by another session's `execute`): its other commands (a user's `!cmd`, an MCP server, a context command) have none.
+- `execute` and `task_create` export chi's own markers into the command, set over the model's `env` (which can't set them: `Error: env key is reserved`): `SAMAGOTCHI_PARENT_SESSION` (the session's id, `chi` without one; a chi started there answers as a parent agent), `SAMAGOTCHI_SESSION_MODEL` (the resolved ref the session runs on, read at each call so it follows `/model`; unset when unknown) `SAMAGOTCHI_SESSION_THINKING` (the session's own thinking level; unset when it has none) and `SAMAGOTCHI_SESSION_REASONING_HISTORY` (its own reasoning_history level, the same way). `chi self` reads the last three for its model, thinking level and reasoning history. The four are `TaskRuntime::MARKER_ENV_KEYS` (and `SessionManager::SESSION_MARKER_ENV`, which a spawned worker unsets). A session's worker never inherits them from whoever started it (a `chi send` run by another session's `execute`): its other commands (a user's `!cmd`, an MCP server, a context command) have none.
 
 Work that needs a model, not a shell command, goes to a child chi session instead: `delegate` / `delegate_result` have the same shape (start, then wait) and return only the child's final reply; see [Sessions: Delegating](../sessions.md#delegating).

data/docs/internals/engine.md

@@ -174,6 +174,19 @@ The differences from the native loop:
   as `stable_length:`), where the prompt's stable part ends. For remote Claude, `LLM::PromptCache` puts the
   first cache breakpoint there; see prompt-caching.md.
 - Each call's result is its own tool message, paired by `tool_call_id`.
+- A model turn's saved reasoning (`thinking:`) goes back as `reasoning_content` per the turn's
+  `TurnSettings#reasoning_history` (`ReasoningHistory.resolve`, the session's own level first:
+  `Session#reasoning_history`, `/reasoning-history`): `all` on every model message, `turn` past
+  `ChatLoop#reasoning_boundary`: the later of the last query (a `role: "user"` entry: a prompt, a steer, merged input,
+  the chat template's `last_query_index`; or a `turn_start` entry) and the Run's start (`Run`'s `@start`, the
+  conversation length at `#complete`), so a continue turn (reminder, context wake, continue after a stop) replays
+  nothing of the run before. `Run#prompt_chars` counts it (`#reasoning_chars`). The native loop differs on a steer:
+  `KernelLoop#inject_pending_input!` doesn't re-sanitize, so native keeps the turn's reasoning across a mid-turn
+  steer, where the chat loop starts again (as the template does).
+- A 400 about reasoning (`BadRequest#reasoning_refused?`) for a request that sent reasoning back asks the step again
+  without it; when that goes through, `#reasoning_history_refused!` marks the model (worker lifetime) and
+  `:reasoning_history_refused` goes out. When it is refused too, the thinking-fields fallback (`#thinking_refused!`,
+  `:thinking_refused`) runs on it, still without reasoning. Up to three requests per step.
 
 ### Shared: ToolResponse (per batch) and ToolRunner (per call)
 
@@ -320,6 +333,7 @@ Turn events (the main ones; `Events` in `events.rb` keeps the shared sets):
 | `:empty_answer_retry` | an empty, cut or malformed answer is asked again | `{iteration, attempt, of, finish_reason, thinking_chars, stopped_by?, malformed?}` |
 | `:steer_cut` | a steer cut the generation | `{iteration, source}` |
 | `:llm_context_edited` | the apply rule applied a batch of LLM context edits (a request, a forget_outputs call, turn end; never the warm-up) | `{moment, why, freed_tokens, tail_tokens, staged, text, groups}` (`LLMContextNotice`) |
+| `:thinking_refused` / `:reasoning_history_refused` | the chat loop asked a step again without the thinking fields / the reasoning sent back; the Engine logs it and makes a once-per-session-and-host `:hook_notice` of it, the event itself never reaches the sink | `{iteration, model, level, detail}` |
 | `:pending_input_merged` | queued input joined the conversation | `{iteration, count, content, steers?, answer}` |
 | `:tool_dispatch_started` / `:tool_dispatch_completed` | around a batch | `{iteration, call_count}` |
 | `:tool_call_started` | before a call runs | see ToolRunner |

data/docs/internals/prompt-caching.md

@@ -135,6 +135,14 @@ is prefilled once. The native and the chat loop use the same plan.
    on its `generation_completed` log line. `/stats` shows "cached N (P%)" and "cache writes". A change that
    drops `cached=` on the second fresh session is a regression. Update the prompt snapshot fixtures with
    `UPDATE_PROMPTS=1` and read the diff: a cache-friendly change moves sections, it doesn't reorder per run.
+6. **Ask before a setting change that restarts the cache.** A session setting whose change makes the server read
+   the conversation again asks a person at a web tab or a TUI first (`CacheConfirm`: the reply carries the
+   `--yes` line, `SessionCommands::Result#confirm` and the `command_ran` event's `confirm`). Each setting has a
+   classifier: `Thinking.cache_cost` (`:full` for Gemma, `:provider` for a remote chat host, `:tail` otherwise) and
+   `ReasoningHistory.cache_cost` (`:history` for a change to or from `all` once an earlier reply has thinking).
+   `CacheConfirm.needed?` asks only for `:full`, `:provider` and `:history`, when the effective level changes and
+   the session has a model reply. A new setting with a cost (a `/model` across templates, `/llm-context` turning
+   forget on) adds its classifier and goes through the same step.
 
 ## Server-side settings worth knowing
 

data/docs/memory.md

@@ -269,7 +269,7 @@ profiles, meta bundles that install a set of them:
 
 | profile | bundles |
 |---|---|
-| `core` | loop-guard, check-in, guardrails: the recommended safety set |
+| `core` | loop-guard, check-in, guardrails, slow-commands: the recommended safety set |
 | `dev` | known-names, mcp, btw, skills, source-links, github-pr, coordinator |
 
 `chi bootstrap` installs `core` and, on a terminal, offers `dev`. An existing

data/docs/plugins.md

@@ -1171,6 +1171,69 @@ and goes with the session; another session starts from config.yml:
 | `/checkin mode ask` / `nudge` / `notify` | the mode |
 | `/checkin nudge` / `later` / `stop` | the card's actions, also by hand |
 
+## The slow-commands bundle
+
+`chi bundle install slow-commands` installs the bundle shipped with chi (`chi
+bootstrap` installs it with the `core` profile). It is written only against
+this API (`lib/samagotchi/bundles/slow-commands/plugin.rb`), with `chi.on`
+hooks and a `/slow-commands` command, and has no memory file.
+
+`execute` kills a command at its limit (120 s, `execute.timeout_sec`). A full
+test suite or a build takes longer, so the model loses those two minutes,
+then starts it again with `task_create` and `task_wait`; the next session
+does the same. slow-commands remembers such a command for the project:
+
+- An `execute` that **timed out**, or ran **`warn_ratio` of the limit** or
+  longer (default 0.8, so 96 s of 120), is recorded as slow. A later run of
+  it under half the limit **with exit 0** drops the entry; a fast failure (a
+  load error) doesn't, since it says nothing about how long the suite takes.
+  Nor does one through a filter the key leaves out (`rspec 2>&1 | tail -30`
+  exits with `tail`'s 0, and a `| head` can end it early).
+  A call the user stopped, or that was denied, records nothing.
+- The **next identical `execute`** is **denied** with advice:
+
+  ```
+  [execute] Error: denied by guardrail (bundle slow-commands): slow command. The user was not asked. This command ran past the execute limit (120 s) here on 2026-10-09. Start it with task_create, then task_wait (timeout 600). A finished task of this command took 4m10s.
+  ```
+
+  The last sentence is there when a task of the same command (and cwd)
+  finished with exit 0 in the project's `tmp/tasks`; a longer one raises the
+  `task_wait` timeout it suggests. The user sees one line:
+  `slow-commands> execute bundle exec rspec: ran past 120 s before, denied`.
+- **Once per command per turn**: the same `execute` again in that turn runs.
+  The model insisting is a signal (maybe the suite got faster), and that run
+  records the new truth. A new turn denies again.
+
+A command is the same when its project and its text match. The project is
+the session's git checkout (else its working directory). The text is the
+command's words and operators (`a && b` is not `a b`), the call's `cwd:`
+folded in as `cd web && …`, and a trailing `2>&1`, `| tail …`, `| head …`
+or `| grep …` dropped (they don't change how long it runs). Arguments stay:
+`bundle exec rspec` (the suite) is slow, `bundle exec rspec
+spec/foo_spec.rb` isn't the same command, and stays the fast path. A
+command that ends inside a quote, `$(` or heredoc is never recorded, nor
+one with a `$(…)`, backticks or a heredoc `cat` or `tee` reads (the key
+can't tell two of those apart). A heredoc script (`python3 - <<'EOF'`)
+keeps its body in the key, so each script is its own command.
+
+Entries live in `$XDG_STATE_HOME/samagotchi/plugins/slow-commands/commands.json`,
+shared by every session (another session's record counts at once) and
+forgotten after `ttl_days`.
+
+```yaml
+# config.yml
+bundles:
+  slow-commands:
+    mode: deny        # deny | notify (warn the user, never deny)
+    warn_ratio: 0.8   # a run this share of the execute limit or longer is slow
+    ttl_days: 14      # entries older than this are forgotten
+```
+
+| | |
+|---|---|
+| `/slow-commands` | this project's slow commands, numbered |
+| `/slow-commands forget 2` / `forget all` | drop one (a wrong entry) or all of them |
+
 ## The skills bundle
 
 `chi bundle install skills` (or the `dev` profile) installs the bundle shipped with chi

data/docs/sessions.md

@@ -68,7 +68,7 @@ chi sessions clean --dry-run --days 7            # test sessions older than 7 da
 **Ordering:**
 
 - `Session.list` / `SessionManager.list_sessions` / `GET /api/sessions?sort=&order=&limit=&offset=` default to `updated_at desc` (newest activity first). Also supports `created_at`, `asc`. `X-Total-Count` header when paginated.
-- Web UI (`chi web`): the page's scope is in its URL. Started in a git repo, `chi web` opens `/?dir=<that folder>`: that project's sessions, and new chats start in that folder; the header chip says `<project> · all`, and `all` opens the same place without `?dir` (every session; a new chat there starts in the server's own folder, shown on the start page, and cards name their folder; `← <project>` goes back to the project view it came from, or to the server's own project). One server serves every project: a second `chi web` (from another repo) finds it through `GET /api/info` and prints (with `--open`, opens) its page for its own folder instead of starting another. The 3 latest sessions sit above the chat (`hide ▴` puts them away behind a `▾ N sessions` pill, remembered; in a window under 900 px wide, where the strip scrolls sideways, `▴ hide` sits in the top bar where the pill comes back; a window under 700 px tall hides them by itself, so a question or approval card in the stage keeps room, and the pill shows them until the window is tall again). A parent and its delegates are one card there: its `▸ 2 delegates · 1 live · 1 waiting` chip (the waiting part in the attention colour, the card's border too) opens their rows in a popover under it (a row per delegate at any depth, indented; a click opens that one, Esc or a click outside closes it, and the strip's order holds while it is open). A fork is a card of its own, and so is a delegate whose parent isn't listed (archived, another project), with its `↳ <parent>` chip; the pill counts cards, and every live or waiting session. "All sessions" (or `/`) opens every session at `#/sessions`, with a search over preview, id and status (Esc or Back returns). There a parent's card holds its delegates the same way, the chip opening their rows inside the card (each with an archive button on hover), open by itself while one of them waits on you; the count says `14 (+7 delegates)`, a search that matches a delegate shows its parent's card with the list open and the matching rows marked, and select mode picks cards (archiving a parent takes its delegates). The open session is in the URL (`#/s/<id>`), so a reload or a copied link opens it again; the chi logo top left goes back to the empty start for a new chat. The message box grows with its text; drag its top edge to keep it taller (double-click resets). A file in a tool row (a read, edit or write's title) and its diff lines are refs: hover one and click to open the current file in your editor at that line, on this machine only (`web.editor`; the browser's "always allow" for the page's port and VS Code's "allow opening local files" are asked once; see [Opening files from chi web](configuration.md#opening-files-from-chi-web)). The info bar copies `chi --attach <id>` for a terminal. A session whose prompt carried model notes has a `notes: deepseek` chip there (the names without `model_notes_`; the tooltip lists each with its scope and size; `session.prompt_notes` in `GET /api/sessions/:id`, the live worker's, else the session file's; see [Memory](memory.md#model-notes)). Its `llm ctx` chip names the LLM context strategy the next turn runs under (`llm ctx stale,forget · session`, in the accent colour when the session set its own; the tooltip gives each value's source), and its popover sets the session's own strategy, apply rule and budget, or follows the model again, by running `/llm-context` in the worker (the reply shows as a command bubble); `GET /api/sessions/:id`'s `session.llm_context` carries the values (the live worker's, else resolved from the session file), and a `command_ran` that changed them carries the new ones. It shows the context used (`ctx 42%`) and the last generation's decode speed (`87 tok/s`, `~64 tok/s` when estimated; see `/stats` in [cli.md](cli.md#session-commands)); hovering `ctx` there or on a session card lists the session's tokens in (summed over every request, with the cached share), out (with reasoning) and the cost when the provider reports one, for this session only (one estimated from a `hosts.<name>.models` price shows with `~`: `cost: ~$0.54 ($0.42 reported, ~$0.12 estimated)`), and the memory indexes its prompt holds (`memory index: ~3.4k tokens in this session's prompt (system 2.0k, project 1.4k)`; see [Memory](memory.md#the-indexs-size)). The start page's model picker (bottom left of the composer, the chosen name `▾`) chooses the model a new chat starts on; it opens a search list over the conversation (↓ or a click; downward when the start page leaves no room above): an empty search shows the last 5 picks (Recent) and then each host's model ids A–Z under the host, the default host first (an id the host declares under `hosts.<name>.models` first, noted `config`, its tooltip `served by config (hosts.<name>.models)`; a host that failed to list its models keeps those ids, greyed and noted `host down`, still pickable; a remembered or default model stays chosen even then, greyed on the button); typed words must each match the host or the id (a substring, else for 3+ characters the letters in order, so `deepseek4.1 fla` finds `openrouter · deepseek/deepseek-v4.1-flash`), ⏎ picks, Esc/Tab close, a pick puts the focus in the message box: `GET /api/models` lists the hosts' models as chi spells them (`{default, models: [{name, host, id, configured?, unavailable?, sampling?, llm_context?}], warning?}`; `configured: true` marks an id declared under `hosts.<name>.models`, listed first under its host, `unavailable: true` one whose host failed to list its models; `sampling` is the model's configured request parameters as `/model` words them, the row's tooltip in the list; bare for the default host, `host:model` for the others, from the same cached lists as `/models`, a bounded wait, a host that is down noted in `warning`), and `POST /api/sessions` takes `model` (blank means the default). Beside it, an `llm ctx` chip shows the LLM context the picked model starts under (each `GET /api/models` row's `llm_context`, as the info bar's); its form sets one for the new chat only, sent as `POST /api/sessions`'s `llm_context` and never remembered (see [configuration.md](configuration.md#llm-context-a-sessions-own-strategy)). The start page's first message goes as later ones do: `POST /api/sessions` with `idle: true` and `preview` (the message, which names the session until its turn is saved), then `POST /api/sessions/:id/turn`, so a failed first turn puts its prompt back in the composer too; a first line that is one of the new session's commands (`/model …`) goes to `POST /api/sessions/:id/command` instead, as later ones do. The browser remembers the last model picked; a running session's model is in the info bar and changes only with `/model`. In the composer a line is a command when it is `!…` or starts with one of the session's command names (its `commands` list; `/stats`, `/exit` and the other terminal words get the page's own reply); an unknown `/word` (`/usr/bin/env is missing`) goes to the model as a prompt, as in a terminal; a one-word `/word` no command answers (`/modle`) is not sent: the page shows `Unknown command /modle. Did you mean /model? /help lists the commands.` (the "Did you mean" part only when a name is close). A `POST /turn` (or a session's first `prompt`) that is one of the worker's commands runs as that command too (`202 {status, command_id, session_id}`), so `chi send`, `chi -p` and a page whose command list lags all get the command. ↑/↓ in the composer walk the prompt history the TUI's ↑ walks ([Persistent Prompt History](cli.md#persistent-prompt-history)): ↑ with the caret on the first line, ↓ from the last line while browsing, ↓ past the newest brings the draft back; `GET /api/history` returns `{entries: [...]}`, oldest first (the page fetches it on focus and after each send). The server records a sent line in the routes once the worker took it (`POST /turn` accepted, a `!command` through `POST /command` or as a session's first line); `"history": false` in the body keeps it out (an image-only send).
+- Web UI (`chi web`): the page's scope is in its URL. Started in a git repo, `chi web` opens `/?dir=<that folder>`: that project's sessions, and new chats start in that folder; the header chip says `<project> · all`, and `all` opens the same place without `?dir` (every session; a new chat there starts in the server's own folder, shown on the start page, and cards name their folder; `← <project>` goes back to the project view it came from, or to the server's own project). One server serves every project: a second `chi web` (from another repo) finds it through `GET /api/info` and prints (with `--open`, opens) its page for its own folder instead of starting another. The 3 latest sessions sit above the chat (`hide ▴` puts them away behind a `▾ N sessions` pill, remembered; in a window under 900 px wide, where the strip scrolls sideways, `▴ hide` sits in the top bar where the pill comes back; a window under 700 px tall hides them by itself, so a question or approval card in the stage keeps room, and the pill shows them until the window is tall again). A parent and its delegates are one card there: its `▸ 2 delegates · 1 live · 1 waiting` chip (the waiting part in the attention colour, the card's border too) opens their rows in a popover under it (a row per delegate at any depth, indented; a click opens that one, Esc or a click outside closes it, and the strip's order holds while it is open). A fork is a card of its own, and so is a delegate whose parent isn't listed (archived, another project), with its `↳ <parent>` chip; the pill counts cards, and every live or waiting session. "All sessions" (or `/`) opens every session at `#/sessions`, with a search over preview, id and status (Esc or Back returns). There a parent's card holds its delegates the same way, the chip opening their rows inside the card (each with an archive button on hover), open by itself while one of them waits on you; the count says `14 (+7 delegates)`, a search that matches a delegate shows its parent's card with the list open and the matching rows marked, and select mode picks cards (archiving a parent takes its delegates). The open session is in the URL (`#/s/<id>`), so a reload or a copied link opens it again; the chi logo top left goes back to the empty start for a new chat. The message box grows with its text; drag its top edge to keep it taller (double-click resets). A file in a tool row (a read, edit or write's title) and its diff lines are refs: hover one and click to open the current file in your editor at that line, on this machine only (`web.editor`; the browser's "always allow" for the page's port and VS Code's "allow opening local files" are asked once; see [Opening files from chi web](configuration.md#opening-files-from-chi-web)). So are an edit or write approval card's paths (at the first line the dry run changes) and its diff lines, before you approve, and the numbered lines of a read's output: `lines 40–60` under it opens the text as read, numbered, when the output is the file as-is (not the head/tail preview of a big file, an error or an image; no numbers after a cut). A `path:line` (or `path:line-line`) in an answer or a step's text is one too once the turn has ended, and after a reload, when it names a file a row or card on the page touched: the path under the session's folder, else the one touched file it ends with (a bare `app.js:12` when only one touched file is named so; two such files make it none); a path without a line counts only when it is a touched file exactly. Code blocks, links (a github-pr link to the PR stays the PR's), bare URLs and inline code with more than the ref in it are left alone, and a file the session didn't touch is never linked. The info bar copies `chi --attach <id>` for a terminal. A session whose prompt carried model notes has a `notes: deepseek` chip there (the names without `model_notes_`; the tooltip lists each with its scope and size; `session.prompt_notes` in `GET /api/sessions/:id`, the live worker's, else the session file's; see [Memory](memory.md#model-notes)). Its `llm ctx` chip names the LLM context strategy the next turn runs under (`llm ctx stale,forget · session`, in the accent colour when the session set its own; the tooltip gives each value's source), and its popover sets the session's own strategy, apply rule and budget, or follows the model again, by running `/llm-context` in the worker (the reply shows as a command bubble); `GET /api/sessions/:id`'s `session.llm_context` carries the values (the live worker's, else resolved from the session file), and a `command_ran` that changed them carries the new ones. Its `think` chip does the same for the thinking level (`/thinking`), and on a chat host its `reasoning` chip for the reasoning history (`reasoning all · session`, `/reasoning-history`; `session.reasoning_history`, null on a native host). A `/thinking` or `/reasoning-history` change that restarts the prompt cache asks first: the reply bubble has an **Apply (restarts the cache)** button that sends its `--yes` line (the chips' Set sends that line itself; see [Changes that restart the prompt cache](configuration.md#changes-that-restart-the-prompt-cache)). It shows the context used (`ctx 42%`) and the last generation's decode speed (`87 tok/s`, `~64 tok/s` when estimated; see `/stats` in [cli.md](cli.md#session-commands)); hovering `ctx` there or on a session card lists the session's tokens in (summed over every request, with the cached share), out (with reasoning) and the cost when the provider reports one, for this session only (one estimated from a `hosts.<name>.models` price shows with `~`: `cost: ~$0.54 ($0.42 reported, ~$0.12 estimated)`), and the memory indexes its prompt holds (`memory index: ~3.4k tokens in this session's prompt (system 2.0k, project 1.4k)`; see [Memory](memory.md#the-indexs-size)). The start page's model picker (bottom left of the composer, the chosen name `▾`) chooses the model a new chat starts on; it opens a search list over the conversation (↓ or a click; downward when the start page leaves no room above): an empty search shows the last 5 picks (Recent) and then each host's model ids A–Z under the host, the default host first (an id the host declares under `hosts.<name>.models` first, noted `config`, its tooltip `served by config (hosts.<name>.models)`; a host that failed to list its models keeps those ids, greyed and noted `host down`, still pickable; a remembered or default model stays chosen even then, greyed on the button); typed words must each match the host or the id (a substring, else for 3+ characters the letters in order, so `deepseek4.1 fla` finds `openrouter · deepseek/deepseek-v4.1-flash`), ⏎ picks, Esc/Tab close, a pick puts the focus in the message box: `GET /api/models` lists the hosts' models as chi spells them (`{default, models: [{name, host, id, configured?, unavailable?, sampling?, llm_context?}], warning?}`; `configured: true` marks an id declared under `hosts.<name>.models`, listed first under its host, `unavailable: true` one whose host failed to list its models; `sampling` is the model's configured request parameters as `/model` words them, the row's tooltip in the list; bare for the default host, `host:model` for the others, from the same cached lists as `/models`, a bounded wait, a host that is down noted in `warning`), and `POST /api/sessions` takes `model` (blank means the default). Beside it, an `llm ctx` chip shows the LLM context the picked model starts under (each `GET /api/models` row's `llm_context`, as the info bar's); its form sets one for the new chat only, sent as `POST /api/sessions`'s `llm_context` and never remembered (see [configuration.md](configuration.md#llm-context-a-sessions-own-strategy)). The start page's first message goes as later ones do: `POST /api/sessions` with `idle: true` and `preview` (the message, which names the session until its turn is saved), then `POST /api/sessions/:id/turn`, so a failed first turn puts its prompt back in the composer too; a first line that is one of the new session's commands (`/model …`) goes to `POST /api/sessions/:id/command` instead, as later ones do. The browser remembers the last model picked; a running session's model is in the info bar and changes only with `/model`. In the composer a line is a command when it is `!…` or starts with one of the session's command names (its `commands` list; `/stats`, `/exit` and the other terminal words get the page's own reply); an unknown `/word` (`/usr/bin/env is missing`) goes to the model as a prompt, as in a terminal; a one-word `/word` no command answers (`/modle`) is not sent: the page shows `Unknown command /modle. Did you mean /model? /help lists the commands.` (the "Did you mean" part only when a name is close). A `POST /turn` (or a session's first `prompt`) that is one of the worker's commands runs as that command too (`202 {status, command_id, session_id}`), so `chi send`, `chi -p` and a page whose command list lags all get the command. ↑/↓ in the composer walk the prompt history the TUI's ↑ walks ([Persistent Prompt History](cli.md#persistent-prompt-history)): ↑ with the caret on the first line, ↓ from the last line while browsing, ↓ past the newest brings the draft back; `GET /api/history` returns `{entries: [...]}`, oldest first (the page fetches it on focus and after each send). The server records a sent line in the routes once the worker took it (`POST /turn` accepted, a `!command` through `POST /command` or as a session's first line); `"history": false` in the body keeps it out (an image-only send).
 - Web notifications: when a session needs you while the tab is hidden or behind another window (a question or a guardrail approval, a plugin card with buttons during a turn such as check-in's, a failed turn, a turn done after 10 s or more; a delegated session only for its questions, a canceled turn never), the page title counts it, `(N) Chi`, until you come back to the tab. The bell at the right of the top bar also turns on OS notifications ("needs an answer", "needs approval", "needs you", "turn failed", "done in 42 s", under the session's first message; a click opens the session): its first click asks the browser for the permission, and the choice is kept per browser. Any session of the page's scope counts, not only the open one. What was already so when the page loaded never counts, and several chi tabs show one notification per event. A chi tab in front tells the others (a `BroadcastChannel`), so while you look at one, the ones behind neither notify nor count what it shows; coming back to a tab clears those events in the other tabs' titles too. The hub's `session` frames carry what this needs: `pending_question` (`{id, kind}`, kind `question` or `approval`), `pending_card` (`{id, bundle}`: the running turn's card with actions, from `pending_card.json` that the worker keeps in the session's folder while one is open; a card without actions, such as loop-guard's, never counts) and `last_turn` (`{outcome, ended_at, seconds, origin}`, saved in the session's JSON as the engine ends each turn).
 - The web frontend is a zero-build ES-module stack in `lib/samagotchi/web/public/`: `data.js` (retrieval, typed SSE `openStream` for a session and `openEvents` for the session list), `sessions_list.js` (the list as a pure reducer over `GET /api/events`: a snapshot replaces it, an upsert keeps a known card in place, a removal drops it; `families()` groups delegates under their parent), `families_view.js` (a parent's family chip, its rows and the strip's popover), `chains.js` (session chains: the links from `continues`, the cards folded into the latest link's, its `day N` chip and rows, the info bar's ← → links, a refused continue), `notify.js` (which of those events needs the user, for the notifications), `app.js` (presentation/state; a session with no live stream gets one when its `session` event says `bridge_up`, after one re-read: `event_seq` starts over in each worker, so a dropped stream is never resumed with its old cursor), `format.js` (pure formatters such as `previewOf`), `prompt_history.js` (the composer's ↑/↓ over the shared prompt history), `commands.js` (session commands: which composer lines are commands, the page's own replies, a `command_ran`'s bubble, the page's command bubbles kept across a re-read), `composer.js` (where a composer line goes, `routeComposerLine`: /cut and /queue, the start page's own replies, a session command or `!cmd`, a typo hint, else a turn; and a session command sent from the composer or a chip), `restore.js` (a failed turn's prompt handed back into this tab's composer, before or after its `/turn` ack), `lists_view.js` (the session lists: the strip and its pill, all sessions with its search, count and select mode, their cards, the family and chain popovers; the cards, tile and pill as lit-html templates, drawn as new nodes each time, and the lists' orders as pure functions), `stream_handlers.js` (the open session's stream event handlers, by event type, over the page's views and hooks; a snapshot replays through them too), `info_bar.js` (the session bar's info line as a lit-html template over a plain model: id, status, model, chain links, chips, ctx, speed, clock, worker badge), `session_state.js` (what the page knows about the open session: its empty state, and `sessionStateFrom`, the fields a `GET /sessions/:id` payload sets), `refs.js` (refs: a kind and a target on the element, the actions per kind, one delegated click). Unit-tested via `npm test` (`node --test spec/web/public/*.test.js`).
 - Selecting a session in the web UI is read-only: `GET /api/sessions/:id` never spawns a worker (it reads a live worker's snapshot when one runs, else the session file). A prompt (`POST /turn`) or a command (`POST /command`) wakes the worker, and `/stream` briefly waits for a freshly-spawned bridge before answering. A caught-up SSE reconnect holds the stream open; `reset` markers are only sent for reconnects behind the ring window, or with a cursor from another worker (event ids are `<event_seq>-<epoch>`, one epoch per worker).

data/lib/samagotchi/bootstrap/config_writer.rb

@@ -7,6 +7,7 @@ require "ipaddr"
 require_relative "../atomic_file"
 require_relative "../config"
 require_relative "../yaml_lines"
+require_relative "../redacted_inspect"
 
 module Samagotchi
   module Bootstrap
@@ -17,6 +18,7 @@ module Samagotchi
     # other key must be unchanged, or the backup goes back.
     class ConfigWriter
       include YAMLLines
+      include RedactedInspect
 
       class Error < StandardError
       end

data/lib/samagotchi/bootstrap/probe.rb

@@ -9,6 +9,7 @@ require_relative "../version"
 require_relative "../llm/openai_chat"
 require_relative "../llm/http"
 require_relative "../llm/api_key"
+require_relative "../redacted_inspect"
 
 module Samagotchi
   module Bootstrap
@@ -17,6 +18,8 @@ module Samagotchi
     # API key, or nothing. One attempt per request, no retries: a refused
     # port answers at once instead of after chi's usual backoff.
     class Probe
+      include RedactedInspect
+
       # The ports `chi bootstrap` with no target tries on localhost.
       LOCAL_PORTS = { 8080 => "llama.cpp", 11_434 => "Ollama", 1234 => "LM Studio", 8000 => "vLLM" }.freeze
       DEFAULT_PORT = 8080

data/lib/samagotchi/bootstrap_command.rb

@@ -9,6 +9,7 @@ require_relative "bootstrap/config_writer"
 require_relative "bootstrap/bundles"
 require_relative "cli/command"
 require_relative "cli/flags"
+require_relative "redacted_inspect"
 
 module Samagotchi
   # `chi bootstrap [TARGET]`: the first setup. It names a model server, works
@@ -19,6 +20,7 @@ module Samagotchi
   # Prompts only on a terminal; a script gets the list and exit 2 instead.
   class BootstrapCommand
     include CLI::Command
+    include RedactedInspect
 
     USAGE = <<~TEXT
       Usage: chi bootstrap [TARGET] [--name NAME] [--model ID] [--key-env VAR] [--no-test] [--dry-run]

data/lib/samagotchi/broadcast_command.rb

@@ -13,6 +13,7 @@ require_relative "broadcast/triage_model"
 require_relative "broadcast/triage_log"
 require_relative "cli/command"
 require_relative "cli/flags"
+require_relative "redacted_inspect"
 
 module Samagotchi
   # `chi broadcast`: share a note with every session it may concern,
@@ -25,6 +26,7 @@ module Samagotchi
   # skipped. For the user only: refused inside a chi session.
   class BroadcastCommand
     include CLI::Command
+    include RedactedInspect
 
     SOURCE = "broadcast"
     # Bytes kept free under SessionInbox's 16 KiB for the line each note