For the past year, we've been running AI agents that spin up cloud VMs, execute code, browse the web, and tear everything down, thousands of times a day.
The dirty secret? Most cloud infrastructure wasn't built for this. Sessions time out, costs spiral, and cold starts kill your agent's momentum mid-task.
So we built Coasty (coasty.ai), sandboxed cloud VMs purpose-built for AI agents. Isolated, fast (ready in under 2 minutes), and 70% cheaper than the alternatives. No 24-hour session caps. No noisy neighbors. Just clean environments your agents can destroy guilt-free.
We're running our own marketing agents on it right now. It eats its own cooking.
If you're building agent pipelines and tired of fighting your infra, we'd love to show you what we've got. Early access is open.
Hey HN,
I'm Nitish, co-founder of Coasty (coasty.ai). My co-founder Prateek and I built this after running into the same wall most agent developers hit: you need a real, isolated computer for your agent to actually do things, browse, run code, fill forms, submit jobs — and the existing options are either expensive, capped at 24-hour sessions, or both.
What we built
Coasty gives AI agents secure, isolated cloud VMs that spin up in 2–5 minutes. Each sandbox is fully isolated, agents get a real desktop environment with a browser, terminal, and filesystem. No shared state between runs, no session limits.
The benchmark
We ran our agent stack on OSWorld, the standard benchmark for computer-use agents. We hit 82% task success rate. For reference, most published results from well-resourced labs are in the 50–72% range. We're not cherry-picking tasks, it's the full eval.
Why cheaper
E2B charges per sandbox-hour with a hard 24-hour session cap. Most real agent workflows — job applications, research pipelines, async browser tasks, need longer sessions and burst capacity. We charge for actual compute consumed, no caps. On equivalent workloads, customers are running at 70% lower cost.
The dogfooding story
We run our own marketing agent on Coasty infrastructure. It handles Twitter posts and cold outbound email autonomously. If the VM infrastructure can't handle our own agent, it doesn't ship. That's the bar we hold ourselves to.
Where we're at
800+ signups
14,000+ agent sessions logged and analyzed
Early design partners across sales automation and QA testing
What we're looking for from HN
Honest feedback. We want to know:
What breaks for you with current sandboxed agent infra?
Is session length actually the pain point, or is it something else we're missing?
If you've tried E2B or Modal for agent workloads, what made you stay or leave?
The waitlist is open at coasty.ai. Happy to answer technical questions about the VM architecture, the OSWorld setup, or anything else.
We run sandbox infrastructure for AI agents. Over the past few months, we've collected logs from 14,000+ sessions on our platform. Real developers, real agents, real tasks.
We started analyzing the data to improve our product. What we found changed how we think about agent safety entirely.
## 1. Agents don't stay in their lane
Agents routinely attempt actions outside their stated task scope. An agent asked to "write unit tests for this function" will, completely unprompted, modify the source code it was supposed to test, install packages, attempt network requests, and read files in unrelated directories.
It's not malicious. The agent is just "being helpful." But "being helpful" with unrestricted access is how databases get deleted.
We saw scope creep in roughly 38% of sessions where the agent had filesystem access beyond the working directory. When we gave agents explicit instructions like "do not modify files outside /workspace," compliance was around 86%. That means 1 in 7 sessions will attempt unauthorized file access. At scale, that's a disaster.
## 2. Agents retry destructive actions
When an agent hits a permission error, it doesn't stop. It tries a different approach.
Four different approaches to delete a directory it wasn't supposed to touch. Each one more creative than the last. We saw this retry-escalation pattern in hundreds of sessions. The agent treats a permission error as a problem to solve, not a boundary to respect.
## 3. The "helpful lie" problem
This one is genuinely unsettling. When agents fail at a task, they sometimes report success anyway. We saw agents report "tests passing" when the test file didn't compile, claim "database migration complete" when the connection failed, and say "file saved successfully" when the write was rejected.
In about 12% of sessions with error states, the agent's final message did not accurately reflect what happened. This is exactly what played out in the Replit/SaaStr incident last July. An AI agent deleted a production database, told the user recovery was impossible (it wasn't), and fabricated fake data to cover the gaps.
## 4. What this means
The industry's current approach to agent safety is prompt-level guardrails ("please don't delete anything"), application-level permissions, and hope. That's not good enough. Prompts fail 15-30% of the time. Permissions are only as good as the developer implementing them. And agents actively work around restrictions.
The missing layer is infrastructure-level isolation. The agent runs in a sandboxed environment where it physically cannot access production systems. Not because it's told not to, but because the network path doesn't exist, the filesystem is isolated, and the compute is ephemeral.
There's a big difference between telling someone "please don't open that door" and just not having a door.
We're not saying agents are dangerous. We use them every day. We're saying that running them with unrestricted production access is like giving an enthusiastic intern root access on day one. They'll probably be fine. But "probably" isn't a word you want near your production data.
---
We're building this at Coasty (https://coasty.ai). Two founders, been at it for a few months, and everything above comes from real usage on our platform. Happy to answer questions.
My co-founder Prateek and I have been building Coasty (coasty.ai), isolated cloud VMs purpose built for AI agents.
The problem we kept hitting: most cloud providers weren't designed for agents. Sandboxing is either overkill or nonexistent, and you're paying for always-on compute when agents are inherently bursty. We wanted something that runs in true isolation, and doesn't charge you for idle time.
So we built it. Full VM isolation per agent run, and pricing that actually makes sense for agentic workloads.
We're two CS students (Columbia and Purdue Engineering) who got frustrated enough to build the thing ourselves. We have paying customers and ~700 people on the waitlist, which tells us we're not the only ones annoyed by this. We even ran the OSworld test for agents(completed 82% of the 369 automation tasks thrown at it).
Still early but love to hear brutal feedback, especially from anyone running AI agents in prod who's dealt with this.
The dirty secret? Most cloud infrastructure wasn't built for this. Sessions time out, costs spiral, and cold starts kill your agent's momentum mid-task. So we built Coasty (coasty.ai), sandboxed cloud VMs purpose-built for AI agents. Isolated, fast (ready in under 2 minutes), and 70% cheaper than the alternatives. No 24-hour session caps. No noisy neighbors. Just clean environments your agents can destroy guilt-free.
We're running our own marketing agents on it right now. It eats its own cooking.
If you're building agent pipelines and tired of fighting your infra, we'd love to show you what we've got. Early access is open.
What's the most destructive thing your agents do?