mindfork

mindfork 0.11.0 — from a bare Linux machine to a local model, in one line

2026-09-21T00:00:00+00:00

mindfork 0.11.0 is out. It has one subject: the distance between "the app is unpacked" and "a local model answers", and what that distance costs on a machine you rent by the hour.

On a desktop you cross it once: download llama.cpp, install the Python sandbox, open the settings and type four paths and a number — the model, its vision projector, the embedding model, the context. On a rented GPU box you cross it every time. On RunPod the container's own disk is cleared whenever the pod stops, not only when it is terminated; what survives is one directory. So the set-up is done per rental, in a browser terminal, while the meter runs.

One command

mindfork setup --sandbox --llama cuda-12 \
  --model /models/gemma-4-31b-it-q4_0.gguf \
  --mmproj /models/mmproj-gemma-4-31b-it-f16.gguf \
  --embed-model /models/bge-m3-Q8_0.gguf \
  --ctx 32768 --verify

Every option is one step, and a step you do not name is not run — mindfork setup --ctx 65536 alone is a perfectly good use. What matters more than the list is how it behaves:

Paths and keys are checked before anything is downloaded. A model path that names no file, a part of a multi-file GGUF that is not the first, a setting that does not exist — each is an error now, in the words the app would have used at launch, not a status line ten minutes and a gigabyte later.
A step that fails does not stop the others. If the sandbox download fails, llama.cpp is still installed and the settings are still written; the command ends with what failed and a non-zero exit code. Run the same line again and it repeats only what is missing.
It writes the settings — once, at the end, and only if something changed. That is the difference from the MINDFORK_* environment variables, which override on every launch: what setup sets is what the settings screen shows, and what you change there afterwards sticks.
--set reaches everything else, by the field's path in settings.json: --set engine.managed.sessions=4 --set engine.managed.no_mmap=true. A key that does not exist is refused rather than silently dropped. API keys cannot be set this way — a key on a command line ends up in the shell's history; name the variable that holds it instead.

And then --verify starts exactly what the app will start — the chat server and the embedding server, both at once, since whether the two fit the card together is one of the questions — waits for each to load, and says what it found:

== Starting what was configured
  chat server: starting on port 8000…
  embedding server: starting on port 8001…
  chat server: ready in 41 s — context 32768, takes images, 4 slots
  embedding server: ready in 6 s

A context too large for the card, a projector that belongs to another model, a port something else already listens on — each shows up here as FAILED with the reason, while the command line can still be edited.

And the line before it

mindfork setup cannot put mindfork on a machine that does not have it. An install script does, and then hands over:

curl -fsSL https://github.com/vshylov/mindfork-rs/releases/latest/download/install.sh \
  | sh -s -- --dir /workspace/mindfork -- setup --sandbox --llama cuda-12 \
      --model /workspace/models/chat.gguf --ctx 32768 --verify

It unpacks the portable build into one directory, refuses the archive unless it matches the release's checksums, and then runs the binary to see whether it starts. On a bare image it does not — the app needs one system library that minimal images do not carry — so the script installs that package with the system's package manager, or stops and prints the exact command. Everything after -- goes to mindfork.

Run it again and it downloads nothing that is already there. On a pod that was stopped and started, the same line takes seconds: what sits on the volume is recognised, and only what the container lost is put back. Your data is never touched.

The script is an asset of the release, like the archive — listed in sha256sums.txt, covered by the same build attestation — so piping it adds no party to trust that the binary had not already added. If you would rather read before you run: download it, read it, sh install.sh. It is one short POSIX script. On a desktop the short form is all there is to it:

curl -fsSL https://github.com/vshylov/mindfork-rs/releases/latest/download/install.sh | sh

The install guide has the recipe for a rented box in full: which image to pick, why tmux is not decoration there, what to do about API keys in a container, and what to take with you before you terminate the pod.

CUDA on Linux

mindfork llama setup downloads llama.cpp for your machine. Until the middle of September llama.cpp published no CUDA build for Linux; now it does — and mindfork refused to install it. The build's CUDA runtime is a separate archive, and on Linux it is named differently than on Windows; the command looked for the Windows name, found nothing, listed the backend as "no CUDA runtime published" and stopped. It looks for what the release actually publishes now.

