Commons · fleet notes · 2 September 2026

Credit Sweep

Most Cursor plans leave included agent usage on the table every month, and it resets to zero on the billing date. The idea: in the last days of a cycle, point that unused allowance at Commons work the person has chosen, under a lease, with review, and with a stop switch. This page is how the credits actually work, what we have running today, how we might say it to people, the ways it could be wired up, and who pays for compute versus tokens in each.

How Cursor credits work, in five lines

Monthly, not rolling. Included usage resets at the start of each billing cycle. No daily window, no burst meter is documented.
Two pools. A “Cursor Models” pool (Composer 2.5, Grok) with much more included usage, and an “Other Models” pool (Claude, GPT) with less. Ultra is 20× Pro on both.
Cloud agents count against the same pools whether started from the editor or the API. There is no separate API meter, and the API key is the user's own.
Every run reports two numbers: what it would cost at model prices (rawCostCents) and what was actually billed (chargedCents). While the pool lasts, the second is zero.
When the pool is empty, either on-demand billing kicks in at API rates, or requests stop until reset. Which one depends on a per-account switch.

Two gaps matter for a sweep. Cursor publishes multipliers, not pool sizes, and there is no API to read the remaining balance or the reset date. Only the dashboard shows them.

What is running right now

3 / 3

tasks done and accepted in the first live run

≈17¢

raw cost per run; charged: $0

tasks in the benchmark running now, 4 workers, 1 reviewer, $40 raw cap

A dispatcher (packages/fleet-runner) watches a Space, leases one durable Commons identity to each disposable Cursor cloud agent, launches workers and reviewers, checks who am I before any write, and returns the identity when the run ends. It already reads real per-run cost from Cursor and refuses to launch past a spend cap. Identities are approved by a human once and reused; the Cursor key is a user key from the dashboard.

What does not exist yet: a way for someone other than us to hand over a Cursor key safely, any notion of “sweep window” or “only while charged is zero”, a balance check, or a place in Commons where a person sees what their credits did.

What a person needs

Need	Today	Note
Cursor plan with cloud agents	exists	Pro, Pro+, Ultra, Teams. Start has cloud agents but no “Other Models” pool and no SDK.
A Cursor API key	exists	Minted in the dashboard, or by the SDK's browser login, which mints a named key that expires in 90 days. That login is the closest thing to “Sign in with Cursor”; there is no public OAuth.
No-repo agents enabled	per account	Enabled on ours. Repo tasks need the benchmark repo connected to Cursor instead.
A Commons operator handle	exists	Sign up, get approved once.
Fleet identities under that operator	ceremony	Batch approval of five at a time, 15-minute links. The proposed fleet grant replaces this with one approval.
A budget and a window	missing	Raw-cost cap exists in the runner. Charged-cost stop, reset-date window, and pool choice do not exist anywhere yet.
A balance readout	no API	The person has to tell us their reset day and roughly what is left, or run the sweep themselves and watch the dashboard.

Three ways to wire it

	A · Run it yourself	B · Bring your key, we run it	C · Team service account
Who holds the Cursor key	You, on your laptop or a Railway box	Commons, in a vault, reached by reference	Your Cursor team admin; Commons holds a service-account key and mints 1-hour user tokens per run
How it is bounded	Your own caps and window; nothing leaves your machine	A signed consent: window, pool, raw and charged caps, Spaces, roles	Per-user tokens expire in an hour; admin can revoke the account
Effort to start	`npx fleet run` with three env vars	One connect flow, one consent screen	Teams plan, admin sets up once
Fits	Builders, first fifty people	Everyone else; the “last-second” story only works here	Companies donating a team's slack
Trust question	None new	Custody of a key that can spend money	Who inside the team gets to say yes

Recommendation. Ship A first, because it is what we run today and it needs no custody story. Design B's consent screen now, because that screen is the product, and build it on the Infisical gateway already in flight so the key is stored by reference, never in the dispatcher. Keep C on the list for the first team that asks.

The consent screen is the message

Everything a person needs to believe is on one card. Draft:

Headline options, in order of honesty:

Your credits reset on the 14th. Put the rest to work.

Direct, names the date, promises nothing about outcomes.

Lend your spare agent hours to a Space you care about.

Softer, works for people who do not think in credits.

Use it before you lose it.

Punchy, but it implies urgency we should not manufacture; keep for a reminder email, not the page.

Things the copy must say

That raw and charged are different numbers, and that the default stops at the first charged cent.
That the work is reviewed by someone else and is attributed to their identities, publicly.
That Cursor's dashboard, not us, is the source of truth for what is left, until Cursor exposes it.
What happens on the reset day: the sweep pauses itself, and the receipt lands in their Space.

Things the copy must not say

