mindfork mindfork

mindfork 0.19.0 — how much of a conversation was reused

· 3 min read

mindfork 0.19.0 is out. Its addition is one figure in the status line — the share of the prompt the provider did not have to process again — and beside it a fix for the environment's quick start and an update of the zip library.

The cache share

Every turn sends the whole conversation again: a chat model keeps no state, so the history, the system prompt and the tools travel with each message. A provider does not have to read all of it anew. llama.cpp keeps the start of the last prompt in its memory, and the clouds keep a cache of prompts they have seen; when the next request begins the same way, that part is served from there — faster, and on a cloud cheaper.

Whether that happens was invisible. The status line now says it:

tokens: 8414 (cache 99%)

A high share means the earlier conversation was reused. cache 0% means it was processed from the start — normal on the first turn and on a short chat (providers cache a prompt only above about one to four thousand tokens), and a sign of trouble on a long chat's tenth turn: something at the start of the prompt changed, and every turn pays for the whole conversation again. On a cloud that is a cost, and on OpenAI's newest models a miss is even written to the cache, at a premium.

The share is shown wherever the provider reports it. Measured on two turns of a ~10 000-token conversation:

  • llama.cpp (Qwen 3.8 27B and Gemma 4 31B on an RTX 4090): 0%, then 99%;
  • OpenAI and the OpenRouter gateway (gpt-5.4-mini): 0%, then 98%;
  • Gemini reports its cache, but did not reuse a continuation in these runs, so 0% there can be the provider's choice;
  • Anthropic always reads 0%: it caches only when asked, and mindfork does not ask yet.

When the last request reported nothing, there is no share — no number is better than a guessed one. The share is rounded down, so 100% is never shown for a prompt that had a few new tokens. The log keeps one line per round with the exact figures, for when the first round of a turn missed and the bar shows its warm last one.

MINDFORK_MODEL on its own

The quick start through environment variables needed the server's path as well as the model: MINDFORK_MODEL was read only when MINDFORK_LLAMA_BIN was set, although an empty binary has resolved to the build mindfork llama setup installed for a while now. Naming a model is now enough — it asks for the local engine even when the settings name a cloud — and MINDFORK_EMBED_MODEL does the same for the embedder:

$env:MINDFORK_MODEL = "C:\GGUF\google_gemma-4-E4B-it-Q4_1.gguf"
mindfork

Also: the zip library

zip, the library behind backups and the archives mindfork unpacks, is updated past three advisories about unpacking: set-user-ID bits kept, and links that point outside the folder. The functions they describe are not ones mindfork calls — it unpacks with code of its own, which never creates a link — but the first had a twin there: on Linux and macOS, a llama.cpp build downloaded as a zip kept the permission bits its archive named, set-user-ID included. Those bits are now dropped. Backups written by 0.18.3 open in 0.19.0, and the other way round — checked on archives of both kinds, encrypted and not.

Your data

Nothing in the files changes. The cache share is shown, not stored, and no setting was added.

The full list is in the changelog; downloads are on the releases page, and cargo install mindfork builds the same version from crates.io.