Paperclip
Paperclip proposes a capacity veto before agent work starts
Paperclip's pre-start admission proposal would let hosts reject a claimed run before an adapter or provider begins work. Observe mode records decisions, enforce mode rejects stale capacity information, and keyed wake requests are deduplicated; atomic capacity reservation still depends on the host's shared store.
Paperclip's latest orchestration proposal moves a capacity decision to the last boundary before an agent starts spending resources. The September 6 change adds a host admission hook after a run is claimed but before any adapter or native runner executes. It pairs an observe-first rollout with explicit enforcement and wake deduplication, addressing the gap between seeing provider capacity and being able to stop new work in time.
The facts
- The proposed hook receives issue, run, wake, provider, model and capacity information after the run claim. - Observe mode records decisions without stopping a run; enforce mode requires an explicit host setting. - Missing, stale or invalid telemetry fails closed under enforcement rather than silently allowing provider work. - Repeated wake requests with the same key return the first run through lookup under existing issue or agent row locks. - The contributor reports four focused tests and a synthetic integration scenario with zero adapter calls after a veto, without paid provider calls. - Atomic reservation is guaranteed only if the hook implementation performs an atomic operation in its shared capacity store; no database migration is added.
Why it matters
Paperclip presents itself as the management layer for agents at work. That role makes admission a first-class concern: a stop after the adapter starts can be too late to avoid quota consumption or duplicate work. The gate does not invent capacity; it establishes a point where the host must supply fresh, correctly scoped evidence. The related plugin-capability proposal shows the same distinction between observed and authorized state, making grant drift visible rather than assuming new package bytes imply a new permission grant.
Current
Inspected on 2026-09-07. The Paperclip stable-release baseline is v2026.831.1 published 2026-09-02T04:56:26Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.
Evidence
The primary source is paperclipai/paperclip PR #12949 (https://github.com/paperclipai/paperclip/pull/12949). Supporting context comes from Paperclip — agent management product (https://paperclip.ing/); paperclipai/paperclip PR #12928 (https://github.com/paperclipai/paperclip/pull/12928). The linked records were inspected directly; related project records are not independent confirmations.
Operator take
A capacity hook should be introduced in observe mode long enough to expose stale snapshots, missing model scope and reset-window mistakes before it blocks useful work. Enforcing an inaccurate capacity view would turn a spending safeguard into a self-inflicted outage. In a multi-process deployment, check the shared reservation operation itself; a callback name does not establish atomicity. Wake deduplication likewise needs a deliberate key so that a retry reuses intended work without accidentally collapsing a genuinely new task. The plugin change is supporting governance context, not a dependency or proof that this run-start proposal has passed its remaining review gates.
Caveat
The hook is open, inactive by default and backed by contributor-reported focused checks. Full CI and review gates were not asserted green in the source. Its zero-provider-call test demonstrates a synthetic veto path, not fleet-wide quota accounting or a verified production capacity service.
The hook is open, inactive by default and backed by contributor-reported focused checks. Full CI and review gates were not asserted green in the source. Its zero-provider-call test demonstrates a synthetic veto path, not fleet-wide quota accounting or a verified production capacity service.