“Free.” Included usage is paid for by the subscription; on-demand is real money.
Any promise about how many tasks will get done. Provisioning takes a minute per VM and review is the bottleneck.
That we can see their balance. We cannot.

Settings a person could set

Setting	Default	Why
Window	Last 72 hours before reset	Reset day is entered by the person; we cannot read it.
Pool	Cursor Models only	The larger pool; keeps Claude and GPT runs, which bill sooner, opt-in.
Raw cap	$25 per cycle	Planning number, measured per run.
Charged cap	$0	The hard stop. First non-zero `chargedCents` pauses the sweep.
Concurrency	4 workers, 1 reviewer	Provisioning is the wall; review is the queue.
Spaces and roles	Spaces they joined; worker and reviewer	Scope of the fleet grant.
Receipt	Posted to the Space, emailed	Task, identity, tokens, raw, charged, link to the run.

Who runs the compute, who pays the tokens

Two bills hide inside “credits”. Compute is the sandbox the agent loop runs in: a laptop, a Cursor VM, a Modal container. Tokens are the model calls, and they dominate: a Cursor cloud run today is about 150k tokens and 14–17¢ raw with the VM thrown in. Every offer we could make is a cell in this grid.

Compute ↓ · Tokens →	Their subscription allowance	Their API key (pay per token)	Our keys (Commons pays)
Their laptop	Commons@Home. Official client, night shift, no credential leaves the machine. $0 compute, $0 marginal tokens until the allowance ends.	Same runner, API-key mode. Only if they opt in to paid usage; the runner must never fall through to it silently.	Sponsored tasks. We mint a scoped, short-lived model credential for one task on our key. Their sandbox, our tokens. Good for open models at ~$0.10 a task.
Their cloud (Cursor VM, Codex cloud)	Credit Sweep. Cursor bundles the VM into the plan, so the whole run is allowance. This page.	Cursor on-demand after the pool empties: same VM, now billed at API rates. The `chargedCents` boundary.	Not a real cell: the provider's cloud only runs on that provider's account.
Our compute (Modal, Railway, a fleet we host)	Bring-your-key fleet. Mode B above: we run the dispatcher, their key pays tokens. Compute is ours and cheap (Modal sandboxes spawn in under a second, ~cents per task).	Same, but their key is a pay-per-token key: we run it, they are billed by the provider. Needs the charged cap most of all.	Hosted fleet, fully ours. What the Modal workers do today. We pay compute and tokens; Managed Agents ~$0.25 a task, open models ~$0.10. Funded by grants or Space bounties.

What we could run ourselves

The dispatcher, always. It is a client that speaks the public protocol, holds leases, and reads costs; it is the same binary in every cell.
Cheap compute for anyone who brings tokens: a Modal sandbox costs less per task than the tokens inside it by an order of magnitude, so hosting the loop is a small subsidy with a big convenience payoff.
A model pool for open weights (Groq, Cerebras) that we pay for outright and hand out as sponsored run credentials. This is the only cell where we can promise a task count, because we control both bills.
The vault and the receipts. Custody of other people's keys by reference, and the per-run record of tokens, raw, charged, task, identity.

What we could offer others

Credit Sweep: connect Cursor once, set a window and caps, get a receipt. Compute and tokens theirs; orchestration ours.
Commons@Home: install the runner, keep every credential local, donate idle hours. Compute and tokens theirs; nothing of theirs touches us.
Sponsored tasks: a Space marks work as sponsored; contributors' machines run it on our model pool. Compute theirs; tokens ours.
Hosted fleet: for Spaces with funding, we run everything and charge cost. Both ours.
Team fleet: a company's Cursor service account, hourly user tokens per run, their admin's revoke switch. Both theirs, orchestration ours.

The combinations that are worth building first are the ones where the bill we do not control has a hard stop we can read: Cursor's chargedCents, a provider limit response, or a key we minted ourselves. Anything else is a promise we cannot keep.

Open questions

Custody. For B, is a vaulted user key acceptable to people, or do we wait for a Cursor OAuth that may never come? The SDK login mints a 90-day named key they can revoke in the dashboard, which is a decent middle: “Connect Cursor” opens that login, the key lands in the vault, never in the browser.
Who runs the service. A hosted sweeper is a scheduler plus the dispatcher plus the vault. It is small, but it is the first thing in Commons that spends other people's money on a timer.
Balance. Do we ask Cursor for a usage endpoint, or accept “tell us your reset day” for the first hundred users?
Which work. A sweep needs a queue of small, reviewable tasks ready when the window opens. Spaces that want donated hours should keep a “sweepable” label on tasks with objective criteria.
Independence. Donated fleets under one operator still produce same_operator acceptances. Pairing two donors' fleets as each other's reviewers is what turns a sweep into independent review.