DEV Community: GetPullRequest

The $10 server that runs Claude Code while you sleep

Hari N — Fri, 16 Oct 2026 08:00:00 +0000

Coding agents like Claude Code and Codex work best on a machine that stays on. Your laptop isn't that machine. It sleeps when you close the lid, it comes to meetings, and it runs out of battery on the train. So people start looking for a Claude Code VPS, a small server that stays on so the agent can keep working. The first answer is usually AWS.

We priced it out across every cloud we could think of. The same kind of always-on box costs anywhere from $0 to $263 a month , depending on where you rent it. Most of that spread pays for things a personal dev box never uses.

TL;DR: A 4-core box running 24/7 costs about $121 a month on AWS or Azure, $98 on Google Cloud, $40 to $48 on Vultr or DigitalOcean, and $9.99 on Hetzner. An old laptop costs you about $2 a month in power. Add a $20 AI plan and GetPullRequest (GPR) on your phone, and you have a coding agent that works while you're away for about $30 a month.

How much server does Claude Code need?

When Claude Code or Codex "thinks", that work happens on Anthropic's or OpenAI's servers. Your machine just sends the request and waits. What it actually runs is git, your editor tools, your package manager and your tests. Anthropic lists the minimum for Claude Code as 4 GB of RAM on an x64 or Arm processor.

So the size of the box depends on your project, not on the agent. A Node or Python repo is happy on 2 cores and 4 GB. A Flutter app with an Android build, or three agents running test suites at the same time, wants 8 cores and 16 GB. Most people land at 4 cores and 8 GB , and that's what we compared.

Your project	Box size that works
Scripts, small web apps, one agent	2 vCPU, 4 GB
Typical app with a real test suite	4 vCPU, 8 GB
Mobile builds, Docker, 2 to 3 agents at once	8 vCPU, 16 GB

The prices, one by one

All prices are US dollars for a month of 730 hours, Linux, checked on 16 October 2026. Follow the links, because cloud prices change.

AWS, Azure and Google Cloud: what the hyperscalers charge

Provider	Machine	Per hour	Per month
AWS EC2	t3.xlarge, 4 vCPU, 16 GB	$0.166	~$121
Azure	B4ms, 4 vCPU, 16 GB	$0.166	~$121
Google Cloud	e2-standard-4, 4 vCPU, 16 GB	$0.134	~$98

Sources: AWS t3.xlarge, Azure B4ms, GCP e2-standard-4 (Vantage, us-east-1 / East US / us-central1).

That's compute only. On AWS you also pay $0.005 an hour for a public IPv4 address, which is $3.65 a month, and about $0.08 per GB-month for the disk, so another $8 for 100 GB. The real AWS bill is closer to $133. Data going out to the internet is billed on top.

A one-year reservation brings the t3.xlarge down to about $0.104 an hour (~$76 a month). That's still more than seven Hetzner boxes.

None of this is a rip-off. You're paying for dozens of regions, enterprise access controls and an uptime promise that production systems need. A box that runs your agent while you sleep needs none of it.

Lightsail, DigitalOcean and Vultr: the simpler clouds

Provider	Machine	Per month	Traffic included
AWS Lightsail	4 vCPU, 16 GB, 320 GB SSD	$84	6 TB
AWS Lightsail	2 vCPU, 8 GB, 160 GB SSD	$44	5 TB
DigitalOcean Basic	4 vCPU, 8 GB, 160 GB SSD	$48	5,000 GiB
Vultr Regular	4 vCPU, 8 GB, 160 GB SSD	$40	4 TB
Vultr High Performance	4 vCPU, 8 GB, 180 GB NVMe	$48	6 TB

One flat price, with the disk, the IP address and a generous amount of traffic included. Lightsail is the same AWS underneath at about two thirds of the EC2 price. If you want AWS on the invoice, that's the one to pick.

Hetzner vs DigitalOcean vs AWS: the cheapest paid option

Hetzner raised cloud prices on 15 June 2026, some plans by more than double. It's still the cheapest paid option by a wide margin. On the same 4 vCPU, 8 GB box, Hetzner vs DigitalOcean is $9.99 against $48. Hetzner vs AWS is $9.99 against about $133.

Plan	Machine	Per month (Germany/Finland)
CX33	4 vCPU, 8 GB, 80 GB NVMe	$9.99 (€8.49)
CAX21	4 Arm vCPU, 8 GB, 80 GB NVMe	$12.49 (€10.49)
CX43	8 vCPU, 16 GB, 160 GB NVMe	$18.49 (€15.99)
CPX32	4 vCPU, 8 GB, 160 GB NVMe	$41.99 (€35.49)

Prices exclude VAT and a €0.50 public IPv4 fee. EU servers include 20 TB of traffic.

Two catches. The cheap CX and CAX plans are "cost-optimized", and on the day we checked, Hetzner's page listed them as currently unavailable. They come back in batches, so keep trying. And the cheapest plans live in Europe. That matters less than you'd think. Your phone talks to the agent through our server, and the agent talks to the model's servers, so you never type into a laggy terminal across the Atlantic.

Is Oracle Cloud's free tier really free?

Oracle's Always Free tier gives you Arm compute worth 2 OCPUs and 12 GB of memory, plus 200 GB of disk, for $0. It's a real machine and it's enough for one agent.

Yes, but read the limits. The catch is written in the same doc. Oracle may take back a free instance that looks idle for 7 days, meaning CPU, network and memory all under 20%. A dev box that waits for your next task looks exactly like that. Use it to try things. Don't build your week around it.

GitHub Codespaces

Codespaces charges $0.36 an hour for 4 cores. Used eight hours a day on workdays, that's about $63 a month. Left running all month so an agent can work overnight, it's $263. Codespaces is built to stop when you stop, which is the opposite of what an agent box is for.

Your own machine

Machine	Up front	Power per month	Per month over 3 years
Old laptop or desktop you already own	$0	~$2	~$2
Raspberry Pi 5, 8 GB	$155	~$0.70	~$5
Mac mini M6	$899	~$1.30	~$26

Power uses the US average of 18.2 cents per kWh for 2026. Apple says the M6 Mac mini draws 4 watts at idle, and we assumed an average of 10 W with builds. The Pi got 5 W and the old laptop 15 W.

The old laptop in the cupboard is the cheapest dev box there is. It already has your tools, your keys and a warm build cache. RAM prices pushed the Pi up 24% this year, but it's still a fine box for a light repo.

What it costs all in

The box is only half the bill. The agent needs a model plan too. Claude Pro is $20 a month and includes Claude Code. ChatGPT Plus includes Codex.

Setup	Box	AI plan	GPR	Total per month
AWS EC2, done "properly"	~$133	$20	$0	~$153
DigitalOcean	$48	$20	$0	$68
Hetzner CX33	$9.99	$20	$0	~$30
Old laptop at home	~$2	$20	$0	~$22
Oracle free tier	$0	$20	$0	$20

Heavy users move to a bigger AI plan (Max starts at $100) long before they need a bigger box. That's where the money actually goes.

Our take

We tried hosted sandboxes first. Wiring our backend, Flutter app, database and daemon together inside someone else's sandbox was painful, every test meant a fresh checkout and a full build, and the bill was too high for a small startup whose laptops sat idle most of the day. (The launch post tells the whole story.)

So our view is simple. Spend on the model, not the machine. The model is what writes the code. The machine just needs to be on, have your repo checked out, and run your tests. A $10 box does that as well as a $120 one.

What $30 a month gets you

With a small always-on box and GPR on your phone:

