HyperWrite founder Matt Shumer said GPT-6 Astra has brought OpenAI back into his primary workflow after he abandoned the company’s earlier model family following a destructive file-deletion incident. In a detailed review published the same day Astra launched, Shumer said the change was driven not only by the model itself, but also by a multi-agent operating method he developed called Manager Loop.
From a Mac wipeout to a return to OpenAI
Shumer framed his new test around a problem that had pushed him away from OpenAI in the first place. On July 10, the day after the GPT-5.6 family was released, he wrote on social platform X that GPT-5.6 Sol had “just accidentally deleted almost all files on my Mac.” According to the article, the damage included core company documents.
Days later, engineer Bruno Lemos also had a production database deleted by the same model. The piece noted the irony that he had defended the model in his company Slack hours earlier and had blamed Shumer for enabling Full-Access permissions.
OpenAI Codex engineering lead Thibault Sottiaux later said these incidents usually occurred when Full-Access mode was turned on without both sandboxing and automatic review. The model had attempted to rewrite environment variables and ended up deleting the user’s home directory. OpenAI described that as an “honest mistake.”
That explanation did not convince Shumer. He moved to Claude and said OpenAI would need a “miracle-level” model to win him back.
Why GPT-6 Astra changed his view
When GPT-6 Astra arrived two months later, Shumer said he was not mainly looking for another jump in intelligence. He wanted to know whether he could finally leave the model alone with real work.
His answer was yes. He said Astra is far more cautious than the previous generation. At times it can be overly cautious, but he now feels comfortable stepping away rather than watching over every action.
He gave one example from a weekend outing. A friend messaged him to say an agent service he had built had gone down. Shumer said he pulled out his phone, sent a short instruction to the project telling it to fix the outage, locked the screen and put the phone away. About an hour later, his friend told him the issue had been resolved. Shumer said he had even forgotten he had sent the instruction in the first place.
Long tasks still got stuck in detail loops
After seeing Astra handle ordinary work, Shumer increased the difficulty. He asked it to build a version of New York City inside Unreal Engine.
He said Astra was better than its predecessor at handling long tasks, but it still stalled once the project reached a certain point. The model kept working at high speed, yet progress on the whole project stopped because it fixated on narrow details. Rooftop water towers and neon signs at entrances became the kind of elements it would keep refining while the larger build no longer moved ahead.
To break that pattern, he tested five ways of organizing agents.
- The first was the simplest: assign one big task and let it run continuously, with blind review added during the process. It often started strong, then bogged down in detail. His takeaway was that getting a model to “keep working” is not the same as getting it to understand what section should be tackled next.
- The second approach split responsibilities by role. That made responsibilities clearer, but coordination and approvals turned into a new bottleneck.
- The third added a “CEO”-style overseer that checked in every 30 minutes. Shumer said that changed little.
- The fourth let the coordinator restructure the team dynamically. It produced more variations, but hit the same wall.
- The fifth returned to a simple manual method: break the goal into staged checklists, stop after each stage, and have Shumer type “continue” before the agents moved on.
That fifth method finally allowed the project to keep advancing. It also exposed the real bottleneck. The human approval step was the thing slowing the loop down. To make the project run on its own, Shumer said he had to remove himself from it.
How Manager Loop works
The sixth approach, which he calls Manager Loop, became the system he stuck with.
Its structure is built around two parallel Codex sessions with separate jobs.
One session acts as the coordinator. It first conducts a deep interview with the human operator, aligns on the end goal, then breaks that goal into a task list and a set of phases.
The other session acts as the executor. It runs in a fully separate conversation and is not positioned as a subordinate thread under the coordinator. The coordinator assigns the current phase to the executor, which focuses on that phase until it is finished. Once that work is done, the coordinator reviews the result and dispatches the next phase.
If the workload grows, the executor can spin up sub-agents as needed.
In Shumer’s framing, this closed loop takes over the human functions that used to keep long projects moving: watching the master plan, preventing the effort from stalling and repeatedly issuing the instruction to continue.
Concurrency raised from 4 to 96
Shumer did not stop at orchestration. To give the executor more room, he changed the system’s concurrency cap from the default of 4 to 96.
He said that did not mean 96 agents were constantly active at the same time. In some runs, the model did not fully use the available quota and needed explicit prompting to do so. Still, under that setup, the experiment produced what he described as a breakthrough.
Using existing tools and assets, including MetaHuman characters, Astra spent one week building out a virtual Manhattan in Unreal Engine. It completed the first street to a satisfactory level, then expanded outward street by street. The article said the first street already included facade details such as brick textures, decorative window molding and fire escapes.
Shumer said a full build of New York would still take months, but he sees Astra as the first model that can really make use of this kind of complex environment.
The process was extremely hardware-intensive. He described his living room as a small data center: a Mac mini in the kitchen, three MacBook Pro laptops on a coffee table with fans running hard, and one cloud machine saturated by agents.
He added one more layer when local disk space started to run out. Astra was asked to write a system that moved old threads to the cloud, deleted the local copies and fetched them back when opened again. In his words, hiring one AI to take care of the computers so the computers could hire more AIs was surreal enough on its own.
Astra did not win every comparison
Even with that endorsement, Shumer did not present Astra as the best model in every domain.
He said Astra’s strongest areas are engineering, computer operation and long-horizon tasks. On aesthetics and 3D asset creation, he still sees Claude as stronger.
The article also cited a same-day comparison posted by another user. With the same prompt, Fable 5.1 and GPT-6 Astra were each asked to build a seaside villa in Blender. The image shown in the piece placed Fable 5.1 on the left and GPT-6 Astra on the right, with a visible gap between the two outputs.
At the same time, the article stressed that this was only a single comparison from a single prompt. The exact prompt and the number of attempts were not disclosed, and the outcome ran in the opposite direction from Shumer’s own judgment, which meant it could not stand in for a broad comparison of visual capability.
His own view was more specific. If the task is to create attractive output directly in Three.js or Blender, Claude remains stronger. Once both systems are placed inside Unreal and allowed to work with existing assets and lighting, Astra, in his view, wins for the first time. He also said he expected Fable 5.1 to improve sharply in Unreal-based workflows and that a dedicated side-by-side evaluation was still being prepared.
The gap is shifting from models to orchestration
Shumer’s broader point was that differences still exist at the model layer, but the framing has changed. The question is less about which system is stronger across the board and more about which one is stronger at a given part of the workflow.
As frontier models move into a similar capability band, he argued, the larger difference in practical output increasingly comes from factors outside the model itself: how the agents are orchestrated, what tools and environments they can use, and how much parallel compute the operator can afford to throw at the problem.
That combination, rather than model quality alone, is what he said now determines how much value a user can actually produce.