Oxagen was built in seven months by one person learning to run a fleet of agents.
Mac Anderson built an agent, a benchmark, a protocol, a verifier, a fleet, and a memory plane before he built Oxagen. He wrote little of it by hand. He ran coding agents, six at a time, and spent most of a summer finding out what a workforce of them actually costs you to manage. Oxagen is the answer to that, and it was built by running the fleet through Oxagen. This page reads the seven months back from the record: his GitHub history, his git history, and the 8,133 prompts he typed to Claude Code.
The GitHub totals start on 26 February 2026, the first day of real activity on the account this year. Before that, GitHub shows 38 contributions in all of 2025. The commit and pull request totals start on 28 May 2026, the first commit in any local clone. The prompt count is the smallest number on this page and the least complete: it covers 81 days on one laptop. What the prompt log covers.
Against the numbers the industry publishes
Four months is a short window, so every figure below is stated per week and nothing is annualized. The window is 28 May to 20 September 2026: 116 calendar days, 16.6 weeks, about 83 working days. He committed on 114 of the 116 days. The published baselines are medians and percentiles, because no credible source publishes a mean. These distributions have a long right tail, so a mean would describe nobody.
Pull requests merged, per week
The one measurement that compares like for like. Both sides count pull requests merged into a default branch, per person, per calendar week.
He merged about 70 times what the median engineer in that population merges, and about 48 times what the top decile merges. His own peak week, 20 August, was 508.
Changes landed on the default branch, per week
Google measures a change, not a commit. A change is one reviewed unit landed in the monorepo, and Google squashes, so one change can carry several commits. That makes the Google column a floor on commits rather than a match for them, and the multiple below is therefore larger than the honest one. Google does not publish the ratio, so the honest number cannot be computed.
Lines of code, added and removed
Counted on default branches only, for source files, with lock files, build output, snapshots, fixtures, fonts, and generated code excluded. Deletions count as work, because most of the removal here is the same person taking out what he put in a week earlier.
That is 235,700 source lines added a week and 92,300 removed, leaving 2,376,660 net. Counting every file he touched, including generated output, the totals are 19,036,241 added and 16,999,466 removed. The largest single file change added 2,000 lines or more only 27 times across 19,223 distinct files, so the totals come from steady churn rather than from a handful of dumps.
There is a baseline here, and it is not an added-only one. No credible source publishes lines added per developer separately from lines removed. The same Google study does publish change size: the median change modifies 24 lines. A median developer landing 3 changes a week therefore touches about 72 lines a week. That figure multiplies two medians, so read it as an order of magnitude and not as a statistic. The real mean sits above it, because a tenth of Google's changes modify one single line and the distribution runs long to the right. He changed about 328,000 source lines a week. The ratio runs into the thousands, and no exact multiple is worth quoting, because the two figures count different things.
One line in that study's method matters more than its numbers. Google filtered out changes made by automated processes before counting anything. The baseline is what people wrote by hand. The number above it is what a fleet of agents wrote.
He did not type this. Agents wrote the code and he ran them, reviewed them, and merged them. The comparison is between one person operating a fleet and one person writing by hand, which is the point of the page and not a footnote to it. Two more things cut against him. These repositories are four months old and carry no release train, no on-call rotation, and no other engineers to coordinate with, so a commit here costs less than a commit at Google. And a pull request he opened and merged himself passed no second reader.
Sources
- Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, and Alberto Bacchelli, “Modern Code Review: A Case Study at Google,” ICSE Software Engineering in Practice, 2018. About 9 million reviewed changes by more than 25,000 authors and reviewers, January 2014 to July 2016, with changes made by automated processes filtered out. The median developer authors about 3 changes a week, 80 percent author fewer than 7, and the median change modifies 24 lines. sback.it/publications/icse2018seip.pdf
- DX, “Engineering Benchmarks,” the diffs-per-engineer measure, defined as pull requests merged each week per engineer. Technology companies under 100 engineers: 3.8 at the median, 5.53 at the 90th percentile. DX does not disclose the sample size. getdx.com/research/benchmarks
- His own numbers come from the git history of 13 local clones, counting the default branch only and deduplicating by commit hash. A rebased branch repeats its commits under a different hash, so counting every branch would have inflated the total by nearly half.
The hive
Each hexagon is one day, Monday at the top, one column per week. Colour is what he was working on: whichever area led that day’s prompts paints the cell. Brightness is volume, so a pale cell is a quiet day and a burning one is a day he did not stop.
The colour is the finding. Of the 81 days the prompt log covers, 50 were led by shipping work: gates, pipelines, deploys, and the machines that run them. 19 went to building the agent, 7 to proving it, 5 to selling it. That ratio is the part nobody warns you about. Running a fleet of agents is mostly building the road they drive on, and he spent most of a summer paving.
The grey cells are the first four months, before the prompt log existed. They still carry his commits, so the shape of the work is there even where the colour is not. What the log does and does not cover.
What the prompt log covers
The 8,133 prompts come from one machine, a laptop set up on 29 June 2026. They cover 81 days of the seven months on this page, and they are not the whole of his Claude activity. He worked on other machines before that laptop and alongside it, and those conversations are not in this file. Nothing reconstructs them.
So read the prompt figures as a sample, not a census. Every count drawn from them, the topics, the colours on the hive, the hours, the happy words and the swearing, describes those 81 days and no others. It is a floor. The real total is higher by an amount nobody can state, so this page does not guess at it.
The GitHub and git numbers are different in kind. Those come from the account and from 13 local clones, they cover the full window, and they are complete for what they count.
How the seven months went
Each chapter comes from reading the prompts in order. The quotes are his, trimmed, with the swearing taken out.
July was for building. August was for proving it.
Above the line, happy words in his prompts each day. Below it, swear words. Both count the same thing, words, so they share one scale. Happy words spread across the July launch weeks. The swearing sits almost entirely in August, in the weeks he spent trying to prove that Stella was done when it said it was done.
What he was building when it went well
- 12 julStella's first week in public. The README brief asked for a project that would
inspire a community that is sick of token waste.
- 19 julA fleet design with no coordinator, where every agent works in one worktree.
BUILD THIS DESIGN I LOVE THIS.
- 31 julWatching the first honest Terminal-Bench run climb to 58 of 89.
I would have worked hard for a reason.
- 2 augA git-backed journal that can resume any turn.
an amazingly elegant answer to the durability problem.
- 13 augCutting 72 tools down to five.
less is more and way less is best.
- 11 sepStarting Oxagen over from a clean spec and 12 parallel mockup builds.
We need to be perfect here.
What he was building when he swore at Claude
- 31 julA "fair" benchmark that turned out to carry a hidden budget cap.
Dont lie.
- 4 augA Files tab that showed no reads and no writes, and a verifier that never wrote its test.
I WILL NOT TOLERATE WIERDNESS IN THE CRUD SYSTEMS
- 8 augA full day of benchmark runs he could not trust. The code graph was silently empty because init never ran.
NEVER RUN A BENCHMARK WITH A BUDGET CAP
- 11 augA pipeline mode that scored below the bare loop, because correct work was thrown away at the sandbox boundary.
- 22 augA redesign reported as finished that did not match the drawings.
Burning tokens for what?
The pattern is the same every time: an agent said something was done, and it was not. That is the problem Stella's witness tests, and later Oxagen's record, exist to answer.
By topic, per 100 prompts
Each prompt is tagged with its strongest topic by keyword. Design earns the most happy words. Verification and model providers earn the most swearing. The two columns use separate scales.
The 1 a.m. hour
Each spoke is one hour of the day, and its length is the number of prompts typed in that hour. Rust dots mark swearing, sized by count.
He prompts every hour except the early morning. The busiest hour is 1 p.m. with 638 prompts. The hours from midnight to 5 a.m. hold 919 prompts, 11 percent of the total, and 53 of the 124 swear words, 43 percent. The 1 a.m. hour alone holds 32.
Wednesday is his busiest day of the week, with 1,363 prompts. Monday is his quietest, with 973. He prompts more on Sundays than on Mondays.
Oxagen and Stella took turns
Weekly commits in the two main repositories. Oxagen started first, on 28 May. In the week of 6 July it took 1,421 commits, and then it went almost silent while Stella took over through August. The week of 14 September, Oxagen came back with 3,501 commits in one week, rebuilt around the decision that Stella would be its engine.
Nearly everything in the agent stack
Each tile is something he designed and shipped in these seven months. Select one to jump the hive to the day it started.
Learning to run a fleet
One agent is a tool. You give it a task, you watch it work, you read the diff. Six at once is a different job, and it is the job this page is about. Nothing in seven months was harder to learn, and none of it was about prompting.
The agent was not the hard part. Running six of them was.
It started the obvious way: one agent, one branch, him watching. That works and it does not scale, because the watching is the bottleneck. So he widened it. The configuration he ended on runs 6 agents in parallel, each in its own git worktree, with background agents on, so work continues while he is reading something else.
Widening it broke things he had not thought to worry about. Two agents editing the same branch. A branch that merged cleanly into main and was still incompatible with what had landed beside it, which cost him three separate repairs to a red main before he understood that a clean merge proves nothing about behaviour. Agents that finished, reported success, and left the work uncommitted. A fleet does not fail the way one agent fails. It fails at the seams between them.
What the seams needed
- An isolated worktree per agent, so two of them cannot touch the same files.
- A written definition of done, because an agent will otherwise decide for itself what finished means.
- Checks that run without him. 21 of them, so review is not the bottleneck six times over.
- A trial merge before the real one, because clean and compatible are different questions.
What he still could not answer
- What did each agent actually do, in order, with what it read.
- What did that cost, and which piece of work was it spent on.
- Who allowed the thing it just did, and under what rule.
- Which of the six is stuck right now, and on what.
The first list he could build himself. The second list is not a tooling gap, it is a management gap, and it got worse with every agent he added. That is the gap Oxagen was built to close.
The code the fleet wrote
The fair question about code an agent wrote is whether it survives contact with anything. Volume is not the answer to that, so here is what is actually in the repository, counted from tracked files on 21 September 2026.
The architecture tests are the ones that matter most with a fleet. A human reviewer notices when a file imports across a boundary it should not. Six agents working in parallel do not, and will each do it in a different place on the same afternoon. A test that fails the build is the only reviewer that scales.
The audit
In September he had the operator console audited against its own specification, by a reader told to be adversarial and to assume the work was incomplete. It returned 14 findings, two of them release gates. Its summary judgement was this:
The app has substantial working foundations, but it does not yet close the core operator workflows.
That is published, with every finding, its acceptance criteria, and the repository it was run against. It is a separate repository from the code, so the findings cannot quietly be edited to match what shipped.
An audit that finds nothing is evidence of nothing. This one is offered as evidence of the practice, not as a clean bill of health, and the two release gates it named are still the standard the work is being held to.
Built with the thing it sells
This is the claim most likely to be read as a marketing line, so here is the mechanism instead.
Every model call made from this repository goes to 127.0.0.1:51781, which is Oxagen's own gateway running on his laptop. The agent's base URL points at it, so there is no path around it. Oxagen sees each call, meters it, and keeps the record. The runs that built Oxagen were governed and priced by Oxagen.
Tool calls take the same shape. A hook sits in front of them and can refuse one before it runs. There is a hook in this repository that denies an agent a full test build, because a fleet of six will otherwise each start one. That is the product's central idea, the agent asks and a rule answers, running against the agents writing the product.
That includes this page. The prompts that produced the words you are reading went through the same gateway, and the prompt log this page is built from is the record it kept.
Scope, stated plainly: this is the local gateway and the record it keeps, which is what a single operator runs. It is the same code path as the hosted control plane, not a separate demonstration build, but one laptop is not a deployment and this page does not claim it is.
The rules that came out of the fights
Most of these started as a frustrated prompt and ended as a line in a CLAUDE.md file, a gate in CI, or a design rule for both products.
Why Oxagen
After the agent, the benchmark, the protocol, the verifier, and the fleet, the agent turned out not to be the hard part. Knowing what it did, what it cost, and who allowed it was.
That is what Oxagen is: workforce management for autonomous agents. Give each agent its own identity. Set its authority, budget, tools, and skills in one mandate. For actions routed through Oxagen, the agent asks, a rule your team wrote answers, and the record keeps the answer with its cost beside it.
Oxagen shows you every governed action, the rule that answered it, the person who approved it, and which agent spent what, on whose behalf.
That is the record this page was written from, turned into a product.
Mac Anderson, founder of Oxagen
He built Stella, the open source coding agent this work started from, and Oxagen, the control plane it led to. Stella is AGPL and free to run. Oxagen is what you use when the agents are no longer yours alone.