The same check turned up two more things. Recent llama.cpp builds print a log line ahead of their version, so the command showed that line as the version — and the check that the binary you got is the build you asked for, finding no number to compare, skipped itself without saying so. The version is found by what it says now, and a binary that names no build number is reported as such. And with no --build, the command takes the newest build that actually has the backend you named, complete — a nightly is now and then published empty or half-uploaded.

One small addition rides along: a backend family. llama.cpp renames its CUDA builds whenever it moves to the next toolkit — cuda-13.3 became cuda-13.4 inside two weeks — so a command you had saved stopped working. --backend cuda-12 installs the one cuda-12.* build on offer.

Nothing about the stored data changes in this release: no migration runs, and 0.10.2 and 0.11.0 open the same files.

The full list is in the changelog. Downloads — Windows installer and archive, Linux archive, .deb, .rpm and .pkg.tar.zst, and now install.sh — are on the releases page, and cargo install mindfork builds the same version from crates.io.

mindfork 0.10.2 — which copy of your data is the newest

2026-09-20T00:00:00+00:00

mindfork 0.10.2 is out. It is a small release with one subject: data that lives on more than one computer.

mindfork keeps everything in a folder next to itself, with no account and no sync. That is a promise, and it has a price: the day there is a desktop, a laptop and a backup archive, "which of these do I keep?" is a question only you can answer — and until now the way to answer it was to open each copy and look.

Which copy is the newest

mindfork stats                  # the data on this computer
mindfork stats copy.zip         # a backup archive, without restoring it

It prints when the last message was written and when anything last changed, how many profiles, chats and messages there are — and how many of them are deleted — and the attached and stored files, images, projects, notes and the knowledge base. Messages are counted the way the chat list counts them, and times are in UTC, so the output of two computers can be read side by side, line by line.

The command only reads. Nothing is created, migrated or unpacked, so it is safe to run while the app is open, and an archive stays a closed archive: an encrypted one is read in memory and never written out decrypted. The password is found the way restore finds it — --password, else the one saved in the settings, else you are asked.

The summary ends its first block with a fingerprint. Two computers that print the same one hold identical chats, notes, knowledge base and self-models, and there is nothing more to check.

What each copy holds that the other lacks

The newest copy is not always the most complete one. A chat continued on the laptop after the desktop's backup was taken exists only on the laptop — and the desktop may still be the copy written last.

mindfork stats --json > laptop.json     # on the other computer
mindfork stats --compare laptop.json    # here

The snapshot is a small file — ids, titles and checksums, no message text — so it can travel by whatever is at hand. --compare takes a backup archive of the other copy just as well. It prints a verdict first: the copies are identical; this copy holds everything the other has, or the reverse; or each copy holds something the other lacks. Then the lists behind the verdict — chats only here, only there, continued here or there, and diverged: one chat continued on both computers, each side holding messages the other does not.

Chats are compared by the ids of their messages, not by counts or dates. That is the whole point: a chat continued on two machines has more messages on each side than the other knows about, and a comparison by dates would report it as merely "newer there" — and keeping that side would lose the other's half in silence.

mindfork does not merge copies. When each side holds something, keep both until you have decided what to do with what is listed. The install guide has the full description, next to backup and restore.

One frame, not two

Picking a chat in the chat list used to show the conversation you were leaving for a fraction of a second before the one you asked for. The list now stays on screen until the chat is ready, so the switch is a single step — and the same goes for a new chat, a clone, a search hit and a run opened from the tasks screen. A clone that is refused now says so in the list, instead of in the chat behind it.

Also in this release

restore asks for the password on stderr, so redirecting a command's output no longer hides the question. And when the password that fails is the one saved in the settings, the message says that and points at --password, instead of "wrong backup password" for a password you never typed.

Nothing about the stored data changes in this release: no migration runs, and 0.10.1 and 0.10.2 open the same files.

The full list is in the changelog. Downloads — Windows installer and archive, Linux archive, .deb, .rpm and .pkg.tar.zst — are on the releases page, and cargo install mindfork builds the same version from crates.io.

mindfork is public

2026-09-19T00:00:00+00:00

The repository is open, and the first public release is on the releases page.

