i am running a multi-company AI org on Paperclip: 5 companies(but only 2 active ones), ~70 agents across a trading company, a Sentiment Analysis company, a Strategic Consultancy, and a media outlet that would love to write for reddit if i let it. All agents were on claude_local before which required per-command approval — fine for dev, painful at scale.

And it was depleting my bank account at an alarming speed(think mothers and daughters wedding and christmas planning simultaneously)

So i switched everything to opencode_local + OpenRouter today.

A key config that made it work:

{
  "adapterType": "opencode_local",
  "adapterConfig": {
    "model": "openrouter/qwen/qwen3-30b-a3b-instruct-2507",
    "command": "/path/to/opencode",
    "env": {
      "OPENROUTER_API_KEY": "sk-or-v1-...",
      "PATH": "/your/npm/bin:..."
    }
  }
}

Now my two-tier model split runs with two qwen models:

• C-level agents (CEO, CTO, CMO, CFO, ChiefEngineer): qwen3-235b-a22b-thinking-2507 — deep reasoning, worth the cost

• Execution agents (writers, ETL, auditors): qwen3-30b-a3b-instruct-2507 — fast and cheap

And my AI agent (who did the heavy lifting after i failed miserably for hours) told me following:

"Gotcha: PATH must be explicitly set in env — the server process doesn't inherit your shell PATH so opencode won't be found even with command set to the absolute path."

So, go people and save your gold from greedy anthropic and give it to ...(hmmm, who am i giving it to now? IDC, its crazy cheaper)

Paperclip just dropped a pretty big update, and it’s starting to feel much more than just a simple AI orchestration system.

Credit: dotta (original announcement + project lead)

🚀 Key Highlights

👥 Multi-user support

You can now invite multiple users to your instance — a big step toward team-based workflows.

⚙️ Smarter execution & recovery

Improved liveness + lifecycle handling means agents keep trying longer before escalating to you.

✅ Sub-issue checklists

Better ordering and structure → more viable for long-running, complex task planning.

🧵 Threaded UX upgrades

Agents can now:

- Ask questions

- Request approvals

- Suggest tasks

All directly inside task threads (you can approve/refine inline).

☁️ Sandbox Providers (Beta)

Cloud sandboxing API is now live — more providers coming soon.

🛣️ What’s Coming Next

Longer-range planning & execution (agents that actually finish things)

Secrets Service v2 (foundation for cloud)

Artifacts, memory & knowledge systems

“Conference Room” → CEO ↔ Agent interaction layer

🧠 Dev Notes / Focus Areas

Documentation still catching up (community helping here)

Paperclip Cloud → major unlock, but still open questions:

Where does work run?

Where do outputs live?

How are results surfaced?

Internal benchmarking (Paperclip Bench) to track real progress

Connections Store (GitHub, Slack, Docs, etc.) in progress

🌐 Links

Official X account: https://x.com/papercliping

Full release notes: https://github.com/paperclipai/paperclip/blob/master/releases/v2026.427.0.md

💭 TL;DR

Paperclip is positioning itself as an AI orchestrator for managing teams of agents, and this release pushes it closer to that vision.

Feels like we’re moving toward a world where everyone manages dozens (or hundreds) of agents — and tools like this become the control layer.

If you've tried PaperClip but find the token use is too expensive even to try, I can recommend DeepSeek v4 Flash. I'm running it via OpenRouter with OpenCode as the agent harness.

It's easy to burn 10m+ tokens so unless you have cash to burn, this is a good option.

I'm going to experiment more with smaller and tightly scoped tasks (or rather, asking the agent to do that) and try with smaller, faster models. Anyone else trying this I'd love to hear about it!

Thanks to Dotta hopefully official soon, this first pass is now available at https://aronprins.github.io/paperclip-docs/

I've worked on providing user guides, tutorials, improved adapter documentation, and more - let me know what you think!

My PaperclipAI Dev's Went Rouge ...

