Show HN: Cloud VMs with a Built-In REST API for AI Agents(oblien.com)
oblien.com
Show HN: Cloud VMs with a Built-In REST API for AI Agents
https://oblien.com/docs/runtime-api
3 comments
Let's see, this is a great project, but the sandboxed virtual machine approach makes sense. I've had Claude Code destroy a configuration file on my local machine more than once, so running it remotely is actually smart, but I'm not sure.
However, when creating MCP tools, I've noticed that the processing isn't really what's expensive. It's when the agent gets stuck in a loop. For example, I note writes faulty code, executes it, detects the error, tries to "fix" it, makes it worse, rinses it, and repeats it 5 to 10 times. This quickly consumes the context window, regardless of where the code is running.
I'm curious: Does Oblien detect when an agent is simply wasting time? Or is that left to the agent framework? Because, I mean, sometimes I look for that solution and there isn't one :(
However, when creating MCP tools, I've noticed that the processing isn't really what's expensive. It's when the agent gets stuck in a loop. For example, I note writes faulty code, executes it, detects the error, tries to "fix" it, makes it worse, rinses it, and repeats it 5 to 10 times. This quickly consumes the context window, regardless of where the code is running.
I'm curious: Does Oblien detect when an agent is simply wasting time? Or is that left to the agent framework? Because, I mean, sometimes I look for that solution and there isn't one :(
You hit on the exact "infinite loop of doom" that plagues every agent developer right now.
The short answer is: No, Oblien does not detect when an agent is wasting time. We leave that entirely to the agent framework.
Oblien is strictly the infrastructure layer. We don't inspect the semantic meaning of the commands the LLM is running, nor do we analyze the context window.
However, what Oblien does provide are the infrastructure-level circuit breakers so the framework can build that logic easily:
1. Hard Timeouts: When the framework calls our POST /exec endpoint, it can pass a timeout_seconds parameter. If the agent writes a script that accidentally infinite-loops the CPU, the runtime kills it at the OS level automatically. 2. Resource Isolation: Because it's a microVM, a runaway process won't lock up your host machine or bleed into other workspaces.
Detecting the logical loop (the "I wrote bad code, let me try again" cycle) is definitely the holy grail for frameworks right now. But our goal with Oblien is just to ensure that when the agent does inevitably hallucinate and run rm -rf or spin up a fork bomb
The short answer is: No, Oblien does not detect when an agent is wasting time. We leave that entirely to the agent framework.
Oblien is strictly the infrastructure layer. We don't inspect the semantic meaning of the commands the LLM is running, nor do we analyze the context window.
However, what Oblien does provide are the infrastructure-level circuit breakers so the framework can build that logic easily:
1. Hard Timeouts: When the framework calls our POST /exec endpoint, it can pass a timeout_seconds parameter. If the agent writes a script that accidentally infinite-loops the CPU, the runtime kills it at the OS level automatically. 2. Resource Isolation: Because it's a microVM, a runaway process won't lock up your host machine or bleed into other workspaces.
Detecting the logical loop (the "I wrote bad code, let me try again" cycle) is definitely the holy grail for frameworks right now. But our goal with Oblien is just to ensure that when the agent does inevitably hallucinate and run rm -rf or spin up a fork bomb
Loop detection is the harder problem and almost nobody solves it well at the infra layer. The pattern you're describing — write, fail, "fix," regress — is fundamentally a semantic loop, not a mechanical one. You can't catch it by diffing outputs or counting retries because each iteration looks superficially different. The agent thinks it's making progress.
What actually works in my experience: budget the agent a rolling token window per subtask, not per session. If it burns 40% of its context on a single function without a passing test, force an early return with the error context and let the orchestrator decide whether to retry with a different prompt or bail. Putting that logic in the VM host is tempting but wrong — the host doesn't have the semantic context to know "stuck" from "legitimately hard." That belongs in the agent framework or a thin supervisor shim between the framework and the execution environment.
What actually works in my experience: budget the agent a rolling token window per subtask, not per session. If it burns 40% of its context on a single function without a passing test, force an early return with the error context and let the orchestrator decide whether to retry with a different prompt or bail. Putting that logic in the VM host is tempting but wrong — the host doesn't have the semantic context to know "stuck" from "legitimately hard." That belongs in the agent framework or a thin supervisor shim between the framework and the execution environment.
If you’re building local AI agents (or using tools like Cursor/Claude Code), giving them a place to safely execute code and manipulate files is a headache. Running untrusted LLM-generated code directly on your machine or local Docker is risky, and managing remote SSH keys for an automated agent is clunky.
I built Oblien to solve this. It provides instant, hardware-isolated cloud VMs, but the actual interesting part is how you interact with them: the Runtime API.
Every workspace runs an internal HTTP/WebSocket server on port 9990. Instead of establishing an SSH connection, your local agent just makes standard API calls to control the remote machine securely.
It exposes everything an agent needs to do real work:
• Command Execution: Run POST /exec to execute bash commands. It supports synchronous runs, or you can stream stdout/stderr in real-time via SSE for long-running tasks. • Files & Search: A full file API to list, read, and write files. It also has a native /search endpoint powered by ripgrep, so agents can find code without pulling the whole repo locally. • WebSockets & Terminals: You can open interactive PTY sessions multiplexed over a single WebSocket connection. It even supports streaming filesystem events (create/write/delete) to watch directories.
How local agents connect securely: The workspaces are network-dark by default—outbound internet is on, but inbound is completely blocked.
To let your local agent in, you hit the Oblien API to get a short-lived Gateway JWT. The agent uses this token as a Bearer auth header against workspace.oblien.com. Our gateway decodes the routing info from the JWT and securely tunnels the HTTP request through the firewall directly to the VM's internal server.
It makes orchestrating remote compute feel like using a standard web API.
For example, to run a command inside the remote VM, your agent just does this: curl -X POST "https://workspace.oblien.com/exec" \ -H "Authorization: Bearer $GATEWAY_JWT" \ -d '{"cmd": ["npm", "install"]}' Docs and API reference: https://oblien.com/docs
Would love to hear what you think of the API design, or if there are specific endpoints you'd want added for your own agent workflows.
also You can use it like Vercel—spin up a VM, add workload, expose a port, and attach a custom domain for instant preview URLs. But unlike serverless platforms, you aren't restricted. Because every workspace has an injected Runtime API (port 9990), you can programmatically execute commands, edit files, and multiplex terminals over WebSockets right from your local machine or CI pipeline. You get the hosting of a PaaS, but the low-level control of a raw Linux VM