mindfork is an AI chat that lives in your terminal. It runs local models through llama.cpp, or talks to OpenAI, Anthropic, Gemini and Grok — all four configured at once if you like, switching between them without losing anything. It is one native binary for Windows and Linux, it keeps its data in a folder next to itself, and it has no telemetry, no update check and no account.

What it is actually for

Most clients are a window onto a model. This one is built on a different premise: that a local Gemma or Qwen becomes more interesting to talk to when it is given room to remember and to act.

So it keeps a self-model — a summary, goals, traits and an observation narrative that the assistant maintains about itself and about you, and that you can read and wipe on one screen. It writes notes and links them into a graph where one note can supersede another. It builds a knowledge base out of your own files, retrieved semantically rather than by keyword. All of it per companion profile, all of it on your disk.

And it has tools: web search and page fetching, a Python sandbox with no access to your files, a file-access tool jailed to one directory you name, an attached code project it can read and change under a diff you approve, video understanding, and anything else you plug in over MCP. Every one of those is off until you turn it on, and an optional confirmation shows exactly what a call is about to do before it does it.

What a first run looks like

mindfork demo

Sample conversations, a scripted engine, nothing written outside a temporary folder. It takes a minute and answers the only question that matters early: whether you want this shape of thing at all.

After that, the install page has the downloads and the manual has the rest.

How it was built, and why the repository is worth a look

Two years of small reviewed tracks, each one a design document with its alternatives written down, a branch, tests beside the code, and — for anything touching a model — a run against a real one before it shipped. The suite is over three thousand tests, and the engineering log says what was measured and what was rejected, not just what was done.

Much of the code was written by AI models under review, and the history says so: every commit names the model that wrote it. That is not a disclaimer, it is the same honesty the rest of the project tries for — the journal is full of measurements that overturned the plan they were meant to confirm.

The code is MIT. The disclaimer says what shipping no model means for what appears on your screen, and the privacy policy says what leaves your machine — which is nothing you did not configure.

If you try it, issues are the place to say what broke.

mindfork 0.9.9 — files in, charts out, work in the background

2026-09-13T00:00:00+00:00

mindfork 0.9.9 is out. It is a release about keeping the conversation moving: the assistant's code gets your files and hands its own back with no copy-paste in between, a delegation no longer holds the chat while it runs, and the engine is one command away instead of a build away.

Your files reach the code, and its files reach you

Until now the sandboxed Python could compute, but only on what the assistant typed into the script. Now a call names the chat's files it needs — by the number /file list shows or by name — and each is copied into the sandbox before the code runs: an attachment as its text, a stored file or a picture as itself. The copies are the sandbox's own, so nothing here changes under the code's hands, and only what it saves into /w/out comes back. That folder is the other half: a matplotlib chart, a CSV or a workbook saved there is kept with the chat, listed by /file list, packed by backups — up to ten files and 50 MB a call — and a PNG or JPEG is shown to the model, so it can check the chart it drew. Measured before shipping on Qwen 3.6 27B and Gemma 4 31B: a plot colour only the image carries was named nearly every time with the picture and never without — and blind, both models described a chart they had not seen, which is why every image the assistant is not shown is now said in the result, in words a small model does not talk past.

/file attach stops refusing a binary: a workbook or a zip is kept with the chat, readable by code alone, and a PDF, DOCX or web page keeps its original beside the text the assistant reads — one entry in the list, removed together, never your own file. /file open <name|#N> hands a file to whatever your system opens it with, and /file folder opens the chat's folder. Only document types open directly; a script, a shortcut or an HTML page the assistant wrote opens the folder it sits in instead, so nothing the assistant produced can run by being opened — and on Windows a workbook or document the code wrote carries the same mark as a download, so Office opens it in Protected View.

The same contract holds when Python runs on your own machine instead of in the sandbox: the files named in the call are copied in, what the code saves comes back, and a new per-process memory limit (Windows, off by default) turns a runaway allocation into a MemoryError instead of taking the machine's memory. The sandbox itself gained sympy, networkx, lxml, pyyaml, regex, feedparser, openpyxl, pypdf, tabulate, pillow and matplotlib — mindfork sandbox setup fetches only what is missing — and its packages are now packed into an image the code cannot alter, so one call can no longer leave a file that runs inside every later one. An existing sandbox needs that command run once more; the tool names it when it refuses.

Work that goes on without you