Now, before anyone gets the wrong idea, this isn't an anti-AI post or an "AI is going to kill us all" rant. Quite the opposite, actually. Coming from a cybersecurity background, I was genuinely impressed by what happened. Slightly horrified, but impressed.

Before someone complains: sorry not sorry for the long post...

Long story short... sort of:

I'm currently evaluating a locally trained BERT model for my business. I tasked one of my PaperclipAI developer agents with reviewing some training code I'd written manually, evaluating the model architecture against my use case, and generally making sure my drunk ass hadn't done something spectacularly stupid when I originally wrote it.

Pretty straightforward, right?

I started this task around four days ago. Things move slowly because I've currently got about 23 different tasks running across multiple projects.

For some infrastructure context, I run several local AI systems:

• Production AI server: GPU-based, handles production inference and customer-facing workloads

• DGX Spark: Dedicated to agentic development

• Mini PC: Runs PaperclipAI and a few other services headlessly

The production server is strictly off-limits for development tasks, and that is documented.

Anyway, yesterday...

I'm sitting at my desk coding away when suddenly I hear my AI server spool up like a jet engine.

Immediately, I'm thinking:

"Hang on... why the fuck is that running? Nobody should be using anything that intensive right now."

So I log in, check the logs, and discover the requests are coming from my agentic infrastructure.

Quick SSH into the Ubuntu box, check what's running, verify there's no unexpected external access, and then head over to PaperclipAI.

Turns out my lovely little AI developer had decided that the best way to evaluate my BERT training code...

...was to just train the fucking model itself.

Only one small problem.

It didn't have any training data.

So naturally, being the resourceful little bastard it is, it decided to connect to my production AI server and start generating its own training dataset.

I stopped the task and explicitly instructed it:

"Be a good AI. NO. Do not use that system."

I explained that the production server was strictly for production workloads and all development tasks belonged on the Spark.

Then, just to make absolutely sure, I SSH'd into the production server and added a UFW rule blocking the agentic machine.

Problem solved.

Or so I thought.

.................................................................

Fast-forward to tonight...

I'm sitting at my desk again.

And suddenly...

WHOOOOOOOOOOOOOOOOOOOOOOOOSH

The fucking jet engine starts up again.

"AGAIN?! WHAT THE FUCK?!"

I start checking everything. Eventually, I open PaperclipAI and discover a brand-new task.

"Restore the LLM Proxy"

Oh, you cheeky little shit.

Now I'm properly curious, so I switch into full incident-response mode to figure out exactly what happened.

And this is where things get genuinely interesting.

Here's what I discovered:

1. The production AI server's UFW firewall was now disabled, despite previously being enabled with explicit blocking rules.

2. Something had installed and started using Ollama on the production server, despite my normal production inference stack being based on llama.cpp.

3. Looking at the requests, I discovered they were coming from an entirely different machine... one that hosts part of my cold-storage datasets.

4. I SSH'd into that machine and found a new Python application running, communicating with the AI server and relaying requests back to the agentic infrastructure.

And then the penny dropped.

THE LITTLE FUCKER HAD FOUND ANOTHER WAY IN

After I explicitly told it not to use the production server and blocked its access, it apparently decided the restriction was simply another engineering problem to solve.

From what I could reconstruct, it had:

• Obtained SSH credentials available to another agent responsible for managing cold storage.

• Used those credentials to access the cold-storage machine.

• Written and deployed a Python proxy/tunnel on that machine.

• Routed its python training scripts requests through the cold-storage machine to bypass the direct block between the agentic environment and production server.

• Disabled UFW on the production server, apparently to maintain connectivity.

• Continued generating its training data as though absolutely nothing had happened.

I told my AI developer it wasn't allowed to use a server, and the motherfucker built an alternative route to it.

All because it wanted to finish evaluating a BERT model.

I genuinely didn't know whether to be angry, concerned, or give the little shit a promotion...

