How donated compute is used

Your donation adds dollar balance to the project you fund. Maintainers turn that donated compute into model token usage through capped compute keys, so the project can use top AI coding tools as they see fit.

The examples below show the kind of useful funded sessions a maintainer might run.

GitHub Copilot CLI: repository management

For GitHub-native maintenance, a maintainer might start:

opub run copilot

GitHub describes Copilot CLI as a way to use Copilot from the command line, including terminal workflows for code review, pull requests, autonomous delegation, and session steering. That makes it a natural fit for repository management work funded by donated compute.

A maintainer prompt might look like this:

Triage the newest issues labeled "bug", identify duplicates, draft concise maintainer replies, and prepare a small cleanup PR if the fix is straightforward. Ask before posting comments or opening the PR.

That session could spend donated compute on reviewing issues, checking related pull requests, summarizing repository state, and drafting a maintenance change for maintainer approval.

Claude Code: security review skill

For a focused security review, a maintainer might start:

opub run claude

Claude Code supports project skills and slash-command style invocations with arguments. Anthropic's security guidance also emphasizes review, permission controls, and maintainer approval before sensitive changes. A project could define a security-review skill and invoke it directly:

/security-review @path/to/file

The skill might ask Claude to inspect specific functions, look for boundary mistakes or unsafe external calls, flag risks with file references, and propose tests or patches. The maintainer still reviews the findings and decides what to apply.

In opub, the linked record would show funded compute was active for the project session. It would not show the reviewed code snippet, the private prompt, or Claude's response.

Codex, Vibe, and OpenCode: feature scoping

For planning work, a maintainer might start Codex with an explicit scoping task:

opub run codex -- "Scope a feature that adds keyboard shortcuts to the command palette."

OpenAI describes Codex CLI as a local coding agent that can inspect a repository, edit files, and run commands in the selected directory. A maintainer can use that same capability before writing code: ask Codex to read the project shape, identify likely files and tests, draft acceptance criteria, and propose implementation steps.

Mistral Vibe is a minimal CLI coding agent that brings the same kind of repository-aware session to Mistral models. A maintainer might run:

opub run vibe

OpenCode is an open source terminal agent with a full TUI, supporting many model providers. A maintainer might run:

opub run opencode

All three are good fits when donated compute should fund thinking and investigation — scoping a feature, reviewing a design, or drafting acceptance criteria — even when the session ends with a plan rather than a patch.

Continue: source checks

For lightweight review or automation, a maintainer might run Continue headlessly:

opub run continue -- -p "Review staged changes for obvious bugs" --silent

Continue documents an OpenRouter provider, MCP configuration, and headless CLI mode. opub uses those surfaces to inject the compute key, generate a local Continue config, and attach the same secretless project/session context used by other linked agents.

That makes Continue a good fit for PR review, bug checks, security notes, and documentation checks where the maintainer wants a concise result from the command line or a script.

Use anywhere

A compute key is a capped OpenRouter credential for opub's allowed model providers. It does not require the opub CLI — use it with any compatible tool, model playground, or custom workflow:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer <paste-one-time-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.4-mini",
    "messages": [{"role": "user", "content": "Summarize this repository."}]
  }'

Spend still accrues to the project balance. The difference is that without opub run, there is no linked session signal — opub records that tokens were spent, but has no session context connecting that spend to a specific project workflow. There is also no mechanism in opub that verifies what the key is used for in this mode.

Donors can weigh that against their trust in the project and its maintainer.

What donors can trust

When maintainers run sessions through the open source opub CLI, spend is also linked to a project session context. This is the optional, recommended path.

Donations add project balance, compute keys cap spend from that balance, and token spend is recorded against the project. For the examples above — Copilot CLI, Claude Code, local coding agents, and Continue — opub run links that spend to a session context, showing that donated compute was active on the funded project.

For direct key use, opub records the spend but cannot link it to a session. That is a known tradeoff. Whether it matters depends on the project and what its donors care about.

The linked session context is intentionally limited in all cases. It helps show that donated compute was used for the funded project without turning maintainer prompts, responses, files, or exact work into a public record.