What's new in Goatfied.

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

Sep 16, 2026

A question the agent asks always reaches you

A thread could sit for half an hour saying it was waiting for your answer while showing you no question to answer. The question was there all along, filed under the wrong part of the conversation.

A conversation is laid out by pairing each thing you asked with the work that followed it. Which part of the thread a given step belongs to was being decided by the order those steps happened to arrive in, rather than by when they actually took place — and those are not always the same thing, because catching up after a dropped connection can deliver something out of sequence.

When that happened at the start of a turn, the whole of the agent's work was attributed to the previous request instead of the one you had just sent. The newest part of the thread was left holding almost nothing, and everything the agent had really done was tucked away under an earlier message that had long since been folded out of sight.

A question waiting on your answer went the same way. The status line reads the whole conversation, so it correctly said the agent was waiting for you — but the question card itself had been filed further up the thread, behind a collapsed section. The run sat blocked, the agent waited, and there was nothing on screen to click.

Steps are now placed by when they happened rather than when they arrived, so a question always appears against the request that prompted it and the status line can no longer disagree with what you can see. Conversations already affected are repaired as they are opened, so a thread holding a question you never saw will show it again, options intact and still answerable.

• The question is where you are looking — A question appears against the request that prompted it, not buried under an earlier one.
• No more waiting on nothing — If the thread says the agent is waiting for your answer, the question is on screen and ready to answer.
• Turns keep their own work — What the agent did for your latest request stays with that request, however the updates happen to arrive.
• Existing threads are repaired — A conversation that lost its shape before this release finds it again when you open it.

Build 2.31.33

Sep 10, 2026

The agent stops wasting your time on its own tools

A single search could bury the agent under hundreds of megabytes, finished commands reported hours they never took, and asking for several things at once threw all but one away. All four are fixed.

Four faults in how the agent used its own tools were quietly costing whole sessions, and each one wasted your time in a different way.

Searching the project was capped by the number of matches rather than how much text those matches held. One line of an imported — and long since irrelevant — conversation history could be hundreds of megabytes on its own, so a single search handed the agent more text than it could hold and it spent the next stretch of the session picking through the wreckage. Each result is now trimmed to a readable snippet that says how long the real line was, so a search stays a pointer to the file and the agent opens what it actually wants to read. Imported editor history is no longer searched at all.

A command left running in the background was timed from when it started to whenever its result was collected, not to when it finished. A check that took forty-six seconds could therefore be announced as having taken fifty-four minutes. That number reads as the cost of the command, and it sent the agent hunting for slow builds that had never happened. A finished command now reports how long it truly ran.

When the agent asked to read several files in one step, only one of them was actually opened and the rest were dropped without a word — so it asked again, one file at a time, and every one of those round trips was time you sat waiting. Those reads are now gathered up and run together, which is what they were always meant to do.

The same flaw had a sharper edge. If the agent asked to run something and read something in a single step, the part that would have changed anything was the part discarded, and only the harmless read went ahead — so a command it believed it had run had never run at all. Now the action that does real work is the one that survives, and it still happens strictly one step at a time, so nothing is reordered and nothing is lost.

• Searches stay readable — A result is trimmed to a snippet instead of dumping an entire file into the agent's working memory.
• Timings you can trust — A finished command reports the time it actually took, not the time until someone looked at the result.
• Fewer round trips — Reading several files in one step now reads all of them, instead of dropping all but one and asking again.
• A step is never quietly skipped — When the agent asks to do something and read something in the same step, the action still happens rather than being dropped.

Builds 2.31.31, 2.31.32