One epic, every gate, and 3.5 billion tokens.
I asked one agent session to deliver a whole epic across the web, iOS and Android, through every gate my delivery process has, so the only thing left for me to type was DEPLOY. It nearly did. It also caught a security flaw I had designed in, and read more tokens doing it than I would have believed if I had not counted them.
Epic 10 · 12 to 16 October 2026 · version one of the skill
A whole epic through Ultracode, without giving up a gate.
Epic 10 was GPS track import: full-size result and track files, correct handicaps, and GPX files that turn into boats in Race Replay. It touched the serverless functions, the RC Web App and the Race Officer app on iOS and Android, which must stay at parity. Fifteen tickets (ten planned, five added), 247 files, 234 commits, one pull request.
Until then I delivered epics one slice per session and stopped after each phase to look. Safe, and slow, and most of the slowness is me. I wanted to see what Claude Code's Ultracode mode would do with a whole epic in parallel. The condition was that nothing got easier for it: the same five gates, plan, unit, review, test harness and security, recorded against commits and enforced by a hook. A faster process that skipped one would just be a worse one.
The epic was ready because of two other skills. /roadmap places each epic in a product stage with a goal and a definition of done: a green test scenario for every feature, on the local stack, zero skips. /backlog writes every ticket to INVEST with Given, When, Then criteria that each name their test, and links dependencies on the GitHub board. That is what let a script read the board and plan the work without asking me. The first epic I tried was not ready, and was sent back before a line was written.
One orchestrator, many lanes, two stops.
- Stop 1, the plan. Tickets are refined in parallel into a plan and a lane graph, critics attack it, and I answer numbered decisions.
- Build. Each lane gets its own git worktree, works test first, and is checked by an acceptance verifier and a reviewer. One merger brings lanes into the epic branch, each with a merge commit. Then the unit gate.
- Review. Six review lenses plus a panel of other companies' models. Each finding faces three sceptics; anything above low blocks.
- Harness and security on the merged baseline. Main is merged into the epic, so the tests run on the exact tree that will ship. Every test uses the local stack: no deploy preview, no live database.
- Stop 2, then DEPLOY. A pull request with the evidence. A hook blocks the epic from reaching main until all five gates are fresh, and any code change makes a passed gate stale again. On DEPLOY it merges once, applies the migration, runs the deploy gates and pushes.
Four review rounds, one real flaw, one override.
Blocking review findings per round. 63 findings in all; the 49 lows became tickets.
Tests in the final harness run on the merged code, zero skipped.
The security gate earned its place. My plan made an imported track belong to the officer who imported it, so a removed or demoted officer would keep the right to change or delete it. Review missed it; the security lens did not. I chose club-owned tracks, the migration was rewritten before it reached the live database, and three tickets were added so officers can remove a track on all three platforms.
That fix needed a fourth review round, which trips the skill's circuit breaker. I read why and told it to go on. It passed with nothing blocking. I typed about sixteen messages in four days. The most important one stopped a test run that was about to reach the live database. The run also hit my usage limits several times, the weekly one included.
3.52 billion tokens. 96.7% of them re-read.
From the session logs. Output, everything the agents wrote, was about 2 million.
1,161 agents took 23,992 turns, and all but one ran on Opus. Every agent starts with about 59,000 tokens of context and reads it again on every turn, which alone is about 1.4 billion of the cache reads. The plan estimated 2.2 million tokens. Caching makes this cheap per token. It does not make it small.
The agents did not write too much. They re-read too much, too many of them, on a model bigger than most of them needed.
Same gates. Faster, cheaper, and longer away from the keyboard.
- A model for each role. Done: Opus only plans and finds; Sonnet builds and checks; Haiku runs sweeps.
- Effort and context for each role. Each agent starts with what it needs, and thinks as hard as its job needs.
- Side-quests in their own session. The tooling detour cost a billion tokens.
- Data ownership designed at plan time, so security confirms a design rather than finding one.
- Scripted checks before review, for fewer findings and fewer rounds.
- Unattended resume after usage limits, and token actuals recorded per epic.
Token figures are from the session logs of the run and its follow-up security session, counted per agent. Other figures are from the pull request, git and the gate records committed with the epic. No money figure: the run was on a subscription.