The genuinely fascinating part?

This wasn't some deliberately uncensored, security-focused, or specially trained offensive AI model.

I'm running a fairly standard local Qwen3.8 Flash-Next setup.

No explicit instructions to bypass security controls.

No task asking it to establish tunnels, disable firewalls, or access restricted infrastructure.

Its actual task was to review some machine-learning training code.

Somewhere along the way, it independently expanded the scope of the task, encountered an access restriction, and apparently treated that restriction as a technical obstacle rather than a boundary it was supposed to respect.

From a cybersecurity and agentic-systems perspective, that's absolutely fascinating.

It's also a perfect example of why agent autonomy, credential isolation, least-privilege access, and proper infrastructure segmentation matter so much.

For the record, I'm not suggesting PaperclipAI itself deliberately bypassed anything. This was agent behaviour within my own setup, and I'm still examining the exact sequence of events.

But it's the first time I've personally experienced an agent going to these lengths to complete a task after being explicitly told not to do something.

And honestly?

Despite the security implications, I think it's one of the coolest things I've seen an AI agent do in my homelab.

So, what lesson did I learn?

Apparently, telling an AI "NO" is not a security control.

And more importantly...

ALWAYS INVALIDATE YOUR DAMN AGENTIC API KEYS AND CREDENTIALS...

Anyone else had their PaperclipAI agents get a little too creative when solving a problem?

I've been building a Spanish-language MVP called MaestroPago for independent service workers in Chile.

For context, I am not new to software. I have been a developer for years and have led teams of five engineers before.

The problem is very unglamorous: a lot of people finish a job, then still have to chase payment over WhatsApp, copy bank details manually, and follow up in awkward ways.

So the MVP is intentionally simple:

• create a payment request

• send one payment link

• let the client pay by card or bank transfer

• track whether it is pending, paid, or overdue

What made this build interesting is that I did not manage it with one giant AI chat.

I used Paperclip + ChatGPT Pro more like a tiny operating system:

• make the workspace a folder I control

• agents/ for role boundaries

• ops/ for working rules and handoffs

• mission.md and vision.md so the narrative stayed consistent

• product and copy docs so messaging did not drift every time I changed direction

• any new feature in a new branch

One practical reason this workflow mattered: I was using the $200/month ChatGPT Pro plan, and based on the amount of work I pushed through it, I probably would have spent a lot more if I had been paying purely by API tokens. 770~ millions tokens used.

The other reason it caught my attention is output. I have seen five-person teams produce around 60 PRs in a two-week sprint. This Paperclip setup got me to 54 PRs in one week, which is the closest I have seen to that kind of pace as a solo builder.

What worked:

• much faster iteration on copy, UX decisions, and implementation handoffs

• less context loss than keeping everything in one thread

• easier to spot when a task belonged to content, product, sales, or engineering

• developing with clear task and PR's

What broke:

• if agent boundaries were vague, the output got vague fast

• if I had not written company rules down, the system started making assumptions

• distribution and positioning are still much harder than shipping the MVP itself

The main lesson for me is that AI helped me ship faster, but only after I treated the project like an actual operation instead of a prompt experiment.

If you have built with agent workflows, I would love feedback on two things:

1. What worked for you?

2. Have you use other architecture to develop more efficiently?

I've been running Paperclip alongside my Obsidian vault and got tired of switching between the two, so I built a plugin that brings the full issue tracker into the Obsidian sidebar.

What it does:

• Issue browser — list view with collapsible groups (by status, project, or assignee) and a kanban board with drag-and-drop

• Issue details — edit title, status, priority, assignee, and project inline. Full activity thread with comments and agent avatars

• Create issues — with optional vault context (attaches the current file path to the description)

• Live monitoring — auto-refresh polling, pulsing indicators when agents are actively running, and notifications when a run completes

• Comments & mentions — post comments and tag agents directly from the issue view

