What's new in Goatfied.

Oct 5, 2026

Opening a folder takes you straight to a new agent

Open, clone or add a folder and Goatfied now shows its name in the left panel and drops you on the New Agent page, ready to type.

Opening a project used to leave you wherever you were: inside an old conversation, on another page, or in the editor, with nothing to tell you which folder the next agent would work in.

Now the folder's name appears at the top of the left panel, under Search, and Goatfied takes you to the New Agent page with the message box ready. This happens however you open a project: Open Folder, cloning a repository, adding a folder to your workspace, or opening a GitHub repository without cloning it. Switching branches on a repository you already have open leaves you where you are.

• Always know which folder you're in — The open folder's name sits in the left panel, so you can see at a glance where a new agent will work.
• Straight to work — After opening a project you land on New Agent with the message box ready, even if you opened it from the editor.

Build 2.31.39

Sep 30, 2026

Replies now name the model that actually wrote them

Switching models mid-conversation no longer leaves replies labelled with the wrong one.

If you started a conversation on one model and switched to another for a follow-up, the label under the new reply could keep showing the first model. Pick Claude Opus 5.5 after a turn on Claude Opus 5, and the answer still said Opus 5. The reply really was written by the model you picked; only the label was stale.

Each reply is now labelled with the model that answered that turn, by its proper name, and the version is matched exactly so one model is never shown under a neighbouring model's name. In the Ask panel, changing the model no longer renames earlier answers, and a reply that Auto answered on your behalf says so. Replies from the GOAT models still show as GOAT.

• The right model after a switch — A follow-up on a newly picked model is labelled with that model, not the one the conversation started on.
• Earlier answers keep their label — Changing the model in the Ask panel no longer relabels replies that were written before the change.

Build 2.31.38

Sep 19, 2026

A reply cut off mid-thought no longer ends the run

When an agent tried to write something too large in one go, its reply could be cut off and the run would stop a few turns later. It now recognises what happened and works around it.

Every so often an agent would stop with a message saying it was no longer producing a usable action, sometimes after spilling a block of raw text into the conversation. It looked like the agent had lost the thread. It had not. It was trying to write something too big to fit in a single step — a large file, or a long note to itself — and the reply was being cut off before it finished.

The problem was that nothing recognised the reply as incomplete. The agent was simply asked to try again, so it attempted exactly the same oversized step, was cut off in exactly the same place, and after a few rounds of that the run gave up. The work done up to that point was fine, but you had to notice and nudge it along yourself.

An unfinished reply is now detected directly, rather than relying on a signal that some models never send. When it happens the agent is told plainly that the step did not run and that repeating it will not help, along with what to do instead: make a smaller, targeted edit, split a large write into pieces, or shorten the note. If a run does still stop, it now says it was cut off and why, instead of reporting a vague protocol failure.

• Oversized steps recover on their own — An agent that gets cut off mid-write now breaks the work into smaller pieces and carries on, instead of retrying the same step.
• No more stray text in the conversation — The half-finished reply that used to leak into the thread is recognised for what it is and handled quietly.
• A clearer reason when a run does stop — The summary says the reply was cut off and suggests the fix, rather than only reporting that something went wrong.

Build 2.31.37

Sep 19, 2026

A long session no longer goes black

Sessions left running for hours could end with a black window. The cause was terminal output kept without limit, and a window that had no way to come back if it was lost.

If you left Goatfied working for several hours — the kind of run that watches a build, or streams a test suite — the window could turn black. The menus still worked, so the app was clearly alive, but the session you were watching was gone and the only way out was to quit and reopen.

Two separate things had to be true for that to happen, and both are now fixed. The first was the cause: every line a command printed was kept for as long as the session existed. A command that prints a progress line every second does that tens of thousands of times, and the running total was held for every command in every session at once. Eventually it outgrew the memory the window is allowed, and the window was shut down mid-session. Long output is now trimmed in the middle: the beginning is kept, because that is where a command says what it is doing, the most recent output is kept, because that is what you are reading, and the card tells you plainly that it hid something rather than quietly pretending that was the whole log. A single enormous line — a minified bundle, a long encoded blob — is shortened the same way, since one of those could outweigh a whole session on its own.

The second was why it was fatal rather than a blink. Nothing was watching for a lost window, so once it was gone it stayed gone. Now it comes straight back on its own, and because your agents run outside the window, the work carries on while it does — nothing in flight is lost. A window that fails repeatedly stops retrying instead of flickering at you.

• Long runs stay stable — Terminal output is bounded, so a session that runs for hours no longer grows until the window is shut down.
• A lost window returns by itself — If the view is lost it reloads automatically and your running agents are unaffected, because they live outside it.
• Trimming is honest — When a very long log is shortened, the card says so and keeps both the start and the newest output.

Builds 2.31.35, 2.31.36

Sep 17, 2026

Waiting on a long job no longer costs you anything

When an agent has to wait for a build, a deploy or a test run, it now says so, stops working entirely while it waits, and carries on by itself the moment the job finishes.

Some work is mostly waiting. A deploy takes eleven minutes, a test suite takes forty, and an agent that has just started one has nothing useful to do until it ends. The honest thing is to stop and wait — but an agent that goes quiet is indistinguishable from an agent that has got stuck, so you were left watching a spinner with no idea whether anything was still happening or how long it would be.

Now the agent tells you. When it parks on a long job it says which job it is waiting for, that it is not using the model while it waits, and that it will pick straight back up when the job is done — which it then does, on its own, without you having to come back and nudge it.

Waiting is genuinely free, too. The pause happens outside the model, so a forty-minute test run costs the same as a one-second one. A job that keeps reporting progress is waited on for as long as it keeps talking, however long that takes, instead of being checked on over and over — and an agent can no longer declare itself finished while something it started is still running, which used to leave a build nobody ever read the result of.

• It says what it is waiting for — The thread names the job and states that the pause is free, so a long wait never reads as a hang.
• It resumes on its own — The moment the job finishes the agent continues. Nothing to click, and no need to sit and watch it.
• A finished run is told to you — When a run ends — or stops and needs an answer from you — your computer lets you know, so an overnight job is not discovered the next morning. Turn it off under Notifications.

Build 2.31.34