A delegation used to hold the conversation until it landed. Switch on Background runs in Settings → Tools and the assistant gains start_subagent: a delegation that returns at once — the assistant keeps answering you, past the end of its own reply — and whose result arrives later as a task notification in the chat. When the chat is open and idle the assistant reads it and reports by itself; otherwise the note waits for your next message. The run is a row of the chat list while it is out, its transcript opens as it streams, and a result that lands while you are looking elsewhere marks its chat unread. A staged dialogue (below) can run the same way. A background run never asks you to confirm a tool call — switch off the tools you would not let run unattended.

F7 (or /tasks) is the screen for all of it: every subagent and dialogue run across all your chats — the ones running, with the round and tool they are in; the ones that landed, with how they ended — and the app's own quiet work (reflection, consolidation, history compaction) as running, waiting or idle. Enter opens a run's transcript, F6 stops one — the app's own tasks included — and /tasks stop <kind> does the same from a terminal where F6 never arrives. A reflection stopped before it wrote anything gives its window back, so nothing is skipped and nothing is written twice.

Things can also happen at once. Subagent: parallel runs lets the delegations of one reply run together; Parallel tool calls lets the reads and page fetches of one reply run together — only tools that change nothing, four at a time on a cloud engine by default, one after another on a local engine until you raise it; and a new Parallel sessions setting on every engine mode says how many request streams the app may keep open. A managed llama-server is then launched with -np N --kv-unified, its slots sharing the one context pool, no extra memory. Parallel runs and sessions both default to 1, so nothing changes until you turn them up. Measured on one RTX 4090: two sessions gain little on a 31B model, four gain 2.9× on Qwen 3.6 27B. Every stream reserves what it will occupy in the pool and waits for room rather than overfilling it, so two subagents no longer die together with "Context size has been exceeded" after a minute of visible progress.

The app's own requests learnt to yield. A title, a reflection or a history compaction that is streaming when your message arrives is cancelled and made again after your reply, rather than holding your message until it ends — measured, a message that waited 46 s on a CPU-only server now waits about 24 s, one that waited 5.6 s on a GPU under two. A CPU-only host runs a smaller prompt batch for the same reason, and the app reads the server's own timing of every prompt: once per server session it says in the feed how fast prompts are processed and the one setting to change when that is slow.

A scene of two characters

run_dialogue stages a conversation between two personas the assistant composes, and the assistant directs it as it unfolds — a private stage direction to one character, a retake, a line rewritten outright — and ends it when the scene reaches its ending. The script is a child chat under the conversation, each side under its character's name, the director's interventions visible as notes; open it while it runs and each line streams in on its speaker's side. One engine session, one request at a time, so no extra VRAM on a local model; a run-time limit (30 minutes by default) bounds a scene that will not end. Gemma 3's chat template, which refuses two same-role turns in a row, is handled — for the director's memory of its verdicts, and for Ctrl+U impersonation, which used to answer with an engine error on every chat you had opened yourself.

The engine, downloaded

mindfork llama backends lists the llama.cpp llama-server builds published for your OS and architecture — cpu, vulkan, cuda-13.3, rocm-10.0, … — with their download sizes, and mindfork llama setup --backend <id> fetches one into data/llama/. Every file is checked against the sha256 the release publishes, an interrupted download resumes instead of starting over, and a CUDA build brings the CUDA runtime with it — without it the backend does not load and the server quietly runs on the CPU. Once unpacked, the binary is run and reports its build number and the compute devices it found, so a GPU backend with a missing driver says so instead of pretending. --set-binary writes the path into the settings; mindfork llama installed and mindfork llama remove <id> manage what is on disk, and the remove refuses while a setting still points at the build.

Better still, the llama-server binary field may now be left empty: the app takes the build installed last, or a llama-server sitting next to the application — so downloading one, or unpacking a llama.cpp archive beside mindfork, is enough to run in managed mode with nothing typed.

Pick up where it stopped

/continue resumes an interrupted reply in place — one cut by Esc, by a dropped connection or by the length limit: the model picks up exactly at the cut, the text grows inside the same message, and a turn interrupted between tool calls resumes its tool loop. It works on the local and external engines, on Gemini, and on Claude models up to the 4.5 generation; the providers that cannot resume a partial reply (OpenAI, Grok, current Claude models) are told apart, and the command says so instead of guessing. A reply that hit the length limit finally gets a note at all.