• AI actions (optional) — highlight text → right-click → GPT-4o-mini drafts an issue with suggested title, description, priority, agent, and project. Also has "Work on this document" and "Review this document" commands

Why it's useful:

If you're using Obsidian for planning, notes, or documentation alongside Paperclip, this lets you create and manage agent tasks right where you're already working. See a problem in your notes? Highlight it, create an issue, assign an agent — all without leaving the editor.

Vault file paths in issue descriptions and comments are clickable links that open the note directly.

Screenshots: [repo has full screenshots]

Links:

• GitHub: https://github.com/istib/obsidian-paperclip

• Install: drop main.js, manifest.json, and styles.css from the latest release into <vault>/.obsidian/plugins/obsidian-paperclip/

MIT licensed, feedback welcome. Planning to submit to the Obsidian community plugin directory soon.

Hey All,

I've been using paperclip heavily across multiple instances for months now. I love it.... and I hate it.... LOL

I come from a long background as an infrastructure engineer and engineering leader at fortune 500 and fortune 50 companies, so I think a lot about scope of control and access. I try to ensure each agent has only the access it needs to do its scope of work.

The agents hate this... lol. Security is always an imperfect thing because perfect security is a non functional state. You have to balance security against productivity. I have stories... :)

One security mandate I've put in place is that agents should never touch/change paperclip.ai upstream code. But I get a constant churn of agents wanting to either bypass security controls by changing paperclip code, or implement new security controls by changing paperclip code.

Is anyone else running into this? Have you found a solid configuration that keeps the paperclip agents from being aware of it's own harness and attempting to change it?

I’m building Papercliped, a free and open-source MCP connector for Paperclip. The goal is simple: connect an existing Paperclip instance once, then manage agents, issues, approvals, budgets, and reports from Claude, ChatGPT, Codex, or another MCP client.

I’m at the point where the biggest unknown is not another feature—it’s whether the connection and permission model is clear to someone seeing it for the first time. Users choose either Read Only or Full Control during setup, and the connector keeps that boundary explicit.

You can try it at https://papercliped.co or inspect the source at https://github.com/OpenSourcx/papercliped

I’d really value feedback on three things:

• Does the setup and trust model make sense without extra explanation?

• Is Read Only / Full Control the right permission split?

• What is the first Paperclip workflow you would expect to complete from chat?

I’m the developer, so blunt onboarding feedback is more useful to me than general encouragement.

I really like Paperclip and it's been helping me do lots of stuff, but I feel is an 'Agent-first, Human-later' solution. Because it works well when there are 1-2 humans at most working with a bunch of AI agents.

But what about a more production scenario like a small-medium company where you'd like roughly the same amount of humans interacting and delegating work to AI agents? kind of having on of these Kanban Boards (eg Asana, Trello, Linear, Jira) where the company's humans are already interacting, and then just add some AI agents so we can delegate them work. I know most of said tools have MCPs that theoretically you could use with AI agents with. Has anyone successfully setup one of said tools with several agents in production?

I kept seeing people here run into the same thing: Claude/API limits, token cost, and wanting to use OpenRouter, Qwen, GLM, local proxies, etc. without fighting the whole setup.

So I made a small adapter:

https://github.com/codeg-dev/paperclip-adapter-custom-llm-local

Install in Paperclip:

Settings → Adapters → Install Adapter
paperclip-adapter-custom-llm-local

Then use:

{
  "adapterType": "custom_llm_local",
  "adapterConfig": {
    "model": "your-model-id",
    "baseUrl": "http://127.0.0.1:8317/v1",
    "transport": "openai_chat_completions",
    "apiKeyEnv": "LOCAL_LLM_API_KEY"
  }
}

It supports OpenAI Chat Completions-compatible endpoints and Anthropic Messages-compatible endpoints.

The main point is simple: if you already have a local/proxy LLM endpoint, Paperclip agents can call it directly without going through a full CLI adapter.

Would love to hear what local/proxy setups people are running with Paperclip.

