Saturday, June 27, 2026
I Automated 100% of a Repo's Development with Claude Agents. I Burned Through My Weekly Limit in Under a Day.
For 19 hours, I did not write a line of code. Did not open a single file. Did not review a single PR by hand.
I launched a loop, and a fleet of Claude agents developed my project in my place: ~120 green merges, from brainstorming through to merge, taking in the spec, the implementation, the code review and the CI along the way.
The technical result is striking. The bill, on the other hand, raises a real question: is this mode of development actually scalable today?
Spoiler: I doubt it. And that is the whole point of this article.
▸ The setup: 4 skills and a loop
The repo is Koine, a domain-specific language (DSL) for Domain-Driven Design, which compiles .koi files into idiomatic C# and TypeScript.
To automate its development, I wrote 4 Claude skills that chain together:
1.
create-issue: creates an issue with a 3-phase plan (brainstorming, specs, implementation plan), then triages it and applies the labels.2.
implement-issue: implements the issue, applies an automatic code review, and even reports unrelated bugs it runs into along the way.3.
merge-pr: waits for the CI to go green, applies the necessary fixes, merges, and opens follow-up issues if needed.4.
auto-dev: a simple loop that orchestrates the other three, keeping 3 agents running in parallel.This is exactly the philosophy the creator of Claude Code was arguing for recently: stop chatting, stop writing code by hand, stop even writing skills, and abstract the work into loops instead. I wanted to test it at the scale of a real repo. It works. Really well.
Then I looked at the numbers.
▸ The bill: 120 sessions, 5.07 billion tokens
I aggregated every transcript from the full run: the orchestrator plus 119 worker sessions running in parallel in separate tmux panes (26 June 15:11 to 27 June 10:26).
120 sessions (1 orchestrator plus 119 workers)
5.07 billion tokens
27,566 assistant turns
≈ $12,042 in Opus API equivalent
≈ $100 per merge
⚠️ An important clarification: those amounts are equivalents at the public Opus API price, computed from the tokens on disk. On a Max/Pro subscription, my actual marginal cost was ~$0 (usage is included, bounded by rate limits, not billed per token). So the dollar figure is not an invoice, it is a scalability signal: it tells you WHERE the tokens go.
And that is where it gets interesting.
▸ 83% of the cost is context. Not work.
The question everyone asks: “it costs a lot because it generates a lot of code, right?”
Wrong. The dominant line item, by a wide margin, is cache read: re-reading the context. The rest breaks down like this:
Cache write (establishing the context): 61%
Output (the code actually generated): 22%
Input: 16%
96.5% of the tokens consumed are cache read. In other words: at each of the 27,566 turns, every agent re-reads its entire context. In a long agentic loop, you are not paying for the reasoning or the code produced, you are paying for context volume × number of turns.
My orchestrator alone re-read 1.5 billion tokens of context over a 2,950-turn marathon, because it was dragging around a 380-entry TaskList that got reinjected on almost every tool call. Pure cache waste, multiplied by 2,950.
That is the real scalability problem. And it is still talked about far too little.
▸ The levers (counter-intuitive ones)
Providers like Anthropic today offer an enormous token volume for ~€200/month. It looks unlimited. Except I automated a single repo, and I blew through my weekly limit in under a day.
The “one Opus agent, full reasoning, infinite loop” mode simply does not scale, not because of the code generated, but because of the redundant re-transmission of context.
1. Model tiering: most tasks were mechanical (a one-line guard, some docs, a snapshot regeneration). Cache read is 5× cheaper on Sonnet, 15× on Haiku. Routing the worker fleet to Sonnet/Haiku and reserving Opus for orchestration would take the run from ~$12k to ~$4-5k equivalent (≈ $7k saved), with no noticeable quality loss. By far the biggest win.
2. Reduce context per turn: do not accumulate useless state, compact the orchestrator regularly rather than running one endless session.
3. Larger units of work: grouping sibling issues into a single worker amortises the cost of establishing the context (140M cache write tokens, i.e. 22% of the total).
4. Less active waiting on CI: a worker polling a slow CI wakes up in a loop, and every wake-up re-reads its context.
▸ The real question, and what comes next
We are being sold the autonomous agent that codes while you sleep. Technically, it is already here. I ran it, it produces merged and reviewed code.
But the underlying economics are not yet ready for this brute-force mode. As long as ~80% of the cost is context re-transmission rather than actual work, scalability is not a question of a smarter model, it is a question of context engineering and tiering.
The future of autonomous development will not be “the best model in a loop”. It will be “the right model, at the right turn, with the minimum context”.
And here I only ran 3 agents in parallel, on 1 single repo. Project that forward: before long, we will probably be declaring a dozen agents across a dozen repos, in parallel. Multiply the context bill by that order of magnitude, and scalability stops being theoretical, it becomes the number one limiting factor.
That is the work I am starting next week: a new loop that runs on Sonnet rather than Opus, and that avoids cache re-reading as much as possible. I will write a second article once I have found the right settings.
Until then, I am genuinely keen to hear from you: have you already let agents run autonomously on a real project? Across how many repos in parallel? And above all, how did you handle the cost and the limits?
Repo and skills are open source: the Koine repo and the 4 skills.
Does this resonate with your team?
Let's talk about how Atypical Consulting can help you move forward.
Contact me