I Moved From Cursor to Paseo: Cloud-Class Agents on 100% Local Hardware

Cursor has cloud agents. I now run the same fire-and-forget workflow on my own hardware — via a Paseo daemon, with Qwen 3.8 served locally by llama.cpp. This post is being written that way too.

Why I left Cursor

I didn't leave Cursor because it's bad. I left because of a mismatch that's grown more annoying the more I use agentic coding: Cursor's agent story is built around their cloud. Fire off a background agent, it runs on a Cursor-managed VM, and you check back when it's done. That's genuinely useful — but it means my code, my prompts, and my model choices all flow through someone else's infrastructure.

I wanted the feature — throw an agent at something and walk away, review the result later — without handing over the hardware. I'd already written about running Qwen3.8-27B locally on an Intel Arc Pro B70 as the model backend. What I wanted was the orchestration on top that didn't force me into a vendor.

That's what Paseo is, and it's the reason I've moved over.

What Paseo actually is

Paseo is a local-first application built around a daemon that manages coding agents and terminals. You drive it from a phone, desktop, browser, or CLI. The shape of it: a daemon running on a machine — in my case a dedicated box — that owns your agent processes and streams their output in real time.

The part that maps to Cursor's "cloud agents" is that these agents are detached. You create one, give it a workspace and a prompt, and it runs. Crucially, the daemon owns the agents, not the client — so you can disconnect entirely and the work keeps going, because it was never running in your editor to begin with.

The key difference from Cursor: the daemon runs on my hardware. The "cloud" is my own box. Which brings me to the setup.

My setup: dedicated box, llama.cpp, direct connection

The current arrangement is deliberately simple:

• A dedicated machine runs the Paseo daemon alongside llama.cpp serving Qwen 3.8.
• At home, I connect directly to the daemon — no relay, no round-trip through anyone's infra. For 100% local, direct is the way.
• Tailscale covers me when I'm not at home, so the same daemon is reachable over the same address regardless of where I am.

So the topology is: local model, local orchestration, reachable from anywhere through Tailscale. Cursor gives you the "reachable from anywhere" bit by owning the middle. Paseo gives it to me by not owning it — the daemon is mine, the model is mine, and Tailscale is just a wire.

The model itself isn't the point of this post — I've covered tuning it separately. But the fact that the default backend is a model I run myself, on the same box as the daemon, is what makes the whole thing feel different from Cursor. No per-token cloud billing for the everyday agentic loop.

Fire it off, come back later

This is the workflow Cursor sold me on, and it's the one that stuck. The pattern:

1. Spin up an agent with a concrete task and a workspace.
2. Walk away. The agent runs detached; the daemon keeps it alive regardless of what my editor or my laptop is doing.
3. Come back when it's done. The agent reports in, I pick up the result.

For the kind of work I throw at these agents — a refactor, a focused investigation, "take this issue and produce a PR" — fire-and-forget is the right shape. It turns agent runs into asynchronous jobs I can batch and drain at my own pace, not synchronous sessions I have to babysit.

The mobile story is where Paseo wins (on Android)

This is the part I didn't expect, and the reason the phone workflow is actually pleasant now.

Cursor does have a mobile app — Cursor for iOS. But it's iOS only. There's no Android app yet (the docs say one is planned, with no date). On Android, you're stuck driving Cursor's agents through the website — functionally "add to home screen" and use the web UI.

Paseo ships a native Android app (and iOS, desktop, web, and CLI). So on the platform I actually use, I get a first-class app rather than a browser bookmark. I can launch sessions, watch them work in real time, review diffs, and steer things from my phone — the same way Cursor's iOS users can, but on Android.

That gap — Cursor on Android means the website, Paseo on Android means an app — is a bigger deal in practice than it sounds. The phone is where the "fire it off, come back later" loop lands. Cursor's cloud agents want you back in Cursor's ecosystem; Paseo's app puts the review on your lock screen without the web-browser middleman.

The model stack (briefly)

Since it keeps coming up, a quick word on models, mostly for context: the default backend is Qwen 3.8 local. When I want a different mind on something, I hop to Ollama Cloud for DeepSeek V4 Flash, GLM 5.2, and sometimes Kimi K3.

The reason this matters for the Paseo setup is flexibility: because the orchestration is decoupled from the model provider, I can point an agent at a local model or a cloud one without changing my workflow. The daemon doesn't care where the tokens come from. That's the same decoupling that lets me run everything local when I want it, and reach for a cloud model when the job calls for it.

And yes — the recursion is real. This blog post itself is being written using the grilling skill from Matt Pocock on DeepSeek V4 Flash, with me steering. The tool I'm describing is the tool I'm using to describe it.

What's missing / gotchas

No setup like this is friction-free. A few honest notes:

• It's more moving parts than Cursor. A daemon, a model server, a tailnet — that's three things that can break instead of one vendor that hides the complexity. The tradeoff is worth it to me, but it's a real cost.
• The dedicated machine is the enabler. This setup quietly depends on having a box that can sit there serving. That's not a given for everyone, and it's the biggest reason "local cloud agents" isn't for everyone yet.
• Fire-and-forget needs good prompts. Detached agents are great until one runs off happily in the wrong direction for twenty minutes. The async shape rewards being concrete about what "done" means up front.
• Cursor still wins on raw agent capability. It's fair to say Cursor's cloud agents run in full sandboxed dev environments with browser verification, screenshots, and video demos attached to PRs. Paseo runs the same coding agents you'd run locally (Claude Code, Codex, Copilot, and plenty more) — which is a different, arguably simpler model, but not the same "agent does everything and demos it" experience.

Why this is the point

Cursor's cloud agents are convenient because someone else runs the machinery. Paseo's version is appealing for the opposite reason: cloud-class orchestration with local hardware underneath. I get the fire-and-forget, the review-from-my-phone — with a native Android app that Cursor doesn't offer on my platform — and the code and the model stay on my box.

That combination — Cursor's workflow, my hardware — is the whole reason I moved. And the fact that this very post was drafted by an agent running on that setup, steered by me, is the shortest proof I can offer that it works.