mindfork mindfork

mindfork 0.18.2 — what a tool tells the model is what happened

· 3 min read

mindfork 0.18.2 is out. It is a release of fixes, and they share a cause: after a tool call, the model was sometimes told something that was not quite what had happened — and acted on it.

Where they came from

Every change to mindfork is checked by a suite of about 250 live tests, run on rented GPUs against three model families: Gemma 4, Qwen and gpt-oss. This release moved the Qwen run from Qwen 3.6 to Qwen 3.8, and reading the runs of all three — what the model was sent and what it did next — turned up the nine fixes below. Each was measured by sending the same request many times with one wording changed, before and after.

A turn ends in an answer

  • When the tool rounds run out, the last round now tells the model so. Before, some local models — Gemma 4 among them — wrote their next call out as text, and that raw call was the reply.
  • When a turn that used tools comes back empty, it is asked once more, with thinking off, and that answer is the one you see. Qwen 3.6 sometimes looked something up and then said nothing.
  • A staged dialogue runs once. Without the tool that reads other chats, a model could stage the same scene nine times in one turn, looking for lines it had no way to read; the result now says where the lines are.
  • Background scenes and sub-agents are started only by their call, and the tools now say so — and that the link to give you is the one the call's result names. Qwen 3.6 had replied that a run was going, with a link it made up, and never started it; this makes the slip rarer there, not gone.

A tool's answer says what happened

  • Images from MCP servers or Python charts, turned off in the settings: the model is told it cannot see them, that this is not an error, and that calling again will not change it. Some models had described images they were never shown.
  • An observation that repeats an earlier one is already written by the time the duplicate check speaks; the hint now says so and asks for a merge. Before, it advised rewriting the old entry "instead of a new entry", and some models kept both.
  • Python on your own interpreter now says the code runs in a working folder holding in and out. gpt-oss had read its files from the wrong place and saved its results where nothing is kept — then said they were saved. A file written beside out instead of into it is now named in the result, with the path that would have kept it, in the sandbox as well.
  • A call that arrives broken — its arguments cut short — is answered as broken, and nothing runs on it. It used to reach the tool as an empty call, and the model was told a field was missing from a call that had it.

gpt-oss through OpenRouter

One of the providers OpenRouter routes gpt-oss to sends the last piece of a call's arguments as if it began a second call. That piece was dropped, so the call came in cut short — in most of the answers that carried a call — and the turn could spend all its rounds on it. The piece is now joined to the call it ends.

Your data

Nothing in the data's format changes, and no step runs at the start.

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