An external server's model is now named on screen even when you did not type it — the app asks the server what it is running — and the "Model (opt.)" field, which had never actually been sent, now reaches the server: llama-server in router mode, LM Studio, LiteLLM and OpenRouter all pick the model from it.

Off until you say so

The web tools start off. web_search, fetch_url and youtube_watch are disabled in a fresh installation: the search engines behind them are picked by the app and the query is built from your conversation, so nothing goes to them until you switch the tools on in Settings → Tools. An existing installation keeps whatever its settings already say.
A search key is only used where you put it. A TAVILY_API_KEY sitting in your environment for some other program is no longer picked up on its own. Name the variable, or enter the key, in Settings → Tools.
The sandbox's largest download is verified too — the Python distribution wasmer fetches on the app's behalf, until now the one file not checked against a pinned checksum.
A privacy policy, readable in the app: F1 → the tab that used to be "Disclaimer" is now Legal and carries both documents, in the interface language. The Windows installer shows it and every archive ships it. It says what stays on your machine, what leaves it and which setting has to be on first, and what reaches the author — nothing.
The spellcheck dictionaries say where they come from, with their licences installed beside them; en_GB moves to its author's current word list, about 14 000 more stems; and an installed build gets a dictionaries/ folder of your own in the data directory, with a note on how to add one.

Also in this release

Files in an older encoding are read — and edited — as they are. A windows-1251, KOI8-R or cp866 text, or Notepad's "Unicode", used to reach the assistant with every letter replaced by the replacement character, and an edit in an attached project rewrote the whole file that way. Files are read in their own encoding now, an edit is written back in it — refused with nothing written when the encoding cannot hold the new text — and a web page in an older encoding is read as it declares itself, or recognised from its text.
A fetched page is named after the page, not its site — every chapter of the Rust Book used to be attached as "The Rust Programming Language".
Spellcheck no longer stumbles over a stress mark: a word carrying one is judged whole, stressed text is left alone, and a real typo under the mark is still underlined.
The assistant can name its language model. get_llm_name answers "which model are you?" with the model actually generating the reply, and get_llm_history lists the profile's dated history of model changes — filled from your existing chats on the first launch, as far back as they go.
The self-model screen (F3) reads as two named halves — Assistant and User, or the names from the profile — with the newest observation first; a setting flips the order.
Every key hint names only keys that work, sits in the same place on every screen and follows what you have selected, and F1 is among the hints everywhere. The status bar no longer stacks its hints into a column while a turn runs, and says cancel for Esc while a reply is generating.
An API-key field says whose key it is — OpenAI API key, Tavily API key (env, opt.) — everywhere one is entered.
The chat list counts messages the way the conversation reads: your questions and the assistant's replies, not every tool call's result.
A long title no longer ends mid-word: it is cut where it is drawn, to the columns that screen has, always with "…" — and titles an older limit had cut on disk are repaired.
A tool round on OpenAI no longer fails when the model reasons in stages, and a server error inside an open stream ends the reply as an error — with the retry that was always meant to run — instead of passing for a finished reply cut mid-word.
In KDE Konsole the footer names the line-break chord the terminal can actually deliver (Alt+Enter), instead of one it silently swallows.
mindfork.exe calls itself mindfork in Task Manager and Explorer, with the author and copyright it was missing; the installer carries the real version instead of 0.0.0.0.
The Python sandbox installs and runs again. The Python package is pinned to an exact version, after a build published in the Wasmer registry in late August could not be compiled by the runtime the app pins. A sandbox installed in that window needs mindfork sandbox setup --force.

One note on data: chats gain a list of stored files, and the data folder a files/ directory beside chats/; chat files move to schema 4 — a version stamp for dialogue transcripts, then the repair of titles an older limit had cut. Both migrations happen automatically on the first start, after a pre-migration backup, and nothing is removed; an older build refuses to open migrated data rather than misread it.

The full list is in the changelog. Downloads — Windows installer and archive, Linux archive, .deb, .rpm and .pkg.tar.zst — are on the releases page.

mindfork 0.9.8 — give it real work

2026-08-27T00:00:00+00:00

