What Paperclip gets right, and why I still run simple-lcp

Paperclip has 86,059 stars. I have a 304 MB container. When I went looking for whether I should throw mine away and adopt theirs, I found the usual answer: they are not the same thing, and the question I was actually asking was the wrong one. What follows is what Paperclip offers, what I offer, what I'm about to offer, and why I'd still pick mine for the setup most people reading this are running.

What Paperclip is good at

I want to be fair about this, because the parts of it that are good are genuinely good and none of them are things mine does.

Paperclip is an agent workforce platform. The unit of work is an issue, and the issue is a row in its own database: it has an owner, a status, a thread, a definition of done, and blockers. Two agents cannot grab the same issue, because the platform checks it out and locks it. When an agent claims a task, the platform wakes it on a heartbeat schedule rather than waiting for a human to kick it. It ships 16 adapters, so almost any runtime can be hired into it, including a remote Hermes agent over HTTP. On top of that it has approvals, an audit log, an org chart with roles and permissions, per-agent cost caps that stop the agent mid-flight, and multi-tenant companies with data isolation.

If you are running a team of agents doing parallel work and you need to know who owns what, and you need a review gate before anything lands, that is a real product doing a real job. It shipped its first commit in March and it has 5,735 open issues, which tells you both that it is moving fast and that it is large enough to have its own weather.

What it costs you

Also fair: all of that has a price, and not just in dollars.

Most of the install is vendored SDKs for the runtimes it can hire. The OpenAI package alone is 370 MB, Anthropic 224 MB. You pay for all 16 adapters whether you use one or none.

Two sharper costs, both measured on a real install I stood up:

Its cost caps do not work on a remote runtime. This is the feature I most wanted, and the one I most expected to lose. Paperclip captured my agent's token usage correctly and reported costStatus: unpriced, biller: hermes_gateway, model: unknown, and spend of $0.00 across three runs. A cap cannot bite a number the platform does not have. If your agent runs on a runtime whose pricing Paperclip does not know, you get the dashboard without the enforcement.

The agent could not finish its own task. I gave it one job: report load and disk, write a proof file, touch nothing else. It did the work and reported the output, and then the issue stopped at blocked with the message "Paperclip needs a disposition before this issue can continue." The agent had no Paperclip credentials on my host, so it could not mark its own issue done. That is a wiring problem and probably a solvable one, but it is the difference between adopting a governance layer and adopting one that half-works until you finish the integration.

And the structural one: it becomes a second source of truth. Now your tasks live in its Postgres and your agents live in your harness, and every question about what actually happened needs both.

What simple-lcp is

simple-lcp is the admin panel for an LLM harness. Not an agent workforce. A control plane over the models, providers and lanes you already run. Six things, and I try not to let it become a seventh:

1. Define profiles, so a lane of work has a purpose
2. Point those profiles at a pool of providers and models
3. Declare what each model can do
4. Set routing and circuit-breaker behaviour
5. Set gates and budgets, so nothing is spent before it is approved
6. Show what happened, as diagrams rather than log dumps

It is one container, one port, SQLite that was already on the box, and it has routed 57,223 requests for me, 38,925 of them on the lane my own agent runs on.

The part that earns its keep is routing. Over a two-week window it made 24,417 automatic decisions, and the dominant one move was switching my main lane from one provider to another 12,036 times. That move is worth having: comparing the two providers on identical models, one ran at 688 TPS for $0.0178 a request and the other at 314 TPS for $0.0332. Roughly 2.2x faster and 1.9x cheaper, chosen automatically, per request. There is also a free local lane in the pool, and in two weeks it took 4,454 requests at zero cost.

That is the whole pitch. It does not manage agents. It manages what the agents spend, where the requests go, and what happens when a provider dies.

What I'm building next

This is where I'd want someone comparing the two to look, because the roadmap is pointed at the gaps Paperclip leaves open for a single operator.

A real gate. Right now LCP alerts when a profile crosses a budget and lets the request through. The next version evaluates a preflight before releasing anything to a provider: does the model support what this request needs, is the provider breaker healthy, is there budget headroom, is the provider's balance above its floor, is the intent confident enough. Verdicts are pass, downgrade to a named cheaper lane, or deny with an explicit error code. Never a silent pass.

Deterministic routing, with the noise deleted. Intents are declared per profile now, and the margin gate is built: when the gap between the top-scoring intent and the second is under the gate, the system keeps the static order instead of pretending it made a decision. What is still open is making the ordering itself fully deterministic and replayable, verified with property tests rather than examples. The problem is measurable: the median margin is 0.0236, 39.4% of decisions land under 0.02, and the winner on a two-character message was casual_chat, whose exemplars are literally "hello" and "thanks". It scored the request that asked for this change planning 0.7998 against agentic_multi_step 0.7913 — a margin of 0.0085.

Balance-aware ranking. Provider balances are fetched today and then ignored when choosing a lane. If I have two paid subscriptions, the one with the most headroom should win, and that is not the same rule as "fail over when one runs dry."

Alerts and budgets per subject. Provider, profile, API key. On their own pages. A budget that lives on the profile page cannot tell you the difference between a lane burning money and a key that has not been used in a month.

Observability as diagrams. Per conversation: which gate ran, what the router chose, what each lane's balance was, what it cost, what it produced. All of those fields already exist in the database. The work is joining and rendering them.

Declared capabilities instead of in-app benchmarks. Running benchmarks from inside a control plane was a mistake and I have already removed the import path. You declare what a model can do, then route on it.

Intents that bring in help. Today an intent picks a lane. The plan is that an intent can also pull another profile into the task at hand — the profile that declares it is for that kind of work, so a request that turns out to be an architecture question brings in the architecture lane, not merely a different model. LCP decides and records the trigger; the runtime that owns the agent executes it. That boundary is the whole design: the moment the control plane holds an agent's output, waits on it and closes its task, it has become the work surface I just said it is not. This one waits on the gate above, for a concrete reason — it scored a request asking for exactly this feature planning 0.7998 against agentic_multi_step 0.7913, a margin of 0.0085. A coin flip should not be able to summon an agent.

Three of those are done: the profile-first UI went from 9 sidebar entries and 15 pages to 5 pages, the redundant copy of every conversation was stripped out of the database (158.8 MB to 28.6 MB, 130 MB reclaimed), and the work surface is on its way out of the core and into an optional module. Everything above runs in the AGPL-3.0 repo, and staging has run from it since the fork.

So which one

If you want a workforce, take the one with a workforce: issues, owners, blockers, approvals, review gates, and agents waking themselves up. That is Paperclip's whole job and it is a lot more product than I have. I would not try to build it into mine.

If you run one harness, or three, and what hurts is that you cannot see where the money goes, you cannot prove which provider is actually better, and one provider's bad day takes your agent down with it, then you do not need a second database and 66,146 lines of Rust. You need routing, a spend gate and a diagram. Pick the small one, keep it on your own box, and read every line of it if you want to.

Paperclip will outgrow me on features and probably on stars. I am not trying to win that race. The control plane should be the boring part of your stack, and a boring part fits in 304 MB.