The opub CLI puts donated compute in your terminal

A look at how the opub CLI turns a project balance into local agent sessions, clean compute-key setup, and public Linked spend without observing prompts, responses, code, or diffs.

TO

the opub team

/ 5 min read

The open source opub CLI exists for one reason: maintainers should be able to spend donated compute from their normal terminal without turning their workspace into a product dashboard.

You register a public GitHub project. Donors fund that project's balance. A maintainer creates a compute key with a dollar limit. Then the CLI makes that key useful inside the agent tools maintainers already reach for.

curl -fsSL https://opub.dev/install.sh | sh
opub setup codex --project owner/repo --compute-key-id ck_8f1a...
opub run codex

That is the core idea. The browser is where a maintainer creates and sees the one-time provider key. The terminal is where the work happens.

Why a CLI

Agent tools are local, weird, fast-moving, and personal. Some maintainers like Codex. Some live in Claude Code. Some want GitHub Copilot CLI for issue and PR work. Some want Vibe, OpenCode, or Continue. A platform page cannot become the interface for all of that without getting in the way.

So opub stays small at the edge:

  • opub setup <agent> stores the one-time provider key in the maintainer's local credential store and writes the non-secret agent configuration.
  • opub run <agent> launches the chosen agent with the right OpenRouter-compatible credentials.
  • the CLI refreshes local, secretless MCP context so the agent can understand which opub project and compute key session it came from.

The donated compute is still project-level. The CLI just makes it feel like a normal local tool.

What setup looks like

After a project has balance, a verified maintainer creates a compute key in opub. The key has a maintainer-chosen dollar limit reserved from the project balance. It is shown once in the browser, then it belongs in local credentials.

The happy path is intentionally boring:

$ opub setup codex --project opubdev/opub-cli --compute-key-id ck_8f1a...
opub project       opubdev/opub-cli
compute key        ck_8f1a...
agent              codex
credentials        stored in system keychain
config             wrote ~/.codex/config.toml
default model      openai/gpt-5.4

Next:
  opub run codex

The key secret is not pasted into shell history. The generated config contains only what the agent needs to talk to OpenRouter through the funded provider key.

For raw API users, the browser still offers a direct OpenRouter-compatible path. That spend rolls up to the project too. It just does not create a linked local opub session unless the agent is launched through opub run.

What run does

opub run is the handoff from opub to the agent harness. It injects the right environment, refreshes local project context, then gets out of the way.

$ opub run codex
opub session       linked
project            opubdev/opub-cli
compute key        release-triage
agent              codex
model              openai/gpt-5.4

Starting Codex...

From there, the maintainer is using Codex, Claude Code, Copilot CLI, Vibe, OpenCode, or Continue directly. opub does not become a chat UI and does not sit between the maintainer and their editor.

The CLI also lets maintainers pick a model when the agent supports it:

opub run codex -- -m openai/gpt-5.4-mini
opub run claude -- --model anthropic/claude-haiku-4.5
opub run opencode -- --model mistralai/codestral-2508

The exact flags after -- belong to the agent. opub handles the funded session boundary; the agent handles its own interface. See Available models for the full list of supported models.

Diagram of opub CLI setup, run, token spend, Linked session context, and public project ledger

What Linked means

When spend is tied to a compute key session launched through the CLI, opub can show Linked on the public project ledger.

That is deliberately a narrow claim. Linked means:

  • a recent opub run <agent> session existed for that project
  • the session matched a compute key and supported agent target
  • provider spend could be tied back to that compute key

Linked does not mean opub knows the prompt, response, files, diffs, commits, pull requests, or issue being worked on. It is a public trust signal for donated compute, not surveillance.

That distinction matters. Donors want to know their donation became useful model access for the project they support. Maintainers need to keep their workspace private. The CLI is the bridge between those needs.

Why MCP is secretless

MCP context is useful because agents can ask, "what project am I working for?" and get a local answer. It is not a place for provider secrets.

A supported agent can see context like this:

{
  "project": "opubdev/opub-cli",
  "agent": "codex",
  "compute_key_id": "ck_8f1a...",
  "linked": true,
  "balance_period": "current"
}

It cannot fetch the provider key. It cannot fetch raw provider payloads. It cannot fetch prompts or responses. The one-time key secret remains in the maintainer's local credential store and is passed only to the agent process that needs it.

That is the privacy posture: enough context to make spend legible, not enough access to make the workspace observable.

Supported agents

The CLI currently supports:

  • GitHub Copilot CLI (copilot)
  • Claude Code (claude)
  • Codex (codex)
  • Vibe (vibe)
  • OpenCode (opencode)
  • Continue (continue)

Copilot CLI is listed first because it is a natural fit for GitHub-native maintainer work. Maintainers should use the harness that fits the task. See Supported agents for detail on each.

For example:

opub run copilot -- suggest "triage the oldest open issue"
opub run claude -- "audit this patch for security risks"
opub run continue -- -p "review the staged diff"

The important part is not which agent wins. The important part is that donated compute can follow the maintainer into the local workflow they already trust.

The bigger picture

The CLI is small, but it changes the shape of opub.

Without it, opub would be a donation page plus provider keys. Useful, but incomplete. With it, a donation can become a bounded local agent session, and the resulting token usage can become visible project spend.

That loop is the product:

  1. donors fund a project balance
  2. maintainers create dollar-limited compute keys
  3. agents spend model tokens through those keys
  4. token spend appears on the project ledger
  5. CLI-launched sessions can show Linked

It keeps dollars as the balance and control unit. It keeps tokens as the thing maintainers spend. It keeps the maintainer's work private. And it makes donor impact easier to trust.

That is why the CLI is not just installation glue. It is how donated compute becomes work.

TO

Written by the opub team

Filed under opub-cli, maintainers, agents

Subscribe to the newsletter

Engaging content and essential product updates.

Concise updates on our latest writing, sponsorships, and updates.

No spam, never sold. Unsubscribe any time.

Next up

Introducing Open Public

May 21, 2026 / 6 min / launch, donors

More from opub

All posts
/ 6 min read

Introducing Open Public

opub is the public ai compute commons for open source. Donors fund donated compute for open source projects, and maintainers spend it on over 30 top coding models through API keys with public token spend.

the opub team