How donated compute is used

Your funding adds dollar balance to the project you support. Maintainers turn that donated compute into model token usage through compute keys with dollar limits, then spend it on the project work that needs extra thinking time.

That work is rarely one grand "AI rewrites the codebase" moment. It is the steady, useful stuff open source projects never have enough time for: issue cleanup, release notes, security review, test triage, documentation, dependency upgrades, design review, and small patches that move the project forward.

Triage the backlog

Maintainers can spend donated compute on the messy edge of project stewardship: reading new issues, finding duplicates, checking whether a bug report has enough detail, and drafting calm replies that help contributors get unstuck.

A good task might be:

Review the newest bug reports, group duplicates, identify issues that need reproduction steps, and draft maintainer replies. Do not post anything without approval.

That is not glamorous work, but it keeps a project usable. Donated compute can turn a neglected queue into a clear next-action list.

Review pull requests

Many pull requests need a second pass before a maintainer can safely merge them. Model tools can inspect changed files, compare the patch to project conventions, suggest missing tests, and point out risky behavior.

They are especially useful for first-pass review:

Review this pull request for likely regressions, missing tests, confusing naming, and places where the implementation does not match the stated goal.

The maintainer still decides what is correct. The compute pays for an extra reviewer that can read patiently and summarize concretely.

Chase test failures

Flaky or failing tests drain maintainer time because they often require broad context: recent commits, fixtures, CI logs, and a good guess about where the failure actually started.

Donated compute can fund that investigation. A maintainer can ask a supported agent to compare a failing test against nearby code, explain the failure path, propose a minimal fix, and add a regression test when the cause is clear.

Tighten security and privacy

Security review is a good use of bounded compute because the scope can be narrow and the value can be high. Maintainers can ask for focused passes over authentication, webhook handling, external HTTP calls, secret handling, logging, or authorization boundaries.

The useful output is not "the model says it is secure." It is a list of concrete risks with file references, suggested tests, and patches the maintainer can inspect.

Improve docs and examples

Good documentation is often the difference between a project people can adopt and a project only insiders understand. Donated compute can help maintainers turn scattered knowledge into installation guides, migration notes, troubleshooting pages, examples, and release notes.

This is a strong fit because documentation work needs context, consistency, and patience more than invention. A model can read the current docs, compare them to the code, and propose updates that a maintainer edits before publishing. For long project context, prompt caching can make repeated review work much cheaper.

Plan before coding

Sometimes the best funded session ends without a patch. Maintainers can use donated compute to scope features, compare implementation options, identify risky files, estimate test coverage, or write acceptance criteria before anyone starts editing.

That kind of planning is especially useful for small projects where maintainers do not have a product manager, QA engineer, security reviewer, and documentation writer sitting beside them.

Use the tools that fit

A compute key works anywhere an OpenRouter-compatible API key works: coding agents, model playgrounds, local scripts, CI helpers, or custom project tooling. The important boundary is the project balance and the dollar limit on the key. See Available models for the current provider and model surface.

The opub CLI is useful when a maintainer wants spend to carry a Linked signal on the public project ledger. Linked spend shows that a compute key was active with recent local project context. Direct key use is also allowed; it still records spend against the project, but without that local session signal. The safeguards and privacy guide explains exactly what linking does and does not make public.

What donors can trust

Donors are not buying specific tasks or steering maintainer priorities. They are funding a bounded project balance that maintainers can spend on model work for the project. The donor guide covers how to find and fund projects.

opub records donations, compute-key limits, spend events, and project balance changes. It does not publish prompts, responses, code snippets, diffs, local files, repository origin, commit hashes, branches, or session timestamps on the public ledger.

That is the tradeoff: enough accounting to make donated compute visible, without turning maintainer work into a public transcript.