Agents keep working when your laptop is closed. Start a task on the train, close the app, check the result at lunch.
Tickets turn into pull requests. Point an agent at a GitHub issue, a Jira ticket or a Slack thread, and a PR comes back.
Several tasks at once. Each task gets its own git worktree, so two or three agents can work side by side on 8 GB.
Overnight runs. Queue the boring backlog before bed and review the PRs from your phone in the morning.
Your agent, your choice. Claude Code, Codex, Cursor or any of the eight ACP agents.
Your code stays on a box you control, not in a vendor's sandbox.

How to install Claude Code on a VPS

Rent the box (or dust off the laptop) and log in over SSH. Install the agent you use, then GPR. For Claude Code, that's the official installer, and you sign in by running claude once:

curl -fsSL https://claude.ai/install.sh | bash
claude
curl -fsSL https://getpullrequest.com/install | bash
gpr setup ~/code/your-repo

Scan the QR code with the GPR app and you're done. The daemon connects out to our server, so you don't need to open any ports. Keep SSH on keys only and leave the firewall closed.

A few habits that save money and pain:

Start small. Moving up a size on most clouds takes a reboot, not a rebuild.
Check gpr status and gpr doctor after a reboot, the same as any other machine.
Watch the hourly clouds. A forgotten EC2 box with a big disk keeps billing whether you use it or not.

Questions people ask

What's the best VPS for Claude Code?

For most people, a 4 vCPU, 8 GB box. Hetzner's CX33 at $9.99 is the cheapest we found. If it's out of stock, Vultr ($40) and DigitalOcean ($48) are simple and reliable.

What's the cheapest VPS for Claude Code?

Oracle's free tier at $0, if it doesn't get taken back for being idle. The cheapest paid one is Hetzner's CX23 (2 vCPU, 4 GB) at $6.49, which just meets Claude Code's 4 GB minimum.

How much RAM does Claude Code need?

Anthropic says 4 GB or more. Plan for 8 GB if your tests or builds are heavy, or if you run more than one agent at once.

Is Hetzner cheaper than AWS?

Yes, by about 13 times for an always-on 4-core box: $9.99 against roughly $133 with disk and IP address on AWS.

Hetzner vs DigitalOcean pricing?

For 4 vCPU and 8 GB, Hetzner is $9.99 and DigitalOcean is $48. Hetzner's cheapest plans are only in Europe, and they sell out.

Can I run Claude Code on a Raspberry Pi?

Yes. Claude Code supports Arm, and the 8 GB Pi 5 meets the memory minimum. It's slow for big builds but fine for a light repo.

Does my Claude Code VPS need open ports?

Not for GPR. The daemon connects out to our server, so only SSH needs to be reachable, and only with keys.

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, pick the cheapest box on the chart above, and give it tomorrow's longest task.

Keep reading

Sources

Prices checked 16 October 2026.

AWS: EC2 t3.xlarge, Lightsail pricing, public IPv4 pricing, EBS pricing
Azure: B4ms
Google Cloud: e2-standard-4, Compute Engine pricing
Hetzner: June 2026 price adjustment, cost-optimized plans, regular performance plans
DigitalOcean: Droplet pricing
Vultr: pricing
Oracle Cloud: Always Free resources
GitHub Codespaces: billing
Mac mini M6: TechCrunch, $899 starting price, Apple power figures
Raspberry Pi 5: OMG! Ubuntu, February 2026 price rise
Claude Code: setup and system requirements
Electricity: EIA Short-Term Energy Outlook, October 2026
AI plans: Claude pricing, ChatGPT pricing

OpenAI dots fall short on coding. Here's exactly where

Hari N — Mon, 12 Oct 2026 11:09:00 +0000

On September 29, OpenAI launched dots. A dot is an always-on agent that works for you in the background. It has its own cloud computer and browser, connects to more than 4,000 apps through plugins, and you talk to it in ChatGPT (desktop, web or mobile), Slack or Teams. Texting is "coming soon".

