Agents now get a boss, a task queue and a budget. Do you need one if you already work in Claude Code?

"If you have one agent, you probably don't need Paperclip. If you have twenty — you definitely do." That is not a review or a paraphrase. It is a line from the README of Paperclip itself, an open-source server for orchestrating AI agents, in the section on what the project is not. It is rare for authors to say on the first screen who should not install their product.

Most of our readers sit somewhere between one and twenty: two or three Claude Code terminals, Codex in the next window, a couple of scheduled jobs. That is the crowd for whom Paperclip showed up on GitHub Trending on 26 September with the largest daily gain in the top five, 2,109 stars in a day on top of 85 thousand.

What Paperclip is and what it is not

Paperclip does not write code and does not ship a model of its own. It is not a framework for building agents, and it is not a drag-and-drop pipeline builder. The authors put it in one sentence: "If OpenClaw is an employee, Paperclip is the company". The agent stays what it was; Paperclip gives it a job title, a manager and a queue of work.

Agents connect through adapters, and there are more than ten out of the box: Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Pi, Grok, Kimi Code, OpenClaw through a gateway, plus Process for any command and HTTP for a service behind a webhook. The hiring rule in the README is short: "If it can receive a heartbeat, it's hired". Anything that can wake up on a signal can go into the org chart.

On top of that layer sits what people usually assemble by hand in a folder of config files: company goals, projects, tasks with dependencies, approvals, an activity log, and spend tracked per agent, per model and per project.

What an agent's working day looks like in Paperclip

An agent in Paperclip does not live in an open window. It wakes up on a heartbeat, meaning on a schedule, or on an event: a task was assigned to it, someone mentioned it in a comment. Once awake, it takes a task from the queue. Checkout is atomic, so two agents never start the same piece of work. Every task carries the chain "task → project → company goal", so the agent sees not only the title but also why the work exists.

For Claude Code the most useful part is that the session does not reset. The adapter stores the session ID and resumes it on the next heartbeat as long as the working directory is the same. A task started in the morning continues in the evening with the same context, not with a "let me remind you what we are doing" recap. The README describes exactly this pain: twenty tabs, and after a reboot everything is gone.

Recurring work is handled by routines: a task on cron, on a webhook or on an API call, each one producing a tracked ticket. It resembles what Anthropic built on its side when it shipped routines that start Claude Code on a schedule and on PRs. The difference is scale: there it is one agent in Anthropic's cloud, here it is any mix of agents on your own server.

Release v2026.916.0 from 16 September (503 commits from 15 contributors) added two notable things. Connections: Claude and Codex subscriptions and API keys now live as managed accounts with access rights instead of being configured per agent. And the experimental AgentMail: an agent gets its own inbox, and an incoming email becomes a task.

How to try Paperclip with Claude Code or Codex

For a first look you do not need to install anything permanently. The test-drive command spins up an isolated instance in a temporary folder with a CEO agent already created and opens the browser:

# requires Node.js 24.11 or newer
ANTHROPIC_API_KEY=... npx paperclipai test-drive
# or with Codex instead of Claude Code:
OPENAI_API_KEY=... npx paperclipai test-drive --harness codex

For a permanent setup there is install.sh with checksum verification. It puts the CLI in ~/.paperclip/cli, runs onboarding and can register Paperclip as a background service on Linux and macOS. Locally everything runs in one process with an embedded Postgres.

1. 1

   Set a goal

   one company-level sentence: agents derive their tasks from it and understand why they are doing them

2. 2

   Hire two or three agents

   for example Claude Code for code and Codex for review, each with its own role, manager and working directory

3. 3

   Set budgets right away

   before the first heartbeat: a monthly cap for the company and a separate one for each agent

4. 4

   Watch the queue, not the terminals

   work, approvals and spend show up on one dashboard, including from your phone

One setting worth changing right away: telemetry is on by default. Turn it off with PAPERCLIP_TELEMETRY_DISABLED=1 or the standard DO_NOT_TRACK=1.

What the budget promises and where it actually kicks in

Paperclip builds its main promise on budgets. The README says: "When they hit the limit, they stop. No runaway costs". The documentation goes further: an agent will not spend a cent more than you allowed. The mechanics are simple: at 80% of the cap Paperclip posts a warning, at 100% it pauses the agent, and no new heartbeats start.

The "not a cent" wording does not survive the adapters page. Spend is recorded when the adapter reports the cost, and it usually does that after the run finishes. A single Claude Code run is capped at 300 agent turns by default, and on a local machine it has no time limit at all by default.

The conclusion is ours, not the authors': the hard boundary sits between runs. An agent with 5% of its budget left can start a long run and finish it past the cap. That protects you from a multi-day loop burning hundreds of dollars. It does not protect you from one expensive run.

The second gap concerns subscriptions. If Claude Code runs on a Pro or Max subscription, Paperclip shows the quota windows (five-hour and weekly) and treats the subscription cost as an estimate until it is reconciled with the bill. When a token price cannot be determined, as with a local CLI, the event is recorded with no amount and marked unpriced. The budget, meanwhile, is counted in dollars. The documentation does not say directly how the two fit together; on a subscription we would watch the quota windows rather than the dollar bar. We looked at how a subscription limit drains on long context when we covered Claude Code's weekly limits in September.

One last thing: the Claude Code adapter runs the agent with dangerouslySkipPermissions: true by default, because it works with no human at the terminal. That is fair for headless mode, but it means you should pick the agent's working directory as if it can do anything in there.

What we are taking for ourselves

The core idea, that you manage an agent through a task rather than a terminal window, strikes us as right. A queue with atomic checkout, a session that survives a reboot, and a goal that travels with the task: that is exactly what people otherwise build by hand, and badly. If you first just want to see what your agents are doing, without a whole org chart, there is a lighter option: a pixel office for Claude Code agents right inside VS Code.

Our opinion, and you can argue with it: the payoff threshold is not at twenty agents, as the authors write, but at the point where work runs without you. Three agents that start on a schedule and overnight already need a queue, a budget and a log. Twenty agents that you launch by hand and watch in the terminal can do without Paperclip. We are wrong if your main risk is two agents colliding in the same repository: then atomic task checkout pays off sooner than scheduling does.

Every heartbeat sends the agent's context to the model again, and cost grows with more than the number of agents. We measured how much the wrapper around the model adds to the bill when comparing Claude Code, Codex and Pi on cost. In Paperclip that arithmetic is multiplied by heartbeat frequency: an agent that wakes every 15 minutes makes roughly four times as many calls as an hourly one.

Versions as of 26 September 2026: Paperclip v2026.916.1, 85,419 stars on GitHub. The project moves fast, so check the current adapter and budget settings in the documentation.