v0.22.4

v0.22.4 — Cache stability: the history baseline now actually stays cached

The v2 history layout was designed so that summarizing your conversation never disturbs the large, stable part of the prompt the provider has already cached — that was the whole point of splitting history into a frozen baseline and a small volatile delta. This release fixes a wiring gap where it wasn't actually behaving that way: every time the historian published a new compartment, it rebuilt the baseline and busted the provider prompt cache, re-sending hundreds of thousands of tokens even mid-session when nothing else had changed. Now it works the way it was always meant to.

What's Fixed

• Publishing a new compartment no longer rebuilds the cached history prefix. The history layout splits into a stable cumulative baseline (m[0]) and a small volatile delta (m[1]), and the baseline is supposed to behave like a frozen prefix that survives routine work — precisely so the provider prompt cache keeps paying off across a long session. It wasn't: a wiring gap made publishing a new compartment count as a baseline-changing event, so every historian run — including ones that fired well below the execute threshold — folded the baseline and invalidated the cache from that point down through the rest of the conversation. New compartments now land in the volatile delta as intended, and the materialization decision is organized around a single, explicit bust taxonomy:

  • No change (defer passes, nothing new) → the whole system + m[0] + m[1] prefix stays cached.
  • New compartment / memory / user-profile delta → only m[1] re-renders; the baseline stays byte-identical and cached.
  • Genuine baseline change (model change, system-prompt change, tool-set change, idle past the cache TTL, or a structural history rewrite) → the baseline re-materializes — but only when the provider cache was already going to be invalidated anyway, so the rebuild is effectively free.

  This also wires up two things the old layout never actually did: re-materializing the baseline when you come back to an idle session past its cache TTL, and detecting a tool-set change (the provider sends tools as a separate block ahead of the system prompt, so a tool change is invisible to the system-prompt hash on its own).

• Pi had the same gap, via a different mechanism — also fixed. On Pi the cache was being cleared on every history-refresh pass, which forced a full baseline rebuild every time — so Pi effectively never had a working stable-prefix path. Pi now keeps the cached baseline and surfaces new compartments in the delta block, matching OpenCode, with the visible-message trim boundary advancing in lockstep so nothing is duplicated.

• Dreamer key-files and user-memory token usage now show up in the dashboard. The key-files selection step and the user-memory review step both spend real tokens on an LLM call, but neither was recording that spend — so the dashboard showed — for those rows. Both now report their input/output tokens like every other dreamer task. (Particularly useful if you've turned on keep_subagents to study dreamer cost.)

What's New

• keep_subagents config flag (default off). When set to true, Magic Context stops deleting its own background child sessions (historian, dreamer, sidekick, memory-migration) after they finish, so you can inspect exactly what they did. It's a debugging aid — leave it off for normal use, since these sessions otherwise accumulate.

Upgrade

npx @cortexkit/magic-context@latest doctor --force

This release adds a database migration (schema v30) that runs automatically on first launch and clears the history cache once so the new baseline re-materializes cleanly. If OpenCode still loads a cached older plugin after upgrading, --force clears the cached install so the new version takes effect on next launch.