Changelog
What's new in Goatfied.
What shipped, why it matters, and how to use it. Updated as releases land — roughly weekly.
Sep 9, 2026
Reconnecting no longer rewrites the conversation
A thread that reconnected could quietly copy itself, burying a question the agent was waiting on and holding back new replies until you typed again. Reconnecting is now invisible.
When a thread reconnects, everything that happened while you were away is sent again so nothing is missed. That catch-up was being added to the conversation rather than matched against what was already there, so a long thread could end up holding several copies of itself — the same reasoning, the same steps, repeated over and over.
The damage was not just clutter. A conversation is laid out by pairing each thing you asked with the work that followed it, and every duplicate looked like the start of another turn. The pairing slid out of step, so the newest reply was filed under an older message and appeared to be missing — which is why nothing seemed to arrive until you sent one more prompt and forced the thread to redraw. A question waiting on your answer could be left stranded the same way, so you never saw it.
A thread now recognises the parts it has already seen and keeps only what is genuinely new. Replies appear as they arrive, a question the agent asks reaches you straight away, and reconnecting as often as the connection requires costs nothing.
Conversations that were already affected are repaired as they are opened, so a thread that lost its shape before this release finds it again rather than staying tangled — including any question that was left buried in it.
- Updates appear as they happen — New replies show up on their own, instead of only once you send another message.
- A waiting question reaches you — A question the agent is blocked on stays visible in the thread rather than being buried by a repeated history.
- Long threads stay in order — Each reply stays with the message that prompted it, however many times the connection drops.
- Existing conversations are repaired — A thread already affected is put back in order when you open it, rather than staying that way.
Builds 2.31.29, 2.31.30
Sep 9, 2026
A silently dropped connection no longer looks like thinking
A thread could sit on “Thinking” for hours while the agent had long since carried on without it. The app now notices the silence and reconnects by itself.
Some connections do not announce that they have gone. A network that drops the link quietly, a laptop that sleeps, a change of network — any of these can leave the app holding a connection that looks perfectly healthy but will never deliver another word. Because nothing appeared to be wrong, no attempt was ever made to recover: the thread simply sat on “Thinking”, sometimes for hours, while the agent went on working out of sight.
The app now watches for that silence. When a running thread has heard nothing for long enough that the connection cannot still be alive, it reconnects on its own and replays everything you missed, so the conversation picks up exactly where it left off — including a question the agent had been waiting on you to answer.
A prompt you send can also no longer go missing. If anything went wrong between pressing send and the message reaching the agent, the field was already empty and the text was gone for good. Your message is now handed straight back to you, along with anything you attached.
- Dead connections recover themselves — A thread that has stopped receiving reconnects automatically and replays what you missed, instead of waiting forever.
- A pending question resurfaces — If the agent asked you something while the connection was down, it reappears once the thread reconnects.
- Your prompt is never lost — A message that fails to send comes back to the field with its attachments, rather than disappearing.
Build 2.31.28
Sep 7, 2026
Frozen conversations and invisible reasoning are fixed
A long run used to stop updating mid-flight, and the model's reasoning was never readable. Both are fixed, and the prompt field now remembers what you typed.
A run could stop updating while the agent kept working, leaving you watching a transcript that had quietly stopped moving. The connection was fine; nothing was being sent down it. It happened most often when the agent was busiest — a large diff or a long stretch of tool output would make the update stream fall behind, and the connection would be closed as though it had died. Quiet connections are now held open, and a brief interruption is retried instead of abandoned after a single attempt.
The model's reasoning was also invisible. When it thought out loud, the reasoning block appeared and folded itself shut in the same instant, so there was nothing to read. It now stays open while the turn is running and folds only once the turn is finished.
A prompt you have typed but not sent is kept, even if you switch to another session and come back. The field used to discard unsent text the moment you left, so a long message you were still composing disappeared if you glanced at another thread.
Stepping back down through your prompt history now returns to an empty field instead of stopping on the last prompt you sent, so the key that recalled a message can also clear it.
- Conversations stay live — A long run no longer stalls mid-flight. The transcript keeps updating even when the agent is busiest.
- Reasoning is readable — The model's thinking stays on screen while the turn runs, instead of vanishing the instant it appears.
- Drafts are kept — An unsent prompt survives a session switch, so you can leave a message half-written and come back to it.
Build 2.31.27
Sep 7, 2026
A dropped connection no longer strands a question
When the agent asked you something and the connection dropped, the answer had nowhere to go. Now it still gets through, and cloud runs ask you to set a spending limit before the first one.
If your connection dropped while the agent was waiting on an answer, the run said it needed one while telling you the only way forward was to start again. Both statements were true and neither was useful: the question was still live on our side, but nothing you typed could reach it. Answering now works whether or not the connection survived, and a delivered answer picks the run back up where it paused instead of leaving a thread that looks dead.
The message you see in that moment says what to do. If a question is waiting, it points at the question rather than suggesting you send something new, which is what made the old screen read as a contradiction.
Cloud runs now ask you to set a monthly limit before the first one. Running in the cloud is included in your plan — the machine it runs on costs nothing extra — and you are billed only for what the model itself uses. A bigger context window uses more, so the ceiling is worth choosing deliberately rather than discovering later. Pick an amount once and you are not asked again.
- Your answer still lands — A lost connection no longer discards the one reply that would have let the run continue.
- The run resumes — Answering a question that outlived its connection reattaches the thread instead of leaving it stopped.
- Cloud spending is your call — Set a monthly ceiling before the first cloud run, from any of the places a run can start.
Build 2.31.26
Aug 26, 2026
Long runs finish, and the work actually lands
A run could stop early, or report a change it had never made. Both are fixed, and the agent now checks its own claims before it makes them.
An agent that sent two instructions at once had the first one thrown away. When that first instruction was the edit, the file never changed while the turn still looked like it had worked — so the run carried on believing work existed that did not. The edit is now the part that survives, because losing it costs the work itself while losing a re-read costs a second. Whatever was set aside is named, so nothing is quietly assumed to be done.
Every write is now confirmed against the file on disk rather than trusted from the report that the write succeeded, and a change that does not land says so in the first line instead of reading like a success.
Long runs stop dying near the end. A summarizer that stopped responding used to take the whole run with it, and waiting on a build or a test suite was mistaken for the agent going in circles and cut short — the failure got more likely the longer the job ran, which is exactly when it costs most. Waiting is now judged on whether anything actually changed, so a genuinely long job runs as long as it needs to.
The agent is also harder on itself. It re-derives a result before citing it, confirms a commit against the repository rather than the message it just printed, and when something it said does not match what is on disk it corrects itself in one plain line and carries on instead of theorising about why.
Its saved notes stopped disappearing, too. Notes were read in alphabetical order until a size limit was reached and the rest were dropped without a word, so most of what the agent had learned was missing from every task. They are now packed to fit the most notes possible, and anything still left out is listed by name so it can be opened on demand.
- Edits are never silently dropped — When a turn bundles a change with anything else, the change is the part that runs, and the rest is reported rather than assumed done.
- Writes are confirmed, not assumed — Every write is checked against the file on disk, and a failure is stated plainly instead of reading like success.
- Long jobs run to completion — Waiting on a build or a test suite is no longer mistaken for a stuck loop, and a wedged summarizer no longer ends the run.
- Claims are checked before they are made — Results are re-derived before being cited, and a correction is one factual line rather than a theory.
Builds 2.31.25, 2.31.24