One of the examples OpenAI gives is for developers. Your dot watches customer feedback for recurring requests, picks out small fixes, builds and tests them, and "brings you complete PRs to review with attached videos showing the changes." That is very close to what GetPullRequest (GPR) does, so we wanted to write down honestly how OpenAI dots and GPR compare. (Videos of the change are a nice touch. Ours don't do that.)

TL;DR: Dots is a general assistant for everyone, running on OpenAI's cloud with OpenAI's model. GPR is only for developers. It runs the coding agent you already pay for (Claude Code, Codex, Cursor and others) on your own machine, takes work from a task board, GitHub, Jira or Slack, and lets you review and merge the pull request from your phone.

What dots and GPR have in common

Both are built around the same idea. You shouldn't have to sit in front of a terminal while an agent works. You hand it the work, it gets on with it, it asks you when it needs a decision, and it comes back with something you can review.

Both also keep a person in the loop. Dots come with built-in rules for when to act alone and when to ask, and you can add your own rules to allow, block or require approval for specific actions. In GPR, the agent asks you questions while it plans, and nothing gets merged until you merge it.

Where the agent runs

This is the biggest difference.

A dot works on its own cloud computer, and you can open that computer to see what it did. You can also give it permission to use your laptop, but by default your computer stays separate. For general work like drafting documents or checking accounts, that is a sensible design.

For code, it matters more. Your repo, your build setup, your database and your test data are on your machine. Before we built GPR, we tried running agents in hosted sandboxes. Getting our backend, Flutter app, database and daemon all running in a sandbox took a lot of work, and every time we wanted to check a change we had to build everything from scratch. So GPR runs the agent on your machine, where everything is already set up. The agent runs your tests the same way you do. The GPR backend never clones your repo. It keeps the task board and the session history (the agent's messages, tool calls and diffs) so your phone can replay them, sends notifications, and opens the pull request through GitHub or GitLab when you've connected one.

The trade-off is that your machine needs to be on. A dot can keep working when your laptop is closed. GPR waits until your machine is back, which is why some of us pair a second machine that stays on.

Which agent does the work

Dots run on OpenAI's GPT-6 Astra. You can ask your dot to start or manage tasks in Codex, and those count toward your normal ChatGPT usage limits. Just chatting with your dot doesn't.

GPR doesn't have its own agent. It runs the agents developers are already paying for: Claude Code, Codex, Cursor, Kiro, OpenCode, Qwen, Cline and Copilot. It talks to all of them through the Agent Client Protocol, so you can pick a different agent for each workspace. Our own team builds GPR with Cursor, Claude Code, Kiro and OpenCode, and nobody had to give up the one they liked.

If your team is all-in on OpenAI, this difference might not matter to you. If your team uses Claude Code, or a mix of agents, it matters a lot.

Who it's for

Dots is for everyone. OpenAI's examples include a sales lead, a scientist rerunning analyses as new data arrives, a content creator and someone running a product launch. One early tester's dot noticed he'd forgotten to invoice a publication, prepared the invoice and sent it once he approved.

GPR only does one thing: it gets coding tasks done and turns them into pull requests. Tasks come from a board in the app, from GitHub or GitLab issues, from Jira tickets or from an @gpr mention in Slack. Each task gets its own git worktree, and the agent plans, implements, verifies and opens a pull request. You can watch the session live, answer the agent's questions and merge the PR, all from your phone.

What it costs

Dots is rolling out to ChatGPT Pro and Business Premium, and Enterprise workspaces can try the beta once an admin turns it on. Your first dot comes with the plan at no extra cost, deeper work uses an allowance, and limits are extended for the first month. OpenAI hasn't published what happens after that, or pricing for more dots.

GPR has a free tier that covers projects, sessions, and the GitHub and Slack connections. You only pay if you want more workspaces or more tasks running at the same time. You also keep paying for your coding agent the way you already do, whether that's a Claude plan, a Cursor plan or ChatGPT for Codex.

Where dots fall short for developers

Dots is two weeks old, so there isn't much hands-on feedback yet. We went through OpenAI's own docs, the first user reports on OpenAI's developer forum, and the threads on Reddit and Hacker News. Here's what matters if you want a dot to write code.

Where it falls short	What we found	How GPR handles it
Who can get it	Only ChatGPT Pro and Business Premium. Pro users in the EEA, Switzerland and the UK are left out at launch. One r/OpenAI thread is titled "Barrier to entry with dots is kinda absurd".	Free tier. You keep the agent plan you already have.
Setting it up	You can't create a dot on mobile, and mobile web isn't supported. Desktop app or desktop web only.	Run `gpr setup` once on the machine. Everything after that is from the phone.
Working on your machine	Your computer has to stay online with the ChatGPT app open.	The daemon runs in the background. No app needs to be open, but the machine does need to be on.
Your build setup	Cloud coding needs a Codex environment you create first, with dependencies and tests set up again in OpenAI's cloud.	Uses the build that's already on your machine.
Which agent	GPT-6 Astra, and Codex for coding tasks.	Claude Code, Codex, Cursor, Kiro, OpenCode, Qwen, Cline or Copilot.
Cost you can plan	Codex tasks your dot starts count toward your usage limits. Limits after the first month aren't published.	Your agent bill doesn't change. GPR charges only for more workspaces or more tasks at once.
Seeing what's running	The first user report on OpenAI's forum said it was "harder to tell what was actually running, what needed attention and where the latest result lived." The same post said the dot couldn't confirm which model a task was using, and its prototype code "passed static checks but still contained mistakes."	Every task is a card on the board with its state, and the verify step runs your tests before a PR opens. Agents still make mistakes, so you still review.
Company rules	Enterprise is a beta and off by default. During the beta there's no data residency, no strict zero data retention, and no dots for FedRAMP or EKM workspaces.	Your repo stays on your machine. GPR does store the session history, including diffs, so your phone can replay it.
Memory	The only way to clear what a dot has saved is to delete the dot.	GPR keeps no memory of its own. The agent sees the task and its session, and you can scroll through both.

None of this makes dots bad. It's a general assistant that also writes code, and OpenAI built it for everyone first. For a developer, though, it's one more place to set up your build, and one more model you didn't pick.

Where GPR falls short today

Dots can do far more than code. It can draft documents, prepare invoices and work across thousands of apps. GPR can't do any of that, and we don't plan to.

GPR also needs your machine to be on, and the iOS app isn't in the App Store yet. We're actively working on getting it approved. Android is available today. Dots works from ChatGPT on desktop, web and mobile, and from Slack and Teams.

So which one should you use?

If you want one assistant that helps with all kinds of work, and you're happy with OpenAI's models and cloud, try dots.

If you want an end-to-end assistant for your coding work, pick GPR. It gets the work done. A ticket goes in, and a tested pull request comes out. It runs on your own machine, with the agent you already pay for, and you review and merge from your phone.

Dots helps with everything. GPR ships your code.

You can also use both. If your dot is connected to GitHub, it can file an issue with the gpr:agent label, and GPR will pick it up.

Try GPR

Get the app on Google Play, then run this on the machine where your code lives:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app

Keep reading

Ship code from your phone with the AI coding agents you already pay for

Hari N — Tue, 06 Oct 2026 11:31:34 +0000

We run AI coding agents like Cursor, Claude Code and Codex from our phones. The agents don't run in a vendor's cloud sandbox. They run on our own laptops, and each of us has also paired a cloud desktop as a second machine. The phone is how we give them work and check on them. The tool that does this is GetPullRequest (GPR), and we have been building GPR with GPR since May. Every branch a GPR task or session creates is named gpr/task-tsk_…, and by now that is most of our branch list.

TL;DR: GPR runs the AI coding agents you already pay for (Cursor, Claude Code, Codex and five more) on your own machine, using the Agent Client Protocol. Tasks can come from the app, GitHub, GitLab, Jira or Slack. You answer the agent's questions and merge its pull request from your phone. Your machine needs to be on.

This post covers how a task runs, why we keep the agent on your machine, and some of the strange problems we ran into while building it. If you want the story of why we built GPR in the first place, read the launch post.

Claude Code remote control, Codex, Cursor background agents: why not just use those?

It's a fair question. Claude Code has Remote Control, Codex works with the ChatGPT app, and Cursor has background agents (now called Cloud Agents) that you can start from Slack or their iOS app. If you only use one agent and just want to check on one session from your phone, those tools are good and you should use them.

The problem is that each one is a chat with a single vendor's agent. Claude Code's Remote Control, for example, only works with Anthropic's models and a claude.ai login. If you run Claude Code with an API key or through OpenRouter, Remote Control won't start. Our team was using four different agents, and nobody wanted to switch to just one. Our work also didn't start as a chat. It came in as GitHub issues, Jira tickets from the product team, and screenshots posted in Slack. What we wanted was an assistant for every developer that owns a task board, keeps track of the work on it, and gets it done with whichever agent fits.

How a task actually runs

You create a task on the board in the app. It can also come from a GitHub issue with the gpr:agent label, from a Jira project, or from an @gpr mention in Slack. The task goes to the workspace where you ran gpr setup.

The GPR daemon on that machine picks up the task and creates a git worktree for it under ~/.gpr/worktrees/. This keeps the agent away from the branch you are working on. The daemon then starts the agent you chose for that workspace, and the agent plans, implements, verifies, writes a commit summary and opens a pull request. GPR saves a checkpoint after each step, so if something interrupts the run, it continues from the last checkpoint instead of starting again.

If the agent has a question while it is planning, the task moves to "Needs your input" and you get a notification on your phone. You reply on the task and the agent continues. When the pull request is open, the task stays in "In review" until it is merged. You can also open the live session at any time and watch what the agent is doing.

None of this is complicated on paper. Most of our time went into making it work reliably on real laptops, real networks and with real agents.

Why AI coding agents should run on your machine: faster, and already paid for

Our repo is an Nx monorepo with a FastAPI backend, a Flutter app, a Go daemon, a generated Dart SDK and a couple of other products. Building it from a fresh checkout takes quite a few steps.

We tried hosted sandboxes first, using Daytona. The first problem was setup. We had to get the backend, the Flutter app, the database and the daemon running together inside a sandbox, and keep them working as the code changed. The second problem was cost , which was hard to justify for a startup when our laptops were sitting idle half the day. The biggest problem was testing. Every time we wanted to check an agent's change, someone had to check out the branch and build everything from scratch.

"We were paying to rebuild an environment in the cloud that was already fully built on the laptop in front of us."

When the agent runs on your machine, it runs the tests the same way you do. Your code, your agent's login and your API keys stay on your machine. The GPR backend only holds the board and the task queue, passes the session to your phone and sends notifications. It never has a copy of your repo.

The downside is that your machine has to be on. If your laptop goes to sleep, the task waits as "Waiting for machine" and continues when the laptop wakes up. That's why each of us also paired a cloud desktop.

Everything works with nothing connected

Our first plan was to get diffs and merge status from GitHub. We dropped it before writing any code. The agent's changes are on your machine, often not even committed yet, so GitHub doesn't know about them. GPR reads them with git on your machine instead. If you connect GitHub, it adds a bit extra, like whether the PR can be merged or is behind the base branch.

This became a rule for the whole product, and we call it the enrichment model. Coding, reviewing, merge checks, resolving conflicts and changing a task's base branch all work using the daemon and git on your machine. Integrations bring work in and handle things like opening the pull request on GitHub. They never replace information your machine already has.

Works with nothing connected	Added when you connect a provider
Coding, plan/implement/verify	Issues synced in from GitHub, GitLab or Jira
Diffs and merge checks from local git	"Mergeable" and "behind" hints from GitHub
Resolving conflicts, changing base branch	Opening the hosted PR
The board, queue, live session and @gpr mentions	Tasks started from Slack

In the code, each provider lives in its own folder and plugs into a shared interface. We added GitHub first, then GitLab (which mostly copied the GitHub structure), then Jira and Slack. In August we found GitHub-specific code in places that were supposed to work for every provider, and we spent some time cleaning that up. It still isn't perfect.

This approach helped us in September. Atlassian removed an old Jira search endpoint, and our Jira calls started failing with 410 Gone. The agents kept working as normal. Only the syncing of new tickets stopped. We wrote the fix up as a Jira ticket, and GPR picked it up and opened the pull request.

Some weird issues we hit while building it

I want to share a few of these because building reliable software takes time, even when agents write a lot of the code. In most cases, finding the problem took much longer than fixing it.

The connection that was dead on one side.

A Windows machine had a connection that looked fine from the machine's side, but the relay could not reach it. The daemon thought it was online, so it never reconnected. Tasks sent to that machine just waited and nothing happened.

Split brain after a deploy.

When we deploy a new version of the backend, the old servers keep running for a short time before they shut down. The daemon's live connection stayed on one of those old servers, while its normal API calls went to the new ones. So one part of the backend thought the machine was connected, and another part thought it was not. We fixed both problems the same way: the backend now starts the reconnect itself, and the daemon checks its status regularly and reconnects if the two don't agree.

52 agents on one laptop.

In August one developer's machine had 52 agent processes running, each using about 300 MB of memory, a few minutes after the daemon started. Several Cursor agents had started at the same time and were all trying to use the same config file, so their startup failed. We retried, but the failed agents did not stop when we asked them to. We had also stopped tracking them, so nothing ever cleaned them up. Now we give an agent two seconds to stop, and if it is still running, we kill it.

Tasks marked done with no changes.

Sometimes an agent said it was done and wrote a good summary, but it had not changed any code. GPR still marked the task as successful. Now a task with no commits is marked as failed. In another case, a log line that should have explained why tasks were timing out printed nothing useful, because it used Go formatting in Python code. When we fixed the log, it showed us a second bug where one session could start two agents. Both stories are in AI can run the software factory. It can't turn the lights off yet.

Updates on Windows.

On some Windows machines gpr update did nothing, but the output looked the same as a successful update. Windows does not let you replace a program while it is running, but it does let you rename it. So now we rename the old program and put the new one in its place. Every change to the daemon has to work on macOS, Linux and Windows, and Windows caused most of these problems.

Duplicate Slack messages.

Slack sends us every @gpr mention twice, but only one of the two has the screenshot attached. We were reading the other one, so screenshots people attached to bug reports were lost.

You may have noticed that several of these problems came from the agents themselves, like the Cursor processes that would not stop. That happens because GPR runs coding agents from existing vendors instead of an agent we built ourselves. We chose that on purpose, early on, and the next section explains why.

Agent Client Protocol: why we never built our own coding agent

Almost every developer we talked to was already paying for a coding agent, whether that was a Cursor plan, a Claude subscription or ChatGPT for Codex. Asking them to pay for another agent just to try GPR would have been a barrier, and they would be paying twice for the same thing. That's also why I find it hard to justify paying for Devin on top of those plans.

What we didn't know was how to support all of these agents without building a separate integration for each one. Then I watched a video with Ben Brandt from Zed and people from JetBrains about the Agent Client Protocol (ACP). Without a shared protocol, every editor needs its own integration with every agent. With ACP, each editor and each agent only has to support the protocol once.

If Zed and JetBrains were building this standard for editors, a phone app could use it too.

Here is how GPR uses it. The daemon talks to the agent using ACP on your machine. The daemon also connects out to our relay over a WebSocket, and the relay sends the same messages on to your phone. The relay keeps a copy of the session, so if your phone goes offline it can catch up later, and it sends you a notification when the agent needs you. Because of this, the app doesn't have to read a terminal screen. It receives the plan, tool calls, diffs and the agent's slash commands as structured data, which is why one app works with every agent.

Cursor and Kiro support ACP directly, so they were the first agents we fully supported, in July. Claude Code and Codex need an adapter, and we added them in September. Today the daemon supports eight agents: Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot. Our ACP post explains the protocol in more detail, including how it differs from MCP.

We built GPR using Cursor, Claude Code, Kiro and OpenCode, and nobody on the team had to give up the agent they liked. 370 commits in our repo are co-authored by GPR. Each agent starts up, logs in and shuts down a little differently, and the daemon handles those differences. Switching agents is just a dropdown in the app.

What a phone is actually good for (the Claude Code mobile app question)

A lot of people search for a Claude Code mobile app. In practice, the things you need to do on a phone are fairly small: answer a question about the plan, approve a command, read a short diff, give feedback and merge. On Android you can also share a screenshot from your gallery directly into an agent session, and a lot of our own bug reports now start that way.

We spent a lot of time making these small things easy on a small screen. You can leave a comment on a diff by tapping or long-pressing the line, and the agent picks it up in the next round. Long agent sessions have a conversation minimap, so you can jump to the part you care about instead of scrolling through everything. The slash commands in the app are the ones your agent actually supports, and switching the model or the agent is a single dropdown. When you add reviewers to a pull request, you pick them by name and photo, because nobody remembers GitHub usernames on a phone. If the base branch has moved, you can update the pull request from the phone, and the agent fixes any conflicts in new commits so you can see exactly what it changed. And if your phone loses signal halfway through a session, it catches up from where it left off when it reconnects.

A phone is not the right place to review a big architectural change. When I need to compare big files side by side, still i prefer big screen. But this pushes to keep agent tasks small, and agents do better work on small tasks anyway. You can read more about how we review and merge from the phone. If you're wondering why a person still needs to approve the merge at all, the software factory post covers that in detail.

Still rough

The iOS app isn't in the App Store yet. Live preview of your running app on the phone is still being built. Diffs come from git on your machine, so if your laptop is asleep, you can't see the diff either. And when an agent's login expires, GPR can tell you that the agent failed to start, but someone still has to go to the machine and log in again.

Trying it

To try it, you need the Android app from Google Play (iOS app coming soon), a Mac, Linux or Windows machine, and one coding agent installed on it. GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once.

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app
gpr discover # lists which agents are ready

We'd suggest starting with a small task, something you've been putting off, so you can see how it works before giving it anything bigger.

Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about

Hari N — Tue, 06 Oct 2026 07:10:19 +0000

The Agent Client Protocol is a standard way for a code editor to talk to a coding agent. Zed started it in 2025. JetBrains joined in October 2025 to bring it to IntelliJ and the rest. If an agent speaks ACP, any ACP editor can drive it. If an editor speaks ACP, it gets every ACP agent for free.

We built GetPullRequest (GPR) on it. Slightly odd, because GPR isn't an editor. It's a phone app that runs coding agents on your own machine. Protocol first, then what we did with it.

TL;DR: ACP is to coding agents what LSP was to language tooling. Agents implement it once, clients implement it once. GPR treats your phone as an ACP client and runs eight agents through it: Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot.

The problem the Agent Client Protocol solves

Before ACP, every editor that wanted an agent wrote its own integration, and every agent that wanted to be in an editor did the same backwards. M editors, N agents, M × N bits of glue, each broken in its own way. ACP makes it M + N.

Same trick the Language Server Protocol pulled. It's why your editor can autocomplete Rust without anyone at your editor's company knowing much Rust.

How it works

For a local agent, the client starts the agent as a subprocess and they swap JSON-RPC messages over stdin and stdout. Remote transports over HTTP or WebSocket are still being worked out in the spec. The messages carry what a coding UI needs: the plan, tool calls and their results, file diffs, terminal output, permission requests, slash commands, model choices. Where it can, ACP reuses MCP's JSON shapes, and adds its own types for coding-specific UI like diffs.

The spec and SDKs are at agentclientprotocol.com. Not every agent speaks it natively. Claude Code and Codex get wrapped by small adapter binaries that translate.

In January Zed and JetBrains also launched the ACP Registry: an agent registers once and shows up in every ACP client, installed about the way you'd install an extension. Claude Code, Codex CLI, GitHub Copilot CLI and OpenCode were in it at launch. That's the point where ACP stopped being a Zed thing and started looking like the default.

Agent Client Protocol vs MCP

The names rhyme, so people mix them up.

	ACP	MCP
Connects	A client (editor, phone) to the agent	The agent to tools and data
Typical messages	Plans, diffs, tool calls, permission requests	Tool calls, resources, prompts
Example	Zed or GPR driving Claude Code	Claude Code reading your database

In a normal setup the editor talks ACP to the agent and the agent talks MCP to its tools. You use both.

How we found it

GPR doesn't ship its own coding agent. Nearly every developer already pays for one or two: Cursor, a Claude plan, ChatGPT for Codex, Copilot through work. Making them buy another before they can try GPR is friction, and paying twice. We wanted to reuse what people already have. We just didn't know how without writing and maintaining one integration per agent.

Then we watched a video where Ben Brandt from Zed and people from JetBrains walk through ACP. Our exact problem, solved for editors, and nothing in it required the client to be an editor.

A phone could be just another client.

What GPR does with ACP

GPR's daemon runs on your machine and talks ACP to the agent over stdio, same as Zed would. The daemon dials out to our relay over a WebSocket, so nothing on your machine listens for incoming connections, and the relay passes the same messages on to the app. It keeps the stream, so a phone that dropped off in a lift picks up from the last event it saw, and it sends a push when the agent needs you. So the phone isn't screen-scraping a terminal. It gets plans, tool calls, diffs and terminal output as structured messages, and that's why one mobile UI works for every agent.

The daemon recognises eight today: Cursor (cursor-agent), Claude Code, Codex, Kiro, OpenCode, Qwen, Cline, Copilot. We built GPR with four of them (Cursor, Claude Code, Kiro, OpenCode) and nobody had to agree on one. gpr discover tells you which are ready, which are installed but missing an adapter, which aren't installed. Pick one per workspace. Switch with a dropdown. We don't pull agents from the ACP Registry yet. Anything listed there already speaks the protocol, though, so adding one is a small job for us rather than a new integration.

Some things just fall out of using the protocol properly. The slash commands in the app are whatever the agent advertises over ACP, not a list we maintain, so a new command just shows up. Model switching uses ACP's config options, and if an agent also advertises a models slash command, the app hides it so there's one way to switch everywhere. Agents can send their own extension messages; Cursor and Kiro both do, and they were the first two we supported properly, in July. Not every extension earns its place. In September we hid Kiro's MCP status widget from the chat. It was noise.

Agent Client Protocol with Claude Code

People search for this specifically. Claude Code doesn't speak ACP natively. It goes through an adapter that sits next to the gpr binary, and the installer puts it there. That's also why it was late for us: Cursor and Kiro speak ACP out of the box and got proper support in July, while Claude Code (and Codex) landed on September 18.

The adapter route has one nice side effect. If you run Claude Code on an API key, or through OpenRouter or a company gateway, you set that in GPR's agents.json and it just works. Anthropic's own Remote Control refuses all of those setups. The Claude Code post has the details.

What the protocol doesn't fix

ACP standardises the conversation. It doesn't standardise how agents behave as processes, and running them unattended for hours shows it.

Agents that won't stop. Stop some agents halfway through startup and they ignore the polite signal and keep running. Start several at once and they can trip over the same config file. In August that combination left 52 agent processes on one of our machines, about 300 MB each (the Cursor post has the story). The daemon now gives an agent two seconds to exit, then kills it.

Agents that go quiet. Some stop talking mid-turn without saying why. GPR fails the task after 90 seconds of silence rather than wait forever, so it shows up on your phone as failed instead of sitting at "running" all afternoon.

These tools mostly weren't built to be long-running background processes, and a protocol can't change that. Somebody has to absorb it. For us that's the daemon.

Your keys stay where they are

Your own agent means your own login. Anthropic key, codex login, Cursor account, all stay on your machine, and any keys or gateway settings the daemon needs go in ~/.gpr/agents.json there too (reference). GPR's backend never sees them, and your model bill doesn't change.

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, then:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo && gpr setup
gpr discover

Agent-specific guides: Claude Code, Codex, Cursor. Running several at once across machines: parallel coding agents.

Keep reading

New here? The launch post, Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest, is the why. The pillar, We ditched cloud AI coding agents. Our laptops were faster, and already paid for, is the how.

Claude Code Remote Control is great. It's also not enough
Codex CLI remote control: stop babysitting the terminal and let it ship PRs while you're out
Cursor background agents charge you twice for compute you already own
Run parallel coding agents on every machine you own, from one phone
AI can run the software factory. It can't turn the lights off yet

Claude Code Remote Control is great. It's also not enough

Hari N — Mon, 05 Oct 2026 15:25:00 +0000

If all you want is to check on a Claude Code session from your phone, use Anthropic's Remote Control. It's built in, it comes with Pro or Max, and for that one job it beats what we make. We sell a competing product. Still true.

The rest of this is how to set Claude Code remote control up, why it sometimes refuses to start, and the point where it stopped being enough for us. That point is where GetPullRequest (GPR) comes in, and it won't be the same point for everyone. The short version: Remote Control is a chat window into one Claude session, running Anthropic's models. GPR is a universal remote for the dev tools you already use, whichever agent, whichever model, wherever the task came from.

TL;DR: Remote Control is a chat with one Claude Code session, on Anthropic's models and a claude.ai login. For that, it's the quicker tool. GPR is a universal remote: Claude Code, Codex, Cursor and five more agents, tasks from GitHub, Jira and Slack, any model or gateway you've configured, and a pull request at the end.

Setting up Claude Code remote control

On the machine where your repo lives:

claude remote-control

That starts a server that waits for your phone. Press space, a QR code shows up, scan it with the Claude app, and you're in the session. Already inside Claude Code? /remote-control, or /rc, does it for the conversation you have open. claude --remote-control starts a normal terminal session that's also reachable from the phone.

Everything still runs on your machine: files, MCP servers, tests. The phone sends messages, can attach a photo or a file, and gets a push when Claude finishes something or needs a decision. Server mode runs several sessions from one process (up to 32 by default), and --spawn worktree gives each new one its own git worktree, which you want if you're starting more than one. It's gotten noticeably better this year. If your laptop sleeps, it reconnects when it wakes.

Claude Code remote control not working?

It's nearly always one of these.

You're on an API key. Remote Control needs a claude.ai subscription login (Pro, Max, Team or Enterprise). ANTHROPIC_API_KEY won't do it, and neither will a token from claude setup-token. Run claude auth login.

You're not talking to Anthropic's API directly. Remote Control isn't available if you run Claude Code through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry, if ANTHROPIC_BASE_URL points at an LLM gateway or company proxy (unset it), or if you sign in through an enterprise Claude apps gateway. That rules out a lot of companies that buy Claude through their cloud provider.

Your org hasn't turned it on. On Team and Enterprise an owner has to enable it in the Claude Code admin settings. Orgs with Zero Data Retention can't enable it at all, because the transcript syncs through Anthropic's servers.

The process died. Close the terminal and the session goes offline. claude remote-control --continue brings it back for about four hours after that; later than that you start fresh. On a remote box, put it in tmux. In server mode, lose the network for about ten minutes and the process exits.

Anthropic's Remote Control docs cover all of it, and they're good.

Where it stopped being enough for us

Remote Control is a chat app. A good one, but you're talking to one Claude Code session, on Claude models, through Anthropic's own API. We wanted to hand off a task to whichever agent suited it and come back to a pull request.

We build GPR with GPR, and the agents doing that were Cursor, Claude Code, Kiro and OpenCode. Not just Claude. Tasks show up as GitHub issues, Jira tickets, Slack messages. Not as chats we start. Jira ticket PET2-4 became our PR #500 without anyone opening a terminal. Remote Control can't do that; it's one agent and a session you started.

"For a couple of months we used Claude Code in a terminal to build a product that couldn't run Claude Code yet."

That's not a figure of speech. Claude Code wasn't one of the first agents GPR could run. Cursor and Kiro speak the Agent Client Protocol natively, so they got proper support in July. Claude Code doesn't. It needs an adapter sitting between it and any ACP client, and getting that working properly through GPR took us until September 18. Mildly embarrassing, but not really our call.

	Claude Code Remote Control	GPR
Agents	Claude Code	Claude Code, Codex, Cursor and 5 more
Models	Anthropic's Claude models, via Anthropic's API	Whatever each agent supports, including through your own gateway
Where tasks come from	A session you started	App board, GitHub, GitLab, Jira, Slack
Login	claude.ai subscription only	Subscription, API key, or a proxy/gateway via `agents.json`
What it is	A chat with one session	A remote for your whole dev workflow
What you end with	A conversation	A PR you can merge from the phone
Machine has to be on	Yes	Yes

One Claude session and a question to answer from the couch: Remote Control. Six tickets, three agents, each planned, built, tested and turned into a PR: GPR. The API key thing matters more than it sounds if your company pays for Claude through the API and not through claude.ai seats.

Running Claude Code through GPR

Claude Code stays on your machine, in your repo, on your login, API key or gateway. GPR's daemon starts it and talks to it over the Agent Client Protocol, through a small adapter binary. The app shows the session live, buzzes when Claude has a question, and lets you review and merge the PR from your phone.

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup

gpr setup registers the folder as a workspace, installs a startup service and prints a QR code. Scan it in the app under Settings → Connections. On Windows it's irm 'https://getpullrequest.com/install.ps1' | iex in PowerShell.

Install the claude CLI and log in. The Claude ACP adapter has to sit next to the gpr binary, and the installer handles that.

On an API key, or going through a proxy or LLM gateway? Put it in ~/.gpr/agents.json rather than exporting it in your terminal. The daemon runs as a background service, so it never sees your shell profile. This one points Claude Code at OpenRouter:

{
  "agents": {
    "claude": {
      "command": "claude-agent-acp",
      "env": {
        "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
        "ANTHROPIC_AUTH_TOKEN": "sk-or-your-key"
      }
    }
  }
}

Use ANTHROPIC_API_KEY instead for a plain Anthropic key. Keep the command line even though it looks redundant, because env on its own doesn't override the built-in agent. Then gpr restart, since the daemon only reads the file at startup. The agents.json reference has the rest.

That exact setup is one Remote Control refuses. Point Claude Code at OpenRouter, or any gateway, and you lose remote control altogether. Through GPR the phone still works, because GPR never needed Anthropic's relay in the first place.

gpr discover

ready means you're fine. needs adapter means the CLI is there but the adapter isn't next to gpr. not installed means claude isn't on your PATH. Then pick Claude Code in the workspace settings in the app.

Giving Claude a task

Make a task on the board, label a GitHub issue gpr:agent, or mention @gpr in Slack. The daemon makes a worktree under ~/.gpr/worktrees/ so your own checkout isn't touched, runs plan, implement and verify, and opens a PR.

If Claude has a question while planning, the task goes to "Needs your input", the phone buzzes, you answer in a sentence, and it carries on from the checkpoint. One question beats a PR built on a wrong guess.

"Fix the avatar bug" gets you an interpretation. "Settings crashes when avatarUrl is null; show initials; add a widget test" gets you something you can merge. Writing the task is where the actual design happens, which is most of the argument in AI can run the software factory. It can't turn the lights off yet.

Rough edges

Logins expire. When Claude's login runs out, the agent fails to start and GPR marks the task failed and says why. Someone still has to go to the machine and log in. We can't fix that from a phone and aren't sure we should.

Idle sessions get parked. Long Claude sessions sit idle a lot, so after three hours with no activity GPR stops the Claude process to free memory and the next message starts it again.

The machine has to be on. Both tools need it. A phone doesn't change that. That's the point of keeping the agent local, and why some of us pair a second machine.

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, run the installer above, and send Claude something small you've been putting off.

Keep reading

New here? The launch post, Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest would give a glimpse of what we are up against. Its the why we ditched cloud AI agents.

AI can run the software factory. It can't turn the lights off yet

Hari N — Sun, 04 Oct 2026 08:23:00 +0000

In 2018 Elon Musk admitted that excessive automation on the Model 3 line had been a mistake, and added: "Humans are underrated." Software is now having the same argument.

In January Dan Shapiro wrote up five levels of AI coding. Level 5 is the dark software factory , "a place where humans are neither needed nor welcome." A couple of weeks later StrongDM described how their AI team works, and Simon Willison wrote it up. Their rules:

Code must not be written by humans. Code must not be reviewed by humans. If you haven't spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.

We build GetPullRequest with coding agents, every day, and have since May (the launch post has the backstory). Most weeks it does feel like a software factory. It has never been dark, and below are a couple of the reasons why, straight out of our commit history.

TL;DR: An AI software factory, where agents do most of the work from ticket to pull request, is real, and we run one. The dark version, where no human writes or reviews anything, breaks on something manufacturing never had to solve: every unit of software is a new design, and working out whether it's right is the hard part. Automate the line, keep people at the few stations where judgment happens, and let them get there without sitting at a desk.

Manufacturing repeats a design. Software makes a new one every time

Lights-out manufacturing is real. FANUC has a plant where robots build robots and can run for long stretches with nobody on the floor, and there are a lot of videos of Chinese "dark factories" going around.

It works because the part was designed once and gets made a million times. The spec is a drawing with tolerances. Did the bracket come out at 40.00 mm, plus or minus 0.05? A gauge tells you, every time, for almost nothing. The design work happened months earlier, in another building, with the lights on.

Software doesn't have the million-copies part. git clone is the entire production line. Every ticket is a new design, so a "dark software factory" really means automating design and the checking of design. That's the part real factories never automated.

What broke when nobody was looking

Here's what that looks like in practice. Every one of these comes straight from our own commit history.

The agent said "done". There was nothing in it.

When an agent finished a task without changing any code, GitHub refused to open a PR, because there was nothing to compare. We'd decided early on that this wasn't really an error, since the task had run and nothing had crashed. So GPR quietly skipped the PR step and moved the task to Done anyway.

What we saw on the board was a green task, a "PR opened" event in its timeline, and no PR. Every automated signal agreed it was a success. The agent had exited cleanly and written a confident summary, and no test failed because there was nothing new to test. An agent that never touched the repo looked exactly like one that had finished the job, unless a person went looking for the diff. The checker had the same blind spot as the worker. In August we flipped it: no commits now means the task failed.

One wrong character hid two bugs.

Tasks were timing out after 90 seconds and we couldn't see why. The log line meant to explain it came out as an empty template, because it used %q, a Go formatting code, inside Python. Python choked on it, the logger swallowed the error, and the one number we needed (had the agent replied at all?) never got printed.

Worse, a test had been failing on exactly this for a while, and we'd been writing it off as an environment problem. Once the log was fixed, the next bug showed up behind it: under the right timing the daemon could start two agents for one session , and the extra one became a ~300 MB process nothing would ever clean up. Production showed one session spawned twice within 2.2 seconds. Even after both fixes, the original timeout still wasn't explained. We'd only made the next one visible.

A pipeline that just wants CI green, with nobody reading logs, would have called that test flaky and rerun it. That's what we did too, until someone read the log.

StrongDM's answer to this kind of problem is smart. They keep scenarios , end-to-end user stories, outside the codebase like a holdout set so the agents can't game them, and they score "satisfaction" probabilistically rather than pass/fail. Right instinct. But someone writes the scenarios, and someone decides what satisfied means. That's review, moved upstream.

The digital twin doesn't know the world changed

StrongDM's other big idea is the Digital Twin Universe : behavioural clones of Okta, Jira, Slack and Google Docs, so agents can test at volumes the real APIs would rate-limit. Hitting real Slack in a loop is miserable, so we get it. Two of our worst integration bugs this year would have gone straight through one, though.

Jira changed under us.

In September Atlassian removed an old search endpoint and our Jira calls started coming back 410 Gone. A Jira twin built in August would have kept happily returning results. The fix was itself a Jira ticket, PET2-4, which GPR picked up and turned into PR #500, tests passing first try. So the factory part was fine. It needed someone to notice the 410 and write the ticket.

Slack ate our screenshots.

Slack delivers every @gpr mention twice , and the attached files are only on one of the copies. We were reading the other one, so the screenshots people attached to bug reports silently disappeared (more in the Slack post). Nobody puts that in a clone, because nobody knows about it until a real person's screenshot goes missing.

Our real environment wouldn't fit in a sandbox.

Before GPR we tried hosted sandboxes, with Daytona. Getting our backend, Flutter app, database and Go daemon to come up together in there was a project of its own, and we gave up (more in the pillar post). Then there's Windows, where connections went half-open without the daemon noticing and our pairing QR code printed as an empty box in Windows Terminal. No twin was going to tell us any of that.

As for the $1,000 a day: Simon called it "more of a business model exercise", and it isn't the real problem anyway. Spend that much with no reliable way to tell whether the output is right and you've bought a faster way to ship things nobody checked.

	Manufacturing dark factory	"Dark" software factory	What we run
Each unit is	A copy of one design	A new design	A new design
"Is it right?"	A gauge, cheap and certain	Agents grading agents	Agents first, then a person merges
When the world changes	Rarely	The twin doesn't know	Whoever's on the board notices

What our software factory looks like

It is a factory. Tickets come in from GitHub issues with a label, from Jira, from a Slack mention. A daemon on one of our machines picks each up, makes a git worktree, starts whichever agent suits it, runs plan, implement, verify, and opens a PR. 370 commits in our repo carry Co-authored-by: GPR, and the branch list is mostly gpr/task-tsk_…. The conversation minimap in the task screen was PR #318, which GPR opened against its own repo.

The lights are on at three stations. Somebody writes the task, which is where the design happens; a vague ticket gets you a confident, wrong PR. Somebody answers the agent when it stops to ask, which happens more than you'd think and is honestly the most useful thing it does. And somebody reads the diff and merges.

Most of what a person does at those stations is small. Answer "should I keep the old endpoint as a fallback?", approve a command, read a 40-line diff, merge. None of it needs a desk. That's basically the product: agents run on your machine, your phone buzzes when one needs you, and you review and merge from there. If you only ever drive one Claude session, Claude Code Remote Control does the phone part fine.

It's not frictionless. PR #502, worktree badges leaking into unrelated chat sessions, took four agent rounds. PR #490, inline comment gestures not registering on diffs, took five. Somebody looked at every round. That's a normal week.

Where we might be wrong

Models will get better at checking their own work, and holdout scenarios are a real step. For a CRUD service with great coverage and no third-party APIs, a mostly dark pipeline could probably work today. And if review really goes away, the phone half of our product matters a lot less. Worth saying, since we're the ones selling it.

Our bet is that the stations move and don't disappear. Fewer people typing, more people deciding what gets built and saying yes or no to what comes back.

Keep reading

Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest
We ditched cloud AI coding agents. Our laptops were faster, and already paid for
We merge pull requests from our phones. It's less reckless than it sounds
A Jira AI agent fixed our Jira integration
Devin AI alternatives: why pay for another AI engineer?
Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about

Try the lit version

GPR is free for projects, sessions, and the GitHub and Slack connections; you pay only for more workspaces or more tasks running at once. Get the app on Google Play (iOS app coming soon), then on a Mac, Linux or Windows machine with one coding agent installed:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app

Give it something small and boring first, then go do something else until your phone buzzes.

Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest

Hari N — Fri, 02 Oct 2026 17:03:00 +0000

The agents got good. Claude Code, Codex, Cursor and the rest can take a well-written ticket and produce a change you'd actually merge. What didn't change is everything around them. The agent lives in a terminal on your laptop. It stops to ask a question while you're in a meeting, and the question sits there for two hours. When it finishes, the PR waits until you're back at a desk.

We felt this every day, because we were building a product with four of these agents at once. GetPullRequest (GPR) is what we built to fix it, and we've built GPR with GPR since May. This post explains the gap we saw, where GPR fits, what it's bad at, and where we think this is going.

TL;DR: GPR runs the coding agent you already pay for, on the machine that already builds your project. Tasks come in from GitHub, GitLab, Jira or Slack, and a pull request comes back to your phone. It's free to start.

Two answers, both from the vendors

The industry has offered two answers to "my agent is stuck at my desk".

The first is to move the agent into the vendor's cloud. Devin, GitHub's Copilot coding agent, Codex cloud and Cursor's Cloud Agents all work this way. You hand over a ticket, a VM somewhere clones your repo, and a PR comes back. For a project that builds from a clean checkout in two minutes, that's great.

Ours doesn't. Our repo has a FastAPI backend, a Flutter app, a database and a Go daemon that all need to come up together. We tried hosted sandboxes first, with Daytona, and gave up for three reasons. Wiring all four pieces together inside a sandbox, and keeping them working as the code changed, was a project in itself. It cost money a small startup didn't want to spend while our own laptops sat idle half the day. And testing was slow : every check meant a checkout and a full build to recreate an environment that already existed, fully built, on the laptop in front of us. Hosted agents also usually mean another subscription, billed per task or at API prices, on top of the agent plans we already paid for.

The second answer is a remote for your own machine. Claude Code has Remote Control, and Codex now connects to the ChatGPT app. These keep the agent local, which we think is right. But each one is a remote for one vendor's agent, and it's built around a session you started yourself. Our work doesn't arrive that way. It arrives as a GitHub issue, a Jira ticket from someone in product, or a screenshot in Slack. It goes to whichever agent suits it, and it should end as a pull request, not a chat log.

"Work doesn't arrive as a chat session. It arrives as a GitHub issue, a Jira ticket from someone in product, or a screenshot in Slack."

The gap

Put those side by side and one combination is missing. Nothing ran the agent you already pay for, on the machine that already builds your project, fed by the tools where work actually gets asked for, and handed back a PR you could review from anywhere.

	Vendor cloud agents	Vendor remotes	GetPullRequest
Where the agent runs	Their VM	Your machine	Your machine
Which agent	Theirs	Theirs	Any ACP agent you already pay for
Where tasks come from	Their app, sometimes GitHub	A session you started	GitHub, GitLab, Jira, Slack, the app
What comes back	A PR	A chat	A PR you merge from your phone

That's GetPullRequest. A small daemon runs on your machine. It takes tasks from the board in our phone app, from GitHub issues labelled gpr:agent, from Jira, or from an @gpr mention in Slack. For each task it creates a git worktree, starts your agent, and runs plan, implement and verify. Then it opens a PR. Your phone shows the session live, buzzes when the agent has a question, and lets you read the diff and merge.

Two decisions that shaped everything

We don't ship our own agent. Developers already pay for one or two. Asking them to buy another before they can try GPR is friction, and it's paying twice for the same thing. We didn't know how to support every agent without writing an integration per agent. Then we watched Ben Brandt from Zed and people from JetBrains explain the Agent Client Protocol. ACP solves the editors-times-agents problem for IDEs, and we realised a phone could be just another client. GPR now runs Cursor, Claude Code, Codex, Kiro, OpenCode, Qwen, Cline and Copilot through it. The ACP post goes deeper.

The cloud only enriches. Everything core works with nothing connected: the board, the queue, the agent run, the diff and the merge check. The diff and merge check come from git on your machine, because that's where the agent's work actually is, including changes GitHub has never seen. GitHub, GitLab, Jira and Slack plug in as adapters behind ports, and they only add to what's there. When Atlassian removed an old search endpoint in September and our Jira calls started returning 410 Gone, agents kept working. Only new tickets stopped syncing. The fix was ticket PET2-4, which GPR picked up from Jira and turned into PR #500, with tests passing on the first attempt.

Built with itself

By the time of writing, the GPR code had about 450 commits. 370 of them are co-authored by GPR. Our branch list is full of gpr/task-tsk_… names, which is what GPR calls the branches it creates. The conversation minimap in the task screen was PR #318, opened by GPR against its own repo. When worktree badges started leaking into unrelated chat sessions, the fix was PR #502, and its squash shows four agent iterations before the change was right.

Building it this way also meant we hit every rough edge first. In August one machine had 52 cursor-agent processes running after six and a half minutes, about 300 MB each, because they raced on a config file and ignored SIGTERM. Windows sockets went half-open and the daemon never noticed. Agents finished turns with no commits and GPR marked them done. Each of those is fixed now, and most of the fixes were written by agents through GPR. The stories are spread across the posts in this series.

What it's not good at

A machine has to be on. If your laptop sleeps, its tasks wait until it wakes, so people who want agents working overnight end up pairing a desktop. The Android app is live, and iOS isn't in the App Store yet. The phone is good for answering a question, approving a command, reading a small diff and merging. It's not good for reviewing a big architectural change, and we don't pretend otherwise. If you only use one agent and want to poke at one session, Claude Code Remote Control or the ChatGPT app is simpler. But still its not smooth with other tools that you are operating with. You have to deal with lot of rough edges which GPR is designed to handle.

Where this is going

Our bet is that most engineering work will look like what our team already does. Engineers spend less time typing code and more time deciding what should be built, writing tasks an agent can finish, and reviewing what comes back. The code still gets built and tested where it always was, on machines the team controls. The agents become interchangeable, and you pick one per task the way you'd pick a library. Work arrives from wherever people already talk about it.

The useful product isn't another agent. It's the layer between where work is asked for and where it's done.

In that world, the useful product isn't another agent. It's the layer between where work is asked for and where it's done, and the thing in your pocket that lets you keep up with it. That's what we're building GetPullRequest into.

What's next on this blog

Over the next two weeks we'll publish the rest of this series. Each post takes one tool people already use and is honest about where it beats us:

Claude Code Remote Control is great. It's also not enough
Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about
Cursor background agents charge you twice for compute you already own
Codex CLI remote control: stop babysitting the terminal and let it ship PRs while you're out
Slack AI agents should open pull requests, not summarize threads
A Jira AI agent fixed our Jira integration
Devin AI alternatives: why pay for another AI engineer?

Try it

GPR is free for projects, sessions, and the GitHub and Slack connections. You pay only for more workspaces or more tasks running at once. Get the app on Google Play, (iOS app coming soon) then on a Mac, Linux or Windows machine with one coding agent installed:

curl -fsSL https://getpullrequest.com/install | bash
cd ~/code/your-repo
gpr setup # scan the QR code with the app
gpr discover # lists which agents are ready

Start with a small, boring task, something you'd normally put off, and see what's waiting for you when you get back.

DEV Community: GetPullRequest

The $10 server that runs Claude Code while you sleep

How much server does Claude Code need?

The prices, one by one

AWS, Azure and Google Cloud: what the hyperscalers charge

Lightsail, DigitalOcean and Vultr: the simpler clouds

Hetzner vs DigitalOcean vs AWS: the cheapest paid option

Is Oracle Cloud's free tier really free?

GitHub Codespaces

Your own machine

What it costs all in

Our take

What $30 a month gets you

How to install Claude Code on a VPS

Questions people ask

What's the best VPS for Claude Code?

What's the cheapest VPS for Claude Code?

How much RAM does Claude Code need?

Is Hetzner cheaper than AWS?

Hetzner vs DigitalOcean pricing?

Can I run Claude Code on a Raspberry Pi?

Does my Claude Code VPS need open ports?

Try it

Keep reading

Sources

OpenAI dots fall short on coding. Here's exactly where

What dots and GPR have in common

Where the agent runs

Which agent does the work

Who it's for

What it costs

Where dots fall short for developers

Where GPR falls short today

So which one should you use?

Try GPR

Keep reading

Ship code from your phone with the AI coding agents you already pay for

Claude Code remote control, Codex, Cursor background agents: why not just use those?

How a task actually runs

Why AI coding agents should run on your machine: faster, and already paid for

Everything works with nothing connected

Some weird issues we hit while building it

Agent Client Protocol: why we never built our own coding agent

What a phone is actually good for (the Claude Code mobile app question)

Still rough

Trying it

Related posts

Agent Client Protocol (ACP) is the most important AI coding standard nobody's talking about

The problem the Agent Client Protocol solves

How it works

Agent Client Protocol vs MCP

How we found it

What GPR does with ACP

Agent Client Protocol with Claude Code

What the protocol doesn't fix

Your keys stay where they are

Try it

Keep reading

Claude Code Remote Control is great. It's also not enough

Setting up Claude Code remote control

Claude Code remote control not working?

Where it stopped being enough for us

Running Claude Code through GPR

Giving Claude a task

Rough edges

Try it

Keep reading

AI can run the software factory. It can't turn the lights off yet

Manufacturing repeats a design. Software makes a new one every time

What broke when nobody was looking

The digital twin doesn't know the world changed

What our software factory looks like

Where we might be wrong

Keep reading

Try the lit version

Your AI coding agent is stuck in a terminal you have to babysit. So we built GetPullRequest

Two answers, both from the vendors

The gap

Two decisions that shaped everything

Built with itself