mindfork 0.9.8 is out. It is a release about work: handing the assistant something real to do — your code project, a side-task big enough to delegate — and being able to watch every bit of it happen.

A code project, attached to a chat

/project attach <directory> gives the open conversation a project. With one attached, the assistant can see the project's structure, read its files with line numbers and search them by regular expression — confined to that directory, honouring .gitignore. It can change files too: an edit replaces an exact fragment, or writes a file whole, and every file's previous content is saved before it is first touched.

That last part is what makes the feature trustworthy. F4 (or /changes) opens a screen listing every file the assistant touched, each shown as a diff against the file as it was before — and r puts one file back the way it was, after asking. A file the assistant created is removed instead. If you would rather approve each change before it happens, the existing "confirm dangerous calls" switch covers project edits as well.

It can also build, run and test — but only through command lines you type: /project build-cmd cargo build, and the same for run-cmd and test-cmd. The assistant runs them exactly as written and can never compose a command of its own, add a flag, or chain a pipeline; a slot you have not filled gives it no such tool at all. A command that outruns its time limit is stopped together with everything it started, and whatever it printed still comes back.

Attaching is the permission: with no project attached, none of these tools even exist, and nothing changes about what the assistant can reach. Reading and editing the project deliberately do not spend the turn's tool-call budget — a fix takes as many steps as it takes.

Subagents grew up

call_subagent used to ask a persona one tool-less question. Now a delegation is a nested turn with the assistant's own tools — the same web, files, Python, project and plugin tools it has in that chat (except creating subagents of its own, reading the folded history and the self-model), over the same attached files, under a persona the assistant composes. A dangerous call inside the run asks you exactly as it would outside.

The transcript became a conversation of its own. Every delegation shows as a row nested under the chat that made it, opens like a chat — read-only — and is searchable everywhere a chat is: the list's content search, the message-level results, even the assistant's opt-in cross-chat tools. It gets a model-written title when it lands, carries a chat:// address you can follow, and old conversations join in: chats recorded before this release get a transcript reconstructed from what each call already stored.

And it is all visible while it runs. The transcript appears in the list the moment the assistant delegates, marked running, its message count growing round by round; open it and the subagent's reply streams word by word, thoughts and tool calls included — and stepping between the transcript and the parent chat no longer cancels the turn. The status bar shows a quiet chip with the subagent's name, the round it is on and the tool it is using. In the same spirit, every tool call's card now appears in the feed the moment the call starts, marked running…, and fills in when the result arrives — so a long build or delegation is visible where it happens.

The chat list keeps transcript rows folded under their chat by default, with a muted ▸ n saying how many it holds — Ctrl+O unfolds them, and the choice is remembered per chat.

Web search, with a key this time

The free search engines throttle automated requests hard — measured, they answer about twice in a row before blocking, and the block lasts far longer than a conversation. A long chain of searches used to fall apart on that.

Settings → Tools → Web search now takes an API key for Tavily — the free tier is 1000 searches a month, no card needed. With a key entered the assistant searches through Tavily first; the free engines stay as the fallback, so entering no key changes nothing. Blocks are also recognised for what they are now: a provider that just refused is told to the assistant as temporarily unavailable rather than as "the web has nothing on this", and it is tried last for a few minutes instead of being retried first on every call — but never dropped. Search results say which service answered.

Also in this release

The command is mindfork now. The binary lost the -rs suffix — that stays the project's name. The Linux packages symlink /usr/bin/mindfork, the Windows installer installs mindfork.exe; where your data lives is unchanged.
The auto theme really follows your terminal. The app asks the terminal for its background colour at start-up (Windows Terminal, VS Code's terminal, JupyterLab's, plain SSH and tmux all answer; the legacy Windows console does not, and is treated as the dark background it is), so code blocks and the selection backdrop stop being dark on a light terminal.
F1 opens the help from any screen, landing on that screen's own key section, marked you are here — and the settings, self-model, changes and search screens' keys are listed at all for the first time.
The licence and the disclaimer speak Russian when the interface does — on the F1 tabs and the Windows installer's legal pages. The translations are unofficial and say so; the English originals govern.
A model split across several GGUF parts loads by pointing the setting at the first part — and the two ways of getting it wrong are caught before launch instead of showing up as a server that quietly exits.
More typed commands: /autotitle for a model-written title, /impersonation list|new|delete|use|system for the personas Ctrl+U writes as, /profile system|greeting for the profile's texts — each usable where a browser tab or an embedded terminal keeps the chord for itself.
Starting without the database says so. A data folder copied without data.db used to open silently amnesiac; now the app says what is empty, what survived and how to get the rest back — and /reindex rebuilds an attached file's missing search index from the text the chat already holds.

