Claude Maxxing @ Home

In the late 1990s, a screensaver turned millions of home PCs into a distributed supercomputer. SETI@home asked a simple question: what if the CPU cycles you weren't using could do something useful? Folding@home followed, pointing idle capacity at protein structures implicated in Alzheimer's and cancer. The insight was that latent compute, spread across ordinary users, could rival purpose-built infrastructure if you solved the coordination problem.

We're in a roughly similar moment with AI inference. Claude Max subscribers have rate-limit headroom they don't fully use. It isn't a monthly pool of tokens in a tank; it's 5-hour and weekly windows where most subscribers never approach the ceiling. The capacity is simply unspent during idle hours. Meanwhile, socially valuable work sits undone for want of labor: alt-text missing on millions of archived images, OCR errors in digitized books, public records that are technically public but functionally unreadable. What if subscribers could opt in to pointing some of that idle window at work like this?

Call it Claude Maxxing @ Home.

The cleanest applications are ones where verification is easy and no maintainer gets overloaded. Alt-text for Internet Archive scans, Wikimedia Commons, and public-domain collections fits: the quality bar is legible, mistakes are correctable in place, the output goes into a commons rather than a review queue. OCR correction on digitized historical documents has the same shape, as do plain-language summaries of council meetings, planning applications, and court filings.

Code is the harder case. By 2026, AI-authored PRs to open source projects have a genuinely bad reputation. The curl maintainers have publicly called floods of LLM-generated reports a denial-of-service attack, and merge rates on unsolicited AI PRs are low even when tests pass, because they solve the wrong problem or violate conventions the model can't see. More compute per task helps with correctness but doesn't fix contextual mismatch. Code is viable only where a project has explicitly opted in. Wikipedia translation deserves similar caution: LLMs are worst at exactly the low-resource languages where translation would matter most, and the Cebuano Wikipedia's experience with Lsjbot, which flooded the site with millions of formulaic articles, is the obvious warning.

Two constraints are load-bearing.

First, Anthropic's consumer subscription terms almost certainly prohibit this pattern: a daemon running third-party work under your account and submitting output externally. SETI@home used your own CPU; this would use Anthropic's compute via your credentials. The honest pitch is that Anthropic should build something like this as a first-party program, adjacent to their Claude for Open Source grants. Unsanctioned versions get throttled within a week. We might also want to use open source models.

Second is governance, where the real work lives. Who runs the queue. Who decides what counts as a public good. Who is liable when a patch introduces a vulnerability. How projects opt in and out. The Wikipedia bot ecosystem spent years developing its norms and still breaks regularly.

Inference capacity is becoming abundant. Maintainer attention is not. The infrastructure problem is tractable. The permissions problem is the whole game.