Why I run my coding agents on my own machine (and you probably should too)

Cloud agents are convenient, but moving execution back to your own machine keeps your code local, your environment intact, and your subscriptions unchanged. Here's the case for local-first AI development with Delego.

There's a version of AI-assisted development that's quietly taking over: you file a ticket, an agent somewhere in a data center picks it up, and a pull request shows up later. It works. It's also a little strange to hand your code, your environment, and your provider account to a black box you don't control.

Delego takes the same idea and moves the work back to where it belongs: your machine. You delegate a Linear issue, a runner on your own laptop (or an old desktop, or a VPS) picks it up, runs Claude Code or Codex exactly the way you'd run it by hand, and opens a PR. Same convenience. None of the parts that make me nervous about the cloud version.

If you lead a team, this distinction matters more than it first appears. Here's the case for keeping execution local.

Your machine, your code, your subscription

The core idea is simple. The Delego runner is a thin orchestrator. When a job comes in, it shells out to the regular claude or codex CLI already installed on the machine, using the session you're already logged into. The repo gets checked out locally and stays there. The model runs against your existing subscription. Yes, the agent has to show the model parts of your code to do anything with it, which is the same API traffic you'd send running the CLI by hand, but the repo itself never gets cloned, stored, or executed on the vendor's infrastructure.

For a team, that's a real distinction, not a nice-to-have. If you work on a private codebase, "where does the source get checked out, stored, and run while the agent works on it" is a question security and legal will eventually ask. With a cloud agent the answer is "cloned and executed on the vendor's infrastructure, under their terms." With Delego the answer is "it stays on the same machine your developer already uses, and only what you'd already send by hand goes to the model." That's a much shorter conversation.

You also keep paying for exactly what you already pay for. No separate cloud-execution fees layered on top of your Claude or Codex plan, no metered compute, no surprise line item at the end of the month. The runner is free. The agent is the subscription you already bought.

You control the environment, completely

This is the part I'd underline for anyone running a non-trivial project. Cloud agents run in a sandbox the vendor built. That sandbox can't reach your private package registry, can't use your local SSH keys, and can't talk to the database or service running on your internal network. For a toy repo, fine. For real work, those limits show up fast.

A Delego runner inherits your whole shell environment. If a command works in your terminal, it works through Delego. Need the agent to run against a Postgres instance in Docker? Spin it up. Need a specific Node version, a private registry token, a seeded test database, a particular set of env vars? It's all just there, because it's your machine. You're not asking a vendor to support your setup. You already have your setup.

You also pick the model per job, not per platform. Some cloud agents decide the model for you. With Delego the model is a Linear label. Run opus on the gnarly refactor, sonnet on the quick fix, switch executor to Codex on the next ticket if that suits it better. No config change, no redeploy. Just a different label on the issue.

It's just your CLI, so there's nothing to get flagged

Here's a worry I hear from teams considering any agent platform: could running our work through a third party get our Claude or Codex account suspended for unusual activity?

With Delego, no, and the reason is structural rather than a promise. The runner doesn't share API keys, doesn't proxy your traffic, doesn't relay model calls through some intermediary. It runs the same CLI you run by hand, in your own authenticated session. From the provider's side there's nothing to distinguish a Delego job from you typing the command yourself, because that's literally what's happening.

The rule of thumb: if you're comfortable running Claude Code or Codex locally for your own work, you're comfortable running them through Delego. Nothing about the trust model changes.

You never leave Linear

Most agent tools want to become the place you live. A new dashboard, a new inbox, a new task format your team has to learn. I've watched perfectly good tools die because nobody wanted to babysit yet another tab.

Delego doesn't do that. You delegate an issue the same way you'd assign it to a teammate: open the ticket, add a label. A runner picks it up, works in an isolated git worktree so your current branch and uncommitted changes stay untouched, and reports progress straight back into the Linear issue. When it's done, the PR shows up and the final report lands as a comment. You watched the whole thing happen in the issue you already had open.

It's no accident that Delego is built on Linear, and that's a good thing. Linear already solved the tedious parts of issue tracking: search, projects, cycles, triage, keyboard-first navigation, mobile. Your team doesn't learn anything new to delegate work to an agent. And because issues already carry context (linked docs, related tickets, comments, attachments), the agent inherits all of it automatically when it picks up the ticket. You don't re-explain the problem in a separate system, and the record of what the agent did stays attached to the issue forever, searchable next to everything else.

It's free to start, too. Linear's free tier covers up to 250 active issues, which is plenty to trial Delego on a real project before anyone signs a purchase order.

Many runners, many jobs at once

A single developer with one agent is useful. A team running several in parallel is a different kind of leverage.

You can pair multiple runners to one Delego account: on the same machine, across several machines, whatever you've got. They all pull from the same job queue at the same time. That old Mac mini in the corner and a cheap Linux VPS can both be runners. Three tickets get delegated, three runners claim them, three PRs come back. The more runners you pair, the more work runs concurrently, and none of it is gated behind a vendor's cloud capacity or queue.

For a team, this is the bit that scales. Your throughput is bounded by hardware you already own and subscriptions you already pay for, not by what a cloud platform decides to allocate you this week.

What one job actually looks like

It helps to walk through the loop once, because the whole thing is less abstract than it sounds.

Say there's a ticket: rate-limit some runner endpoints before they get hammered by unauthenticated traffic. A teammate writes it up in Linear with the usual context, then drops a label on it to delegate it. The label says which agent runs the job, which model, and which repo it works in.

The webhook fires. Delego queues the job, a free runner claims it, and on that machine the runner spins up a fresh git worktree off main so nothing in the developer's working directory gets touched. A Claude Code session opens with the model the label asked for. From there it's ordinary agent work: read the relevant files, edit the middleware, run the test suite, commit when the tests pass.

The whole time, progress streams back into the Linear issue and the Delego dashboard. You can see the worktree get created, the session open, files get touched, tests go green. When it finishes, it pushes the branch, opens a pull request with a written description, and posts the PR link back onto the issue. If you've connected Linear to GitHub, that PR shows up attached to the ticket with its status checks, so you review it without leaving Linear at all.

Total human effort: write the ticket, add a label, review the PR. Everything in between ran on a machine you control.

What it takes to try it

The setup is modest. You need a machine that runs Node 20 or newer, a Claude Code or Codex install you're already signed into, the GitHub CLI authenticated, and Git. Connect Linear (a one-time OAuth setup, about five minutes), create a few labels so Delego knows which agent, model, and repo to use, and pair a runner. Then delegate your first issue and go do something else.

So, is it worth it?

If you're already living in Linear and already running Claude Code or Codex, Delego mostly removes friction without asking you to give anything up. You keep your environment, your data, your subscriptions, your model choices, and your account standing. You add the ability to hand a ticket to an agent and walk away.

The cloud agents are genuinely convenient, and for throwaway work the trade-offs might not bother you. But the moment your code is private, your environment is non-trivial, or you're answering to someone about where the source goes and what it costs, "it runs on our own machines, the same way our developers already run it" is a hard answer to argue with. That's the whole pitch, and it's a good one.