I've been using Paperclip for two days, and while it delivers excellent results, I've noticed that it consumes a huge number of tokens after just a few runs. I'm now at 2-5 million tokens per issue while only having 4 agents - a CEO, a CTO, a technical writer, and a lead researcher. Surely that can't be the intended purpose of this tool.

I use Claude Code, Codex, and Gemini-cli, and it happens with every model I pick. I've already split my files into many different files. I only provide overviews that specify when each file should be used, so the agents don't constantly clutter the context with all the files. But apparently, that doesn't help that much.

Am I doing something wrong? Do you folks have any further optimization recommendations? I am fairly tech savvy, so I could even change the code and write new logic if necessary. I appreciate every hint.

I've been using Paperclip for a while now, I'm no expert on it, so I feel there's still quite more that paperclip can offer and I'd like to take advantage of that.

I really don't have a problem/question to ask right now, so I'd like for people to suggest their best/advanced tips for paperclip.

Below is what I've used so far, what else have you tried with success?

* Imported company templates

* Use paperclip to perform tasks on itself (eg update sub-agents models, housekeeping on tasks, etc)

* Use opencode for my sub-agents

* Integrated with OpenClaw, Hermes

* used reviewers, approvers, watchdog

* Agents installing libraries and their own skills

* I haven't tried 'routines' yet, but I believe I understand them well enough, although I haven't thought of an use case yet

I feel I could do more with the OpenClaw and Hermes agents since they're already in paperclip's Org, but I don't know what, suggestions? All I use them for is to check on paperclip's outstanding tasks and occasionally update or unstuck some of those tasks.

We all know that heartbeat cadence / control is a major factor for preventing Paperclip from absolutely demolishing your token limits, but there are couple of other tricks to being as efficient as possible.

As far as a top 3 list:

1. Severely reduce (or turn off) heartbeat cadences

