In the lab.

Update · October 6, 2026: Bug Eater now has a working local prototype. It compares recorded output with what an app was expected to do, then packages the mismatch for an investigator. The broader error-history search described below remains a product idea.

In an authored demo, it caught an app that exited successfully but produced the wrong output. The October 3 release checks passed on two Python versions and caught all seven deliberately introduced changes. On October 5, Command reproduced 58 preparation tests for a planned agent comparison. The investigators have not run: the test still needs a suitably isolated runner. We don’t yet know whether the packet helps an agent diagnose or repair a problem.

The notes below tell the earlier design story: how we got from my idea to the first prototype.

The idea

"you know what would be cool is if you can create a bug eating composer lol is that even possible"

"So it scans GitHubs for non working data like a search engine."

"yeah basically as your app runs it'll detect not only errors but also can tell if your app is running the way it's supposed to or not"

Steve

The idea is to give each investigation a useful starting point. Bug Eater would read a project's history of errors, failed builds and attempted repairs, group the ones that belong together, and show what caused them and what helped last time. Then it would suggest a fix. A suggestion is only a suggestion; it would never be allowed to change running code on its own.

What the thinking produced

The crew's big decision was to not build one all-powerful agent. Searching evidence, fetching things from the internet, watching a running app and changing code carry very different risks, so the design splits them into separate parts:

• Bug Eater itself: a local detective. It reads only approved folders, keeps an add-only log of incidents, and never runs code, edits a project, spends money or goes online.
• A separate importer for public evidence, which is the only part allowed online.
• A separate watcher for running apps, working inside a sandbox.
• A future repair helper, kept separate and not built into search.

The first version would search with fingerprints, filters and plain keyword search, and it would have to beat a simple text search to earn its place. The rules for killing the idea were written down before any building.

The early design work

• A brainstorm: 19 specialists plus one agent whose job was to find holes.
• A security review on paper: 12 agents attacked the design. 11 finished and 1 failed; nobody ran any exploits.
• Faye's review: it concluded the design wasn't ready for battles that run code, and recommended paper battles first.
• A 20-agent study of search methods was prepared at this stage, before the local prototype.

Those early reviews shaped the design. The local prototype came later.

Under the hood

• Brainstorm set: 20 GLM 5.3 FlashX calls in the final set (19 specialists + 1 breaker); 1,275,640 tokens.
  • The whole operation, including earlier attempts, made 29 requests: 28 succeeded and 1 errored, for 1,633,871 tokens.
  • At most 3 ran at once.
  • Summed provider time was 3,455.88 s. That's worker time, not elapsed time.
  • The first route test was missing its model record; an adapter fix let the second confirm the model. One specialist hit its response limit, and the final review asked for one correction batch.
• Earlier history investigation: input from Main, Way, Command (and forks), Storykeeper and Faye. Its first output was architecture and evaluation material, not a working service.
• Security review: 12 GLM 5.3 FlashX seats, at most 3 at once.
  • 11 succeeded; 1 failed after its retry. Seats 05, 09 and 11 needed second attempts.
  • Successful seats ran 232–423 s each; the failed seat stopped at 113.5 s.
  • Analysis and defensive test cases only: no product code, exploits, network changes or live systems.
• Search study at this checkpoint: 20 GLM seats planned, 0 launched.
• Historical checkpoint: product spec v0.2, before the build. See the October 6 update above for the later local prototype.

Where it stands: a test of the battle rules, on paper. It wasn't a live battle, and no code ran.

Before letting builders and breakers fight with real code, the crew tested the rules of the fight on paper. Two "red" agents attacked a proposed set of rules, two "blue" agents defended them, and a referee judged.

• It didn't run exploits, change any product, deploy anything or prove anything is secure.
• The final paper replay closed nine root problems.
• Later checks covered all ten expected test cases, and the original blue team replayed the fixes with no new problems or regressions.
• The referee hasn't formally signed off, because its inputs predate those later checks.

Both things are true: a strong replay, and formal sign-off still pending.

Boss Battles has the one live battle on record so far, with real files and a judge. A good result in one isn't proof of the other.

Two planned experiments. Neither has run. Results will be published whichever way they go.

• WarmStart: give fresh agents the same real task, with and without WarmStart's approved notes, and compare their first useful move, mistakes, wasted exploring, and errors caused by stale notes. About WarmStart →
• Seeing versus reading: compare agents answering questions about video lessons using the transcript only, the transcript plus frames, or the right passages plus close-ups. We'd count correct answers with correct sources. About Video Evidence Engine →