Why are you still using local coding agents?
byโข
We launched Hoplite today - it's a passion project driven by our love for dev tools (especially ones that feel incredible to use, like Linear).
In simple terms, Hoplite allows you to 'effortlessly' use cloud coding agents. We port over your local sessions/memories/MCP servers, so you can just pick up right from where you left off, but now you can close your laptop lid!
One of the things we're most curious about is why people are still using local agents like OpenCode or Claude Code. Is it stickiness? Lack of good cloud solutions? Cost? Or something else? Would love to know!
( p.s, we have a super ultra rare promotion running right now, so you can try out the full platform for free ๐)
132 views
Replies
WebCurate.co
In my opinion, itโs mostly about workflow and control. Local agents are already deeply integrated with the repo, terminal, files, and existing MCP setup, so switching to cloud isnโt just about getting the agent off your laptop.
BTW, congrats on your launch!!! Share the link to your page and I'll support you! ๐
Hoplite
@hosseinyazdiย What if everything on your laptop could be ported over to the cloud - like auth state and CLIs and whatnot. Would you shift over then? (this probably isn't 100% technically feasible though)
And thank you!! Here's the link: https://www.producthunt.com/p/hoplite
Hoplite
Personally I use cloud agents for almost everything. But there are a couple times where I'll need to boot up Claude Code locally (e.g. for clearing up disk space and editing local documents) - however this feels like missing tooling on our (Hoplite's) part that should enable this type of workflow.
YourSitee
I think local agents still win mostly because they're already there, they understand the environment I'm working in, and there's almost zero friction to starting a session. But the moment a task becomes long-running or I want several agents working in parallel, the cloud starts making much more sense, especially if Hoplite can preserve the same sessions, tools, and MCP setup without making me reconfigure everything. Feels like the real unlock is making moving between local and cloud feel invisible rather than forcing developers to choose one forever :)
Hoplite
@andrasczeizelย That makes a ton of sense! We're actually launching a desktop app very soon, and one of the features we're adding is seamless hand-off. So you can just say 'switch this over to a cloud agent', and it'll do it without any hassle. (plus some cool stuff around automatically doing the hand-off when the computer's lid gets closed/it shuts off)
YourSitee
@benceredย Okay, then you're basically building the exact thing I was describing :))
The automatic hand-off when the lid closes sounds especially smart - if local and cloud can really become one continuous session instead of two separate workflows, I can definitely see myself using that.
Hoplite
@andrasczeizelย Awesome!! Will let you know when it's out ๐
The hand-off story is compelling, but the reason I still keep a lot of work local is control over context boundaries. Local runs let me inspect exactly which files, secrets, and tools are in scope, keep latency predictable, and avoid the "works in cloud, breaks on my machine" drift. If cloud hand-off can preserve that determinism and make approval plus secret exposure obvious at the transfer point, the local-vs-cloud split starts to disappear.
Hoplite
@getosmoย With Hoplite we do all that! Our environments can be really specifically tailored to your exact local set up, so (almost) everything can be replicated in the VMs. Latency is also often times lower since our sandboxes are very close to the model provider's servers.
I think the reason local persists is execution parity more than stickiness. My real Mac already has repo state, Xcode/SDKs, Keychain, SSH agents, simulators, local DBs, network access, weird CLIs, etc. A cloud VM can reproduce packages; reproducing the same capability graph and failure modes is harder.
Iโve actually been experimenting with the opposite direction: keep the reasoning UI remote (normal ChatGPT) but let it execute on the Mac via MCP. That made me realize the handoff UX should probably show an explicit diff: what state/tools/credentials/local services survived the move, what became unavailable, and what authority widened or narrowed.
If Hoplite can make that diff legibleโand let you hand the same task back local when it needs the physical machineโIโd stop thinking of local/cloud as competing modes.