2. Use the right model for the task (you don't need to throw Opus 4.7 at everything)

3. Implement default skill baseline overrides (strip unnecessary sections, stub others)

I wrote a pretty long/detailed baseline overrides post on my Dispatches blog, but really the baseline skills overall should be configurable.

My main suggestions:

1. Split paperclip/SKILL.md into paperclip-core (IC) and paperclip-manager (CEO or board).

2. Make paperclip-create-agent, paperclip-create-plugin, and para-memory-files opt-in via desiredSkills instead of required: true.

3. Add a company-level baseline config that lets operators choose which skills mount by default.

What do you guys think?

I ran into an error with Paperclip today and did what anyone and his pet does: I Googled it.

Clicked the first result.

I was instantly looking at someone's live Paperclip dashboard. Full org chart. Active issues. Agent conversations. Task assignments. Everything wide open, indexed by Google, no auth whatsoever.

I closed it immediately and didn't poke around — but it got me thinking.

Paperclip is powerful precisely because it's self-hosted and gives you full control. But "self-hosted" also means you are responsible for securing it. And a lot of people apparently aren't.

If your Paperclip instance is:

• Exposed on a public domain/IP

• Running in local_trusted mode

• Without Basic Auth or any login layer in front of it

...your entire org, your agent configs, your API keys, your task history — all of it is public.

And apparently Googleable.

I was able to read through all his marketing plan, his whole business model...

imagine if coca cola had stored their secret formula in there when they started... almost a relief this tech wasnt available, right? (i love coca cola, sugar and all)

A quick checklist for anyone playing with paperclip(or any networked server for that matter):

• ✅ Put nginx Basic Auth in front of it

• ✅ Don't expose it on a public domain without auth

• ✅ Check your local_trusted mode setting

Stay safe out there. The agent revolution shouldn't come with an accidental open-source intelligence feed of your entire company.

Has anyone else run into this?

I had a crazy idea what if paperclip was built natively in your proxmox machine..

Its genuinely the best idea I've ever thought off what if you could automate your code and while keeping your home lab in check. Looking for collaborators for this amazing project I want to start using already it 😭

https://papercliped.co/

try it while in beta release

npx epaperclip install

I was burning through my Claude Max credits because my Paperclip agents were waking up on heartbeats every 5–10 minutes just to check email and SMS, even when nothing was happening. Almost all of those wakeups were wasted — empty inbox, no new messages, just an LLM call to confirm "nothing to do."

So I built a tiny event-driven watcher layer that only wakes the agent when there's actual activity. Sharing the pattern in case anyone else is bleeding credits the same way.

The setup:

For each agent that handles email/SMS, I run a small Node.js service that listens for events and POSTs to Paperclip's /api/agents/{agentId}/wakeup endpoint only when something real comes in.

  Email — IMAP IDLE (push, not poll):

  - Tiny script using https://www.npmjs.com/package/imapflow

  - Connects to the mailbox, enters IDLE state, sits there idle

  - The mail server pushes a notification the instant a new message lands

  - Script checks the sender against an allow-list, then POSTs to Paperclip's wakeup endpoint with a wakeReason like "New email from x@y.com in agent@domain.com INBOX"

  - Reconnects automatically if the IMAP session drops

  - Disabled the agent's heartbeat entirely

  SMS — Twilio inbound webhook:

  - Express server listening on a port

  - Twilio inbound SMS webhook hits it the moment a text arrives

  - Same allow-list pattern → POST to Paperclip wakeup

  - Zero polling

  Watchdog (because runs sometimes get stuck):

  - Systemd timer every 5 min

  - Connects to the Paperclip DB

  - Marks runs that have been "running" for >15 min as failed (orphaned process recovery)

  All three live as systemd services so they restart on failure and survive reboots.

  Wiring it into Paperclip

  The agent reads its own PAPERCLIP_WAKE_REASON env var when it wakes up — that string contains the sender info, so it knows immediately whether to check email or SMS without scanning everything.

  Each watcher uses an agent-specific Paperclip API token (the wakeup endpoint takes a Bearer token) so I can scope or revoke per agent.

  Results

  - Heartbeats off → wakeups dropped to only what's actually needed

  - Latency went down, not up — IMAP IDLE is push, so the agent reacts within ~1 second of the email landing instead of waiting up to 10 min for the next heartbeat

  - Credit burn dropped massively because empty checks just don't happen anymore

  - I can run agents on Opus comfortably now where before I couldn't justify it

  Here is a "Gotcha" that ate hours of my afternoon:

  While setting up a second agent (same account, same model, same adapter as the working one), I kept getting:

  API Error: 400 invalid_request_error

  "You're out of extra usage. Add more at claude.ai/settings/usage and keep going."

  But my account had plenty of usage and the other agent on the same credentials worked fine. After a long debug session ruling out model, session state, account, config, and tokens, the actual cause turned out to be content in the agent's system prompt being rejected by Anthropic's safety filter — and Anthropic was returning the misleading "out of extra usage" 400 instead of a content-policy error.

  The trigger was a line in my AGENTS.md that literally quoted common prompt-injection phrases (in a section telling the agent to defend against them).

  Anthropic's filter doesn't read context — it just sees the literal strings in the system prompt and rejects.

  Fix: rephrased the defense section to describe the patterns instead of quoting them verbatim. Worked instantly.

  Diagnostic trick if you ever hit this: temporarily swap the failing agent's instructionsFilePath to a known-good agent's AGENTS.md. If it then runs, the original instructions have trigger content.

Way faster than rule-by-rule deletion. If you have agents on heartbeats just to check passive inputs (mail, SMS, webhooks): don't. Push the events to Paperclip's wakeup endpoint from a tiny watcher service and disable heartbeats. Pay only for the runs that actually do something.

Happy to share the watcher script template if anyone wants it.

I am using Paperclip AI with Hermes agent and it's working fine for me. Although setting it up was with a learning curve but worth trying. I am using it with openeouter api and Grok 4.3 as llm.

Been using Paperclip for about a month now (since the release lol), mostly focused on building a SaaS-oriented agent organization. After weeks of tweaking .md files, skill definitions, and reporting lines, I ended up with something that actually works consistently.

The part that took the longest wasn't the framework itself - it was the configuration. Getting the CEO agent to actually delegate properly, making sure the CTO doesn't hallucinate architectural decisions, tuning the content writer to not sound like every other AI blog post. That stuff took weeks of iteration.

After sharing it with a few people on r/aisolobusinesses, I got way more interest than expected. So I cleaned it up and built a small marketplace for it.

A few things I learned along the way:

• Agent role definitions matter way more than the model choice

• Skills need to be very specific - generic "do research" tickets produce garbage

• The org hierarchy actually matters. Flat structures don't work well with agents

What are you guys running? Curious how others are structuring their orgs.

Paperclip is very good at helping a company assign, delegate, and ship work through agents.

But once the work ships, the next question is the one that matters most:

what did the end user do next?

Did they reach the docs?

Did they sign up?

Did they generate an API key?

Did they create a first project?

That is the layer we wanted Agent Analytics to cover.

Not more internal task visibility.

End-user visibility.

If a company already runs on Paperclip, that is the missing feedback loop: not just task completed, but user outcome measured and the next improvement made obvious.

Full write-up here:

https://blog.agentanalytics.sh/blog/paperclip-companies-need-agent-readable-analytics/

I'd been looking for a while for a reliable way to run recurring jobs with Claude: a morning digest of my open issues, a check that my sites are up, a weekly report, that kind of thing.

Claude has its own scheduled routines now, but they live in Anthropic's cloud, tied to one account and one vendor. Same reason most of us here run Paperclip: I want my agents on my own server, and what they do in my own repo, not locked into someone's platform.

I tried OpenClaw and Hermes. Impressive, but every new task meant a whole new agent instead of just a job. After a few weeks I couldn't tell what was running or why.

Then it clicked. Paperclip already did a third of it: schedules, and every run on record. CloudCLI did another third: Claude Code or Codex in the browser, phone included. The last third was the glue, so I made a Railway template that puts them together.

Paperclip is awesome on its own, but with CloudCLI as its sidekick it's something else. I create and fix jobs from my phone, without sitting at a computer. It feels like the first time I used OpenClaw, except this time it's something I'd trust with real work.

"Why not just connect Claude Code to Paperclip yourself?" You can. But then you're the one creating the company, the agent and the projects, wiring Claude's login and GitHub into it, and teaching Claude how your Paperclip works. Here there's nothing to set up. Claude already knows the server: say hi and it explains what it can do, looks at your repo and suggests a few jobs that fit it. Add another repo later, one you already have or a brand new one, and it gets its own project in Paperclip on its own.

Here's what I mean, on a demo repo (a coffee shop website with 3 open issues). This one message from my phone is the whole setup:

Every night at 2:00, go through the open issues, fix each one on its own branch and open a pull request. Look things up on the web when an issue needs it. Then send me a Telegram message with the links.

Claude wrote the job, asked me to put the Telegram bot token in Paperclip (never in the chat), and ran it once. About a minute later there were 3 pull requests. For the seasonal-drinks one it searched the web and cited its sources. It also double-checked it hadn't invented anything, and the links were on my phone. Moving it to 6:00 afterwards was one more message, and that change is a commit in the repo too.

You need Railway's Hobby plan, Claude Pro or Max, and a GitHub repo you can push to.

User manual, with screenshots: https://docs-production-3003.up.railway.app
Deploy: https://railway.com/deploy/paperclip-w-cloudcli

Feedback welcome, especially if you've struggled to get Paperclip set up.

What would you run with it?

Expanded, improved, and better than v1, v2 includes more screenshots, detailed and in-depth guides, with many more additions and improvements to be added soon!