Background coding agents: what to send to the cloud and what to keep local

Sunday evening, phone in hand, you assign three issues to a background agent in the cloud and put the phone down. By breakfast there are three pull requests waiting. It feels like discovering a night shift you never had to hire.

Monday tells the rest of the story. One PR is exactly right. One solved the wrong problem, because the issue was two lines long and the agent filled the gaps by guessing. The third died forty minutes in on a private package the sandbox could not fetch: a failure anyone at a terminal would have fixed with one line, discovered only when you opened the logs.

None of that makes background agents overhyped. It makes them a tool with a shape. The useful question is not "cloud or local?" as a loyalty test. It is: which work belongs where?

What background coding agents actually are

A background agent runs where you are not. Services like OpenAI's Codex cloud and Anthropic's Claude Code on the web spin up a sandboxed environment, clone your repository, and let the agent work unattended: no terminal open, no laptop awake. When it finishes, you get a diff or a pull request, and you were free the entire time.

The key property: you trade steering for parallelism. Ten tasks can run at once, and none of them can interrupt you. Which also means none of them can ask you anything. Every ambiguity gets resolved by the model, alone, and you meet the consequences at review time.

What the cloud sandbox is genuinely good at

Credit where due, because some of this is hard to replicate on a desk:

• Fan-out on small, mechanical work. Ten scoped chores, ten sandboxes, zero contention. Nothing on your machine competes for CPU or attention.
• Machine independence. Kicked off from a phone between meetings, still running with the laptop closed. The work stops depending on your hardware being awake.
• Isolation as a guardrail. The agent cannot touch your shell, your files, or your credentials. For work you barely trust, distance is a feature.
• A clean room every run. No leftover state from the last job, no half-applied experiment polluting the next one.

The real costs of unattended work

The honest section, because the bill arrives in specific ways:

• The sandbox is not your machine. Secrets, running databases, private registries, seeded data, a logged-in browser: everything your local setup provides without being asked has to be declared up front. Tasks that need any of it fail early and report late.
• Feedback arrives at the end. A local session can be interrupted the moment it takes a wrong turn. A background run resolves every open question silently, which makes the quality of your brief the single biggest predictor of whether the PR is worth opening.
• Review lands in batches. Fan out ten tasks tonight and the payment is ten unfamiliar diffs tomorrow. Reviewing agent work is already the bottleneck in most agent workflows; batching it does not remove the cost, it schedules it.
• Corrections cost a full round trip. Locally, a course correction is one sentence typed into a live session. In the background, it is a new brief, a fresh clone, and another complete run.

A routing rule that holds up

If a task needs your judgment mid-flight, keep it local. If it only needs your judgment at the end, it can run in the background.

Good background candidates share a profile: mechanical, self-contained, and verifiable by CI without you. Dependency bumps. Filling test gaps. Lint and formatting sweeps. Documentation updates. A scoped bug fix with a reproduction attached.

Keep local the work that is exploratory or ambiguous, anything touching schema or infrastructure, tasks that need your real environment, and anything where you would glance at the terminal every few minutes anyway. That instinct to watch is information: it is telling you the task has open questions.

Local does not mean serial, either. You can run several sessions side by side and give each its own git worktree, which buys you the fan-out without giving up the steering wheel.

The queue is the real magic, and local deserves one too

Strip away the novelty and what makes cloud agents feel so effortless is not the data center. It is the workflow shape: tasks go into a queue, results come back to a review pile, and dispatching work takes one tap. Most local setups have none of that. They have terminal tabs.

SanuDesk gives the local half of your split that same shape. It is a desktop app that tiles your Claude Code, Codex and Gemini sessions into one grid, next to a Kanban board that does the dispatching: write the task as a card, deploy it to a fresh session with one click, and when the agent stops, the card parks itself in a review lane with a "what changed, how to test it" note. Loops handle the recurring chores on a schedule, with one advantage a sandbox cannot offer: they run with your real environment, so the job that needs your database or your dotfiles just works. It is bring-your-own-model, driving the agent subscriptions you already pay for, and the grid and board are in the free plan (details on pricing).

Background agents and a local grid are not rivals. They are the two halves of the routing rule, and the board is where the local half stays honest.

Try this today

Write down the next five tasks you plan to hand to an agent. Mark each one B or L using the mid-flight rule: does this need my judgment during the work, or only after it? Send one B task to a background agent tonight. Put two L tasks on a board tomorrow and run them side by side locally. At the end of the week, look at where your review time actually went. Most people find the split becomes obvious after one honest pass, and that both halves get better when neither is asked to do the other's job.

Download SanuDesk free to give the local half a grid and a queue, or see how the board, grid and Loops fit together on the features page.