Spare Claude Code capacity, matched to work someone would build with it

One CCU is 1% of a Claude Pro weekly Claude Code allowance. That is the whole definition — everything else on this page is just that number applied to a bigger or smaller plan.

It is deliberately relative rather than an absolute token count. Anthropic's published usage limits move over time; a unit pinned to a fixed number of tokens would drift out of date the next time they change. A unit defined as a percentage of whatever the current Pro allowance is stays honest regardless — pledges, estimates and the ledger all still mean the same thing next quarter that they do today.

The API / pay-as-you-go tier is left out of that table on purpose: it has no weekly ceiling to take a percentage of, so percentToCcu returns 0 for it. Pledging from an API budget works differently and is priced in dollars instead.

Every project gets a CCU estimate from one of two paths, and the platform always tells you which one produced your number. An estimate is a starting point for a conversation with whoever pledges against it, not a quote either side is bound to.

The AI path

When an ANTHROPIC_API_KEY is configured, the brief goes to Claude Sonnet 5 with a tool call it must use — it can only answer by calling record_usage_estimate, which forces a total CCU figure, a confidence between 0 and 1, a size band, a plain-language rationale, and three to six priced phases of work. The response is validated against a schema before anything is trusted. If the phase figures and the headline total disagree by more than a small margin, the phase sum wins — the phases are the actual reasoning, the headline is just a summary of it. Whatever comes out is then clamped into the platform's supported range, so a model that answers wildly high or low still lands somewhere usable. If the model call fails or refuses for any reason, the estimate falls back to the deterministic rubric below rather than surfacing an error.

The deterministic rubric

With no API key configured, estimates come from a scored rubric instead — the app is fully functional without a key, just less precise about it. The rubric reads the title, summary, body and tags for roughly a dozen keyword patterns — things like auth, a real data model, an API surface, third-party integrations, background jobs — and adds a fixed weight for each distinct surface it finds. It adds a small score for how much detail the brief actually contains, and nudges the total up for scope language like “platform” or “production-ready” and down for words like “MVP” or “prototype”. The kind of project sets a base score too — a loop is priced for a meaningful run of cycles, not one pass, and a prompt is priced mostly for the iteration it takes to tune it. That composite score picks a size band and a position inside it, which converts to a CCU figure, then splits back out into phases — scoping, the core build, whatever named surfaces stood out, testing, and handover — weighted so the numbers read like a real breakdown rather than one lump sum divided evenly.

The result is stored as estimateSource — ai, heuristic, or manual — on the project itself and on every row in project_estimate. Every estimate a project has ever had is kept, not overwritten, so re-estimating after a scope edit never silently changes the number a contributor already agreed to work against.

A pledge is a percentage of your own plan, for a cadence — weekly, monthly, or one-off — converted to CCU at the moment you make it and snapshotted against whatever plan tier you were on. If you upgrade or downgrade your plan later, the pledge keeps the CCU total it was written with.

The ledger is the part worth trusting rather than taking on faith. allocateCapacity reserves CCU off a pledge the moment an engagement is accepted, not when it is merely proposed — so a pending proposal never ties up capacity someone else could use in the meantime. releaseCapacity hands it back if the engagement is cancelled or the agreement falls through, and it is clamped to what was actually allocated so a double release can never inflate a pledge past its total. recordConsumption is separate again — it records what was actually burned and moves the delivered counters, without touching the remaining balance, because consumption is reporting, not accounting.

One negotiation, two ways to start it. A claim is a contributor stepping up to fund and build someone else's posted project. A proposal is a builder pitching an idea directly at someone's open pledge. Same state machine either way — pending, then accepted, declined or withdrawn, then eventually completed or cancelled — just opposite directions of who reached out first.

Suggested matches are scored, not just filtered. Coverage — whether the pledge's remaining capacity is enough to fund the estimate — carries the most weight, at 0.45 of the score. Shared interest between what the donor said they want to back and the project's tags carries 0.25. Whether the donor's acceptable ownership models include the project's actual model carries 0.2. The remaining 0.1 rewards a pledge that is open and recently updated over one that has gone stale. A pledge with no stated interests or no ownership preference is not penalised for it — it is scored as neutral rather than as a mismatch.

Full coverage is not required to surface a match. A pledge shows up as a partial match down to 25% coverage of the estimate, because several pledges can fund one project together — a pledge covering a quarter of the work is still worth knowing about.

Before work starts, a template is picked and its {{variables}} get filled in — names, the project, the ownership terms — and the result is rendered to markdown and frozen at that moment. A SHA-256 hash of that exact text is stored alongside it, and each signature separately records the hash of the content the signer actually saw when they signed. Either party can later prove nothing changed underneath them after the fact, because the hashes have to match.

An agreement moves through draft, pending signatures, and executed, or it gets voided. The ownership model is one of six: solo owner, equal split, proportional, open source, public domain, or custom — set before either side signs. The full set of templates lives in the terms library.

None of this is legal advice. The templates are a reasonable starting point for two people agreeing on who owns what — not a substitute for a lawyer if the project or the stakes get serious.

This is meant to be precise, not reassuring. Here is the whole path a message takes.

1. Your browser generates an ECDH P-256 keypair the first time you set one up. The public half is stored on the server as a JWK, in the clear — there is nothing to protect about a public key.
2. The private key never reaches the server unprotected. It is wrapped with AES-GCM under a key derived from your passphrase with PBKDF2. The salt, the iteration count and the wrap IV are stored so the wrapping can be reversed later — the passphrase itself is not, and it never leaves your browser.
3. Each conversation gets its own random AES-GCM key, generated client-side. That key is wrapped separately for every participant, via ECDH against their public key using a fresh ephemeral keypair each time. Adding someone to a conversation later just means wrapping the same key again for them. The server only ever holds wrapped copies — it never sees the conversation key itself.
4. Message bodies are ciphertext plus an IV. So is the conversation subject line. There is no plaintext column in the message table — that is deliberate, not an oversight.
5. A fingerprint is stored so you can confirm you still know your passphrase before rotating your keys, without the server ever learning what it is.

It is also honest to say what this does not protect against. The server still sees who is talking to whom, when, and roughly how much they are saying, because conversation metadata is not ciphertext, only the content is. And the server serves the JavaScript that does the encrypting in your browser, which means this scheme protects your messages against a database breach or a curious operator poking at rows — it does not protect them against someone who compromises the server itself and changes what code it ships you.

No money moves through the platform. Nobody hands over account credentials — what gets pledged is someone's own time on their own plan, running Claude Code on your problem under their own login. Actually sharing plan access is a different thing entirely and is not what happens here; check the terms of your own plan and decide for yourself, because this project is not affiliated with Anthropic and cannot make that call on your behalf.

Estimates are estimates, from a model or from a rubric, neither of which has actually done the work. Agreement templates are a starting point, not legal advice. Reputation counters reflect self-reported outcomes of completed engagements — they are a signal, not a guarantee.