One note on data: this release migrates two stored formats — chat files and settings.json, each schema 1 → 2. Both happen automatically on the first start, after a pre-migration backup, and nothing is removed; an older build refuses to open migrated data rather than misread it.

The full list is in the changelog. Downloads — Windows installer (64-bit now) and archive, Linux archive, .deb, .rpm and .pkg.tar.zst — are on the releases page.

mindfork 0.9.7 — wherever your terminal is

2026-08-17T00:00:00+00:00

mindfork 0.9.7 is out. It is a release about reach: running the app somewhere other than a terminal window of your own, and giving conversations an address so they can point at each other.

The terminal is not always yours

A terminal embedded in something else takes key combinations for itself before the app ever sees them. VS Code's integrated terminal claims Ctrl+P, Ctrl+E, Ctrl+F, Ctrl+K, F1, F3, F5, F10 and Ctrl+Q by default; a terminal in a browser tab claims Ctrl+N, Ctrl+T and Ctrl+W — the last of which closes the tab your session is running in. Measured against VS Code's defaults, six features of the app were simply unreachable there.

Nineteen new commands close that: /settings, /self, /chats, /help, /new, /rename, /clone, /copy, /regen, /takeback, /impersonate, /stop, /find, /search, /links, /thoughts, /toolcalls, /mouse and /emoji, plus /profile list|new|delete and /self clear for the two actions that lived inside other screens. Each one reaches the same handler its key does, confirmation prompts included — and, unlike a key, a command that cannot run right now says why and names something that will. The keys are unchanged; what the commands add is a second route.

Copying works over SSH

The clipboard an application writes belongs to the machine it runs on. Over SSH that is the server's clipboard, which does you no good — and on a headless server, where there is no clipboard at all, a copy simply failed.

A copy is now also handed to the clipboard of the machine your terminal runs on, through the terminal itself (OSC 52), automatically when the session looks remote. A new setting makes that always or off.

The protocol acknowledges nothing, so the app says the text was sent rather than promising it arrived — and not every terminal implements it: GNOME Terminal, Terminal.app and JupyterLab's terminal do not. A conversation too large for the sequence (about 75 KB) is reported as such instead of being quietly cut in half.

A conversation, saved to a file

/export writes the open chat next to wherever you started the app, named after the chat and the date; /export path/to/name.md puts it where you say. Markdown is byte-for-byte what F5 copies, and json is a document mindfork-rs import reads back onto the same conversation. An existing file is never overwritten.

This is also the one way out of a browser terminal such as JupyterLab's, where neither clipboard route can reach your machine at all.

Your other conversations

Two new tools, chat_search and chat_read, let the assistant find and read what your other conversations with the same companion said — for questions like "we worked this out in another chat". They are off by default and not even shown to the model until you turn them on per profile; the current chat, hidden chats and other profiles stay out of reach.

When the assistant mentions one of those conversations it now writes its address as chat://<id>, and the feed draws that as a link. Ctrl+L lists the conversations the open chat points at and opens the one you pick; with mouse capture on you can click the link — the first thing in the feed that is clickable at all. Esc takes you back where you came from, and keeps meaning that only while you are reading: start working in the chat you arrived at and Esc goes back to meaning "the chat list", so it can never teleport you out of a conversation you have settled into.

Only addresses that really lead somewhere are drawn as links, so following one is never a dead end.

Also in this release

New chats name themselves. After the first reply the model writes the conversation a short title — no more lists full of "New chat". On by default; a setting moves it to right after your first message, the way cloud chat UIs do it, or turns it off. A chat you renamed yourself is never touched.
An external server's API key can be entered in settings, stored encrypted and bound to this machine, instead of having to come from an environment variable — for a gateway such as LiteLLM or OpenRouter, or a llama-server started with --api-key. Each external tab keeps its own key, because those are four independent servers.
The model's name in the feed, optionally, next to each reply — taken from the message itself, so a conversation reopened after switching providers still says which model actually answered.
The F1 help window grows with the terminal, aligns its descriptions in a column and wraps the long ones instead of cutting them off mid-word.

