458 repos and a spend cap — Chovy's Blog
458 repos and a spend cap
2026-08-16, by Anthony “chovy” Ettinger.
How this was written: drafted with an AI assistant from my own notes,<br>then edited by me.
The count
I ran a find over my source directory this morning. 458 git repos, spread across 10 GitHub<br>orgs. 271 of them are under one org. Some are dead, some are a README and an idea, a few have<br>real users. The number that pay for themselves is small enough that I do not need a spreadsheet<br>to track it.
That is not a confession, it is the strategy. I have been building on the assumption that you<br>cannot pick the winner in advance, so you buy more tickets. It worked when a ticket cost me a<br>weekend.
Tokens are the new bet size
What changed is not that I got faster. It is that the price of an attempt moved from my time<br>to my token bill, and those two things fail differently.
Time is self-limiting. I can only burn one weekend per weekend. If a project is going badly I<br>notice, because the cost is coming out of a bucket I feel. Tokens do not work like that. Six<br>agents can run in parallel on six repos, and every one of them is spending, and none of them are<br>telling me which of the six is the one worth spending on. The cost per attempt went down and the<br>number of simultaneous attempts went way up, so the total went up too.
The part nobody prices in: the losing bet costs the same as the winning one. Getting a project<br>to the point where you can tell it is a dud is most of the token spend. You do not get a refund<br>for finding out.
The day the meter ran out
I found the ceiling the dumbest possible way. Every Anthropic key in our vaults started<br>returning this:
HTTP 400 invalid_request_error<br>"You have reached your specified API usage limits.<br>You will regain access on 2026-09-01 at 00:00 UTC."
Two keys, two different vaults, same message. The limit is account level, so swapping keys<br>does nothing and provisioning a new one from the same org does nothing.
Two things about that are worth writing down. It comes back as a 400, not a 429, so every app<br>I own logged it as a code error and I spent real time debugging a bad request that was actually a<br>billing state. And the apps that degrade gracefully degrade silently. One of mine falls back<br>through three providers, another swallows the error to keep the page rendering, so a capped key<br>does not look like an outage. It looks like a feature that quietly stopped working, with nothing<br>in the logs.
That is the honest version of the gamble. It is not that I might spend too much. It is that I<br>had no idea how much I was spending until an HTTP error told me, and my own systems were built to<br>hide it.
So what
I am not going to stop. 458 repos is not a plan I arrived at by accident, and I still think<br>volume beats picking, because I have been wrong about which project would land every single time<br>I have had an opinion about it.
What I am changing is small. Set the usage limit on purpose instead of discovering it. Treat a<br>400 from a model provider as a budget signal, not a bug. Make the fallback chain log loudly when<br>it falls back, because a silent downgrade is worse than an error page. And accept that the token<br>line is a marketing budget, not an infrastructure cost, because that is what it actually is: I am<br>paying to find out which one of these is the winner.
We are all doing this. Spraying projects into the world and hoping one of them sticks, except<br>now the ante is metered per token and the house sends you a 400 when your chips run out.