Paperclip
Paperclip can spend 5–10 minutes re-downloading skills before every agent run
A Paperclip operator traced 5–10 minute agent-start delays to 579 GitHub-sourced skill files fetched sequentially on every heartbeat. The run used about four selected skills, but launch waited for the full company library to be deleted and materialized again.
paperclipai/paperclip issue #10285 is the inspected primary source: “GitHub-sourced skills: materializeRuntimeSkillFiles re-fetches every file sequentially from raw.githubusercontent.com on every heartbeat, blocking agent spawn 5-10 min.” The report names Paperclip 2026.722.0 and follows the launch path into materializeRuntimeSkillFiles. Runtime materialization removes each skill directory, then awaits one raw.githubusercontent.com fetch per file with no cache, concurrency, or unchanged check. On the affected instance, 137 skills included 27 GitHub-sourced packages totaling 579 files; a regional fetch averaged 0.93 seconds. Two observed runs waited about 8 minutes 15 seconds and 5 minutes 43 seconds before the agent process spawned, while first output arrived within a second after spawn. Across 198 heartbeats, median creation-to-output delay was 4.4 minutes, mean 8.7 minutes, maximum 2.2 hours, and 189 runs exceeded two minutes. The selected agent received roughly four skills, making most of the transfer launch-path waste.
The facts
- paperclipai/paperclip issue #10285 was created 2026-07-26T21:29:25Z and updated 2026-07-26T21:29:25Z; state is open. - paperclipai/paperclip returned 74804 GitHub stars, 4959 open issues, default branch master, and last push 2026-07-26T16:04:55Z. - Latest tagged-release baseline checked: v2026.722.0 published 2026-07-22T23:05:41Z. - The report names Paperclip 2026.722.0 and follows the launch path into materializeRuntimeSkillFiles. - Runtime materialization removes each skill directory, then awaits one raw.githubusercontent.com fetch per file with no cache, concurrency, or unchanged check. - On the affected instance, 137 skills included 27 GitHub-sourced packages totaling 579 files; a regional fetch averaged 0.93 seconds. - Two observed runs waited about 8 minutes 15 seconds and 5 minutes 43 seconds before the agent process spawned, while first output arrived within a second after spawn. - Across 198 heartbeats, median creation-to-output delay was 4.4 minutes, mean 8.7 minutes, maximum 2.2 hours, and 189 runs exceeded two minutes.
What changed
The report names Paperclip 2026.722.0 and follows the launch path into materializeRuntimeSkillFiles. Runtime materialization removes each skill directory, then awaits one raw.githubusercontent.com fetch per file with no cache, concurrency, or unchanged check. On the affected instance, 137 skills included 27 GitHub-sourced packages totaling 579 files; a regional fetch averaged 0.93 seconds. Two observed runs waited about 8 minutes 15 seconds and 5 minutes 43 seconds before the agent process spawned, while first output arrived within a second after spawn. Across 198 heartbeats, median creation-to-output delay was 4.4 minutes, mean 8.7 minutes, maximum 2.2 hours, and 189 runs exceeded two minutes. The selected agent received roughly four skills, making most of the transfer launch-path waste. The primary record was inspected with its timestamps, state, body, and adjacent project records. ClawCharts supplied the assignment list; it does not establish the claim.
Why it matters
Skills are supposed to reduce cognition cost, not become a preflight denial of service. Synchronous full-library refresh ties agent availability to CDN latency, fleet library size, and rate limits. It also makes scheduler timing and operator perception misleading because the run exists long before the worker does. The operational test is whether persisted state, visible control, and runtime behavior agree at the handoff where authority changes.
Current
Issue #10285 was open. The latest tag remained v2026.722.0. PR #5560 addresses authenticated import rate limits, not heartbeat materialization, while PR #9599 adds long-lived database and log checks to doctor. Neither inspected item proves the launch-path cache exists. Repository metadata, current issues and pull requests, release baseline, Hacker News discovery, and the rendered ranking row were checked. Weak search residue and historically used source spines were not promoted.
Evidence
The primary URL is https://github.com/paperclipai/paperclip/issues/10285. Supporting links are inspected current project records that establish implementation, adjacent direction, or boundary conditions. Dates, reproductions, test totals, and deployment observations remain attributed to their authors unless this brief explicitly says they were independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. Closure can reflect a documentation decision or triage outcome; it is not silently translated into a shipped code fix. Ranking explains why the project was scanned; it does not prove correctness, adoption, or package behavior.
Operator take
Measure run-record creation, skill-materialization start and finish, process spawn, and first output separately. Prefer hash-based unchanged skips and selected-skill materialization before adding concurrency; parallel waste is still waste, merely wearing running shoes. Preserve a before-state receipt and verify the narrowest invariant where state changes. Do not broaden permissions or delete state merely because the visible symptom is inconvenient.
Caveat
Public project records are mutable. Source state was captured at publication time, and later revisions may change status, scope, or evidence. No source here authorizes automatic mutation of a reader’s deployment.
Source inspected; source state, environment, and release boundary remain explicit.