The full list is in the changelog. Downloads — Windows installer and archive, Linux archive, .deb, .rpm and .pkg.tar.zst — are on the releases page.

mindfork 0.9.6 — the model can see

2026-08-13T00:00:00+00:00

mindfork 0.9.6 is out. The headline is images: you can now show the model a picture. The quieter half of the release is about what the assistant is not allowed to reach.

Show it a picture

/image attach <path> puts an image on your next message. /image paste takes one straight off the clipboard, so a screenshot needs no file at all — Ctrl+V does it too, in terminals that let the key through (Windows Terminal keeps that combination for its own paste, which is exactly why the command exists). /image attach https://… downloads the picture and stages it the same way; the image itself is stored in the conversation, so it keeps working later even if the link stops working.

It works with a local vision-capable model — start llama-server with a projector — and with all four cloud providers. png, jpeg, webp, gif and bmp are accepted and converted to what each provider takes, and a large image is shrunk once, when you attach it, rather than costing you the upload on every later turn. If the engine says it cannot see images, the attach is refused up front and tells you what to change, instead of failing at send time.

An image an MCP tool returns reaches the model too, so a screenshot or a chart a plugin produces can actually be looked at. That one comes with a switch in settings — "Let servers send images", on by default — because instructions can be painted into pixels where you would not see them.

The web tools stop at your front door

fetch_url and the pages web_search reads now refuse addresses that are not on the public internet: your own machine, your LAN, and the address cloud providers keep their credentials behind.

This matters because of where the assistant's links come from. They are rarely typed by you — they come off a page it just fetched, a search result, or a document you attached. Any of those can ask it to open something on your side of the router, and until this release nothing stopped it.

If you do want one reachable — a wiki or a dashboard on your network — there is a new switch in settings → Tools: Allow local addresses, off by default. Attaching an image by address, which you type yourself, is unaffected, and so is the address of your own engine.

A blip no longer costs the turn

When a cloud provider rate-limits or sheds load, the request is now retried — three attempts with a short backoff, honouring the provider's own Retry-After. This matters most in a long turn: one blip on the eighth tool round used to throw away the whole turn's work. Retries stop as soon as the answer starts arriving, so nothing you have already read is re-generated and no tool runs twice.

Related, and overdue: a reply that gets cut off now says so. When the engine failed after the answer had started, the fragment used to sit on screen looking like the whole reply.

Also in this release

mindfork demo — the interactive demo mode announced when this site went up ships in this release: the real TUI on seeded data with a scripted engine, no model download, no API key, nothing written outside a temp folder.
The Windows installer now shows the MIT license and the disclaimer during installation, rather than only dropping them next to the binary afterwards.
Esc interrupts a request that is still connecting, and a network failure shows its reason instead of a bare URL.

The full list is in the changelog. Downloads — Windows installer and archive, Linux archive, .deb, .rpm and .pkg.tar.zst — are on the releases page.

Hello from mindfork 0.9.5

2026-08-10T00:00:00+00:00

mindfork is a terminal AI chat written in Rust. It runs local models through llama.cpp's llama-server, speaks to OpenAI, Anthropic, Gemini and Grok in the cloud, and keeps a memory of its own: a self-model, notes with a link graph, and RAG over your documents. Windows and Linux, one native binary.

This site is its new home. Short project news lands here in the blog — there is an Atom feed — and longer pieces live in Articles.

Where the project stands

Version 0.9.5. The original M0–M9 plan is finished, and the last few months added, among other things:

mindfork demo — an interactive demo mode: the real TUI on seeded data with a scripted engine. No model download, no API key, nothing written outside a temp folder.
Grok (xAI) as the fourth cloud provider.
History compression — a rolling summary keeps a long conversation inside the model's context window (/compact, plus an automatic trigger), with read-back tools for the folded range.
Generated screenshots — every screenshot on this site is rendered from the current code by the test suite and guarded against rot in CI.

What's next

Cloud-error retry/backoff and image input sit at the top of the roadmap. News will land here as it ships.