Forty-Nine Tickets

## Where I left it

In Leaving the Party I handed an idea for an issue tracker to Claude at 01:12 and went to sleep. When I wrote that post, at noon on 11 October, it had designed the whole thing overnight and built 21 of 49 tickets.

This is what happened next. It took 58 hours from my first message to the last ticket, and the line above is not a straight one.

## The fast start

The build ran from one Claude session acting as an orchestrator. For each ticket it started an agent in its own copy of the repo. That agent wrote the tests first, then the code. A second agent merged the work only if the full test suite passed. Every merge closed its ticket in Linear with a short note.

The first six hours were what you hope for. Twenty-one tickets landed, the test count went from 20 to 795, and the agents found real problems on their own. At 09:13 a test with 40 writers hitting the tracker at once failed about half the time. The easy fix was to make the test smaller. The advisor's note to the build said no: "Don't lower the writer count or loosen that assertion to get green." The agent found a real bug instead, and fixed it.

Then the build got more careful. From about 08:00 every ticket went through three reviewer agents and a fixer before merging. The reviews kept catching real bugs, and they also made every ticket take longer and cost more.

## Going nowhere

In the afternoon I closed T3 Code by accident, twice. Each time I typed "continue", and the build recovered without losing anything that had merged.

Then it started to fall apart, slowly. Claude ran six ticket pipelines at once, and the machine went to 100% CPU. Tests that depend on timing started failing at random. Agents re-ran them, waited for the machine to calm down, compared runs before and after, and asked for exceptions. GOK-148 merged at 18:14. After that, nothing merged for 14 hours.

At 19:03 I asked if everything was alright. Seven minutes later I asked again, more directly. The answer to the second question was the real one: an agent hardening the tests had started two endless test loops "as synthetic load" two hours earlier, and never stopped them. Every other agent had been running 3 to 5 times slower since.

At 19:47 the build hit my Claude usage limit for the first time. It came back after the reset. At 23:46 it hit the limit again, and this time nothing woke it up. I was asleep. The shaded part of the chart is that night.

## The morning after

At 06:16 I typed "resume". At 06:33 I changed my mind: "ok stop all subagents". Two minutes later: "we used a lot of usage for last 12h and no progress let advisor have detailed information about it then let it plan a new implementation plan."

The build's post-mortem is the most useful thing it wrote all weekend. Thirteen hours without a merge, about 10 to 15 million tokens. And under root causes, first on the list: "Main cause, my own." It had run too much at once, and its own test loops had made everything slower. The worst part was something nobody had noticed: 6 tests had been failing for real since 15:37 the day before, and the noise had hidden them for 15 hours.

## Plan v2

The advisor, the session that had been running the design since the first night, wrote a new plan:

• Green first. Fix the 6 failing tests, then never merge on a failing test again. No more exceptions.
• One full test run at a time on the whole machine, behind a small lock it wrote and tested.
• No synthetic load, ever. After three failed fixes for the same problem, stop and say it's blocked.
• Two tickets at a time.
• One reviewer instead of three, and only on the 16 risky tickets: data formats that can't change after publishing, anything that deletes, anything that starts other agents.

It worked. The tests passed again at 07:38. By 10:53, 30 tickets were done. The line on the chart starts climbing again and doesn't stop.

It wasn't smooth. A fix for one flaky test added another one, and merges were blocked again for two hours on the evening of the 12th. This time the advisor didn't just let the test be swapped for an easier one. First the build had to prove that syncing hadn't actually got slower for users, and it set a deadline.

It also made decisions for me while I wasn't looking. It overruled a reviewer that had rated three data-corruption risks as "low". It decided not to exclude the test folders from Microsoft Defender, even though Defender's scanning is what keeps the everyday test run at about 9 minutes instead of 5, because my machine would be less safe and the people using grimoire will have Defender running too. That decision found a real Windows bug. It also picked the MIT license, because nobody had picked one. I'm fine with all three. I also didn't make any of them.

All 49 tickets were done at 10:39 on 13 October.

## What it cost

The numbers come from Claude Code's session logs, from my first message until 12:15 on the 13th:

• 22,963 model calls, almost all of them on Claude Opus 5.5
• about 12.5 million tokens written by the model, and about 4 billion read back from the cache
• about $2,089 at API list prices, all of it on my Claude subscription, which ran out twice

Split by stretch, which is the interesting part:

• the design night and the spec: $327
• the fast start, 21 tickets: $385
• the next 18 hours, 4 tickets: $715, about $410 of it while nothing merged at all
• plan v2, the other 24 tickets and the final review so far: $662

Plan v2 built six times as many tickets as the bad stretch, for less money. The difference wasn't a smarter model. It was fewer things running at once, and a rule against merging on a failing test.

## What's left

At the moment it's finishing the close-out. A final review found 116 problems, about 20 of them worth fixing before anyone installs this, and three agents are on those now. Then the pull request merges, and grimoire gets published to npm. That last step needs me, because my npm login expired somewhere in the middle of all this.

After that comes the part I'm actually curious about: installing it in a real project and finding out whether the idea was worth any of this.

I don't really know what to think yet. The first night felt like magic. The second felt like leaving the stove on. The morning after, it wrote a better post-mortem than I would have. I'm not sure all of that was AI-assisted prototyping. Some of it was just me, watching something run while I slept, and then reading the receipts.